Cause Event 1 or Event 2 or Both???

[Hummer1]

Now that I understand how to use latch action buttons to trigger events (put the control in the event block diagram so it gets read), I have another problem.

Say I want to cause an event by pressing button 1...(that works fine as described above)

Say I want to cause a different event by pressing button 2...(that works too.)

Now comes the problem.

I want to cause both event 1 and event 2 to occur by pressing button 3.

You can't include button 3 change value in the event structure of both event 1 and 2 because you get the "Duplicate event handlers are not allowed." message.

You can't use button 3 to cause a change value(signaling) in a property node value signaling for button 1 and 2 or you get the

"LabVIEW:  When a Boolean control has a latch mechanical action, you cannot use the Value property to read or write its value.

Property Name: Value (Signaling)" warning.

So, I'm sure there is a simple way, but I just don't know what it is.

Any ideas.

The Hummer, once again stumbling over very small stones.

example attached.

[Norbert_B]

Simpler solution: Producer/consumer architecture where the consumer is a state machine (so called "combined architecture").

hope this helps,
Norbert

[rpursley8]

I don't think you can do it like you want.

How about if you change Button 1 and Button 2 to 'Switch until Released' and then set your Events for these buttons to both 'Value Change' and 'Mouse Up'.  When you press Button 1 or 2 the linked event will trigger due to 'Mouse Up'.

Button 3 will then use the Value(Signaling) properties to trigger the two event.  You can connect the matching Value property to each so no actual value change of the button will take place.

[Hummer1]

Actually, I would like to stick with using the change value events so that the vi could be run from another vi if desired.  The only event that gets passed by variables or by using vi static address references is the change value event.

I used to put all my controls in a for loop with a wait for front panel activity.  I used to have all the mechanical action be "press on - press off" (the first option in the mechanical action selections.)  This caused me to have to do the following things.

Within each event, include a case structure for finding out the state of the switch.  (If new value true do what you want, then reset the button using a property node value(signaling)...which did not have any effect on the switch until I included the "Cause Front Panel Activity". )  If the value was false, then don't do anything.  But the changing of the button on the front panel caused another event...so on and on.

Altenbaugh (sp...please forgive ... not worthy of valuable advice from this real pro) and Lynn have convinced me that using the latch action with the switch inside the event simplifies things greatly...and it does...(only one event ... button status gets cleared when the event fires, no need to sort out T/F status of the switch with Case structure...and so on)...there is just this little nagging problem left by this arrangement...

As to the producer consumer architecture...I don't want to go there, yet.  Ultimately, I will build state machines for the management of all this stuff using the state module with the developer suite we have, but ... first things first...just a simple little problem to get my head straight before moving on to the fun stuff.

Thanks.

Never wear sandles in a rock garden....the Hummm

[johnsold]

I agree that Norbert has the right idea.

Separate the concepts of the events and the tasks which are performed when an event occurs.

Here is the list:
Button 1 Value Change Event => Task A
Button 2 Value Change Event => Task B
Button 3 Value Change Event => Task A followed by Task B

By putting the tasks somewhere other than in the event cases, it is relatively easy to do this.

Generally you do not want to put anything very complicated or time consuming inside an event case, so that the event structure can respond immediately to other events. The Producer/consumer state machine architecture and the event structure are very complementary.

Lynn

[Norbert_B]

Another thing to add to Lynns explanation:
Putting dedicated code into the event structure makes it hard to maintain.
Event 1 = Action A
Event 2 = Action B
Event 3 = Action A followed by B
You will have duplicated codesegments.

Choosing the approach you are currently "wanting", you use methods which are not "LV stylish" and can mess up things easily.
Using a queue to ensure order of execution and splitting up event vs action is the best way to do it...

Norbert

[rpursley8]

I forgot to mention in my response that I also usually disable the buttons on the front panel so they cannot generate Value Change events.

[smercurio_fc]

Well, I tend to agree that the producer-consumer architecture is the cleanest way to do this. At the risk of being accused of advocating or recommending "hack" programming I will suggest an alternative. I do this mostly because it's sometimes beneficial to see what can happen when you try to do "hack" programming.

You can use a simple LED (hidden if you want), and use the Value (Signaling) property of that. Your event case for button 1 value change can also handle a value change for this LED. You would need to use a separate LED for each button. In the event case for button 3 you would write a value to the Value (Signaling) property of each LED. Doesn't matter what the value is. I've attached a simple example.

As I said, this is a hack, and not something that I would normally recommend. As has been previously noted, the producer-consumer architecture is the best way to handle this.

[Hummer1]

interesting example...it is simple and does what is needed.

It works. 

I did a simular thing, but did not have any data passing through the while or event boundaries.  My while consumed the entire processor.  So I added the polling timer...thing...to keep the machine cycles down...then I though of adding the wait for front panel activity which led me to moving all the buttons out front with a wait for front panel activity...which lead me to what Altenbach and Lynn found and helped me with.

I note that your while runs only once when each button is pressed...Guess I'm confused about that.  I modified mine to do the same thing and it seems to work as well.  Why doesn't the while loop spin at machine speed rather than waiting for each event to fire?

I think I almost have a handle on it now.

Thanks

Here's my latest...see if that matches what you are thinking.

[smercurio_fc]

In your first example you had an event structure by itself. This is not very useful. An event structure is really meant to be used in a while loop so that once an event is handled it. If the "Timeout" input of the event structure is left unwired it defaults to -1. This means the event structure will sit there until an event occurs. It does not consume CPU cycles in this state. If you want an event structure and have it perform something at a "periodic" rate, you wire a timeout value to the "Timout" input. For example, if you wire a 50 it means that if no events have occured in the last 50 msec, then whatever is in the "Timeout" event case gets executed.