LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Strange flaky Queue behavior

This might be the weirdest LabVIEW problem I've ever seen. Super simple Q messaging between loops, done it 100 times & never seen this kind of thing. So I've stripped things down to the absolute minimum functionality.  One "sending" loop sends a message (Ye Olde Enum & Variant Data Cluster) to a "receiving" loop.  As I removed functions/features the behavior has changed, but now it's down to 2 things:

 

1) Clicking the STOP button on the "Sender" works normally/reliably to stop the "Receiver" and the application.  (It hasn't before removing things, but we'll move on).

2) When sending any other command+data to the Receiver, nothing happens.  The timestamp on the Receiver is not updated.  It's as if the Q has become ?released/corrupted/??.  **BUT** then clicking STOP from the Sender works properly - "oh, the Q is working again!".

 

I originally suspected some kind of race condition, but (I think) I've stripped everything down to where I can't imagine what would do that. So - before I removed some stuff, the MOST bizarre behavior was exhibited.  I could see (using probes' timestamps "Last Update") that after the top level app sat idle for about 23 seconds (repeatably - 23 seconds) the Q began "receiving" (phoney) items on precisely 1 second intervals, which would continue until stopping the app.  Dequeue Timeout? Nope, not wired.  Sender timeout event case?  Nope - a Timeout event did exist, but it's always been completely empty.  That quit happening, tho, after removing some stuff...

 

Clues? Sympathy? Reinstall LabVIEW? Open to anything!

 

Using LV 2019 but saved as 2015.

0 Kudos
Message 1 of 3
(1,995 Views)

Your loops are in series, rather than parallel.   Your receiving loop doesn't start till you have stopped the sending loop (allowing the first subVI to end a the second to start).   The Queue is working fine.  To do loops in parallel, you need to create the Queue and pass it to both loops in parallel.

 

BTW, your two-subVIs-connected-with-one-wire design would work if the wire was a "channel wire", a relatively new LabVIEW feature intended to support this kind of design.  

0 Kudos
Message 2 of 3
(1,979 Views)

OMG I can't believe I did that! Imagine my embarrassment!!! Just gotta laugh at my own folly.  Guess I got thrown by something late last night and sprinted down a blind hole.  Thanks a bunch Dr. Powell (even if you're smirking, unseen by me)! That's what other humans are for...

0 Kudos
Message 3 of 3
(1,974 Views)