> I expect functions like this (eg Close Reference) to executed even if there is an error in the input cluster.
Exit is different from Close Reference, IMHO. Close Reference is done unconditionally at the end of code blocks. Exit is an actual operation of the application -- and the error on the wire could easily be error code 43, "Cancel Error", which comes out of various operations, like "ok to abort running VIs?" type of dialogs.
I don't think Exit (or Stop) is quite as cut an dried as Close Ref. That's not to say I think this is a bad idea... it would require careful contemplation, as we did with Wait (ms).
> In a good LabVIEW code, there is no Stop LV function.
I think I disagree. I agree that many apps need to do a lot of clean up when they shut down, but you can put that clean up work inside an App Close event frame in each module and trigger all of those frames by firing this primitive. Why not let LV do all of your abort work?
I can probably be convinced the other way. What's your argument?
I talked about the Stop function, not about the Quit LV function.
I really dislike the Stop funtion, because it aborts violently a VI.
To be honest, I dislike the Quit LV function too.
I agree with you it's a way to shutdown all running modules through the App Close event, but I prefer using a dedicated message.
I don't say it's the best way, but in 9 years I saw only one LV developper using this event.
Another related point : if everything is closed properly (dynamic VIs, references, etc...), using a Close FP method on the last remaining module is enough to exit LV (dev or runtime) (see the JKI state machine as an example).
You work in the R&D of NI, right ?
I see your "name" so many times in the NI sphere...
Are you the author of the actor framework ?
Is there a forum of TestStand experts, just like lavag.org for LV ?
Yes. On LabVIEW core team. Coming up on my 15 year anniversary.
> Are you the author of the actor framework ?
Yes.
> Is there a forum of TestStand experts, just like lavag.org for LV ?
Not that I know of, but TS is not generally my knowledge domain.
> I really dislike the Stop funtion, because it aborts violently a VI.
I dislike how it is *typically used*. But that's different from disliking the function itself. 🙂
I've had long term plans to put together more architectures that use that Stop function more agressively. I believe we could write much more resilient parallel programs in LabVIEW in many cases if we were willing to kick off two parallel VIs, wait for either one to finish and then abort the other one. Consider database searches as an easy example: You have two different things to search, say the files on disk and some sort of cloud API. You kick off two separate VIs, one to search the disk and the other to search the cloud. When one of them finds the result, tell the other one to just Stop. No need to do a lot of clean up work in that case. Like Exception throwing in other languages, it can simplify the writing of the main code.
I think there's a lot of room to explore elegant uses of violent abort. It just doesn't get much contemplation from those who worry about hardware states. And even if you need to clean up hardware, that can be done in the caller (launcher) VI. More experimentation is needed here, IMHO.
