Limit maximum instances of dynamic events

[pabolleta]

Hi everyone,

I'm trying to develop a module to remotely control some oscilloscopes. For this purpose, I’ve created a generic user interface with several controls so the user can interact with the instrument.

Among these controls, there are some dials/knobs used to adjust parameters such as the horizontal or vertical scale of the instrument. These operations require some processing time, so if too many events accumulate, it can affect the responsiveness of the program — something that tends to happen with this type of control.

Previously, I used to limit the maximum number of event instances within the event structure. However, in the current version of my program, the control events are handled through dynamic events, and this method doesn’t offer the option to limit event instances.

In related posts, I’ve seen that there’s a block called "Flush Event Queue" to clear the event queue, but I haven’t been able to make it work the same way.

Is there any alternative solution to this problem? What is the usual way to handle these kinds of situations? Is there any existing proposal for LabVIEW to include an option to limit instances for dynamic events as well?

P.S.: This is my first time posting in the LabVIEW community forum, and English is not my native language, so I apologize in advance if I’ve missed any important information or if anything is unclear.

Thanks a lot!

[daveTW · Accepted solution]

Hello pabolleta,

welcome to the forum.

As I understand your problem, you want to make sure that you skip most of the very high frequently events coming from the "value change" of some knobs or other controls. But with every event you don't know, whether it ist the last of a series of events. So if you skip every second or nine out of ten, you don't know whether it is the lates with the most current value.

To handle this, in the event case you could put the latest value via shift register in a variable and additionally a "user input available"- flag and handle the time consuming code in the timeout event if the flag is set. This way you would control the latency to the user input via the timout- value.

If you want to handle every e.g. tenth event, you could build a queue with the values (or have a counter), and if there are ten elements in the queue the code is executed. Additionally in the timeout event you have to handle the last event as described above.

This comes from the principle of the event structure, that every defined event will be executed immediately (like 1st level events) and only if for the timeout- period there is no event, the timeout- event will be executed (2nd level event). But this makes sure, the was no 1st level event for a certain time and then you can handle the latest "value change" event.

I hope this was good to understand.

[pabolleta]

Hi Dave,

First of all, thank you very much for your quick reply.

To confirm what you described, your solution proposes using defined events (what you call 1st-level events) to handle/filter control value changes, and using the timeout case as the block where the time-consuming code is executed.

That sounds like a good idea, but I’d like to know if it’s compatible with the structure of my code, which is based on the Queued Message Handler (QMH). In this setup, the code is executed in the Message Loop, while the Event Loop (where the Event Structure is located) is only responsible for handling user interface events. Each time a user interacts with a control and an event is generated, the Event Loop queues a new message, which is later handled by the Message Loop. In other words, the time-consuming code is executed asynchronously from the event.

According to your solution, would the timeout case be used to somehow filter events to avoid the saturation we discussed? That would certainly help reduce the number of events to process.

Best regards

[daveTW]

It should also be manageable to implement this with QMH.

From my understanding then it is important to be able to handle the queued messages for the QMH. In your implementation is it possible to manipulate the message queue? So you can preview the queue or filter for certain elements? Then there would be the possibilty to remove messages except the latest or to skip the time-consuming code execution until the latest element.

[pabolleta]

Hi Dave!

You're right - in my case, it's possible to manage and filter the message queue within the QMH, so that could be another solution.

I've been doing some testing, and the first solution you suggested worked perfectly.

Before closing the thread, I just wanted to thank you for the clarity and speed with which you replied to my messages. You've been a great help.

Thanks so much for everything! 😁

[daveTW]

That ist great to hear.

Good luck.