What are the best practices for detecting non-UI trigger events? (Polling seems not)

[nzywlll80@gmail.com]

Responding to UI events with an event structure is generally considered to be a more efficient model, but in practice actions are often triggered by non-UI events, such as buttons, scanner inputs, and what is the best strategy for responding to these types of inputs? Polling doesn't seem to be a good solution.

[billko]

You mean like, for a physical button, etc?  I guess, generically, anything can trigger a user event.

[ZYOng]

Creating Custom Events

[altenbach]

---

nzywlll80@gmail.com wrote:

Responding to UI events with an event structure is generally considered to be a more efficient model, but in practice actions are often triggered by non-UI events, such as buttons, scanner inputs, and what is the best strategy for responding to these types of inputs? Polling doesn't seem to be a good solution.

---

You have now started two basically identical thread (see here), and it is not obvious what problem you are actually trying to solve. There is nothing wrong with polling (... and before the event structure was introduced, that's all we had).

You mention the term "efficiency" without really defining what you mean by that. Are you trying to solve a particular problem? Do you have performance issues? The polling overhead is typically insignificant compared to everything else. You can poll a button many millions of times per second, so if you chose a more reasonable polling interval (e.g. 50ms), the CPU use is a tiny fraction of a percent. I can guaranteed that if you have performance problems, polling is never the culprit.

Event structures have their own set of problems, especially for the inexperienced programmer, and there are plenty of landmines if you don't exactly know what you are doing. For example an event cannot fire unless it is waiting and ready and there could be dataflow issues preventing that if you are not careful.

You have only very generically said what your program is supposed to do and what kind of triggers you are monitoring and what the reaction time boundaries need to be. For example if you need to instantly react to hardware triggers with hardware responses (e.g. a very fast PID loop (Maglev train) or fire an airbag when a crash is detected) only an FPGA solution would work.

[paul_a_cardinale]

---

@altenbach wrote:

---

nzywlll80@gmail.com wrote:

Responding to UI events with an event structure is generally considered to be a more efficient model, but in practice actions are often triggered by non-UI events, such as buttons, scanner inputs, and what is the best strategy for responding to these types of inputs? Polling doesn't seem to be a good solution.

---

You have now started two basically identical thread (see here), and it is not obvious what problem you are actually trying to solve. There is nothing wrong with polling (... and before the event structure was introduced, that's all we had).

You mention the term "efficiency" without really defining what you mean by that. Are you trying to solve a particular problem? Do you have performance issues? The polling overhead is typically insignificant compared to everything else. You can poll a button many millions of times per second, so if you chose a more reasonable polling interval (e.g. 50ms), the CPU use is a tiny fraction of a percent. I can guaranteed that if you have performance problems, polling is never the culprit.

Event structures have their own set of problems, especially for the inexperienced programmer, and there are plenty of landmines if you don't exactly know what you are doing. For example an event cannot fire unless it is waiting and ready and there could be dataflow issues preventing that if you are not careful.

You have only very generically said what your program is supposed to do and what kind of triggers you are monitoring and what the reaction time boundaries need to be. For example if you need to instantly react to hardware triggers with hardware responses (e.g. a very fast PID loop (Maglev train) or fire an airbag when a crash is detected) only an FPGA solution would work.

---

My guess is that he believes that there’s no such thing as a hardware triggered event and therefore, under the hood there’s always polling.  This leads him to wonder what the point is of an event structure. 

[nzywlll80@gmail.com]

My operating system knowledge is very limited. Does the underlying mechanism(OS Interrupt handler service) for detecting hardware triggered events not require polling?It doesn't seem possible to me, i think it's just that polling at the OS level(CPU periodically checks to see if an interrupt has occurred is more efficient than polling the front panel in the LabVIEW software

[paul_a_cardinale]

---

nzywlll80@gmail.com wrote:

My operating system knowledge is very limited. Does the underlying mechanism(OS Interrupt handler service) for detecting hardware triggered events not require polling?It doesn't seem possible to me, i think it's just that polling at the OS level(CPU periodically checks to see if an interrupt has occurred is more efficient than polling the front panel in the LabVIEW software

---

No, it does not require polling.  When hardware triggers an interrupt, it interrupts the software* and an interrupt service routine is executed.

* That's why it's called an interrupt.

[LLindenbauer]

---

nzywlll80@gmail.com wrote:

My operating system knowledge is very limited. Does the underlying mechanism(OS Interrupt handler service) for detecting hardware triggered events not require polling?It doesn't seem possible to me, i think it's just that polling at the OS level(CPU periodically checks to see if an interrupt has occurred is more efficient than polling the front panel in the LabVIEW software

---

The question is very open and unspecific, so the answers will be, too.

Generally, just about every micro-controller or microprocessor you would consider programming for and running a program on will have hardware and software interrupts (e.g. check the interrupt handling on 6502). Hardware interrupts can trigger on an electrical signal (e.g. a keyboard indicating a button press), software interrupts can be triggered by internal clock counters (e.g. a periodic function to check every second if the processor is still running). These interrupts stop the current execution and cause the processor to do something else to deal with the interrupt. Check out Ben Eater's 6502 Keyboard Controller for a very hands-on demonstration.

[altenbach]

In the case of an event structure, all it can do is place an item in the event queue. There is still no guarantee that the event will execute without a delay, because there are many other factors that can interfere or even block it forever if the programmer does not know what they are doing.

I also assume you are running under windows, which might decide that other things are more important than your LabVIEW program, event structure or not.

Back in the mid nineties, my LabVIEW program ran on a 100Mhz Pentium 1 (64MB Ram, 2GB HD) under windows 95 and there was no event structure in LabVIEW 4 (not even "undo"!) and I never had issues with polling. Today, computers are many orders of magnitude more powerful. You still did not really say what your timing constraints are and what problem you are trying to solve. Your program will spend 99%+ doing other things, and that's where optimizations are more useful.

[nzywlll80@gmail.com]

I'm still a little confused. If you want an interrupt to occur, it seems that the software/operating system still has to perform certain checking processes periodically, and when a hardware interrupt occurs, branch to the interrupt handler. This process may not usually be called polling, but it seems similar（That is, there is a program that runs periodically and initiates the appropriate proceure depending on whether an interrupt occurs or not）.