Watchdog not fed

[brianelite]

Hi - I am running 2010imagedemo code...

when I enable the robot in the driver station it says "watchdog not fed" for a few seconds and then the message goes away... and it goes into one of the three modes.

Is this normal? And if not what can I do to fix it?

[byteit101]

yes, this is normal due to the line that says

GetWatchdog().SetExpiration(1.0);
Wait(3.0);

Whoever wrote this was not thinking clearly

[pilum40]

Originally Posted by brianelite

Hi - I am running 2010imagedemo code...

when I enable the robot in the driver station it says "watchdog not fed" for a few seconds and then the message goes away... and it goes into one of the three modes.

Is this normal? And if not what can I do to fix it?

We're noobs so our question may be dumb...
If the driver's station goes into auto mode after a few seconds, one, what do we do if it STAYS in watchdog not fed mode, two, does anyone have a patch we could install to overwrite the existing code that doesn't work, three, how do we turn watchdog off? There is not a switch (green switch) on our copy of the software.
I know y'all are laughing but hey...we gotta' ask! Cut us some slack already!

Steve Miller
Coach 3355

[byteit101]

GetWatchdog().SetEnabled(false);

HOWEVER, YOU SHOULD NOT DO THIS UNLESS YOU HAVE A VERY GOOD REASON, LIKE A BUNCH OF Wait STATEMENTS.

GetWatchdog().Feed(); is your friend

[taichichuan]

Rather than disabling the watchdog (not a safe thing to do), you can also set the expiration of the watchdog to something like 5 seconds. That way, if your system hoses, the robot will automatically stop after 5 seconds.

e.g.,

GetWatchdog().SetExpiration(5.0);

[NullEntity]

I know (using LabVIEW) our team had this issue. Turns out we had to reset the robot each time. I'm not sure if they solved it though.

My Analogy:

• Buy dog = Turn on robot
• Dog is hungry so he doesn't listen to you = Watchdog Not Fed
• Shoot dog = Turn off robot
• Repeat = ...

[byteit101]

you don't have to kill the robot to solve the watchdog not fed error, just feed it (or give it a larger Expiration)

my interpretation of the watchdog analogy:
there are two Watchdogs, System and user. The user watchdog is a poodle that you can kill at will. you also have a poodle re-animation device. On usercode load, you create a new poodle, and you can set its fatness (time to starve) via the SetExpiration. You must feed the poodle within this period, or it dies, falls down, and shorts the motors, so you cannot move until you re-animate it and it gets off the shorted circuts. so you feed it, and re-animate it, and you can continue

[NullEntity]

Originally Posted by byteit101

you don't have to kill the robot to solve the watchdog not fed error, just feed it (or give it a larger Expiration)

I think it was fixed by now (I''m not on Controls), but that's what we had to do.

[pfreivald]

I don't know if this is useful at this point, but after struggling with watchdog issues throughout the build season, we corrected it by putting a 5 ms wait statement in our main loop. That cured the problem instantly, and it didn't come back.

(I'm not at all a programmer, but I know that's what they did, so I thought I'd share it here. Good luck teams!)

Patrick

[bronxbomber92]

Originally Posted by pfreivald

I don't know if this is useful at this point, but after struggling with watchdog issues throughout the build season, we corrected it by putting a 5 ms wait statement in our main loop. That cured the problem instantly, and it didn't come back.

(I'm not at all a programmer, but I know that's what they did, so I thought I'd share it here. Good luck teams!)

Patrick

I'll expand upon what we did :-)

We were experiencing system level watchdog "not fed" errors. For awhile we couldn't figure out what exactly was happening except that it had to do with the camera feed on the dashboard. It turned out that we were starving the background task/thread that was responsible for serving the dashboard with the camera image packets by hogging CPU time with our main task/thread (the thread that OperatorControl() runs within). This affected our communication between our driver station and cRIO, effectively timing-out the watchdog that monitored communication.

The fix was to suspend the main thread for 5/100 of a second, thus giving other threads (ie, the camera feed thread) more time to execute.

void OperatorControl() {
    while(IsOperatorControl()) {
        ... do you own work ..
        .. then at the end of the loop, suspend the task ..
        Wait(0.05f);
    }
}

[pfreivald]

Thanks, Jedd.

[iblis432]

the 5/100 of a second seems plausible, any guesses if this will work for labview too? I'm sure it would, but i'd like other input

[Greg McKaskle]

All loops in the LV framework delay either until an occurrence is sent or for a timed amount. If you do not put a delay into a loop, you are informing the compiler and scheduler that it must run as fast a resources allow, which is often way faster than you need. The way to tell it how fast you need is to put in either a time delay or a notifier.

Since it isn't obvious, the LV framework suspends inside the Get Mode subVI waiting for the next packet to arrive. It does this using the Wait for Occurrence primitive. That is why no waits are inside the Robot Main loop.

Greg McKaskle