event structure vs case structure

[nkhoa]

I am developing LabVIEW: instrument control and vision. Front Panel will have many buttons, each button will execute a single or a group of VIs. 

I have found that:

1. Event structure is good for numerical change. i.e. User change a corordinate and motors are moved. 

2. Case structure is suitbale in case such that use clicks "run MTF", a case structure is excuted to compute MTF. 

I have tried to use event-strcuture to pick up button click but it's NOT workign reliably, such as user clicks too fast and LabVIEW doesn't register the event or LabVIEW registers the same event twice 😞

However, I will have many case structures for many functional clicks. My block diagram will be umanageable. 

Any insight/tip/trick will be greatly appreciate! 

-best

[Bob_Schor · Accepted solution]

If you understand how LabVIEW works, and understand the principle of Data Flow, what I'm about to say will make sense.

The idea of an Event Structure is that it sits there, taking no CPU time, until an Event (typically a change in a Front Panel Control) takes place.  Then it does whatever you instruct in its Event case.  The trick is to do almost nothing in the Event structure, but to tell another loop, running in parallel, to do something.

The key idea here is that you have two loops, running in parallel, independently, at their own rate.  One, the Event loop, is waiting for an "Event".  When it gets it, it "sends a message" to the other loop (or loops) which do the processing (that might take some time) as specified by the Event loop.  The point is that sending the message (which is usually done via a Queue) is very quick, so the Event loop is capable of responding much faster than the User can push buttons on a Front panel.

On the other hand, when the Event loop hands off the Message "Go Do This Task" to another loop, the task can take additional time.  If the tasks are put on a Queue, then as they get finished, the next task will be run.  The key element here is that the two loops, the "Asking" loop (Events) and the "Doing" loop, run indepedently and at their own speed, neither dependent on the other.

Bob Schor

[nkhoa]

Ah! Thanks!!

FIrst time hearing of queue concept. Will check it out!

Link is here

http://www.ni.com/white-paper/3023/en/

[altenbach]

Bob already gave you good advice on desing patterns, but some of your original words bother me

---

nkhoa wrote:

I have tried to use event-strcuture to pick up button click but it's NOT workign reliably, such as user clicks too fast and LabVIEW doesn't register the event or LabVIEW registers the same event twice 😞

---

Event structure will pick up all clicks and queue them up in the event queue unless you limit the event queue specifically. There is no such thing as "too fast" or "the same event twice". By default, events also lock the front panel until the event completes. If you click twice, you will have two successive events queued up. Some mechanical actions (e.g. switch until released" booleans will fire two events, one on press, and one on release.)

---

nkhoa wrote:

However, I will have many case structures for many functional clicks. My block diagram will be umanageable. 

---

 Are you now talking about case structures or event cases? If the task is complicated, the code necessarilty cannot be simple. A good code architecture goes a long way of keeping  complex code manageable. For example instead of many buttons, use an array (or cluster) of buttons. Now you only have one terminal on the block diagram instead of many.

Maybe your description is too ambiguous. We could give much more targeted advice if you could show us some example code of what you are doing.

[nkhoa]

I used event-structure WITHOUT queue. In fact, this is the first time I have heard of queue 🙂

attachement is image to illustrate what I have been doing. I have realized that my approach wouldn't be effective. "Queue and Event-Structure" might be the way to go. 

(Sorry, I have used Labview for more than 1 year, but still lack of technical terms)

[Bob_Schor]

Sadly, the image you showed is not an Event Structure!  To see what I'm talking about, open LabVIEW 2012, choose New Project (or Create Project -- I forgot what it says), and create the Queued Message Handler example.  This is a little more complicated than you need, but it shows an Event Structure (the loop on top) and a Message Handler (the loop below).  The idea is that (as you can see) the Event loop does almost nothing -- it only puts a "Message" on the Message Queue, and leaves all the work to the Message Handler loop, below.

Actually, maybe a simpler way to go is to start LabVIEW, go to File, New, and from the Create New dropdown, choose From Template, Frameworks, Design Patterns, Producer/Consumer Design Pattern (Events).  This is exactly what I'm talking about (I'll have to remember to suggest this ...).

Bob Schor

[nkhoa]

Bob 

Thanks! I will check it out. 

To further illustrate my previous point, please see the newly attached image. 

Image 5 cases structures and 1 event-structure in the VI. IT has made my main VI unmanagebale. 

The new design pattern (queue and evcent-structure) seems to be able to largely reduce the unncessary complexity that I am encoutering.

[RavensFan]

The event structure should have a Boolean 1:Value change event.  The Boolean1 button should be latch action and placed in there.  You won't need to write a false to the value property because reading a latch action boolean will automatically reset it.

Likewise a Boolean 2:Value change event for tha one.  Boolean 2 should be latch action and placed in that event case.  Any other Do action code belongs in the respective event cases.

Now you'd have one while loop wrapping one event structure.

[nkhoa]

understood 

thanks!

given that I will have 5+ of these case structures. Do you think queueing approach make it more elegant and efficient? 

[RavensFan]

No.

Queueing only makes sense if any given action takes a long time and you want to pass off the activity to another loop to do processing and allow the event structure loop to return to looking for more user interaction.