Error: A timeout has been exceeded.

[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.