LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event structure detect button change? Good practice?

Solved!
Go to solution

Several buttons on the Front panel need to be read in the state machine at different places. To use references feels normal but where to place the terminal?

This time I placed an extra while-loop with an event structure externally relative the loop for state machine. It works great. It feels a little to easy so I asking you, Is this good practice?  I thinking, "something" need to observe the status of the buttons and why not an event structure?

 

(I have only one event structure)

0 Kudos
Message 1 of 10
(984 Views)

Your description is wat too vague to really say much.

 

A terminal gets read when it is in the dataflow and that happens anyway in a well designed state machine, just don't bury the terminal inside deep stacks of structures.

 

A secondary event loop is sometimes useful to do UI changes, but should probably not be the main tool to read terminals because you still need to read the new values elsewhere where they are needed.

 

Can you explain your use of "references"? Are you talking about local variables or something more convoluted?

 

It probably would help of you could attach a small code skeleton so we can more easily tell what you are talking about.

 

0 Kudos
Message 2 of 10
(963 Views)

Sorry. I used wrong description. Not Reference, I mean Property Node.

 

I understand that using this method of reading buttons and use the status in another while-loop needs caution but if you are aware of the behaviour it works well I think.

 

Thanks!

 

0 Kudos
Message 3 of 10
(897 Views)

There's nothing inherently wrong ('it works'). But the program might not scale up well.

 

In general, you don't want waits in an event structure. The idea of the event structure is to be responsive. The wait in an event case blocks the user interface until the case is done. 

 

Sometimes it's OK that the user interface blocks. Sometimes it's even desirable.

 

Let's say you add a stop button. The program won't stop until the wait finishes. If you increase the wait to 60000 ms., that will really bother the user.

 

Things will get worse if you add waits to the second loop. You should, as atm it uses 100% CPU on one core. But if you do, timing between loops will start to misalign.

 

There are numerous solutions to the problems you don't have right now... We can talk about them next 😁.

0 Kudos
Message 4 of 10
(882 Views)
Solution
Accepted by topic author TakeANap

BTW. I'd put the terminals in the control's event case (value change event if there are multiple events).

 

That way, I can double click the control and land in the control's event case.

 

Also, latching buttons will automatically latch, so there's no need to reset the value. You'd have to put it in a (*sigh*) sequence structure if you want to latch it after a wait.

 

If I register for controls dynamically, I usually put all controls on the top level diagram. Definitely not in the event loop's while loop. That loop has no relation to the controls at all, so it feels random to me.

Message 5 of 10
(873 Views)

Yes. You right. No wait in a event. The wait was just a "quick-fix" I added so I could see the green LED on the button lit up when I pressed it. Everything in the prototype was quick-and-dirty. 🙂

However, the application I will use this technique in is not a huge one and will not be bigger. I think I have 13 states in the machine.

 

I have problems with latching buttons when I need to read the status in a prop.node. I haven't thought about it so much. Therefore I often use this "normal switching" buttons.  (I think I use wrong structure if I need to read a value via prop.node to a latching button)

0 Kudos
Message 6 of 10
(854 Views)

I have problems with latching buttons when I need to read the status in a prop.node. I haven't thought about it so much. Therefore I often use this "normal switching" buttons.  (I think I use wrong structure if I need to read a value via prop.node to a latching button)


Yes, latching basically work well only with the event structure for triggering actions like start, stop, save, close, etc. If you have Boolean controls that really have two states like enabled/disabled, high/low, etc. they should not use latching. For reading the control value (at least on Booleans), local variables give better performance than property nodes.

 

Still, the missing question here is, how do you transfer the information from an event to our state machine. You probably want to have something where your events send messages to the SM using a queue or something. There's plenty of NI examples and (3rd party) frameworks available for something like this. I don't know your application well enough to say more. 

0 Kudos
Message 7 of 10
(840 Views)

@TakeANap wrote:

However, the application I will use this technique in is not a huge one and will not be bigger. I think I have 13 states in the machine.


Famous last words 😂.

 


@TakeANap wrote:

I have problems with latching buttons when I need to read the status in a prop.node. I haven't thought about it so much. Therefore I often use this "normal switching" buttons.  (I think I use wrong structure if I need to read a value via prop.node to a latching button)


That is the solution and the problem mixed together.

 

The wait is required, or the event loop will latch the button, so the wait is needed. Because the wait is needed, and the switch action, the 2nd loop can actually read the switched state of the button.

 

You'll get a much more robust mechanism if you decouple the GUI and the 2nd loop completely. This means, don't use controls and indicators in the 2nd loop. Let the event loop handle the GUI, let the 2nd loop be it's slave. Handling\using the GUI in both loops will complicate things a lot, although it seems manageable at the moment.

 

You could have a look at the classics master\slave pattern. This decouples the event loop and the slave loop with a queue.

0 Kudos
Message 8 of 10
(809 Views)

wiebe@CARYA wrote:

@TakeANap wrote:

However, the application I will use this technique in is not a huge one and will not be bigger. I think I have 13 states in the machine.


Famous last words 😂.

 


@TakeANap wrote:

I have problems with latching buttons when I need to read the status in a prop.node. I haven't thought about it so much. Therefore I often use this "normal switching" buttons.  (I think I use wrong structure if I need to read a value via prop.node to a latching button)


That is the solution and the problem mixed together.

 

The wait is required, or the event loop will latch the button, so the wait is needed. Because the wait is needed, and the switch action, the 2nd loop can actually read the switched state of the button.

 

You'll get a much more robust mechanism if you decouple the GUI and the 2nd loop completely. This means, don't use controls and indicators in the 2nd loop. Let the event loop handle the GUI, let the 2nd loop be it's slave. Handling\using the GUI in both loops will complicate things a lot, although it seems manageable at the moment.

 

You could have a look at the classics master\slave pattern. This decouples the event loop and the slave loop with a queue.


I've never seen an engineering tool not grow up into a full-fledged application.  Once word gets out that you have this neat tool that does "A", someone asks you if you can make it do "B" as well.  Next thing you know, it becomes the application that you use to talk to a family of devices.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 10
(788 Views)

 

You'll get a much more robust mechanism if you decouple the GUI and the 2nd loop completely. This means, don't use controls and indicators in the 2nd loop. Let the event loop handle the GUI, let the 2nd loop be it's slave. Handling\using the GUI in both loops will complicate things a lot, although it seems manageable at the moment.

 

You could have a look at the classics master\slave pattern. This decouples the event loop and the slave loop with a queue.


 

I like the idea! Between you and me 😊, I don't like the use of prop.nodes. Why? Doesn't feel right. I try to avoid it.

You mention queue. I have played with it but haven't used it yet in a serious application. Perhaps now is the time.
The state machine use a main cluster that hold all the vars and indicator values application use.  I can see that the event handler can react on a variable in a cluster. That is....a way forward I think.

Thanks for all the good advice.

0 Kudos
Message 10 of 10
(782 Views)