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

[Jon236]

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]

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

[Ether]

Originally Posted by Mark McLeod

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]

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

[Ether]

Originally Posted by Mark McLeod

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.

Originally Posted by Mark McLeod

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]

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]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Mark McLeod

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 ?


~

[kamocat]

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)

[kamocat]

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

[Ether]

Originally Posted by kamocat

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]

Originally Posted by Ether

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.

[Ether]

Originally Posted by Alan Anderson

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.


~

[Jon236]

Originally Posted by kamocat

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

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.

[Ether]

Originally Posted by Jon236

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?