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.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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?


~

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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.


Yes, it does depend on that. I was assuming "proper" use of user watchdog.


~

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

Does anyone know what the timeout value is for the User Watchdog, and for the System Watchdog ?


~

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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)

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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:


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

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

Much longer than I expected. Can you provide a link to where this is documented?

Thanks.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

Thank you.

I'll ask a LabVIEW programmer to show this to me next week at the next team meeting.


~

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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.

Re: Working code in Windows shows 'Watchdog Not Fed' once deployed
 

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?