To exit the Labview program

[vivek_sony]

I am working with drivers of a instrument in LABview and want to completely exit/stop the whole Labview program is something goes wrong. Like, indefinate execution of some while loop..etc.. How can I do that?

[Conseils]

Check out the EXIT VI on the Application Control sub pallette

[Dennis_Knutson]

Your while loops should have some sort of error checking to prevent an infinite loop. For example, if you are reading an instrument until a certain reading is detected, add a timeout to the exit parameter. You can simply add an Elapsed Time function and or the Time Has Elapsed output with the existing exit condition. Then if, you do get a timeout, set your error status (in the error out cluster) so that the timeout status can be processed in the calling VI. What you want to do is to always exit gracefully. Simply killing a program can lead to nasty things.

[vivek_sony]

yeah Dennis, I was thinking of what u mentioned. but, I cant make out some simple logic from the existing timing VIs.

[falkpl]

I agree with dennis, use the exit application as a very last resort.  Especially with a driver you want to make sure you leave a device in a safe (from the user and instrument) state.  The last thing you need to do with a driver is leave an instrument in a dangerous state or fry your (usually many $1000s) equiptment.  Error handling will allow this; each vi can have a case structure and error in and outs to allow for error propagation.  This will prevent the vi from executing in an error state, and the error can be passed to calling loops for stopping infinite loops.  Also for drivers you can implement timeout and watchdog situations to further prevent calling programs from crashing on driver calls.  I am not really sure why the exit application is provided, just encourages bad programming practices.

Paul

[Dennis_Knutson]

The attached picture shows a fairly typical error/timeout handling situation. The while loop will terminate if an error, correct reading, or timeout occurs. If an error happens, the error cluster is passed straight though the error case. If no error happens, then the no error case determines whether a timeout occured. You don't have to use the Elapsed Time Express VI. Put a Tick Count or Get Date/Time in Seconds outside the loop and inside, the same function and then subtract last reading from start reading and compare it to the timeout value.

[Conseils]

Well all I feel a little 'ganged up on' there and if one took Pauls comments to heart, some less sensitive souls might have burning ears.

In the spirit of discussion rather than direct critique; I post the following from the 'on-line documentation' to clarify my perhaps overly concise previous posting. Where the comment 'check out' might not be taken in the spirit within which it was intended.

"If quit? is TRUE (default), LabVIEW quits. If you wire an error cluster to quit? and an error occurs, the error cluster passes a TRUE value to the function. "

Paul, are you proposing that the Exit function is not the correct exit technique from Labview?

Message Edited by Conseils on 07-02-2005 12:25 AM

[falkpl]

sorry I am not out to offend anyone, I just have had bad experiences with the exit function.  I had used in the past since it is very easy to use, but have had some bad experiences.  I am just suggesting not to use it if possible because it leaves the system in an uncontrolled state.  Error handling is a much more controlled method of exiting a program.  Just like globals they is often a safer way of controlling a program.  If you can verify that it is a safe method to use then go ahead and use it, but with a driver this is often hard to do since the possible state space of the system is large.  Again I just am suggesting that I have found the exit application commands to be a last resort   (besides the fact that the user can always execute an OS system command and there is no stopping that). 

-Paul

[falkpl]

Other things to consider if you plan to use the exit command to terminate execution on the vi are that the exit command must be able to execute.  If the exit command is in the same thread of execution where the driver/subvi command is stuck in an infinite loop, it will never be called, so you can consider putting the exit in its own thread.  This could be like a watch dog looking for the states you worry about.  Also, There is an exit application event which I think should be called after the exit application is called (I haven't tested this).  In this event case, you could put your driver clean-up calls:  turn off high voltages, reset instruments save unsaved data or anything else which needs to be done to properly turn off the system.

Paul

[Conseils]

This is exactly the discussion I was hoping to stimulate. (I hope interesting, educational and possibly controversial). I think that the most valuable part of the discussion to date is your experience and issues with the application of the Exit vi.

I suspect I may be about to commit heresy to many. But in suggesting what follows, I hope you will keep in mind a British comedy that I like called 'Black Adder' with Rowen Atkinson. I am applying this to many levels in this response. I admit to brevity again here....

He is struck with a dilemma of forbidden love and cares what the world will think and goes to the 'Wise Woman' for advise on his problem: -
She gives him three possible solutions: -
  Kill yourself - 'No' says he.
  Kill the object of desire - 'Not really' says he.
  Kill everyone else - 'Not really practicable' says he.

He elects not to take the advice of the 'Wise Woman' - It transpires that there was a solution, as there was an error - he just didn't have all the facts..........

To add one small part to the story, I would like to add that everything dies eventually!

So here it comes.... Everyone SHOULD be putting in at least one EXIT vi in a production application!
Still sat in your seat?

I propose - For exactly the reason that has been pointed out with regard to the hardware and safe shut down. That is to allow the software (LabVIEW) to do the same. To explicitly and formally state when and where the application terminates - Even if in principle it is not actually intended that it should - the exit point and software shut down sequence should be clearly indicated. I would suggest there should be normally one exit point for a classical application.

To this end the example posted would be modified to include the EXIT vi - when the designer has, resolved all issues or just can't cope any more.
What one tends to see, both in this forum and in released applications; is development code or applications that were never reviewed to completion. Effectivley Beta applications.

NI don't put the EXIT vi's in Examples; as it, of course, EXIT's LabVIEW cleanly and completely!!!! (bit of a pain for a novice). But as a result neither do many others.

So are you a convert to the cause?

Now my questions to the forum are: -
  Do you allow for and provide, a single point of software shutdown; clearly stated and explicitly defined for production applications (would you admit you don't / haven't)?
  If you don't; what do you do?
  How do you go about trying to assure clean up of any problems (I have yet to meet the perfect systems designer, I live in hope).