flush event queue and record number of events flushed

[Jay14159265]

Hello, 

When using event structures I typically limit the number of events in the queue to 1 so things don't queue up. I ran across a case that I need to ignore queued up events but I need to know how many times an event happened. I thought I would use the flush event queue to do this but having never used it before was not able to get it to do what I need (because of my lack of knowledge on directly interacting with the event queue I'm sure )

I made a demo vi that shows what I have going. My goal is to clear any value changes that happen in the 'wait' case and to display how many events were removed from the queue. This is a contrived example so there is no practical application represented here. 

Perhaps someone can let me know what I need to do to get it to flush the events. 

Thanks 

-J

[paul_cardinale]

1. Remove the Event Reg Ref wire (did you notice that it's causing an error?).
2. Your Value Change event for the "Wait" button it set to lock the front panel until the case completes; that makes it impossible to trigger more events during the wait.

[Jay14159265]

Hello Paul, 

Thanks for looking. I removed the Event Reg Ref wire. I did notice the error but I was not sure how the flush event queue vi got a reference to the event case.

I made the change and updated the vi to REV B, it does not throw the error any more but it also does not flush the event queue. Even though the 'wait' case is set to lock the front panel until the case completes, events are still being queued up as you can see in the plot of timeout deltas and the newly added counter on the 'wait' case. 

Does the Flush Event Queue vi need to have some reference to the event case or should it run as is in the vi? 

-J

[JÞB]

When using Boolean controls with latching mechanical action you MUST have the terminal in code that will execute to read the value and reset the latch.  If the terminal is not read, the latch is not reset and no further value changes may occur.

When there is an event case that fires on the value change event for a latching Boolean control place the terminal INSIDE the case that handles the value change event.

Both of your latching Boolean controls (Stop and Wait) are outside the event structure and outside the while loop so the values can only be read once. Just move them into the right event cases and don't worry about trying to flail about why the events aren't firing. They aren't firing because you cannot reset the latches.  This also explains why you are confused about the flush event queue output.  Since the Boolean value change is only occurring once there is nothing to flush.

[billko]

---

@JÞB wrote:

When using Boolean controls with latching mechanical action you MUST have the terminal in code that will execute to read the value and reset the latch.  If the terminal is not read, the latch is not reset and no further value changes may occur.

When there is an event case that fires on the value change event for a latching Boolean control place the terminal INSIDE the case that handles the value change event.

Both of your latching Boolean controls (Stop and Wait) are outside the event structure and outside the while loop so the values can only be read once. Just move them into the right event cases and don't worry about trying to flail about why the events aren't firing. They aren't firing because you cannot reset the latches.  This also explains why you are confused about the flush event queue output.  Since the Boolean value change is only occurring once there is nothing to flush.

---

I wonder what odd architecture is the OP using that a flush is even necessary?

[Jay14159265]

Hello Jay

Thanks for taking a look. I moved the 'wait' button inside the event structure and made the mechanical switching action 'switch when released'. I made a REV C version of the new vi. But the problem still stands.

If you click the wait button 5 times as fast as you can, it generates 5 user events and queues them up and runs them as can be seen by the 'number of times wait is called' field and can also be seen in the delay it causes between successive calls to the timeout case. 

What I would like to do is after the first click in the 'wait' case clear the other 4 'wait' clicks that got queued up. 

I thought I could do this using the 'Flush Event Queue' but I don't understand where to put the 'Flush Event Queue' so that it clears the event queue after the button click events are put in the queue. Right now the 'Flush Event Queue' vi is in the 'wait' case but maybe that is the wrong spot (or not configured correctly). 

 I would be happy to try any other advice to get it to clear the event queue. 

Thanks 

-J

[Jay14159265]

---

---

I wonder what odd architecture is the OP using that a flush is even necessary?

---

In many years of programming labview I have never had to worry about flushing the event queue. Then I found this VI called 'Flush Event Queue' and I said; "I have never used that before, lets give it a try." Lo and behold I could not get it to work, and I could not find a satisfactory example. So here I am at the mercy of the NI community trying to learn something new. If you know how to use it, please let me in on the secret. Also, If you know of any examples please point me to them and if you see any glaring problems in any of the vi's I posted, don't be afraid to tell me just how wrong I'm doing it : ) 

Also from the original post:  " This is a contrived example so there is no practical application represented here. " so there is that ...

[JÞB · Accepted solution]

Modified and attached in LabVIEW 2020

A very nice use of "Bundle" rather than "Bundle by name."  Not too often you run across those.

Notes are documented in the code.

[drjdpowell]

Instead of using Flush, consider this kind of structure, where one handles every Event, but only does the time-expensive operations (that don't need to be done every Event) after the Event queue is empty.  This is done using the Timeout case and a fed-back timeout that is zero.  See attached.

This method is a lot more widely useful than using Flush, as you can gather any info you want from the Events.  In the example, I gather the info about the timing of the Wait button events).

[Bob_Schor]

Just when you think you are pretty "comfortable" with LabVIEW's Event Structure (and have been using it, including with User Events, and even Event Messenger Channel Wires) for multiple years, someone posts a question in the Forum about something you've never noticed (Flushing Event Queues) and several Experts who hang out in the LabVIEW Forum provide very insightful "Teaching Moments".

Thank you, Jay(π-3), JÞB, and drjdpowell for your questions and comments.

Bob Schor