View Full Version : Working code in Windows shows 'Watchdog Not Fed' once deployed
We have code that works fine in Windows but once built and deployed gives us a 'Watchdog Not Fed' error. What conditions would produce this? We have disabled the power-saving in the Classmate and see the error on our programming laptop as well.
Mark McLeod
08-04-2010, 22:40
Don't know why Run would inhibit the User Watchdog (but I'd suggest not letting it distract you from fixing the obvious Watchdog problem, of course).
The message you see is generated from the User watchdog and the operation of that is self-contained within your code running on the cRIO. It doesn't depend on the Classmate for anything. So Run would have to be affecting the execution of the Watchdog delay on the cRIO somehow. That's implemented below the visible layer of code in the FPGA, so the FPGA programming might be smart enough to allow for slower response times when LabVIEW is running in debug mode. Joe Hershberger would be the one to know.
The Classmate doesn't affect the User watchdog, power-saving or no. The fastest PC you have won't matter to the User Watchdog, because that's not what it's watching.
The User Watchdog is concerned solely with how often your cRIO code feeds it. Sort of like my neighbors cat. It doesn't care how it's fed or who feeds it as long as the food shows up in the bowl at regular intervals.
A laggy Classmate might affect the System watchdog, but that one typically just shows up as a count on a Diagnostic tab message, or as jerky robot motion, not as "Watchdog not fed".
The Classmate doesn't affect the User watchdog, power-saving or no. The fastest PC you have won't matter to the User Watchdog, because that's not what it's watching.
The User Watchdog is concerned solely with how often your cRIO code feeds it.
I thought I understood the user watchdog but now I'm not so sure.
If the cRIO feeds the user watchdog in TeleOp, and TeleOp is executed only when the Classmate sends a DS packet, can't the behavior of the Classmate affect the user watchdog?
~
Mark McLeod
09-04-2010, 10:34
Depends on how the Teleop calls are implemented. If Teleop is simply called on a 50hz timer, or called only when a new DS packet arrives?
I'd have to look.
Also depends on how and where the Watchdog is included. Just in Teleop or in periodic tasks and elsewhere as well. I see many people dropping Watchdog feeds helter skelter until the Watchdog warning goes away...
Depends on how the Teleop calls are implemented. If Teleop is simply called on a 50hz timer, or called only when a new DS packet arrives?
I'd have to look.
I read somewhere (can't remember where off-hand) that TeleOp is called only when a DS packet is received. If I can find where I read that, I'll provide a link.
Also depends on how and where the Wathdog is included. Just in Teleop or in periodic tasks and elsewhere as well. I see many people dropping Watchdog feeds helter skelter until the Watchdog warning goes away...
Yes, it does depend on that. I was assuming "proper" use of user watchdog.
~
Mark McLeod
09-04-2010, 10:54
Thinking about it, I don't believe we'd see "Watchdog not fed" from slow Classmate transmission packets regardless of how Teleop is implemented.
I think the Classmate would have to completely freeze up before the lack of the packet transmission heartbeat would cause the User Watchdog in Teleop to react.
Long before that occurred I believe a System Watchdog would be thrown for lack of communication and we'd see a whole different error message displayed on the DS.
Mark McLeod
09-04-2010, 11:12
I read somewhere (can't remember where off-hand) that TeleOp is called only when a DS packet is received.
Made me look.
Get Competition Mode waits for a DS Occurrence, which I assume to be the arrival of a new packet. It's got a drop-dead timer of 1 second associated with it, i.e., no packet = mode goes to finish and terminates the user program.
If this happened and communication was subsequently restored, we'd see the "No robot code" red light appear on the DS. The only recovery would be to reboot the robot.
Get Competition Mode waits for a DS Occurrence, which I assume to be the arrival of a new packet. It's got a drop-dead timer of 1 second associated with it, i.e., no packet = mode goes to finish and terminates the user program.
Does anyone know what the timeout value is for the User Watchdog, and for the System Watchdog ?
~
User watchdog is .5 seconds, or 500ms.
System watchdog uses a TCP connection between the DS and the cRIO. (I don't know what the timeout period is, but when it times out, your DS will say there's no robot connection)
Usually, the source of a "watchdog not fed" during Teleop is that Teleop is taking more than 500ms to execute.
What I would do is time how fast the loop in Robot Main is executing, like so:
http://content.screencast.com/users/kamocat/folders/Jing/media/b26a38c9-5c9c-44d0-9575-b8eede3fa23d/00000043.png
If you have an IO conflict (say, something has been "opened" more than once), then that tends to take a LONG time to resolve per iteration (somewhere around 600ms).
User watchdog is .5 seconds, or 500ms.
Much longer than I expected. Can you provide a link to where this is documented?
Thanks.
Alan Anderson
09-04-2010, 13:29
Much longer than I expected. Can you provide a link to where this is documented?
As with almost everything in LabVIEW, it's documented right where you would use it. In this case, that's the Watchdog Open vi. With "hover help" active, you'll see the default "Expiration (0.5s)" shown. The "Detailed help" link explains it completely.
As with almost everything in LabVIEW, it's documented right where you would use it. In this case, that's the Watchdog Open vi. With "hover help" active, you'll see the default "Expiration (0.5s)" shown. The "Detailed help" link explains it completely.
Thank you.
I'll ask a LabVIEW programmer to show this to me next week at the next team meeting.
~
Usually, the source of a "watchdog not fed" during Teleop is that Teleop is taking more than 500ms to execute.
What I would do is time how fast the loop in Robot Main is executing, like so:
http://content.screencast.com/users/kamocat/folders/Jing/media/b26a38c9-5c9c-44d0-9575-b8eede3fa23d/00000043.png
If you have an IO conflict (say, something has been "opened" more than once), then that tends to take a LONG time to resolve per iteration (somewhere around 600ms).
Excellent suggestion....we did exactly that in Teleop and saw delays up to 150 ms. The strange behavior here is that the code runs fine under Windows, but once deployed as startup code, it shows 'Watchdog Not Fed' when enabled in either Teleop or Autonomous.
Excellent suggestion....we did exactly that in Teleop and saw delays up to 150 ms.
Are these delays being caused by your own code in TeleOp, or do you think something somewhere else is causing the delays?
I would much like to learn from your experience. Would you be willing to post your code, or perhaps PM it to some of the very experienced and helpful LabVIEW experts here?
Are these delays being caused by your own code in TeleOp, or do you think something somewhere else is causing the delays?
I would much like to learn from your experience. Would you be willing to post your code, or perhaps PM it to some of the very experienced and helpful LabVIEW experts here?
I would be happy to....you can download it from here (for another few days):
https://www.yousendit.com/transfer.php?action=download&ufid=RmNEYUlnQ3RlaFJFQlE9PQ
Excellent suggestion....we did exactly that in Teleop and saw delays up to 150 ms. The strange behavior here is that the code runs fine under Windows, but once deployed as startup code, it shows 'Watchdog Not Fed' when enabled in either Teleop or Autonomous.
Are there any other differences in the two between how you are communicating with the robot?
(Is a different computer used for the driver station? Are you tethered vs wireless?)
Does your LabVIEW update match your cRIO image?
Are there any other differences in the two between how you are communicating with the robot?
(Is a different computer used for the driver station? Are you tethered vs wireless?)
Does your LabVIEW update match your cRIO image?
It happens with a cross-over or wireless connection.
It happens with the Classmate or my Asus.
All imaging is up-to-date.
My head is a little flat from banging it on the wall, however.
Does it happen with a default robot project?
Does it happen with a default robot project?
No
Okay, I'll take a look at your code.
EDIT:
I don't see anything that would cause a delay more than 500ms.
I'll see if I can test this on a cRIO.
EDIT2:
Sorry, I can't find my cRIO power supply. It may be awhile before I can test this.
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.