Releasing hardware resources on LabVIEW crash

[Praveen_a09]

Hi all,

I am using PXI chassis with many DAQ cards, mux, ARINC,RS-422 etc.

It is a common problem that in the event of LabVIEW crash, the hardware resources are not released and the system should be restarted to access the resources again.

Scenario:

LV1 is the main LabVIEW program that opens the harware resources. 

LV2 is a separate LabVIEW program (a utility) runs as a separate process.

Now if the LV1 opened few references to the hardware devices and shares these references to the LV2.

In the event of LV1 process crash, LV2 still runs; can the LV2 process close the open references?

Can LV2 process release the resources opened by LV1? 

[Bob_Schor]

Is the PXI running as a Real-Time platform using LabVIEW Project?  I'm not sure when, but certainly since LabVIEW 2010, the preferred mode of execution of code on the RT Platform (when not in Development mode) was to have the code run at Startup (when the hardware was in a known, defined state) and to terminate by rebooting the PXI (returning the hardware to a known state and restarting the Remote code).

You could also code your remote routine to have an "Error" state where it goes through a process of shutting down and restarting all of the hardware, and then restarts the PXI code in a "safe" state (such as the Initialize state).

I've done something like this in a LabVIEW RT project.  If an error occurs on the RT side, it sends a message to the Host saying "I'm exiting, and you better do so also" and then reboots.  On the other hand, if the Host says to the Remote "I'm done with this for now, but want to restart with another set of parameters", the Remote interprets this message as "Shut down the Hardware and go back to the Initialize State, as though we just started".  When the Host is really ready to exit, it tells the Remote "I'm going to Exit now", and the Remote, when it sees it, does an "orderly" (as opposed to an Error) shutdown (which entails a reboot).

Bob Schor

[Praveen_a09]

Thank you Bob for the reply.

The context that you have expalined may be valid in RT and the method of handshaking messages is good when the processes exit properly.

But the question I have asked is more general towards the LabVIEW crashing abruptly. When a large project is running there will be crashes while developing and testing the EXE as well. The only way to release the hardware resources is restarting the system. I am thinking of having a separate LabVIEW utility program that can close the orphaned references of a crashed LabVIEW program, so that we do not need to restart the system.

My question is when a LabVIEW (EXE1) program opens a reference to hardware resource and shares the reference to another LabVIEW (EXE2) program and crashes abruptly.So there is EXE2 in running state with the references opened by EXE1. Can the EXE2 close all the references?

[rolfk]

I'm pretty sure a reference is process scoped. That means sharing a reference across process bounderies is not really going to help you. The reference is not meaning anything in the other process.

[Bob_Schor]

I was unaware you should share references across executables.  I have shared references against detached processes (code run with Start Asynchronous Call), and have had issues where a detached process was left running, and the easiest way to stop it was to reboot the system (though I think I figured out a utility that could search for processes and stop them), but then started adding code to my processes that (I hoped) would guarantee that they could be stopped.  Then it only became a question of proper error handling in my Main so that on Error, it would be able to call the Shutdown routines.  Of course, this assumes no BSOD ...

BS

[billko]

I think it's recommended that you reboot the OS in the event of ANY application crash, not just LabVIEW.  Windows XP was really bad about not cleaning up after an app crash.  I think Vista and 7 were better at it, but still could lead to an unstable environment.

[rolfk]

It really depends a little. Even XP was fairly good about releasing normal OS objects such as all kind of handles (files, synchronizationo objects, GDI objects, etc). But once kernel resources get involved things get a lot  more trickier and I really doubt there is an universal way for an OS to make sure even such resources get properly closed on process termination without a very intensive, expensive and performance hungry bookkeeping. And I don't see the average user wanting to pay that price in performance all the time for the incidential case when the system crashes.

So in general it is safer to restart the OS after a crash even if the system seems to work fine, This is definitely true if your application has been involved in some way with directly invoking kernel drivers, which any application that interfaces to NI (and other manufacturers) hardware basically does. I'm not saying that NI couldn't possibly improve that in the user space part of those drivers somehow. However the effort for that could be pretty expensive and the perceived advantage would be small for most end users.

[Praveen_a09]

Thank you rolfk and billko for joining the discussion.

As rolfk said, the references are related with process and all the references die out when the process has crashed. But, do the references actually point to the hardware devices, so that they might be still valid from the hardware point of view; or they are invalidated by Windows OS once the process has crashed and exited? This I want to try and test with programs in LV.

And Bob told that opening a VI with asynchronous call makes it to run as separate process, (but it runs as separate thread in the same process memory space as far as I know), If it still runs even when the first LV process is closed; do this running process be able to refer to the open hardware and close it?

Billko, you are right. It is the OS that allocates the hardware devices for the process and when the process is crashed, windows should release the resources used by that process, but that's not happening even with Windows 7. And coming to LabVIEW, I wonder why they can't provide a resource management utility that can be used to deallocate the resources in the event of LV crash. 

Once again, thank you all.

[Praveen_a09]

Once again, thank you all.

[rolfk]

Opening a VI asynchronously doesn't make it automatically an out of process component. As far as Windows is concerned it is still part of the LabVIEW process. And if that process dies the asynchonous VI dies too.

You would have to start up a second LabVIEW process and run the VI in question through VI server in that other process. It would look the same in the LabVIEW diagram except that you have to first somehow start a second LabVIEW instance and in the Open Application node connect the IP address and port of that instance rather than leaving them open, which indicates the local process VI server.