A question about the underlying implementation of the event structure or how does Event structure avoid polling?

[nzywlll80@gmail.com]

Event structures are often said as a way to avoid polling front panel controls, but without some sort of recurring structure that continually checks the interface and user actions, how does an event structure detect for events to be triggered?

If this is unavoidable anyway, to what extent can it be said that event structures improve efficiency?

[ZYOng]

My understanding is that an event structure uses an event queue to store user events and handle the user events in the order in which they occur. In contrast, polling checks each control continuously. I guess the main difference is in the number of polling to be carried out at the low level.

Reference: Event-Driven Programming in LabVIEW

[paul_a_cardinale]

Key presses and mouse clicks generate hardware events.  They don’t need to be polled. 

[Yndigegn]

Hi

Basing a diagram on an Event Structure to set off action is the modern way of programming in LabVIEW.

However, the ability to use such a structure weren't possible until LabVIEW 6.1 was introduced in 2001. 9 Years after LabVIEW really took off. And 15 Years after the first release.

So all the initial developers had no choice but to use the polling concept. There are many methods to do so, but that is another story.

And therefore we had the heated, almost never ending story of polling versus event programming on every LabVIEW related forum since 2001.

The fact is that you can write useful programs using either concept. At least I can.

A notice. Even the early LabVIEW versions supported kind of "events", in the form of the Occurrence, the Notifier, the Semaphore, and the Rendezvous. So even in a polling environment one could/should handle these events.

There is this old story of polling takes "time". Yes it does, not much though, so you just program accordingly. No problem.

But use the Event Structure. Nice advices to that end are already given.

Useful references :

https://lavag.org/topic/19355-when-are-events-queuedregistered/

'LabVIEW for Everyone' by Travis & Kring

Regards

[Intaris]

My understanding is:

When you define an event, there is an underlying piece of code in whatever language is being used which handles the "concept" of Events.

When we define an Event, it's like defining a button. When the event is fired, the button is pressed.

So the code might be "If Button Pressed then [X]" but "[X]" is defined only as a placeholder (with datatypes and so on defined). When we register for an event, we have the reference to the piece of code in charge of the "If Button Pressed then [X]" so we can add our code to the list. Then, whenever the Event is triggered, [X] can be executed without any other processes needing to be in any specific state. It is a single context and a single thread.

If I have a process called "Y" which wants to respond to an Event "Z" from module "F" to write a file, I pass on a pointer to the code responsible for writing the file to the event handler to the handler for the Event. Whenever the event "Z" from Module "F" is triggered, the file is written using the code passed on by "Y", but the process "Y" is actually no longer involved. It has, in a way, delegated the functionality to "F"

In some ways, it's code injection into a foreign process. It's just typically used as a mode of communication to the module which registered for the event, but it's not a requirement. Similar to command pattern in Actor Framework.

I've no idea if this is correct, it's how I've always understood it.

[Yndigegn]

Hi

For the first many years LabVIEW was loyal to the wire connecting concept.

The only object breaking the rule was the Occurrence object. An object without a wire source. The program could be set to check for a change and then continue when that change happened. It was typically used in data acquisition to wait for a timer/counter board interrupt to activate it. 

In LabVIEW 5.0 additional objects, the Notifier, the Semaphore, the Rendezvous, and the Queue were added. Which pretty much is what we have today. All these objects are messaging/synchronization mechanisms. Useful but quite exotic. Except for the Queue object.

LabVIEW broke its own basic rule once again when NI bought the Vision Development concept from a French developer. You manipulate multiple Megabytes of image data using a wire to reference the data. Meaning that the compiler cannot determine the order of execution. So you really have to watch out when programming. But useful.

And Kodosky broke it once again why he tried to be smart related to the Control and Simulation Module, introducing the feedback operator. But it had a purpose, so it was ok.

So now on to 'Events'.

Almost all 'Events' have no user source code that generated them. The OS generates them, for button click events and so on. As already described in this thread.

LabVIEW has the pre-made 'Event Structure' that subscribe to events. You add a case in that structure to define what should happen when an specific kind of event occurs. Which would often be calling a Sub-VI. Very simple.

So you don't 'define an event'. Normally not that is. But that is another story.

Modern LabVIEW breaks many of the original paradigms. The original concept was 'follow the wire'.

Modern OOP/class based LabVIEW refers to complex objects that has no wire source. And when there are wires then they are just reference like types. Making figuring out what is going on ( debugging ) difficult. It is not bad, just different, compared to 'legacy' LabVIEW. 'legacy' meaning what our ancestors did.

Some may prefer ( and rightly so ) the 'legacy' programming concept for small LabVIEW projects. My advice is, that if C++ is your thing, then use modern LabVIEW. C++ means a lot of inter-related sub-routines and a minimal main program. If not, then use 'legacy'.

Regards

[Intaris]

Events utilise callbacks.

To further clarify:

Callbacks are when we pass a reference to a piece of executable code as a parameter to another piece of code.

When an event is triggered, it has a set of callbacks associated with it which are then called directly. If the callback is a VI, the VI is executed, if the Callback is for the Event Structure, it will queue up the data in the appropriate data structure for handling by the event structure.

It's the callback element of registering for an event (and the callback functionality exposed by the event handling framework which allows this) which means that no, events do not require polling.

[Yndigegn]

Hi again

About Events and Callbacks specifically related to LabVIEW.

Normal Events, such as those generated by Controls on the VI Front Panel, are automatically serviced ( ~ subscribed to ) by the Event Structure. No need to 'define' anything. 

All the nasty callback stuff is hidden somewhere out of reach for the happy LabVIEW developer.

Only for a few special cases does the LabVIEW coder need to consider Callbacks. The manual says :

https://www.ni.com/docs/en-US/bundle/labview/page/callback-vis.html

A DLL may also require you to create a Callback VI. But again, special stuff.

Regards

[altenbach]

As discussed in the somewhat parallel discussion here, While events somewhat break the original dataflow paradigm, they are still a slave to dataflow. If that even structure is hidden deep in a case structure that is not active or in some other inaccessible place, it will not be able to service the queued up event, independent of the implementation under the hood.

[Intaris]

---

@Yndigegn wrote:

Hi again

About Events and Callbacks specifically related to LabVIEW.

Normal Events, such as those generated by Controls on the VI Front Panel, are automatically serviced ( ~ subscribed to ) by the Event Structure. No need to 'define' anything. 

All the nasty callback stuff is hidden somewhere out of reach for the happy LabVIEW developer.

Only for a few special cases does the LabVIEW coder need to consider Callbacks. The manual says :

https://www.ni.com/docs/en-US/bundle/labview/page/callback-vis.html

A DLL may also require you to create a Callback VI. But again, special stuff.

Regards

---

OP asked a question as to whether events relied on polling. The answer is "no" and the reason is the use of callbacks. It's 100% related to the actual question OP asked. The callbacks are generally, in many languages offering event.based operations, the key to the "no polling required" functionality. Yes, the callbacks I'm referring to are internal, but they are callbacks nonetheless. Sometimes it's worth knowing what's going on behind the scenes in order to make more educated decisions about code.

Fun side-note however, you can also create a callback VI for a standard User Event in LabVIEW. Callbacks are not limited to ActiveX and .NET at all.  It's not really special stuff at all, just not very widely used. It can still be super useful when used in the right situations, though. When a callback is created for a User Event, the event is "subscribed" but not via Event structure. As such, the events are then processes without ever going via an event registration refnum or event structure. These two are not actually REQUIRED to handle Events in LabVIEW. Yes, this is getting into niche knowledge, but for someone who starts asking about the background implementation of events, I think it's an important point to make.