inspect queued events in a compiled application

[ensegre]

Debugging an application of mine, I ran into a very possible occurrence of https://lavag.org/topic/9986-out-of-order-events-is-not-a-bug-sort-of/ . Now, I have reasons to suspect that, due to some race, while in the IDE I have a positive timestamp difference between one certain dynamic and another user event, in the compiled application the two can be nearly simultaneous. Enough for treating the race in the first place, but academically wondering: in the IDE I can help myself out with the Event Inspector; can anyone suggest a way to filter and display information from the event queues in the apps? Looking at the GUI of the Event Inspector, that looks like one of these many tools written in G, modulo using password protected blocks, I haven't been diligent enough to search for its whereabouts yet. LV2014.1.

Otherwise, for the present case, I suppose that just sequencing the event generating blocks together with a Clock Tick and displaying the results may do, for the debugging I need.

 

TIA, Enrico

[pawhan11]

If You want to monitor all messages comming from Queues or UE i think You should create another thread in application that will handle that. Whenever You enqueue message you will also add copy about that message + time, source and whatever you want and sent it to thread that monitors all of that.

[ensegre]

Right, that is a quick way and fits well my need of knowing the event fired timestamp; and when it is about filtering out just a couple of events out of many, it's really easy to set up an additional concurrent while loop with an event structure for them two. Thanks.

 

However, remark, this doesn't give access (not that I really need it) to further information visible in the Inspector, such as the event and queue number. I would have expected some queue accessor from the Events Palette, like Preview Queue Element or Get Queue Status for regular queues. The only one of this kind, on the Events palette, is Flush Event Queue.

[ShaunR]

Right, that is a quick way and fits well my need of knowing the event fired timestamp; and when it is about filtering out just a couple of events out of many, it's really easy to set up an additional concurrent while loop with an event structure for them two. Thanks.

 

However, remark, this doesn't give access (not that I really need it) to further information visible in the Inspector, such as the event and queue number. I would have expected some queue accessor from the Events Palette, like Preview Queue Element or Get Queue Status for regular queues. The only one of this kind, on the Events palette, is Flush Event Queue.

 

If you want a queue. Use a queue primitive. The queue that is used for events is an opaque implementation detail that is part of how Events are realised internally within LabVIEW. If you want a more accurate timestamp, pass it as a parameter. In some of my event systems and even some TCPIP implementations I have a "send" time. You can hook the event with a viewer and logger if you want to analyse your messaging and compare sent and received times.

 

Forget that events have a queue and even forget that they happen to have order on any particular event stack. Certainly don't rely on it - you'll live longer and with more hair.

Edited October 11, 2015 by ShaunR

[drjdpowell]

Debugging an application of mine, I ran into a very possible occurrence of https://lavag.org/topic/9986-out-of-order-events-is-not-a-bug-sort-of/ . ... LV2014.1.

 

I thought they had fixed that issue before 2014.

[ensegre]

Much plausibly so. By now I've found the reason for my bug, actually elsewhere than in the time difference between the events. Nevertheless, the discussion helped. I have among the rest used what pawhan suggested to exclude simultaneity in the application, and went on pondering the faulty logic to find the true reason.

@shaun: yes, it was an academic question... I used queues with timestamped data too, when I needed so.

[hooovahh]

I thought they had fixed that issue before 2014.

I thought so too but personally never had this issue.

 

The Event Inspector Window is indeed a LabVIEW UI.  I posted at some point where I wanted the ability to get a queue status on user events, similar to a normal queue here.  I eventually made an idea exchange (linked in that thread) but looking at the source you can see that there is some what of an API for reading the event queue but it is for the whole application, and you need to do decent amount of filtering to get to the structure you want, and the events you want.

 

I'll be honest I haven't personally used this beyond a demo to see that it is possible, I don't know what kind of potential memory issues using this might have.  That being said I do have a demo that shows it in action.  Attached is a VI that when ran will query the event inspector data and show the events queued up, what VI they are from along with the event type.  As a demo just try to resize the VI when it is running to see it in action.

Demo Event Queue Read.vi

[ensegre]

So ditto: it is an opaque implementation, there is a critical password-protected subvi, hooovah though about three weeks before me, I don't really need it but why not asking... I kudoed the idea.

[hooovahh]

From what I've seen, most password protected VIs shipped by NI are just call by library nodes, to a method that they don't want to be exposed.  By keeping the low level call passworded, they can change the interface underneath but the terminals of the output of that subVI don't have to change.  Looking over the list of possible calls to the LabVIEW internals I'd say they are calling the GetLVEventQueueDebugData function.

[ShaunR]

I'd say they are calling the GetLVEventQueueDebugData function.

 

Correct.

[Yair]

This is no longer relevant for this question, but a nod towards the DETT might be in order for the next time. I'm not sure exactly how much data it shows you about which events occurred and what their values were, but it should show some.

[ThomasGutzler]

This is no longer relevant for this question, but a nod towards the DETT might be in order for the next time. I'm not sure exactly how much data it shows you about which events occurred and what their values were, but it should show some.

 

Don't you have to build with debug enabled to be able to connect the DETT?

[Yair]

Don't you have to build with debug enabled to be able to connect the DETT?

 

I don't know, but I expect the answer is yes, at least if you want the info related to the BD (which I think the DETT can give you).