[Greg McKaskle]

What I'd suggest is to instrument the drive code to note each timestamp when you call update for the drive. Once the robot is started, the robotDrive safety mechanism considers 100ms to be the update period. If this only happens once at the beginning of teleop, it could simply be because the disabled wasn't updating the robotDrive, or it could be some init code that you didn't consider. Anyway, instrumenting it is pretty easy.

The first thing to do is to open the support folder in the project window. The VI called Elapsed Times can be dropped into teleop, into periodic loops, autonomous loops, vision loops, or wherever you want to measure the elapsed time between subsequent calls. If you wire up a string, that is the identifier it will use, otherwise it will use the calling VI's name.

Once inserted, run the robot code and open the panel. Each unique name will be on a new row of the table, and the number to the right is the last deltaT.

If the typical time seems good -- around 20ms, it may be useful to modify the Elapsed Times VI to keep some statistical data such as the largest delta you've seen since startup.

Please post back with details on what you find.

Also keep in mind that the safety mechanism is on for the RobotDrive by default, but if you are comfortable with the typical times, you can disable it in Begin, teleop, or anywhere else in your app. It is there to help with breakpoints and the like, but isn't mandatory.

Greg McKaskle