Continuous Polling versus the Event Structure, please help me understand

[rg8766]

Dear Forum,

I am 3 months into LabView. I have created quite a front panel with what I consider a sensible set of code underneath with a boulean based Input Control feeding a Case controlled set of actions. I attach a heavily striped down version of this structure with many of the button sections removed and the executed code removed to simplify just asking about this control structure. After the recent Webinar I understand this form of control to be called a continuous polling structure - and this makes perfect sense and seems natural to me from the point of dataflow programming.

But according to the Webinar it is considered better practice to use the Event structure.

However the event structure seems really weird to me. My main question here is surely the event structure MUST be polling each of the values itself ANYWAY otherwise how would it know that an event had taken place??

So what is the difference between explicitly "polling" the buttons myself with a while loop and using a complicated (to me) Event structure with 'hidden' polling underneath?

The polling of the 4 buttons in my example should be being done concurrently if Labview is truely multithreaded/parallel? There should be no difference at the machine level between my code doing the polling and the 'hidden' code of the Event Structure doing the polling.

Thank you in advance for you help with clarifying my confusion.

Sincerely,

Robert Gibbs

[DanRen_IQA]

The Event structure is inherently more efficient than polling because while it is waiting for a defined event to occur, your LabVIEW code is essentially idle, using zero processor resources. All of the event recognition is done by the operating system. Think of it like this; does your LabVIEW code have to explicitly handle mouse movements when your code is running? Of course not. The OS handles that. Likewise it is the OS that handles events, like mouse clicks. LabVIEW simply recognizes those events as pertaining to one of your defined Event cases, or not.

Event structures are not that intimidating, once you've done a few programs using them, and you'll likely soon be praising them as well. There are lots of training resources and examples out there to help you learn how to use Events.

Good luck.

Dan

[Ericgo67]

Hi,lets think about it in a everyday example way.

Everyday your getting mail in your letterbox( not the electronic one). if you were to poll you letter box every 5 minute to check if mail has arrived, you would be busy all day long waiting and checking for mail, that leaving no time to do anything else. Instead, your postman rings your bell everyday when he puts mail in your letterbox, to let you know that you can come pick it up. In that case you won't have to wait (poll) your letterbox, but just to do whatever else you want to do beside, eventually nothing (Idling), and react on the Bell (trigger).

The same applies in microcontrollers for example... u can choose to have a main loop polling for inputs and checking state changes, or you can have hardware doing the job for you and allowing the micocontroller software to do eventually nothing. this happens when you put your controller in sleep. The wake up call, eventually an external input, triggers the wake up of the controller and restarts code execution, until it is finished, where the processor can go back into sleep.

The main difference, IMOO, between both mehtods is that with the polling , your software continuously checks the state of your button, a little bit like a Master, while in the Event method, the events decide when the code is going to be executed, and when the programm is going to be idle again , after the code execution, the code being virtually a slave ( it isn't actually , since you are still the one that decides which events are going to find a signification into your codes execution and which won't).

Basically, the polling method is still very ressource consuming since your using your software constantly, mobilising all the ressources available, while the events method just puts the code in sleep until an event triggers the code execution, letting ressources being allocated to other processes.

Hope this helps

Eric

[crossrulz]

---

rg8766 wrote:  My main question here is surely the event structure MUST be polling each of the values itself ANYWAY otherwise how would it know that an event had taken place??

---

No, it actually does not poll.  It uses what are called "Interrupts".  So the OS triggers an interrupt and then your Event Structure performs the duty when an interrupt it is registered for is triggered.  This uses 0 CPU.

The Event Structure will also greatly reduce the amount of case structures and parsing code you will have to do.  You just have an event case for each button and that case reacts accordingly.

[rg8766]

Thank you everyone for your very helpful replies.

It is probably my ignorance, which I am sure will pass as I struggle with this concept, but I still don't understand why there is advantage in processing time between getting the OS to do the polling of everything and sending out  "Interupts" and your own code just looking for itself.

Using Ericgo67's analogy of the postbox. Your code will have to have a "listen for whether the postbox bell, has the bell rung?" poll going on every 5 minutes or it wont know the bell has rung, using triggers is a further abstraction?

Surely the process:

OS checks for button press >> OS encodes what trigger to send >> OS sends a trigger that the button has been pressed >> Labview checks if a trigger has happened >> Labview decodes what action has been encoded in that trigger >> Labview performs appropriate action based on trigger

has more steps and is more processor intensive than

Labview checks for button press >> Labview performs appropriate action when button is pressed ??

Regards,

RG

[Intaris]

There is no polling with events.

When an event is registered on an action, the code the action should execute is idle.  No polling.

Think of it in this way.

Every piece of code which executes has a function pointer which can be added to a stack.  The code then gets executed one after the other in the order of the stack.  Some code may "jump the queue" but that is a completely other topic.

If you register for an event, you are coupling two different functions.  If you want to register an event on Action X (to do Action Y - a case of the event structure) then you are essentially telling the OS to inform Action X to put a pointer for Action Y on the stack when it's finished executing.  It's like dynamically linking the sequence of functions (just with a certain abstracted interface).  This way Action Y is invoked without having to poll for the status of Function X.  You also cannot "miss" events in this way, N calls to X will give you N calls to Y without having to poll anything.

You can't register for events on everything, only "exposed" events can be registered.  These portions of code support the interface required for "when finished put this pointer on the stack" functionality.

That's how I understand it at least but it might be terrible inaccurate in modern OS design.

[crossrulz · Accepted solution]

---

@rg8766 wrote:

Surely the process:

OS checks for button press >> OS encodes what trigger to send >> OS sends a trigger that the button has been pressed >> Labview checks if a trigger has happened >> Labview decodes what action has been encoded in that trigger >> Labview performs appropriate action based on trigger

has more steps and is more processor intensive than

Labview checks for button press >> Labview performs appropriate action when button is pressed ??

---

The OS is already doing most of that process anyways.  So you are actually doubling the effort regardless.  And the OS is a lot more efficient at it than your code will be.  So just let the OS do the heavy work while your code sleeps.

And think of the trigger more like an alarm clock.  You are asleep (doing nothing, using no CPU) when your alarm clock goes off.  You wake up and do the task the alarm told you to do.  When done, you are waiting for another alarm, so you go back to sleep.