Watch Dog stopping robot from working?

[Biolore]

So, my team is trying to get our robot running. I put the default code on, and its not working. It said that it failed because it couldn't communicate to the camera, so I took out the camera codes. Now I'm getting a message on the driver station that says "Watchdog Expiration: System 1, User 0." Can someone help me out?

[Biolore]

I'm getting error code 44061

[Biolore]

"FRC: The Loop that contains RobotDrive is not running fast enough. This error con occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop." I'm pretty sure this shouldn't happen if its just the robot frameworks with game code from labview

[EricVanWyk]

Check the loop that contains RobotDrive. What else is in it? Did you leave some camera code behind?

[Team#2057-Vegas]

im looking into a similar problem.. i saw on the framework tutorial from NI something about fixing that with a safety vi after your drive motors near the camera or w/e. check it out

best of luck

[Mark McLeod]

The Framework this year behaves a little differently than last year. There is a new type of "Watchdog" hidden within the Arcade/Tank/Holonomic Drive vis.
It's optional, but enabled by default.
If you want to change it (enable/disable) you do so in Begin.vi inside the Open 2 Motor or Open 4 Motor vis.

The way it now works is the drive motors will shutdown if you don't call Arcade/Tank/Holonomic Drive within every .1 seconds.
It is no longer "set it and leave it"

If you suffer from this you will see this error message on the Diagnostics tab error window:

ERROR <Code> -44061 occurred at "Left and Right Motors" in the VI path: Robot Main.vi
<time>23:15:45 01/21/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.

If you think you code should be setting the Drive quickly every iteration, then you may have sluggish code of a long loop that is keeping you from leaving the vi.

[DavidGitz]

Originally Posted by Mark McLeod

The Framework this year behaves a little differently than last year. There is a new type of "Watchdog" hidden within the Arcade/Tank/Holonomic Drive vis.
It's optional, but enabled by default.
If you want to change it (enable/disable) you do so in Begin.vi inside the Open 2 Motor or Open 4 Motor vis.

The way it now works is the drive motors will shutdown if you don't call
Arcade/Tank/Holonomic Drive wthin every .1 seconds.

We are getting the same "not running fast enough" error in our Teleop.vi I can post it here, although we still need to clean it up some. But my question is we have an auto-score mode that runs some code if enabled by a driver that uses the Arcade drive, and if it isn't enabled by a driver the driver manually controls the robot with the Tank drive vi. Since we are pulling the same reference (default "Left and Right Motors") and using Arcade on one mode and Tank on another mode that can be changed back and forth, could this result in the error noted above due to the Arcade/Tank difference?

In our Teleop.vi we have no code that forces anything to pause, such as waits.

[WizenedEE]

[quote=DavidGitz;1006228Since we are pulling the same reference (default "Left and Right Motors") and using Arcade on one mode and Tank on another mode that can be changed back and forth, could this result in the error noted above due to the Arcade/Tank difference?[/QUOTE]

No. If you open up the vis, it shows that the only difference is some processing of the joystick values before it runs the "runMotor" and "safetyupdate" vis.

Try adding a timer to see how fast the loops are running. To do this, add a tick count to your teleop.vi, then a feedback node. Connect the tick count to the input of the feedback node (on the arrow, not the diamond) and then add a subtraction command. Wire the output of the feedback node to the bottom of the subtraction command and the tick count to the top. Then put an indicator on the end of the subtraction command and look at it while the code is running.

[Greg McKaskle]

You may want to look for a VI called Loop Time, Loop Timing, or something similar. It is a subVI you can drop into a loop, and since it is called each iteration, it will record info about the rate of the loop. You can then open the subVI at any point and peek at what has been going on.

Additionally, you can wire up a string to different calls in other loops, and instrument as many loops as you care to watch.

There is a small amount of overhead for having this in, and apparently they decided not to put this into the default framework, but it is very handy for issues like this.

Greg McKaskle

[MaxMax161]

We had a the same problem and after killing ourselves trying to find the programing error we realized that all the PWMs were in backwards which was shorting out the digital sidecar. Double check the electrical work, especially if the default drive code is having problems too. Hope that helps.

[DavidGitz]

Originally Posted by MaxMax161

PWMs were in backwards which was shorting out the digital sidecar.

Wow. No that's not the problem.

[Greg McKaskle]

I discovered that the loop timing info is described in the Troubleshooting link on the Getting Started window.

Greg McKaskle

[xYinx161]

This is team 1208's time from an elapsed time function. With default code (on the right) the time is 40 miliseconds and with our code (on the left) it is on 90 miliseconds on average. We have also included our teleop.vi. Is this a problem and if so what can we do to fix this.

[U5ER NAM3]

i need help on the motor control Set Speed icon but i cant find it so i cant finsh the while loop until i get the Set Speed icon can u help me?

[Mark McLeod]

Originally Posted by xYinx161

This is team 1208's time from an elapsed time function. With default code (on the right) the time is 40 miliseconds and with our code (on the left) it is on 90 miliseconds on average. We have also included our teleop.vi. Is this a problem and if so what can we do to fix this.

If it's an average of 90ms, that will be a problem. It's right on the edge of the Safety vi timeout at 100ms and since it's an average nearly half will be beyond the tripping point.
I don't see anything obvious that's slowing you down, although it's easy to isolate the slowdown using Disable structures on the stand-alone blocks of code.

It looks like you are also setting your motors in two different places. Those two conflicting sets will be fighting for control of your robot when the time comes. You need a way to choose one or the other, not both at the same time.

Originally Posted by DavidGitz

Since we are pulling the same reference (default "Left and Right Motors") and using Arcade on one mode and Tank on another mode that can be changed back and forth, could this result in the error noted above due to the Arcade/Tank difference?

The Arcade/Tank mixture shouldn't be a problem. They don't remember who was called last and they both reset the Safety vi.