LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event structure in event structure

Solved!
Go to solution

Is there a way I can have an event structure which is in another event structure? When I run the code, I can't operate other buttons. (See diagram for clarification) 

 

EventStructure.png

0 Kudos
Message 1 of 13
(6,322 Views)
Solution
Accepted by topic author AndreaD

Don't put event structures into event structures! There is never any reason to do so.

 

Re-architect your code into a proper state machine.

 

 (By default, events lock the front panel until the event completes and if you trigger the inner or outer event first, the other event can never fire because the current event can never complete or is unreachable by dataflow.)

 

Message 2 of 13
(6,303 Views)

@AndreaD wrote:

Is there a way I can have an event structure which is in another event structure?

 


Yes, you have already found the way, you have also found the reason that it is ill-advised 🙂 Unless everything is pushed in the exact right order, your code locks up! 

 

I can't tell exactly what you are doing in that event structure, but if you want to change some instrument settings, you could do it in a Sub VI that "pops up" when it is run. You could also put the instrument into a parallel loop to wait for messages from your main loop. 

Message 3 of 13
(6,282 Views)

You can use event structure within event structure. The reason behind your problem is, front panel is locked until event finihses it's task.

        Then only way that you can acess other controls in front panel when an event occurs is have to wait until that event case complete its task. Here first structure start to execute its case, but task of first structure enabling another event within that structure that is not possible becuse front panle is locked until fisrt event structure finishes its task. In order to avoid this, select first event structure>edit events handled by this case>uncehck the option called "Lock Front Panel until the event case for this event completes" . 

Now you are able to do what you said in question.

But it is not recommended. Instead you use state machine or producer consumer architecture!

 

here i attached an image.

 

 

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
Message 4 of 13
(6,248 Views)

@dhans wrote:

 

Now you are able to do what you said in question. 


No, he won't!

 

For example even if the events don't lock the front panel, things will not work right unless the controls are clicked in exactly the right order.

 

Imagine if the user presses "Test" 100 times at the start of the program. Nothing will ever happen until "agilent DAQ" is triggered, at which time the inner event structure will also execute right away, leaving 99 event queued up. For the next 99 times, this will repeat. From a user perspective it will not be usable unless you jump through flaming hoops to disable/enable controls depending on the current "state" to enforce that buttons are only pressed once and in a defined order. Since you now need to keep track of the current state, you need a state machine anyway. 😉

 

 

0 Kudos
Message 5 of 13
(6,232 Views)

Yeah, you are right. This is only possible if user use controls in an ordered manner. But i mentioned in my post that this not a recommended style of programming. 

Best Regards,
Dhans 😉
Kudos are welcome 😉
Aspirant Labview Programmer (Labview 14) 😉
0 Kudos
Message 6 of 13
(6,225 Views)

Dynamic registration for ui events to the redcue.....

0 Kudos
Message 7 of 13
(6,222 Views)

@Intaris wrote:

Dynamic registration for ui events to the redcue.....


Is something can be easily fixed with less code, there is no reason trying to fix it by throwing even more code at it. 😄

0 Kudos
Message 8 of 13
(6,206 Views)
It is recommended to create proper state machine architecture and once the first event is fired call for a state where you can place your sub vi to pop up for the user input if needed.

It's better not to have time taking logic inside event which will make the user from accessing other controls during emergency. So always use event for capturing the particular event and from there you can transverse your state to different cases based on your requirements using state machine architecture.
----------------------------------------------------------------------------------------------------------------
Palanivel Thiruvenkadam | பழனிவேல் திருவெங்கடம்
LabVIEW™ Champion |Certified LabVIEW™ Architect |Certified TestStand Developer

Kidlin's Law -If you can write the problem down clearly then the matter is half solved.
-----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 9 of 13
(6,188 Views)

The target of my post was threefold.

1 you cant put an event structure in an event structure (you can if you do it properly)

2 I still dislike that we cant tell an event structure to stop listening to statically assigned ui events

3 I cant remember what the third was, maybe it was purely disruptive...

Smiley Surprised

Message 10 of 13
(6,182 Views)