state of outputs when computer hangs

[BobM3]

I'd like to write a program that can turn on and off 2 external opto isolators. It's important that the user be able to turn off the optos. My concern is that the application or the OS will lock up and I will not be able to turn the optos off from the application. So what happens to the port signals (serial, parallel) when a lock up occurs? Do they go high or low or stay where they were or is it unpredictable?

 

[itsmoked]

Unpredictable because a problem may occur such that a "freeze" might just leave the signals static but then a reboot switches them all to another state.

I have an aquarium that has a 12 year old XT running it. I run an opto board off the parallel port. Whenever the XT reboots (only for power failures) all the optos go ON until it finishes rebooting. This means all the air solenoids and lights go ON. Very annoying! I added a small program in the boot-up that reverses all these outputs to OFF but it still takes some time, about 8 seconds which drains some inter tank syphons.

A better design would include some hardware that must be constantly updated OR the outputs are forced OFF. This way unless the computer is active the outputs automatically go OFF or to a desired state.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[analogkid2digitalman]

Some digital I/O hardware cards have what is called a "watchdog timer" that continuously must be reset at a given time interval- if the OS or applications hangs, the watchdog kicks in and sets the outputs to a predetermined state automatically. This is what Keith was referrring to, I beleive.

If the risk is low and the operator is at the PC when the application or OS hangs, you could always wire up some switch(es) to force the optos to the preferred state. Then in case of lock-up, the operator could hit the switch(es).



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"It's the questions that drive us"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[BobM3]

I think using hardware is a good idea. And I think that an "E-Stop" button on the hardware is a good idea. The watchdog timer sounds like a good idea also. Ever hear of an application that "partially freezes"? For instance, could an application stop accepting inputs from the user but still send out the watchdog signal?

 

[zeitghost]

Yes. I've seen partially active software still run the watchdog... never managed to track the cause since the company went down the pan.

 

[BobM3]

Yikes, sounds like a tough job counting on a PC and hardware to get 100% control of the outputs.

I think I'll make the cable to my hardware long enough so that the user can have the hardware "E-stop" on the desk. Not nice, but it sounds like the only sure way to turn off the outputs.

 

[swn1]

Best piece of advice I've seen on watchdogs is to split the "set" and "reset" operations between separate sections of the code. Make the hardware timer require transitions so the process has to execute in both sections to keep it reset.

One system I built had numerous communicating processes. I arranged for them to pass a software token among themselves, with the highest priority task resetting the dog and the lowest setting it when they get the token.

You can build the watchdog function into the drivers: use a retrigerable oneshot to drive the isolator and make the software toggle the outputs to keep it on. Either static state means "off", no false trigger on on->off transition at reboot.

 

[itsmoked]

I usually set things up so the watchdog is updated by a comparison of a bit pattern in a byte, which it then promptly clears in the next instruction. The only way to set all the bits again is to visit all the routines that each set one of the bits.

So occasionally when the watchdog routine is called the pattern is checked and if not the correct pattern nothing is done. This means if the program partially hangs all routine bits will no longer be properly set. If the the program hangs in the watchdog routine it will never be happy because the bit pattern will never be correct and if it just happened to be correct then the one time the watchdog is kicked then the pattern is cleared and never rebuilt -> WDOG will soon trip.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com