Quote:
|
...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.