Reset digital output state on labview crash / end task

[GrassNinja]

Hi all,

I've built a LabVIEW program to control an experimental rig in my lab. It controls a 2kW heater using a relay that is controlled by the digitial output on an NI USB 6211 DAQ. Unfortunately a few weeks ago a collegue shut down the program using task manager so that the routine that was supposed to switch off the rig and clear all the tasks was never run. The heater stayed on even after the program was closed and it eventually overheated and melted...

Is there any way I can configure the DAQ so that the digitial outputs are zero when the program closes even if it crashes or is closed using task manager?

Thanks for your help,

Dan

[crossrulz · Accepted solution]

This is one reason not to use USB DAQ for control applications.  Depending on your other requirements, I would personally use a cRIO-9064 or a 9147 Ethernet Expansion Chassis.  Then you use the FPGA for all of the control.  This is a lot more reliable and not subject to the program being shut down via task manager.  And if the power is pulled, the DIO should reset to off (double check the digital module).

The other thing you need to do is have a hard E-stop button that will cut power to the heater when pushed.

[RavensFan · Accepted solution]

Definitely use hard e-stops if you need certainty that power is killed when someone actively hits the button.  But I have another suggestion that would handle the situation in the event a computer crashes while no one is watching and is around to press a physical e-stop.

Get a watchdog timer as physical hardware.  Your program will periodically send a signal to it to reset its clock if your program is running normally.  If the timer does not get a reset signal, then it knows your program has stopped communicating.  It wil timeout and physically set a relay to false and disconnect any critical components from power.

[Ben]

It is hard to keep up with what NI is sellingh today but some hardware devices have a "fail-safe" configuration option. Fieldpoint for example had DO modules that let you define a safe condition.

But a watchdog retrigerable relay is useful in all situations.

Ben

[RTSLVU]

When working with heaters you should always have some sort of hardware over temperature cutoff that is independent of software. Could be as simple as a self latching relay and a thermal switch that opens the relay when the temperature gets too high, requiring a manual reset.

I had to learn that the hard way too

[GrassNinja]

Ours wasn't quite as extreme but it still gave us a bit of a fright when smoke started billowing out... Thanks for your reply.

[GrassNinja]

The rig is used as part of an undergraduate teaching experiment where students learn about different control types. The program must allow them to change controller parameters (gain, integral time etc) quickly to see how the controller responds. They should also have the ability to change the sensor (thermocouple in the reactor, flow meter on the inlet etc) and the actuator (heater, pump, FCV). When the control was based in LabVIEW this was a simple matter of using an PID control VI with numeric controls wired to it's inputs and a drop down box selecting which DAQ task to read data from. From my understanding of FPGA modules they have to be programmed each time you want to change the parameters. How quickly would the parameters the student selects on the LabVIEW front panel be written to the FPGA controller?

Thanks,

Dan

[edjones93]

Hi Dan,

I am Ed from National Instruments Applications Engineering. I just finished up teaching our Embedded Control and Monitoring course this week. In lesson 1 we discuss crashes and highlight that since an FPGA does not incorporate an Operating System, Drivers and other such software concepts, it is not susceptible to crashes or being interrupted by Task Manager.

Another component to the FPGA is a hardware watchdog, it can be aware as to when the control application is down and perform several actions, in most cases this is: Set IO lines into a safe state and reboot the controller.

The most common FPGA hardware is a CompactRIO, I would take a look at our product page for the CompactRIO.

One other note is that you don't need to recompile the FPGA to change parameters, create an FPGA VI which provides controls to all the parameters you wish to change and then write to these from the application level.

Best regards,

Ed

[crossrulz]

You can easily pass those parameters into an FPGA.  You just have a GUI application.

If you are graphing data, then you have to stream it.  You would then need a cRIO.  So your PC application is the GUI and it just sends commands to the RT of the cRIO via TCP.  I like to use the STM library.  Network Streams also work really well.  The the RT passes the parameters to the FPGA.  And you also have the reverse happening (FPGA to RT to PC).  The other thing I like to do here is have the RT store the last set of parameters in a configuration file.  So when the cRIO boots up, it is already doing its job without any interaction with the PC.

[perhult]

A FPGA is great, but there are several inexpensive DAQ cards like for instance the NI USB-6525 that have a watchdog timer that you could use that serves the same purpose a as a FGPA solution.

With said, let me reiterate what RTSLVU wrote:

NEVER EVER use electrical heaters without any physical thermal protection! It seems very risky in the long run even if you have software watchdogs in place.

You should also do some kind of risk assesment when setting up a permanent or semi-permanent rig to catch these kind of problems...