06-18-2010 01:19 PM
I have been developing some control code that uses an Event loop to both handle "front panel" events (rare things, like button pushes, where time isn't so critical) and State Machine processing. My State Machine "state" is an enum, and I've created a "dynamic event" to handle it. By raising a "new state" event whenever it is necessary, the Event Loop wakes up and does whatever processing is needed to start the state.
I want to have several independent State Machines running in parallel. The legacy code developed in LabVIEW 7 I am "modernizing" used "servers", VIs that were called through VI Server and were passed "messages" telling them what to do. I found that keeping track of these multiple "servers" problematic, among other reasons because it was difficult to "follow the code" and find the VIs being called.
In one implementation, I used a single Event Loop and implemented multiple State Machines by having multiple Dynamic Events, each controlled by a separate "state machine enum". However, having only a single loop means that the State Machines "block" each other -- while processing the code for one state, no other state can be recognized.
The obvious way around this is to have parallel Event Loops, i.e. multiple While loops inside of which is an Event structure. Each Event structure would handle a single (and different) Dynamic Event, that is, each loop would process the "state" of its own State Machine. This runs counter to the "conventional wisdom" that says "Do not put more than one Event Structure in your VI" (this is a quote from Travis and Kring).
Being an experimentalist, I went ahead and implemented a three-event-loop test that basically blinked three front panel lights at different frequencies. It worked perfectly, and there didn't seem to be any "cross-talk" among the three event structures. Only the first of these had "conventional" events (e.g. a Front Panel "Stop" button) associated with it -- the other two had only a single Dynamic Event.
What (if anything) are the drawbacks to this LabVIEW paradigm? Do independent Event loops handling only user-created Dynamic Events interfere with each other? [I suspect the answer is "no"].
Bob Schor
06-18-2010 03:16 PM
We use multiple event structures for programming. It is a really good way to do what you are talking about. It also allows for you to have a common exit if your loop does not have to shut down differently than the other loops, or have common commands for all of your loops when they need to do the same thing. An example of this is I have three loops for data acquisition AO, AI and DO. If the USB gets unplugged I can send one command to all three loops to reset, start and read the channels when the system is plugged back in.
What (if anything) are the drawbacks to this LabVIEW paradigm?
If you register events to the event structure you have to have the event registered independently to each loop. An example of this is say you have a global event that tells all of the loops to go to safe mode. You have to register the event to each loop independently. You will not be able to create it once and tie it to all of the event loops with one wire. If you do that the first loop that gets the event clears it from the rest of the event structures.
Do independent Event loops handling only user-created Dynamic Events interfere with each other? [I suspect the answer is "no"].
You can register any event to the event structure you just have to know what you are doing. You can have one event do the same thing in every loop say exit or you can send different commands to individual loops.
I am sure that there a some people that would say that it is bad practice but I think if you know what you are doing and are careful about what you put in each loop you should be OK. I hope this helped.
06-21-2010 02:04 AM
Instead of having multiple event structures, use one Event structure that can add an element to one or more Queue's or Notifiers (under Synchronization). That way your Event Structure is kept very lean and fast, and your application will be very responsive. Each Queue/Notifier can drive a separate, parallel While loop. This is known as a producer/consumer model. Have a look at these links:
http://zone.ni.com/devzone/cda/tut/p/id/3085#toc5
http://decibel.ni.com/content/docs/DOC-5404
http://zone.ni.com/devzone/cda/tut/p/id/3023
Try to keep any lengthy code out of your event structure.
06-21-2010 02:52 AM
@pauldavey wrote:
Try to keep any lengthy code out of your event structure.
Just one minor correction to that:
Try to keep any lengthy code out of your UI event structure.
Using an event structure with only user events as part of a state machine can work fine with "lengthy" code inside the event structure.
Shane.
06-21-2010 07:57 AM
@aeastet wrote:
...
Do independent Event loops handling only user-created Dynamic Events interfere with each other? [I suspect the answer is "no"].
...
THe note about sepearate registrations for each event struture stands.
Re; intefering with each other?
I throw this out just to get you thinking a bit.
Filter Events give you a chance to cancel same. So if you have multiple swtructres registered for a filter event the events are serviced in the order they were registered so if there are three structure registered for teh event the first can see and pass it the second cancel it and the last never sees it.
Ben
06-21-2010 08:17 AM
Too late to edit but here is a link to a mind blowing thread on event registration.
Let your coffee start working before you attempt to read that thread.
Ben