Controlling execution order of init/release

[BPerlman]

I have a small program I am writing in LabView.  It is exercising an API (a set of VIs wrapping the DLL functions to control a device). 

The other such programs in our shop make liberal use of sequence structures.  I understand that sequence structures in LabVIEW are not usually recommended.  I am trying to write my program with better LabVIEW style (as much as I understand -- I am still a relative novice in LabVIEW).

I found that I could wire together the error in/error out terminals to create a data flow to control the order of execution, and it works beautifully.

However, there are a few cases where this is not sufficient.

Here is one example.  Hopefully the answer to this will answer my other questions.  If not, maybe I'll post more.

One of the first VIs I call is an Init function.  One of the last VIs is the Release function. 

The Release function must be called at the end, after the rest of the program has completed execution (in this case, that is after the user requests stop).  So it should naturally be at the end (or almost end) of the chain of error in / error out connections (as it is currently).

However, the error in that it receives, which will determine whether or not it should execute, should be the output of the Init.  Release should run even if something else failed.

I have enclosed a picture demonstrating the problem, with most of the code snipped out (as exactly what happens in the middle is irrelevant).

What is the elegant way to handle this in LabVIEW.  Is this truly a case for a sequence structure, or is there a nicer or better way?  How would you recommend handling it?

Thank you very much.

BP

[pincpanter]

A classical case. Not sure whether it's an "elegant" way, however my opinion is that if you think that the code into Release should be executed in any case, just execute it, irrespectively of the error input value. Just pass the error value out unchanged, or merge it with a possibile error in Release.

[stevem181 · Accepted solution]

I agree with what pincpanter said, plus you need to use the status from the "Init" function.

Note that you can ignore the error in and do the merge inside the Release Vi if you like.

steve

[BPerlman]

Thank you.  I did something very similar to what you suggested.

I didn't want to change the release VI because it will be used by others.  Also, I don't want it to always execute, regardless of error in.  Sometimes when there are errors it should not run.  Really I'd like to just wire the error out of the init to the error in of the release -- that's logical here.  But then I have problems with controlling when release is executed.

I'm attaching an image which shows approximately what I did.  Note that I did not have to pull the status out of the error cluster -- wiring the error cluster directly to the condition of the case statement gave me a beautiful "error" / "no error" case statement which is color coded too (red around the error case and green around the no error case).

A big part of the key for me here was the "Merge Errors" VI.  I was hoping there was something like that but didn't know about it.  (Just a note; when helping inexperienced LabVIEW programmers like me, it would be helpful to show the label of a VI like this, so I could know better what it is and find it.  I got it, but it took me a bit of work to figure out what that VI was and where to find it.  Pardon my ignorance....)  This helps me with something else I wanted to do, which was to execute two independent initialization paths in parallel, but come out with one error cluster....

Thank you.

BP