Driver Station Errors

[Creator1326]

I too am getting the -44061 drive loop is running too slow errors and let me preface this with we are 100% completely new to LabView this year.

I've taken all of my control code that runs the conveyer, aiming, shooting, and trigger servo/morors out of teleop.vi and placed them into a periodic task while loop and it seems to make no difference if I set it to 10 ms or 100ms I still receive the error. We are hardwired to our develop PC and should have next to no communication errors.

[DavidGitz]

Originally Posted by Creator1326

I too am getting the -44061 drive loop is running too slow errors and let me preface this with we are 100% completely new to LabView this year.

I've taken all of my control code that runs the conveyer, aiming, shooting, and trigger servo/morors out of teleop.vi and placed them into a periodic task while loop and it seems to make no difference if I set it to 10 ms or 100ms I still receive the error. We are hardwired to our develop PC and should have next to no communication errors.

Are you actually having a problem when using the Robot? In my experience this error isn't a big deal if it throws it every now and then (such as when you Enable) but you will get a lag issue if it continually throws it, which is probably a problem with your code.

See Post #4 in this Thread, specifically concerning the Camera. If you are not using the Camera, make sure to delete all the Camera code in the Begin, Finish and Disable/Delete the Vision VI in the Robot Main.

If that doesn't work post your complete code, it's hard to troubleshoot without it.

[Greg McKaskle]

At the regionals I've attended, I've seen a number of teams throwing this when disabled because they are using a different name for their drive or for other reasons aren't updating the speed. Setting the speed there is useful to avoid jumps when the robot first enables, but otherwise isn't super important.

The most troubling issue with these issues is that they bog down the cRIO so that deploying new code is a bit more difficult, especially when other parallel loops like vision and Timed tasks are running at high CPU usage.

I also saw an error in built apps caused by the calibration code on the Vision diagram. That may not be common, but it makes sense if the panel is being removed during build.

I wish the error messages were a bit easier to understand, but if you are still having ones you can't find, post the Diagnostic messages, including the location info.

Greg McKaskle

[Sconrad]

Disclaimer: This is kind of a hack job solution and should only be tried if the previous suggestions did not work or you don't have time to try them. Also, although this fix worked for us, I can't say I did a ton of research into how exactly it worked so I can't guarantee it will work (Mr. McKaskle probably could better explain exactly why this works, etc.).

Our team encountered this early on in the build season. Drive -> SetSafetyMode vi (I'm not sure if that's the exact name, I don't have LabVIEW up in front of me) has a boolean input labeled something like Enabled? By placing this vi in the Begin vi in between the Open and setRefNum vis, we managed to make the error go away. Again, we only made the error go away, not the problem itself. The above suggested solutions are probably better ideas in general if you have the time to execute them.

[Alan Anderson]

Disabling the Motor Safety on the Drive motors might actually be an appropriate solution, but only in a very limited set of situations. It's theoretically possible for the robot code to be right at the edge of overtaxing the CPU, and a rare event could cause the safety timeout to throw an error...which uses more processing, which tips the system into a constant cycle of CPU overload and motor safety timeouts and errors eventually leading to watchdog timeouts and a disabled robot. With the safety disabled, there might be an occasional couple hundred milliseconds where the drive motors won't respond to a joystick change, but the robot won't get disabled because of it.

I'd still want to find the underlying reason for having so much CPU usage in the first place.