How to stop an application?

[Eric1977]

Is there any way you can show us what you've done so far? I think if we SEE what you've have already, we can better understand what kind of stop mechanisms you can use. Package up all your VIs and your project file in a ZIP file and send it to us.

If not, can you give us an example of how you have it structured? Seeing what you've done can tell us SO MUCH MORE than words can.

[JimB.]

---

@1984 wrote:

---

You certainly shouldn't need to send multiple AppStop, then you have some bad design. If VIs are serial it's easy enough to send out a Stopped boolean or simply set an error "User stopped" that'll prevent the following VIs to run.

As for parallell tasks, a Notifier or Event solves it well.

---

As I wrote above my VIs use event structures. If during the execution of VI#1 the event occurs it stops VI#1, but then VI#2 again registers the event (or I roll the dynamic event terminal from VI to VI) as the event is alreay fired it just stay there.

I could query the notifier status periodically but right in the original post I mentioned that I'd like to avoid continously polling something in the timeout of the event structure. As this would be a very simple latching notifier I wouldn't even bother using it cause I could use a latching FGV.

Stop boolean? Sure it might work if you have four VIs, not when you have hundreds. Plus of course does not work with events.

An error could be used, thats true. Its not the holy grail thoughas at a certain point I need to differentiate between "non-critical" and "app stop" type errors which again introduces a new coding "must do".

---

Passing from one event structure to another is not really an ideal architecture, especially if those event structures are being used for application control.

There's a few ways you can tackle this. Quickly off the top of my head, a basic way would be to use a simple state machine inside the timeout case of your event structure to execute these VIs in sequence. A stop event occurring in between iterations will trigger the stop case to run instead.

[RTSLVU]

---

@1984 wrote:

---

An error could be used, thats true. Its not the holy grail thoughas at a certain point I need to differentiate between "non-critical" and "app stop" type errors which again introduces a new coding "must do".

---

That's what custom error codes are for. I use these custom error codes in one of my larger programs.

5000 Safe Operating Limit Trip
5001 Find Instrument Fail
5002 EOT Shutdown
5003 User Abort
5004 Emergency Stop
5005 Application Closed

5000 and 5004 instantly disable all power sources, turn off all high current DC switches, and initiates a buffer dump of measurements taken at 100mS intervals of the 10 seconds prior to the error trip.

5001 Just throws an error message and allows the end user to try again or exit

5002 Shuts everything down and exits

5003 and 5005 askes the use if they want to leave the UUT powered or shutdown then exits

[1984]

---

If not, can you give us an example of how you have it structured? Seeing what you've done can tell us SO MUCH MORE than words can.

---

Sure, see the BD below.

How does it work:

1. If no error occured so far then this VI does nothing
2. It handles errors in two ways:
   1. An error comes in. In this case the the error is stored in the "ProgramEndGroup" container. The storage is done by the leftside VI in the middle, the mechanism is not important
   2. The second VI in the middle reads the "ProgramEndGroup" container and passes out any error stored there as well as it outputs TRUE on its output. This means if any VI anywhere in the application threw an error to this container then this VI outputs that error 
   3. (its easy to see that if an error comes in or an error occured somewhere else then from that point the error cluster from the middle will always have that error)
3. As a result if an error occures then the VI latches the "Program end" boolean TRUE, latches the error out and the generates an App exit event once.
4. If no error is occured but the "force program end" is TRUE then the VI generates one event, latches the "Program end" boolean TRUE and throws a custom "program end" error to the "ProgramEndGroup" which ulitmately latches the error output as well

(there is nothing in the other case of the case structures just passing thru the inputs)

(Generating the event once is a problem which I have described earlier in my posts so the most actual version of this VI  (not attached) generates an event everytime its executed and an error occured, meaning that AppExit event is generated multiple times)

This VI is used in two ways:

1. there are some VIs executing continously running loop(s). At the end of the current iteration this VI is called and used as an exit condition (either the error output or the Program End output based on the part of the app). This is the "POLLING" usage
2. There are VIs using an event structure. For these VIs this VI is placed before the event structure and the structure registers to the App exit event. This is the "EVENT BASED" usage of the VI.

[Yamaeda]

---

@1984 wrote:

---

You certainly shouldn't need to send multiple AppStop, then you have some bad design. If VIs are serial it's easy enough to send out a Stopped boolean or simply set an error "User stopped" that'll prevent the following VIs to run.

As for parallell tasks, a Notifier or Event solves it well.

---

As I wrote above my VIs use event structures. If during the execution of VI#1 the event occurs it stops VI#1, but then VI#2 again registers the event (or I roll the dynamic event terminal from VI to VI) as the event is alreay fired it just stay there.

---

Thus the comment about serial VI's. When the 1st gets cancelled it should send out a boolean that it's cancelled or set an error so the following ones don't register.

[Yamaeda]

I'd do something like this:

[Eric1977]

---

@1984 wrote:

---

Gonna bust your boys a bit here...next time, upload the VI instead of embedding an image. We can't debug images.

[1984]

Cool, mate! Let me bust back bit: if the concept is not clear from the screenshot and detailed explanation then attaching a more complex structure would not go thru either. I can't really attach the VI anyways due to the high number of dependent VIs.

And just to pre-emt a doublebust: I've been on these forums for 15+ years, and never - not even once - I saw an example of somebody receiving effective help based on attaching an entire project. People have no time to understand the concept of others (understandable) and if somebody does attach a project then the conversation immediately deters unrelated nuances of the code (not understandable). 

No offense (and non taken on my side) and I appreciate your efforts trying to answer my question!