How to disable NI 9265 output if program is not running

[Harry.W]

Hello,

I created a Labview program to generate 4-20mA current outputs using a 9265 module (it's plugged in a 9714 chassis). My program works ok and 9265 outputs whatever it's told by the program to generate.

However I noticed that 9265 will hold a current output (say 10mA) from last cycle even if the main program is stopped, either user closed the program or the program dead by itself. How can I avoid this happening? What I want is the current output goes to 0 if the main program is stopped, either by user or due to accidental error.

Can anyone give me some suggestion please? Thanks a lot

Rgds,

Harry

[KyleTTU · Accepted solution]

Hi Harry, 

My first question is what version of the DAQmx driver is installed on your system?  We did see a need to fix a couple issues relating to the normal open state of some of our current output modules that was fixed in DAQmx versions post 8.6.  If you have a DAQmx version previous to 8.6 I would suggest updating it and see if this alleviates the issue. 

In terms of monitoring the system to see if the program crashes or is stopped (assuming aborted thus not clearing the DAQmx Task) this is not too easy of a solution.  While it is not impossible, it is not very straight forward. The first thing we should look into is why the program is crashing in the first place.  We never intend to have LabVIEW crash and I think it would be a good idea to look into that before anything else.  

A second approach we could take to this issue would be to build a stand-alone application that communicates with your main program. This could be implemented in a executable that runs alongside your development environment using the run time engine (RTE).  Which would be an acceptable approach, and there are two ways to implement this. One is to create an executable that houses a functional global variable (FGV) that will check to see how long it has been since the FGV has been reset. In your real application, you can continually reset the FGV in a separate thread or concurrently with your code. If your code ever crashes, the FGV will not reset, and in your separate application you will see that its been X amount of time since last reset. Once this happens, you can have the FGV call DAQmx Reset on your devices and shut down the system. 

Another option using the same architecture is to use a global variable instead of a FGV. This global variable can be updated by the main app, and then read by the application executable. If the global variable does not change after a given amount of time, you can reset and terminate DAQmx tasks.

Finally, a great option for protection against crashes is the use of a cRIO system. I understand this requires a hardware change and would probably not be the path you would want to immediately go, but it could be something to consider in the future. The upside to cRIO is the fact that you program in FPGA, and your program runs on a stand alone processor on the chassis. This would eliminate any possibility of crashing as long as the system has power, it will run for many years uninterrupted. Also, this allows for watchdog timers that can check for communication and adjust if it were to go down. For reliability, this is the ideal option, and if there is any future projects you look to do I would give some time and thought to migrating this way to ensure reliability. 

[Harry.W]

Kyle,

First all, thank you so much for all your detailed suggestions! If you don't mind, can you send me your contact to harry.wang@thermofisher.com so i can contact you for future questions? Thanks

1. Back to the DAQmx version, we are using v9.1, along with LabView2010.

2. The reason I am worried that program might crash is because Labview is a PC based tool. Under industrial eviroment you will always worry what if Woindows is down (happened quite often isn't it?). I would agree using a cRIO system is a good option in the future and I'll consider it down the road.

3. Considering the time being, I am thinking gives 3rd approach a try where you mentioned using a globle variable. Rigth now, my program has only one excutable which is the main one. So you suggest me to divide the part of current output code into a seperate excutable? I also have a current input card 9203, so I should seperate this part as well?

4. Also can you point out a good example of variable transfer btw different excutables in the LabView examples? I've never done that before.

Again, thanks so much for your help!

[KyleTTU]

Hi Harry, 

Basically in order to set up the applciation to have a standalone monitoring tool all you would really need is a seperate application doing the monitoring, and if necessary the clearing of the DAQmx task.  Everything in your main application would stay as is with the exception of deploying a global variable that is updated continuously.  In your monitoring program you would continue to check and compare the value of the last time it was read and detect either how much time has passed since the value has changed, or how many times the loop iterates until it has seen a new value.   Once it has hit a threshold value we want to go ahead and clear the DAQmx task, effectivly setting the card back into normally open operation.  

There is a ton of information out there about shared variables, some of which I'll share with you below.  The first two links are mostly documentation explaining what the shared variable engine does and how it works, a good background to read before deploying them in your system.  The last is more focused on how to deploy a global variable and link them between two standalone applications.

Using the LabVIEW Shared Variable

http://zone.ni.com/devzone/cda/tut/p/id/4679

All You Need to Know about Shared Variables

https://decibel.ni.com/content/docs/DOC-4081

Deploying Portable Shared Variable Applications

http://zone.ni.com/devzone/cda/tut/p/id/

Give those a read and let me know if you have any questions using this idea in your application.  However, please understand that if Windows were to go down this would not work.  What might be the solution in that case would be to use a network shared variable and have the monitoring program running on another machine, on the same network.

Regards, 

Kyle S

[Harry.W]

Thanks Kyle. I appreciated it!

[KyleTTU]

Not a problem, good luck!

Regards, 

Kyle S