Driver Station Errors

[Greg McKaskle]

The user login message suggests that someone may have done the quick switch that allows for multiple users to be logged in. The DS no longer allows this and the new one sends a message to the old one to shutdown. But you could potentially have other programs hogging resources I suppose.

Greg McKaskle

[Mark McLeod]

From your description of the placement of the robot radio, it needs to be relocated. You listed a lot of things it shouldn't be close to (battery, motor, I bet it's close to speed controllers too isn't it).

Before rewiring, if you can, just take it off the robot and attach an extra Ethernet cable/power cord just so you can hold it in your hand while the robot runs while up on blocks.
Watch the Charts while holding it away from the robot with the motors running, then move it closer and to various places on the robot to see how proximity to various things affects the packet loss and round-trip transit time.

We just did that with a visiting team and it was quite an eye opener for them.
Nice job with the Charts this year Greg. Kudos.

[Greg McKaskle]

Thanks. Now we just have to learn how to use it. Thanks Mark.

Greg McKaskle

[Team 4117]

Unfortunately it's not the placement of the wireless radio (rewired and moved it several feet away from our bot)...

Also checked to confirm we are getting a steady 5V from the transformer (it sometimes gives a quiet but high pitched hum) which we are...

The inSSIDer is a great tool and there does seem to be a lot of 2.4Ghz traffic here (see screenshot) but we got the same errors at their campus which had significantly less traffic (although there were brief periods where we had perfect wireless communication).

One of the guys who works at FIRST events managing the wireless systems worked with it for about and hour and said he pretty much narrowed it down to being an issue with the wireless radio itself. He said that it shouldn't be a problem at the event though since we will be running 5Ghz and if it is he'll give us a new radio (for now we'll just run code tethered).

Not the ideal solution but I've wasted far too much time on it already.

Thanks again for looking at this.

[Jurrian]

Originally Posted by cilginbilgin

ERROR <Code> -44061 occurred at "Left and Right Motors" in the VI path: Robot Main.vi
<time>09:00:09 02/18/2011
FRC: The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.

This is the error I am getting and I couldnt manage to solve it!

Here is my Teleop.vi

Did anyone seriously find the answer to this because we need to solve this immediately.

[juchong]

Remove as many things from your teleop.vi and put them in periodic tasks! Also, if you're developing code on another laptop and pushing code into RAM, try removing as many controls on the front panel as possible, that REALLY slows everything down.

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

[blackflame2996]

I can confirm that there is not anything wrong with your teleop. something else is using up all of the RIO's processing power. I would look at any vision processing that you have running; that is what caused us problems. Now, as to the watchdog, feed it in the 10 ms loop of timed tasks. this will eliminate all of these errors except when switching modes.

[Greg McKaskle]

The watchdog is not on by default. If it were, feeding it in a parallel loop is equivalent to turning it off, so you may as well just turn it off.

The safety config if "fed" when you update the RobotDrivr. Don't update them in parallel, just update them. Or set it to be disabled. Make sure that anyone else debugging the code knows it is off so the robot doesn't drive through walls.

Greg Mckaskle