04-04-2024 02:12 AM
Hi,
i have several DQMH modules in my project. the main function of one of them is to log into TDMS some data that come from other modules
i decide to configure the TDMS file inside the MHL of logger module, but to write data into TDMS inside "helper loop". the helper loop is registered to the dynamic event (logger module's Request and wait for reply) called "Logger RT APE"
DQMH module's that generate data for tdms use the dynamic event "Logger RT APE" (without wait for the reply) to send data to the logger and they could send for example 1D array of DBL around 100/200 elements every 50-100 milliseconds.
i cannot control how many times this dynamic event is called..i would like to undertand if there is a way to know how many events have been "enqueued"...maybe "enqueued" is not the correct word...because they are not queue...
for example can i access this informations here?
or here?
or inside the ReR?
thank you for the support..
Solved! Go to Solution.
04-04-2024 10:05 AM
Why do you want to know how many events are in the event queue? Needing to know this information in any async framework (events in a DQMH request/broadcast event queue, messages in a DQMH message queue, Actor messages in AF, etc.) is almost always a code smell of some sort.
04-04-2024 10:24 AM
Hi Darren,
1) because a lot of module could call this event
2) inside the API in the helper loop there is a TDMS write.vi (not advanced write)
i want to be sure that all the events will be executed (tdms writing speed is faster than enqueue events)
i cannot control the ReR using wait for reply = TRUE
do you need more info?
thank you
04-04-2024 10:38 AM
If you are firing too many events for your helper loop to handle, then you need to come up with a different design. What exactly would you have the code do if you find that your events are backing up?
That being said, you can follow this (unsupported) procedure to query the size of the event queue:
https://forums.ni.com/t5/You-May-Not-Know/Programmatically-Inspect-Event-Queues/ba-p/3549367
04-08-2024 03:48 AM
Hi Darren,
i will follow the usupported features to test only the first time to check if the logger's helper loop is faster respect to enqueued events. i'm very close to the final release of the sw...so i hope that the results of the checking will be truthful
if the number of events will increase i would like to generate a warning, so i can take actions. in any case, this request is caused by the fact that i decide to not use Request and Wait for replay = TRUE, so i'm not sure that the log event is executed (within the timeout).
i would like to preserve the DQMH design, adapting its features to my needed (for example using helper loop to log data coming randomly from several modules). i know that there is always a way to do it better, if you've thought of another way to do this, I'd be happy to hear about it 🙂
thank you!
04-08-2024 08:28 AM
@Michele__, you can also use the Flush Event Queue to handle event structure overflow.
The example shown above is available on GitLab.
I encourage you to read the Help to understand how this function works.
Hope it can help.