Error: A timeout has been exceeded.

[Ether]

Originally Posted by rod@3711

back in our shop, we made the most simple C++ robot builder system with a 4 motor chassis and that is all. When we build and deploy, it also gives the 117-timeout message every 1 second

What kind of computer are you using for the DS?

Have you tried shutting down background tasks that may be interfering with the DS software realtime operation?

[rod@3711]

One is a toshiba tecra r850, intel I7 cpu, running windows 7, 32 bit.

The other is a Samsung ????, windows 7, 64 bit.

My tests with this simple command-based program was run with Eclipse, DS and Labview Dashboard running. Not confident on how I could stop other services.

[Ether]

Originally Posted by rod@3711

One is a toshiba tecra r850, intel I7 cpu, running windows 7, 32 bit.

The other is a Samsung ????, windows 7, 64 bit.

Have you tried running the robot with each of those computers as DS? Do you get the exact same problem with each one?

[GeeTwo]

This may not help the other issues, but on the error message:

If you're getting the same message every second, then it appears that you are never setting the motor speed, at least not in a way that the MotorSafetyHelper understands.

Are you perhaps bypassing the MotorSafetyHelper class and setting the speeds of the motors directly?

[rod@3711]

Yes. I deployed the simple command based program from my toshiba and got the 117-timeout error every second. Then I disconnect toshiba from router, then connected Samsung to router, then started DS. Same error.

[rod@3711]

the most simple C++ robot builder system with a 4 motor chassis" does not even try to run the motors. It is basically a chassis.cpp subsystem that does nothing and the following Robotmap.cpp (all generated by Robot Builder)

// RobotBuilder Version: 1.5
//
// This file was generated by RobotBuilder. It contains sections of
// code that are automatically generated and assigned by robotbuilder.
// These sections will be updated in the future when you export to
// C++ from RobotBuilder. Do not put any code or make any change in
// the blocks indicating autogenerated code or it will be lost on an
// update. Deleting the comments indicating the section will prevent
// it from being updated in the future.


#include "RobotMap.h"
#include "LiveWindow/LiveWindow.h"


// BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=ALLOCATION
SpeedController* RobotMap::chassisSpeedController1 = NULL;
SpeedController* RobotMap::chassisSpeedController2 = NULL;
SpeedController* RobotMap::chassisSpeedController3 = NULL;
SpeedController* RobotMap::chassisSpeedController4 = NULL;
RobotDrive* RobotMap::chassisRobotDrive41 = NULL;
// END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=ALLOCATION

void RobotMap::init() {
// BEGIN AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=CONSTRUCTORS
LiveWindow* lw = LiveWindow::GetInstance();

chassisSpeedController1 = new Talon(0);
lw->AddActuator("Chassis", "Speed Controller 1", (Talon*) chassisSpeedController1);

chassisSpeedController2 = new Talon(1);
lw->AddActuator("Chassis", "Speed Controller 2", (Talon*) chassisSpeedController2);

chassisSpeedController3 = new Talon(2);
lw->AddActuator("Chassis", "Speed Controller 3", (Talon*) chassisSpeedController3);

chassisSpeedController4 = new Talon(3);
lw->AddActuator("Chassis", "Speed Controller 4", (Talon*) chassisSpeedController4);

chassisRobotDrive41 = new RobotDrive(chassisSpeedController1, chassisSpeedController2,
chassisSpeedController3, chassisSpeedController4);

chassisRobotDrive41->SetSafetyEnabled(true);
chassisRobotDrive41->SetExpiration(0.1);
chassisRobotDrive41->SetSensitivity(0.5);
chassisRobotDrive41->SetMaxOutput(1.0);


// END AUTOGENERATED CODE, SOURCE=ROBOTBUILDER ID=CONSTRUCTORS
}

[ozrien]

There have been many threads on CD about motor safety tripping. The biggest culprit I've seen seems to be not "setting" motors in all loops (auton/disable/teleop) so when you transition it seems to cause the motor-safety to expire.

But even after making that change, my bot trips the motor-safety once in a while, so I ended up just turning it off.

Do you need the motor-safety features? Generally it is only helpful when source-level debugging/breaking-pointing. If you are just deploying code, there really is no advantage to it.

[rod@3711]

Thanx for your time. We have been ignoring the message, so by disabling motor safety, we won't see any messages. That may not change things, but may make us feel better.

[ozrien]

Wait... you're seeing MotorSafetyHelper errors and you're robot still functions as normal? That means that the motors that are being forcefully disabled are ones you are not actually using, (or you just didn't notice them not moving).

So... that suggests you have created at least one motor object in software, that you are not actually using (not updating it in your loops).

[rod@3711]

Our robot has 4 drive motors and one elevator motor. They all work as expected, even when the messages are displayed.

We are not the as experienced as we should be, so I assumed we screwed things up. But when I went back to Robot Builder and built a very simple 4 motor drive system with no operator inputs nor commands, I expected that the 117-timeout message would go away. Since it did not, I assume Robot Builder does know how to make C++ code with out that error.

If we ever figure it out, I will post it. For now we need to move on.

[ozrien]

...when I went back to Robot Builder and built a very simple 4 motor drive system with no operator inputs nor commands, I expected that the 117-timeout message would go away. Since it did not, I assume Robot Builder does know how to make C++ code with out that error.

[1]This is wrong. If you build an app that creates motor controller objects and don't update their throttles periodically, the DS will tell you that you are not updating the throttles, and therefore will trip the motor safety. This is the whole point. So that doesn't mean the RobotBuilder is at fault, technically you are for creating MCs and not using them.

[2]If your actual robot code [that actually calls Set() on every Talon in every auton/disable/teleop loop] is seeing motor-safety trips then that's something else entirely. Most often teams don't call Set(0) on all of them in the disable loop will help. Or just SetSafetyEnable(false) and be done with it.

Either way having errors pile up in your DS make it difficult for CSAs to help you at events when you run into trouble, so you should try to fix it.

[3] Even with [2] I've noticed occasionally I get a trip on transitioning between teleop/disable, so generally I just turn off the motor-safety feature.
But if you need to debug then prop up the robot on blocks and have someone ready on the disable button in the DS.

[4]If you're actual robot code is seeing motor-safety trips AND you are still able to drive every motor that is created in source, then something is bizarre. Or I guess you're seeing something that contradicts my experience with the motor-safety features of the control system.

Posting the actual source might help clarify that.

[rod@3711]

Thank you Ozrien....
I added drive commands to my simple command base program and the 117-timeouts went away.

Also I started looking at the DS charts with the original program and noticed extreme Loss% (I assume lost packets). See attached plot labelled "Original JoeBot."

Finally found where someone had put a conditional statement on the mecanum drive function, that resulted in the function being skipped (thus the 117-timeout).

During my investigations of the DS charts, I found that we get a hickup every 1:08 minutes when running wirelessly. It did not happen when tethered to the router. This occurs on both of our computers and on 2 different routers. Did not get to try 2 different roboRios, since one is in a bag. When the hickup occurs we usually get a 117-timeout message. This does not seem to cause grief.

Does the DS chart labelled "Samsung, 3712,, Original joebot... removed" look anything like what you see on your robots?

Thanx again. I do think the network was been clobbered with error messages.