DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Number of events "enqueued" from other DQMH modules, how many are there?

Solved!
Go to solution

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"

Michele___0-1712213007395.png

 

 

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?

Michele___1-1712213210984.png

 

or here?

Michele___2-1712213260857.png

 

or inside the ReR?

 

 

thank you for the support..

0 Kudos
Message 1 of 6
(242 Views)

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.

0 Kudos
Message 2 of 6
(204 Views)

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

0 Kudos
Message 3 of 6
(201 Views)
Solution
Accepted by Michele__

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

 

Message 4 of 6
(198 Views)

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!

0 Kudos
Message 5 of 6
(154 Views)

@Michele__, you can also use the Flush Event Queue to handle event structure overflow.

 

OlivierJOURDAN_0-1712582582227.png

 

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.

 

 


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 6 of 6
(141 Views)