NI USB box problem when Labview is terminated abnormally

[Sun87]

Hi all,

recently I had a problem regarding to the NI USB box used in Labview.

I wrote a very simple program and it is running in Labview 2011. It basically reads some data from a NI USB box and also send some data back. According to my knowledge (I am not sure if it is right or wrong), when the Labview is terminated no matter how it is terminated, the USB box should also stop working. But the thing is, when the Labview program is terminated abnormally, let's say I directly terminate it from the windows task manager when it is running, all ports of the USB box will keep their final states until I restart Labview and write new values to them.

This phenomenon could be very dangerous. For example, when I use the USB box to control the power of a power supply, if the Labview program crashes (which happens a lot), the USB box and power supply will keep running until I restart the program again. I tried several different types of NI USB boxes on different PCs and the problem always occurred. So I am wondering if there is any mechanism that can prevent such problems or if I can do something programmatically to avoid it.

Thank you so much for your help and time.

Best regards,

Sun

[Hooovahh]

The analogy used around here is you are stopping a car by crashing it into a tree.  It will stop but starting it again maybe difficult.  Perform normal stop functions and close references, set outputs to off, perform a device reset, or do what ever else you think is important on exit.  Do not ever use the red stop button on the front panel of a VI unless you know full well what it will do (or not do).

You said your program crashes alot.  This should not happen and needs to be resolved.

[Sun87]

Hi Hooovahh,

thank you for your reply.

Maybe I am not quite clear in my original post.

1. I do use the normal stop function and it works well. I did not use this red abort button at all and actually I even made it disapear from the appearance.

2. I did not mean to make the Labview program crash. The fact is, this VI is a just small sub VI used in a relatively large project. The main VI has many different threads running at the same time, one of which is acquiring 32 frames per second from the camera and recording these frames into a .avi file. What I am trying to say is, the main VI takes a lot of memories of the PC and sometimes it is stuck. And even in this situation, the USB box is still running.

3. Let's also use your analogy, it is like somebody is driving a car.  The brake is working perfectly and he knows how to stop the car in a normal way. But you do have to admit that traffic accident happens a lot no matter what the reason is. What he needs is just something that reduces the damage when the accident happens, like air bags or anything else. I think Labview should have a similar mechnism or at least it can be done programmatically.

I hope this time it is clearer.

Thank you again for your help.

Best regards,

Sun

[Taki1999]

I think the problem is that LabVIEW doesn't know what's going to cause it to crash. Without knowing that, it's hard to say what it should do to protect itself.

It's up to the programmer in most instances to decide what are the likely failure modes and how to protect against them.

For your particular application, I'd recommend a hardware Estop and maybe something controlled by a watchdog.

The safe course of action is often application dependent. Sometimes killing power is the safe course of action. If you're using that power to hold up a 10 ton weight, engaging a brake and keeping power on is safer.

Those sorts of decisions fall on the designer and not LabVIEW itself.

[billko]

---

@Sun87 wrote:

Hi Hooovahh,

thank you for your reply.

Maybe I am not quite clear in my original post.

1. I do use the normal stop function and it works well. I did not use this red abort button at all and actually I even made it disapear from the appearance.

2. I did not mean to make the Labview program crash. The fact is, this VI is a just small sub VI used in a relatively large project. The main VI has many different threads running at the same time, one of which is acquiring 32 frames per second from the camera and recording these frames into a .avi file. What I am trying to say is, the main VI takes a lot of memories of the PC and sometimes it is stuck. And even in this situation, the USB box is still running.

3. Let's also use your analogy, it is like somebody is driving a car.  The brake is working perfectly and he knows how to stop the car in a normal way. But you do have to admit that traffic accident happens a lot no matter what the reason is. What he needs is just something that reduces the damage when the accident happens, like air bags or anything else. I think Labview should have a similar mechnism or at least it can be done programmatically.

I hope this time it is clearer.

Thank you again for your help.

Best regards,

Sun

---

"Normal stop function?  Do you mean the "Stop Sign" in the Application Control Palette?  That is EXACTLY like pressing the abort button.

Apparently your simple application is TOO simple.  If your LabVIEW application is crashing constantly, I'd take care of that first.  It's all well and good to try to clean up in the event of a crash it's much better to prevent them in the first place.  Make some error trapping code that shuts things down gracefully on an error.  Handle all the errors you can think of happening in explicit ways; handle all unexpected errors in a generic way.  Note that the "generic" way would be more of a nuclear option - shut everything down - because you have no idea how critical an unexpected error would be and should be treated as a worst-case scenario.

And I think that the expectaion for something to shut down gracefully under ANY conditions is unreasonable.  If it was reasonable, MS Office wouldn't have a recovery option upon crashing.  😉

[johnsold · Accepted solution]

Sun,

Another area where you may have a misconception: LabVIEW does not control the USB DAQ device. The LabVIEW program calls the DAQ driver program (typically DAQmx or DAQmx Base) and those drivers tell the OS to send messages through the USB port to the DAQ device. So stopping the LV program, whether intentionally or accidentally, does not tell the DAQ driver and the OS USB driver to put the DAQ device into a safe state. 

If you have a setup where the LV program can be stopped before it can send "safe state" commands to the DAQ device, then you cannot assure that the DAQ device will shut down properly.

There are some "watchdog" VIs which have been written in LV, but even those depend on the LV run-time engine functioning. 

You need to carefully rethink your entire system, making the safety issue one of the primary objectives right from the beginning.  Most likely you will find that you need a separate device, either hardware timer or PLC, to perform the shutdown if the software fails.  You should also consider whether you need a real-time operating system to avoid some of the problems associated with standard desktop OSes.

Lynn

[Sun87]

Hello guys,

thank you so much for all your replies above. It really helps me to think a lot.

1. By 'normal stop function', I mean put an additional 'stop' button on the front panel. Every time you press this button you can stop the whole program. By the way, I also considered the error signals from all VIs. I think this is the normal and correct way to stop a program and that is why I call it 'normal stop function'.

2. Maybe I should not use the word 'crash', and 'stuck' is more accurate. I explained a little bit in my second post that most (99%) of the abnormal termination is caused by the running out of memories and the whole PC is stuck.  I have to admit that for the rest 1%, it did happen once or twice that the entire Labview program suddenly closed by itself and jumped back to the desktop. I tried to debug but never repeated this scenario again. Besides this, I believe the whole program is running well and I did consider how to deal with possible failures of different VIs.

3. I am wondering if there is any setting to the DAQmx device that if the corresponding program is not running, the device itself will go back to some kind of default state... Sorry if it sounds like nonsense and I realized maybe this requirement is a little bit unreasonable for Labview. I will think about the hardware way to solve this.

Thank you all for your help and time.

Best regards,

Sun

[billko]

It didn't sound like nonsense before.  Sometimes it takes a short q and a session for you to more fully explain yourself.  🙂