Act when any control changes

[Ken_Brooks]

I need advice on how to structure a complex interaction loop. There are some things that need attention only if a particular control is changed. There are also calculations that need to be done, and a graph updated, every time ANY control is changed. But no reason to waste processor time doing those calculations when the user has not done anything. How can I structure such a loop to work efficiently? The "Event" structure seems almost, but not quite suitable.

I also find myself wishing that the event structure had an "Initial" case that runs exactly once the first time the structure is entered. It would let me put code comfortably in there, together with all other related code, instead of having to stick it someplace off to the left. Anybody got some good tricks for this one?

Ken

[GerdW]

Hi Ken,

you should try a (event driven) state machine to decouple events (like control change) from actions (like generating plot). Then you could have several events (like single control vs all controls) starting the same action...

When "firing" a value change event via property node ("Value.signalling") you could easily generate an event on startup of your VI to "call" the event structure!

[Mark_Yedinak]

I would recommend that you look at the producer/consumer architecture. This consists of parallel loops (tasks) with one of the tasks generally being an event structure. The producer (the loop with the event structure) can monitor the controls for changes. When an event occurs it would send a message, generally using a queue, to the consumer loop (generally a state machine) which then process the event. Using this archictecture you can fire off the necessary commands based on which controls were modified. You could include a message which would get sent for when any control is modified as well. When there is no activity both loops could be idle. Or your state machine may be doing some regular background processing as well.

[smercurio_fc]

A producer-consumer architecture can do what you want. You can have the producer generate the events, and have the consumer determine whether to do the actual action. If you wanted to not even have the event be handled you could go so far as dynamic event registration. An example ships with LabVIEW showing you how to do this.

[Lucither]

Like Mark said, you need to look at the Producer/Consumer loop. As for your 'Initial' state, this would be implemented in your case structure in your consumer loop. Before entering the Consumer 'While Loop' you would create and then fill a queue with an 'Initialisation' State. This is generally used to set all initialisation code, like setting control states, reading ini files etc........

[Mark_Yedinak]

---

Lucither wrote:
Like Mark said, you need to look at the Producer/Consumer loop. As for your 'Initial' state, this would be implemented in your case structure in your consumer loop. Before entering the Consumer 'While Loop' you would create and then fill a queue with an 'Initialisation' State. This is generally used to set all initialisation code, like setting control states, reading ini files etc........

---

Depending on the initialization this may be done before both tasks are started. For instance if you need to create any LVOOP objects that are used in each of the tasks this is best done before starting the task so the wire can be wired directly to both loops. Where the initialization occurs really depnds on exactly what is being initialized and how much needs to be shared between the tasks.

[Ben]

---

Ken Brooks wrote:

...

I also find myself wishing that the event structure had an "Initial" case that runs exactly once the first time the structure is entered. It would let me put code comfortably in there, together with all other related code, instead of having to stick it someplace off to the left. Anybody got some good tricks for this one?

Ken

---

In really simple code like a user dialog I have used the Time Out case to do that using a trick I learned from Christian.

Feed the Time out value from a Shift Register.

THe loops should start with a TO value of "0' to fire the Time Out and do the init stuff. When the TO event completes it returns a value "inf" to the SR so the TO event never fires again.

Ben

[Lucither]

Good point. I'll get back in my box