Event structure doesn't fire

[Pavel_47]

Hello,

There is simple case:

• 2 buttons: START and STOP
• when START is clicked, the VALUE increments
• when STOP is clicked, VI should STOP

START functionnality is OK, whereas STOP doesn't work.

Where I've been mistaken.

Thanks in advance

Pavel

[Norbert_B]

Basic rules for event structures:

1. DO NOT USE MORE THAN ONE EVENT STRUCTURE PER VI unless you are very well aware of what you are doing

2. USE A SINGLE EVENT STRUCTURE FOR SINGLE SOURCES. In your case: use ONE event structure to handle all frontpanel activity

3. Put the source of the event inside the event structure case handling that source' events

4. Don't use loop timing and timeout event concurrently

5. NEVER nest event structures unless VERY sure about what you are doing (don't to document this!)

6. Beware of FrontPanel locking!

7. .... (many more following)

Guess which ones are not met by your code....

Norbert

[TiTou]

There is nothing wrong with using mutiple event structures in the same VI, well... almost.

No seriously, there is a list of caveats and recommendations about that.

[paul_cardinale]

This appears to be a bug in LabVIEW.

You can work around it by changing the Value Change event in the 1st event structure so it doesn't defer FP updates.

However I would reccommend restructuring it to use only one event structure.

[Pavel_47]

Thank for suggestions,

I've modified the VI, leaving only one Event structure.

Am I correct while saying that for the scenario, that I described in my 1st mail, the only solution is to employ "state machine" (or case structure) ... at the condition that only one event structure is employed.

Regards

Pavel

[GerdW]

Hi Pavel,

your VI can improved a lot by using latching switches and a shift register for "Running"…

Get rid of all those local variables!

[Pavel_47]

Hi GerdW,

But if "non-latched" switches are imposed by concept, can this VI be still improved ?

Concerning "Running", frankly speaking I didn't understand how to employ it with shift registers.

Could you explain a little bit more (if you have a time, of course)

Thanks in advance.

Pavel

[Norbert_B]

Pavel,

you can get rid of the "parallel case" by simply modifying the timeout time and get the code (increment and display) into the timeout case.

Do something like this:

Do NOT forget to set timeout back to -1 in any event case which stops the timeout!

Norbert

[Ben]

Norbert,

I think Pavel has found a bug.

If you take his example, and edit the event in the fist frame such that it does NOT disable FP unitl Event completes, it works fine.

The bug appears to be that the first event case is failing to enable FP when it completes.

I call it a bug.

Ben

[Norbert_B]

---

@Ben wrote:
[...]

I call it a bug.

Ben

---

Ben,

i am not sure if i should say "contradiction".

The point is that this scenario is definitely NOT recommended and it is for sure not tested for.

Now for the point i am not sure about:

I assume that LV internally treats the code to something like this:

Make a test: Press Stop before Start. If everything would be as simple as you think, the first loop would stop when pressing "Start" and immediatly the second event structure should de-queue the stop.

This is not happening which indicates that both event structures use the same event-queue!

As the source of the structures is the same (FrontPanel) i find this rather expected.....and hence the first structure doesn't revoke the lock on the panel as the second would have to execute as well to make that possible.

Norbert