Showing results for 
Search instead for 
Did you mean: 

Reset digital output state on labview crash / end task

Go to solution

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,


0 Kudos
Message 1 of 10
Accepted by topic author GrassNinja

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.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 10
Accepted by topic author GrassNinja

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.

0 Kudos
Message 3 of 10

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.



Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 10

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



Unfortunately, most readers of this Forum, including some real Experts, have not mastered the skill of being able to read the code that Posters fail to post. If we cannot see "what you did wrong", we are unable to tell you how to fix it. (Bob Schor 28 August 2018)
0 Kudos
Message 5 of 10

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.heater.jpg

0 Kudos
Message 6 of 10

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?




0 Kudos
Message 7 of 10

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,


0 Kudos
Message 8 of 10

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.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 10

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...

0 Kudos
Message 10 of 10