What is the best way to monitor boolean controls within a loop?

[Ramteke]

Hi:

I am trying to monitor 3 boolean controls within loop. Currently I am using references to monitor the state change. Is there a better way of performing this action? Like using Event structures or local variables.

Thanks,

PR

[Dennis_Knutson]

Not sure why you would be using references instead of the controls themselves but the event structure is the best. Try to completely avoid using local variables.

[altenbach]

---

@Ramteke wrote:

I am trying to monitor 3 boolean controls within loop. Currently I am using references to monitor the state change.

---

It is a bit ambiguous what you possibly mean by "monitor".

To detect state changes, put the value in a shift register, which you compare with the control value in the next iteration using e.g. "not equal". You'll get a TRUE whenever the value has just changed.

If the booleans are just controls waiting for user input, use an event structure.

[Ramteke]

I will try to rephrase my question.

I am using a state machine within a loop. I am monitoring state changes on 4 boolean controls and the boolean controls are within a cluster.

What would be a good way of monitoring the state changes.

I understand that event structures are the best way of doing this but would it be a problem if I used event structures every where I monitor the boolean controls?

Thanks,

[smercurio_fc]

Tip: The OpenG Comparison library has a convenient little VI called "Data Changed" that will allow you to not use shift registers. It makes the wiring a little cleaner.

[smercurio_fc]

Note: I posted my previous response prior to your follow-up, so it got crossed in the history.

To your follow-up: Event structures are not meant to be used in multiple places. You can only have one event structure in a VI in order for it to work properly. This means you need to have your VI event-driven, or state-driven. For a combination you're looking at a producer-consumer architecture. This is essentially two loops. One loop houses your event structure that responds to events and places states on a queue. The second loop houses a state machine construct. If you just want a simple state machine construct then you need some sort of "Idle" state or "Check for Changes" state that you periodically go to in order to check for changes. Prior to the introduction of the event structure I used a state machine construct in this manner. I had a "User Interface" state that simply checked for changes in controls. Whatever changed placed the state to go to in order to handle that event. The states were managed as an array of strings (this was prior to queues).

[altenbach]

---

Ramteke wrote:

I understand that event structures are the best way of doing this but would it be a problem if I used event structures every where I monitor the boolean controls?

---

It would really help if you could attach a small example VI to show what you are doing.

Suddenly you "monitor" controls in many different places? Why? What do you need to do when the state changes, and in how many independent places do you need to do it?

Does the loop spin always or is it sufficient if it spins only when one of the values change?

---

Commenting on the other post by smercurio_fc, there is no problem having multiple event structures in the same VI.

I often have several parallel loops containing event structures, some of them even listening to the same events (e.g. "stop": see Stopevent.vi). There is no problem with that. It gets a bit more tricky if you place more than one event structure in the same loop. Thypcally a bad idea because they tend to block each other. But even here, you could make all event structures in the same loop "transparent" with near zero timeouts and set the loop pacing elsewhere.

Still, I do not recommend overuse of event structures. One or two are often enough. Please also read the recommendations in the online help.

Message Edited by altenbach on 05-16-2007 08:19 AM

[smercurio_fc]

True, you can have more than one event structure in a VI, and I am well aware of that. Whether or not you should, which is what I meant to say, is a different matter. Typically when I see people trying to use multiple event structures they just do it wrong, and just cause more problems than the one they're trying to solve in the first place, so my recommendation is to stick with one event structure. I have not run into a case where I've needed to have events being listened to in more than one place, but I do not assert that such a situation would not, or cannot, exist.