Figure 3. LabVIEW RT Watchdog Palette
The LabVIEW Real-Time module includes a palette that contains the watchdog VIs. This is the palette used to configure and reset the watchdog timer. The VIs that are contained in this palette are the following:
Watchdog Configure is called at the beginning of your application to define the timeout of the timer and the actions that will be taken when the timer expires.
Watchdog Whack is used to reset the timer. This will be called in a while loop in your application to periodically reset the hardware timer. If this VI doesn’t get called again within the timeout value passed to the Watchdog Configure VI, the configured actions will occur.
The Watchdog Clear VI is called at the close of your application and resets the watchdog hardware and closes the watchdog session.
- Advanced Watchdog Palette
The Advanced Watchdog palette contains the building blocks that the other VIs are made of. These don’t need to be explicitly used in most circumstances but would be if your application requires more intricate interaction with the watchdog timer.
An example of how to use the watchdog timer is included in the LabVIEW Real-Time Module in the example finder under Toolkits and Modules >> Real-Time >> General >> Watchdog – RT Engine.lvproj.
A standard LabVIEW Real-Time application is divided into deterministic and non-deterministic tasks. It’s suggested to have your watchdog configured and interacted with in a non-deterministic task. If the watchdog VIs are included in a deterministic task, they can cause jitter and impact the performance of your application. Another consideration is to interact with the watchdog in a low priority task. Imagine a system in which the highest priority task is taking too much time to run and starving all the lower priority tasks, preventing them from running. If the watchdog is included in that high priority task, the timer will be continually reset as expected, and the system won’t realize it’s in an error state and will continue operating in that incorrect state. The best practice in this scenario is to ensure that your watchdog VIs are being called from a low priority task to ensure that the watchdog will catch any process starvation in the application.