LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Event Inspector Window - Unhandled Events: "how bad" are they?

Solved!
Go to solution

Hello,

can I read the sequence # in the event structure? I mean, I'd like to understand the sw flow during the run time and I need the sequence#, at the moment I'm doing it by myself. Please see the attached VI.

 

Thank you,

Fabio

0 Kudos
Message 11 of 16
(665 Views)

First, you should have started a new thread for your question. It has nothing to do with the original topic. Secondly, use a shift register for your sequence number. Then you can access it in any case of the event structure. It will need to be wired through all event cases.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 12 of 16
(642 Views)

@Intaris wrote:

I have just tested it and it is indeed exactly as mentioned, an Event structure deletes all registered events which it is not told to handle.


I know this is an old thread, but I just ran into it when researching a specific aspect of the topic, and for the sake of posterity, I wanna clarify (or maybe just say in my own words?).

 

Regarding programmatically registered events - both user events and UI events:

 

  • An event structure handles all events contained in the event registration reference that is wired to the Dynamic Event Terminal (usually that means all user event references that are wired to the event registration node).
  • If there is no event case in the event structure for any of the registered events (the event inspector window calls those "unhandled"), those events will be silently discarded.
  • The event structure can only discard events when it's "entered", i.e. when it is waiting for events or for the timeout. This means that as long as a case in the event structure is executing, it cannot discard any unhandled events.

The last point led to a nasty memory leak in one of our customers' application, where the event structure was stalled in one case, which led to unhandled events not being discarded, which led to a crash eventually.

 

Also, since the last comment here, a new source for learning is available: Olivier's great presentation about "10 things to know (or more) about events in LabVIEW"




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 13 of 16
(248 Views)

The status of being handled or unhandled by the event structure here is a bit of a red herring.

 

This would result in RAM consumption independent of whether the events are handled or not, no?

0 Kudos
Message 14 of 16
(217 Views)
@Intaris wrote:

The status of being handled or unhandled by the event structure here is a bit of a red herring.

 

This would result in RAM consumption independent of whether the events are handled or not, no?


I agree, yes. Here's my understanding:

 

  • For each event that we register for, the event registration creates an event queue behind the scenes.
  • From the point of time of the registration, events are enqueued and thus use up RAM. 
  • Only an event structure (ES) can dequeue events (and thus free up memory).
    • if a case was created inside the ES for an event (NI calls this "handled"), it is processed and its memory freed up only whenever this case executes
    • if no case is present in the ES for an event (this is "unhandled"), it gets discarded only while the event structure waits for the timeout or other events to happen - i.e. those events do not get discarded while any other event case is being executed (or, obviously, if the ES is not executed at all)

Reading it back, it makes sense. I don't think I've ever thought about this (and picked my words) so diligently 🙂





DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 15 of 16
(206 Views)

@joerg.hampel wrote:

Reading it back, it makes sense. I don't think I've ever thought about this (and picked my words) so diligently 🙂



Understanding precisely how Event Structures and Events in general work has been a real revelation to me. Jack Dunaway's post from years ago opened my eyes to how it actually functions "behind the scenes".

 

Events which have been registered (either statically within an ES or dynamically via "Register for events" node) are "deallocated" when they are handled or the "Event Registration Refnum" of the associated event registration is destroyed.

 

An event which is "next" in the execution queue of an Event structure (ES maintains order of execution of events across multiple different events) will be deallocated whether it is handled or not..

 

This changed in LV 2013 IIRC. Up until then, the memory leak was present even if the ES didn't hang. The events would be queued up and never handled, and thus never deallocated.

Message 16 of 16
(200 Views)