LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Seeing strange buffering with User Events... struggling to find cause....

I realize this is a complex issue I've created here, but I hoping that I may even find a cause through rubber ducky-ing here on the forum.  It's a hail mary given that I cant share my code 🙄

 

I have a QSM based app that I put a nested loop in (on the queue) where it should hang out re-enqueuing the case with the event structure (with a timeout) in until that same event structure receives a user event that will modify data in a shift register so the code in the timeout case will not re-enqueue after the User Event has been received.

 

I have used this (arguably not-fantastic solution) countless times before and never seen this strange buffering when the code in the user-event driven case executes in <1/10th the timeout value.

 

I even built a test setup to see if I could reproduce this to make sure there's not an issue in my library or in the very idea im trying to use here and could not reproduce it...  I'm totally stumped at the moment...

 

TL;DR: Can anyone think of a potential cause for the buffering (stacking of unhandled events) in my event structure with the following "assumptions":

 

- the "resUE" event case executes in <10ms and the timeout is >250ms

- the vi that sends the user event has been ruled out as the cause

 

here's the event viewer showing the behavior im struggling with:

6X6NwEIiE3.gif

 

Here's how I expect it to behave (with the timeouts executing in between the user events)

I wrote a little demo app using the same code but it works fine:

 

P7rvN4Mk2G.gif

thanks for reading, any ideas or random suggestions for cause appreciated at this point...

EDIT:   so I actually think I at least discovered what is causing this at a high level...  looks like if I manually trigger the user events it works (by dropping some files in a directory on remote computer), but when I use an actor framework based lib I wrote to drop those files in place via FTP, I get the strange buffered events scenario 🤔   could this be one of those strange root loop wait shenanigans?    Time to go digging...

 

also to be clear the af lib is running on the same computer as this app, set up to (via msg) asynchronously drop files from this computer onto another computer that does some analysis then sends it over...

0 Kudos
Message 1 of 5
(1,490 Views)

Oh, my goodness.  You are using a slightly complex, advanced framework (the Actor Framework), you have an unexpected behavior, and you can't show us any code.

 

Well, try to build a "simulated" version of your Project that only does a small subset of your Project that involves the elements that are mis-behaving.  I can't even imagine how your code is structured, except it involves the Actor Framework, QSMs, Event Loops, and bizarre behavior.

 

[Hmm -- Frameworks, QSMs, Actor Framework --- maybe you should investigate whether another Framework, say the DQMH, might work more reliably/predictably in your situation ...  Fabiola de la Cueva, co-author with Richard Jennings of "LabVIEW Graphical Programming, Fifth Edition" and knows a lot about the DQMH, devotes a chapter or two in her book on the Actor and DQMH Frameworks].

 

Bob Schor

0 Kudos
Message 2 of 5
(1,432 Views)

It looks like the handling of your first User Event takes an unexpected 3-4 seconds. Given that you mention accessing files on a remote computer, I immediately think it's something to do with the network (dhcp request timeout, say?).  Nothing to do with Actor Framework, I don't think, as that app just FTPs a file.  As a test, you could switch to using a local directory to see if it is network related.

Message 3 of 5
(1,430 Views)

Thanks for the input!

 

Sorry I had typed in another "edit" update then the edit expired and as a reply I forgot to hit the post button...

 

Through some more testing I realized that the issue is actually not related to the FTP functionality.

 

I managed to reproduce the issue by removing the state that does the FTP copy from the initial queued list of states, then I manually firing off the FTP copy in a different VI while the primary app is in the nested loop waiting for it and the issue is present.

 

So this means the stinking problem is somehow resident in my QSM.   How embarrassing 😆    I've been chasing this issue so long that I'm dying to know whats causing it

0 Kudos
Message 4 of 5
(1,407 Views)

Given the proprietary nature of your code, it might be time to hire a LabVIEW Consultant, have them sign the NDA, then have at least a pair of eyes looking at (and testing) your code.  Have you no in-house LabVIEW experts?

 

Bob Schor

0 Kudos
Message 5 of 5
(1,332 Views)