Event structure doesn't fire

[Norbert_B]

There is indeed no obvious documentation on this (at least i haven't found it within 3 minutes...), but i want to share my "best practises" when using FP "Boolean" based events:

1. Always use boolean mechanical action "Latch When Released". This is the common and recommended button behavior for most Windows based applications (oops, clicked on the wrong button but still pressing the mouse? No problem, move away and release the mouse button, no harm done!)

2. Always put the button terminal into the event case handling value change. This is necessary for graphical update (refer to event structure caveats)

Following the both rules never let me down in the past and is indeed also a solution for the original VI (thanks Ben for highlighting!). So Ben is correct when stating that a mechanical action from "Switch" based buttons fire two events where the second blocks the FP in the original VI code.

Norbert

EDIT: So my assumption of a shared queue reveals itself to be wrong. I already had a struggle with that theory and all because i simply failed to check the buttons mechanical action...... 😞

EDIT 2: Pavel, can you please add a quit button to the VI (and handle in the event structure to stop the loop!). Having to stop the VI with "Abort" is very bad practise!

[Pavel_47]

Hello,

I've complicated the VI, getting it more close to final task.

Here I'm trying to control signal generation by 2 buttons:

• clicking to "START" runs square signal generation
• clicking to "STOP" aborts generation

The "START" functionnality works, but "STOP" doesn't.

Once generation started, the button "STOP" seems to be not accessible.

Thanks in adavnce

Pavel

[Pavel_47]

Here with wired waveform parameters

[crossrulz]

---

Pavel_47 wrote:The "START" functionnality works, but "STOP" doesn't.

Once generation started, the button "STOP" seems to be not accessible.

---

Data flow 101.  You have a While loop that can't be stopped (basically a constant due to the tunnel) and the event structure cannot be checked again until that inner loop stops (everything inside of a loop must complete before a loop can iterate).  Now that we are seeing more of what you are trying to do, I say you really should go to a state machine architecture.  States should include: Idle (where you check for the button presses), Start Acquisition, Stop Acquisition, Write Waveform.  The idea should be that when you press the start button, you go to the Start Acquisition state followed by the Write Waveform state.  From there, bounce back and forth between the Idle and Write Waveform states until the stop button is pressed.  When that happens, go to the Stop Acquisition state.  There should not be any loops inside of your state machine.

[Pavel_47]

Ok thanks.

According to this concept, button actions are controlled in 2 states:

• "IDLE" (waits for "START" button)
• "Write WaveForm" (waits for "STOP" button)

Should I use 2 "event" structures or use single "event" structure outside state machine ?

[Norbert_B]

You will not "Wait" for button interaction. In a classic state machine, you "poll if something changed". And there is only one state doing this: Idle.

There are a lot of possible, suitable approaches to your task which most likely depend on your skills in LV:

- State machine (polling)

- User Interface Event Handler (event based)

- Producer/Consumer (event based)

Please take a look into all three architectures (aka "Design Pattern") by opening the template browser (File >> New). Select From Template >> Frameworks >> Design Patterns to access them.

With LV 2015, the simple state machine was removed there as it is now available in the project wizard (Create Project).

Try to understand those architectures and walk through basic LV tutorials in case you don't understand them (or attend a LV training class!).

Also try to sketch a possible solution on paper using a traditional pen (so no electronic device!). If you come up with a design (flow chart, state chart, ...) which looks promising to you, pick the architecture which is closest to that approach.

Norbert

[Pavel_47]

Ok, thanks

[Intaris]

Ben, I have encountered this hugely non-intuitive behaviour of LabVIEW int he past.  The problem for me is that the first Event structure cannot STOP listening to events.  This is why I love using user events, even for FP items because this way I can disable the registration, something we can't do with "static" events.

Oh, I had an idea for something similar on the Idea Exchange but it dies a slow death (Less than 5 Kudos in 5 years).