Timing within the Queued Messenger Handler

[Hiphiphooray]

Hello all,

I have a Queued Messenger Handler program similar to the Continuous Measurement and Logging (CML) template.  Events on the front panel create a "ui queue message" that the UI Messenger Handler recieves.  The UI Messenger Handler then sends a "data queue message" to my Data Loop vi.  (This is similar to the acquisition loop in the CML template.)

The Data Loop vi is intended to read priority messages sent from the UI Messenger Handler, such as start, stop, terminate. Once it reads the start message, it enters the start case and continually performs a task once every X milliseconds.  When a priority stop message is sent, it should immediately stop performing the tasks.

I'm thinking it should involve the Data Loop continually sending messages to itself to perform the task.  That way the priority message could easily slip in front and shut down the process.  Is this a correct implementation?  If so, how do I make sure the task is performed at the correct time?

Thanks!

[crossrulz]

What I tend to do is use the Timeout of the queue.  You can store your timeout in a shift register.  Have it default to -1 (wait forever).  When you get the start message, you store your time in ms in the shift register.  Then if no message is recieved before the timeout, you perform your iterative task.

[Hiphiphooray]

I'm a bit confused. What exactly does the timeout do to the queue?

[Bob_Schor]

If a Dequeue function has a non-negative Wait configured, when that many milliseconds have expired without another Element to dequeue, it will "unblock" with its Timed Out? terminal set to True.  You can test that with a Case statement, thereby detecting "I did not get a request in Time t" and doing whatever is appropriate.

Bob Schor 

[crossrulz · Accepted solution]

Just to rephrase what Bob said...

The timeout is acting as your timing source.  So if no message was recieved within the timeout given (negative waits are wait forever), then the queue returns the default value for the data type (ex empty string for a string data type) and the "Timedout?" output is TRUE.  You can detect this and perform whatever action you need to at your intervaled rate.

The beauty of this setup is that if a message does come in you can handle it immediately.

[Jacobson-ni]

In mikeporter's write-up about user defined events he does something similar to what was suggested above. It might not be exactly what you are looking for but it's an interesting read that may give you some additional ideas.

http://www.notatamelion.com/2016/03/22/dynamic-udes-the-power-for-reentrant-processes/

http://www.notatamelion.com/2016/04/12/implementing-dynamic-user-defined-events/