Reset Stop Button after event structure activated

[brianmacinnes]

Hi All

1st post. I want to be able to abort Process_1 with the stop button  in the attached VI and then reset the stop button so it can be used to abort process 2. I cannot figure out how to reset the stop button so it can be used in the Process_2 event structure. It stays true when I read the new value in the value change event. Tried local variable, value signaling. Any help or suggestions would be appreciated.

[GerdW]

Hi Brian,

---

@brianmacinnes wrote:

Any help or suggestions would be appreciated.

---

Restart your VI from scratch! (Sorry for sounding harsh…)

• Use only one (1) event structure in your VI. (That's NIs recommendation in the LabVIEW help on event structures!) Really: only one event structure for the whole VI!
• Don't hide event structures within while loops within cases within another while loop: you need only one (outer) while loop for a proper statemachine!
• Generic advice: draw your statemachine behaviour on a sheet of paper to define the algorithm…
• Use a shift register for your "status lights" to eliminate all of those locals!
• You don't need those one-frame sequence structures…
• You don't need to wire the error cluster through a case structure when it is not used within that structure…
• Those case structures can be replaced by simple Select nodes to determine the next state…
• …

---

@brianmacinnes wrote:

I cannot figure out how to reset the stop button so it can be used in the Process_2 event structure. It stays true when I read the new value in the value change event.

---

Because you don't read the stop button (terminal) within the event!

Because you set the mechanical behaviour to "switch…" when you want to use a "latch…" behaviour instead!

[Bob_Schor]

There are two obvious problems with your code.

• By "convention" (which you are allowed to ignore, but possibly at your peril!), the "Rectangular" Boolean Icons (Stop, OK, Cancel) have their Mechanical Action set to "Latch when Released", and are meant to be used in a Top-Level VI's Event Structure.  You can, of course, change this, but it is ill-advised (it will certainly be confusing to most LabVIEW Users who expect the Latching behavior).
• Much more serious, you have two Event Structures in your VI.  I wouldn't dare predict what complex behavior will result, but there's probably a good reason NI warns against this. .

Rethink your Event Handling logic and use a single Event Structure.

Bob Schor

[billko]

---

@Bob_Schor wrote:

There are two obvious problems with your code.

• By "convention" (which you are allowed to ignore, but possibly at your peril!), the "Rectangular" Boolean Icons (Stop, OK, Cancel) have their Mechanical Action set to "Latch when Released", and are meant to be used in a Top-Level VI's Event Structure.  You can, of course, change this, but it is ill-advised (it will certainly be confusing to most LabVIEW Users who expect the Latching behavior).
• Much more serious, you have two Event Structures in your VI.  I wouldn't dare predict what complex behavior will result, but there's probably a good reason NI warns against this. .

Rethink your Event Handling logic and use a single Event Structure.

Bob Schor

---

I've noticed that new LV programmers are just fine with case structures having multiple cases, but fail to make the connection that an event structure is just a fancy case structure where cases are executed according to what event happened instead of the value of a wire.  They end up thinking that they need a separate event structure for each event.

[brianmacinnes]

I can make sub VI with their own event structure for each of the processes but I am still stuck on how to provide the user with 1 button to abort each process in the master VI and then reuse the button as a possible abort for the next process.

[altenbach]

---

@brianmacinnes wrote:

I can make sub VI with their own event structure for each of the processes but I am still stuck on how to provide the user with 1 button to abort each process in the master VI and then reuse the button as a possible abort for the next process.

---

You make very little sense. Please carefully read all advice, starting with Gerd's.

The secret is a clean state machine, not a pyramid of event structures inside loops inside case structures, and so on! One toplevel loop, one (or NO!) event structure. If your processes can happen in parallel, a little more code is needed but I doubt that's the case here.

You also don't need any local variables!

Don't use signaling value  properties!

Process_2_max has the wrong representation.

Since you are polling anyway, you don't need any event structures at all!

If you use typedefs, please attach them too! Why does the state enum not have an idle state?

It is super annoying if the front panel and diagram windows are maximized to the screen. Why?

[altenbach]

See if this can give you some ideas ... keep it simple!

[brianmacinnes]

Thanks for the input. I will take another stab at defining the flow issue. I have attached 2 main vi and 1 sub vi. The first Main vi uses a while loop to start the vi and using references is able to stop the conditional for loop in the subvi. This is the behavior I want. The second main vi is done with event structure. My current work around is to open the subvi front panel so the user can stop the ramp if needed. I would like to start and stop the subvi with event queue in the event structure but have not figured out how to do the event structure correctly.

[altenbach]

You have several serious problems:

1. The event is set to lock the front panel until the event completes, so you cannot interact with it while the subVI event is running. (It is generally a really bad idea to have lengthy code inside event cases!). You should probably do an asynchronous call instead.
2. The subVI is set to MODAL, so it will be on top of all other windows and won't allow you to interact with the main VI while the panel is open. Bad idea if it is left open during editing. Why do you set the front panel to modal if it is typically is not even open?? And NO, also setting the caller to MODAL is just plain silly!
3. "Start ramp" and "stop main VI" should be latch action.
4. You can reset the "stop ramp" after the subVI completes via a local variable.
5. Don't do the call setup to show the front panel of the subVI if you don't want it to show.
6. Don't attach VIs that are claimed by a library.
7. Use reasonable connector assignments. The Numeric ref input should NOT be on the right edge!

As I said, you should really improve the overall architecture. This is just a band-aid fix to get it working with minimal changes. Not recommended!

[brianmacinnes]

Can you resend attachment in version 19. Thanks in advance.