Event Structure Queue

[jon_mcbee]

Is there a way to get access to the queue that holds events that need to be handled by the event structure? I think that there can be multiple queues if the structure is registered for multiple events, but I assume that at some point they are all loaded onto a single queue for handling. I would like to be able to insert an event at the front of the queue in certain situations to ensure that it is handled immediately. All thoughts appreciated.

Regards!

[Yair]

The basic answer is no. If you want to do stuff like that, you need to use a real queue where you can control these things.

As for the single queue theory, as far as I know, even that is not true and there are at least two queues (one for user generated events and another for dynamic events), not to mention what happens when you have filter events, which interact with the queue of any event structure which handles them. In any case, since you can't access this information, I see it purely as an implementation detail (or a bug, actually, since under certain conditions it causes unexpected behavior).

[Black Pearl]

You can use an event driven queued state machine (or better described as message handler). You will capture all events in the event structure, but instead of processing them there, you enqueue them as commands. You either can use the enqueue elements at opposite for priority events, or you use multiple queues for several priorities. The processing is handled inside the seperate consumer loop of that queue(s).

Felix

[jon_mcbee]

You can use an event driven queued state machine (or better described as message handler). You will capture all events in the event structure, but instead of processing them there, you enqueue them as commands. You either can use the enqueue elements at opposite for priority events, or you use multiple queues for several priorities. The processing is handled inside the seperate consumer loop of that queue(s).

Felix

Thank you both for the response. I plan on using the queued message

handler inside my modules, using dynamic events to pass commands

from a controlling VI to the modules. I was hoping I could find a way to

assign priority levels to these events, so i could broadcast an abort command

to all modules registered at a higher priority. I think the solution will have to

be that I have a seperate event struct only registered for a high priority event

that can take control of the producer/consumer that drives the module.

Regards

[Black Pearl]

You also could use a two staged event consumer:

* Register the event structure 1 for the abort event and use a timeout (0 or 1 ms), register event structure 2 for the messages and the abort event (use seperate Register for event nodes!)

Way1: Place both event structures inside one While loop, force execution flow that event structure 2 only executes after event structure 1 went through timeout

OR

Way 2: place event structure 2 inside the timeout case of event structure 1

Way one allows to make the event structure 1 a SubVI, I guess it's better to make that one reentrant. But you need a case around structure 2 anyhow (either a boolean from the subVI or throw an error and use that to inhibit execution).

What happens (or should happen):

* If there is an abort event prior to the loop iteration (fired befor entering the code or during processing an event in structure 2), the structure 1 will catch it, structure two will not be executed and you terminate the loop

ELSE

* Structure 2 is now waiting to process any events. If this is an abort event, terminate the loop

Sounds a bit crazy, but I propably try that pattern myself...

Felix

[Daklu]

Thank you both for the response. I plan on using the queued message

handler inside my modules, using dynamic events to pass commands

from a controlling VI to the modules. I was hoping I could find a way to

assign priority levels to these events, so i could broadcast an abort command

to all modules registered at a higher priority. I think the solution will have to

be that I have a seperate event struct only registered for a high priority event

that can take control of the producer/consumer that drives the module.

Personally I'm not a fan of using events to issue commands to other modules. Technically you can do it but I don't think it's good design. User events are best used as a way for a module to send information out, not take information in. Use regular VIs to have the module expose commands the controlling vi can issue to it. These VIs simply append the user's data to a pre-defined message and put the message/data package directly on your module's internal message queue.