How to configure watchdog timer on 6509

[ajclegg]

I can't find the watchdog timer anywhere in the documentation for the PCI-6509. The only reference to it in the help file describes WHAT it does, same as in the product spec PDF. How do I set it up -- somewhere in MAX, or in LabVIEW (using version 7.1)?

Also, what is a "tristate"?

[Spencer S.]

Greetings,

The following LabVIEW example demonstrates how to configure and implement the Watchdog Timer with the PCI-6509:

Examples >> Hardware Input and Output >> DAQmx >> Digital Generation >> Write Dig Chan-Watchdog Timer.vi

Additionally, the following document provides an explanation of Tristate Outputs:

Introduction to Wired-OR Outputs and Open-Collector Circuits

Good luck with your application.

Spencer S.

[ajclegg]

Thanks, Spencer. The only problem I have with this example is that if I interrupt the vi by clicking Stop, or by more "forceful" means (such as ending the task in task manager), the logic states do not time out to my safe (low) state, but remain high. I was under the impression that the Watchdog Timer was a piece of hardware on the board, with safe states stored in an EEPROM (programmed somehow from MAX). This hardware timer would revert selected lines to safe states if the timer reset signal was not received for ANY reason, including application termination or failure, PCI bus failure, etc. This is how it's described in the spec sheet for the PCI-6509 board. If the watchdog timer resides solely in a vi, then its effectiveness can be compromised more
easily than if it resides on the board as a piece of hardware.

Any words of advice?
Thanks,
Aaron.

[Tiptop]

Hey Aaron,


I think Spencer�s example is exactly what you are looking for. If you look here, you can see how this application should behave. The Create Task VI is storing the watchdog states in hardware, most likely on a EEPROM.

Pressing the Stop button should indeed end the effects of the watchdog timer. The reason is that the task is being cleared outside of the while loop. Once the task is cleared, the watchdog timer no longer applies. However, if you successfully kill this VI from the Task Manager, the watchdog timer should go into effect. Is this not happening?

Just let us know if this provides a better explanation or if yo
u are seeing incorrect behavior.

Best regards,

Justin T.
National Instruments

[Spencer S.]

Justin is absolutely correct. Considering these details, does the device's watchdog timer appear to be functioning correctly?

Spencer S.

[ajclegg]

Justin,
Thanks for the helpful link, which clarified things. The timer is now correctly writing the safe states when I kill from task manager. The LabVIEW dialog "Quitting will abort all running vi's" appeared, and in order to really "kill" the vi, I had to answer "Cancel" to that question (before I had said "Quit"), and then the watchdog did expire as expected after I clicked "End Task" in the Windows dialog that came up.

(Funny thing: I tried different timeouts, and on my system any timeout greater than or equal to 3 seconds did not expire properly. I also noticed that the task manager took 3 seconds before it killed the LabVIEW task. Apparently any timeout less than this "task manager kill duration", will be effective, but any
timeout greater than that will not work. No matter: I'll probably stick with 0.5 sec or shorter.)

Further Question: As it stands (no watchdogging yet), my app has a "test.vi" (mid-level sub) which calls "select cathode.vi" to close a relay for testing. "test.vi" then runs current through that relay, and finally calls "select cathode.vi" again with -1 argument to open all relays before ending test. If I'm going to implement the watchdog feature (with low safe states to close all relays), obviously I need to write some code into the "test.vi" to continually reset the watchdog. Can I start the watchdog task in "select cathode" and then pass that task back to "test" through the subvi connector, finally clearing the watchdog task in the last call of "select cathode"?

OR is it better (or possible?) to leave "select cathode" running in parallel to "test" and have "select cathode" just handle all the DIO and watchdog stuff?

--> Thanks again for the excellent help.
Aaron.

[Spencer S.]

Aaron,

Without examining your application, it is difficult to obtain a good understanding of its architecture, but both implementations of the watchdog timer/DIO functionality sound feasible. Personally, I would continue using your current architecture.

Spencer S.

[ajclegg]

Spencer,

It just seems like I will have to change architecture somehow.

Here's my app in a nutshell:
runup-test (subvi) is called with test parameters and argument of (say) 8 for position 8.
runup-test calls "select cathode" with argument of 8 to close switch 8. "select cathode" finishes task immediately and closes.
Now runup-test does a bunch of things to cathode 8.
Finally runup-test calls "select cathode" again with argument -1 to open all switches.
runup-test terminates after switches are open and passes test data back to main program.

So -- I would love to keep the same architecture, but SOMEWHERE I have to keep resetting the watchdog timer? If reset watchdog in "select cathode" then I have
to find a way (?) to keep that subvi running in the background while runup-test is doing all its tests. On the other hand, if I reset the watchdog in runup-test, I have four different sequence frames in which to build in watchdog reset loops. And I would have to pass the watchdog task out and in through the connector to "select cathode", right?

It seems that either approach will involve significant changes to my program architecture. Is this incorrect?

Thanks again for the patience with a beginner,
Aaron.

[Spencer S.]

Aaron,

Thanks for the description of your application. Have you considered placing the watchdog timer functionality in a VI that you call dynamically when "runup-test" begins executing? Then, after "runup-test" has completed, you would stop this dynamic VI, which is responsible for resetting the watchdog timer. This implementation would require minimal changes to your current architecture. The Dynamic Load Example.vi example demonstrates how to dynamically control VIs.

Spencer S.

[ajclegg]

Spencer,

Thanks very much. Unfortunately this example cannot run in the Base version of LabVIEW, which is what I have. I wonder if dynamic loading is at all possible with the Base version?

Aaron.