Software Watch-Dog Timers

Consider an application in which the Host PC must periodically check to determine whether RT Series hardware is still running an embedded VI. The purpose of this check might be to shut down a top-level application when the VI running on the RT Series hardware terminates. Or consider a situation in which an embedded application running on RT Series hardware must know when an external system shuts down or fails. The mechanism used to perform such a check is known as a watch-dog timer, and it can be used in several different ways:

1) The embedded VI running on RT plug-in hardware (PCI/PXI 70xx) can determine whether the host PC is still running "Instance A". To accomplish this, the Host PC can write (Poke) a byte to shared memory, located on the plug-in RT series device, during normal operation. The RT series device can then periodically check (Peek) that memory location to determine whether the Host application wrote a new value.

Similarly, the host PC can determine whether the plug-in RT hardware is still executing a VI. In this case the embedded application must Poke a new value to shared memory periodically, and the host PC must periodically Peek that memory to see if a new value was written.

2) Digital hardware can also serve as a watch-dog. Suppose an embedded application running on RT series hardware controls a data acquisition board equipped with digital inputs and outputs as well as counter/timers. The embedded application can determine whether the external system is still "alive" and running by reading from a digital line that the external system writes to periodically.

Similarly, the external system can respond to the termination of an embedded LabVIEW RT application by monitoring a digital output line that the embedded application writes to periodically while running. The external system might respond by powering itself down when it discovers that the embedded application is either no longer toggling a digital output or incrementing a counter/timer.


In the illustration below, both situations described above are depicted. The heart-shaped figures represent the statuses of the Host PC, Embedded PC, and External Systems. The "?" is a boolean indicating whether another application has "died" or stopped working.


For example, an application running on the host PC can detect when the embedded LabVIEW RT application has stopped running by reading the plug-in board's shared memory. If the embedded application stops writing a new value to shared memory, the host application will detect this with a Peek and can change its mode of operation by executing a different case within the VI running on the host PC. Furthermore, the embedded application can switch between modes of operation depending on the state of an external system it is controlling. If External System 2 stops incrementing a count register on the RT Series hardware or no longer toggles the state of a digital line, the embedded application can detect this by simply reading the counter/timer value or digital line state. When the external system "dies", the embedded application might need to shut itself off or start some other process, which could be implemented with a case structure as well in LabVIEW RT.

All of the same general concepts also apply to networked RT targets. Some of the mechanisms of communication change, but the general concept remains the same. For example, networked RT targets do not have shared memory to communicate data between the host PC and the RT target. In such an application, DataSocket could be used instead of shared memory to send and monitor data to determine if the time-critical code is still running.

Networked RT targets also have a set of watchdog VIs that can be used to set up a software watchdog. With these VIs, a timeout period is configured, and a software call from within the time-critical code resets the watchdog counter to 0. If something causes the time-critical code to stop running for longer than the timeout period, this software call to reset the watchdog counter will not execute in time, and the timeout condition will occur. When the watchdog timeout occurs, a software occurrence can be set, and PXI trigger line can be set in a PXI system, FieldPoint output lines can be set to a known state, or the system can be configured to reboot itself.

Related Links:
Digital Pattern Watchdog
Using a Hardware or Software Watchdog in a Real-Time Application

Reader Comments | Submit a comment »