LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2019 Queue bug?

Why is my queue always empty? As you can see by probe #2 and #3 the elements are being loaded into the Queue.

But the consumer loop never executes because the Queue is always empty? 

Probe #4 0 queued elements

Probe #1 and #5 Not Executed

If I stop and restart my program it runs fine until it doesn't. I have not figured out what makes it stop working

QQQCapture.PNG

 

This is part of a larger project involving MODBUS communications to a bunch of other devices. So I will upload some code once I reduce it to just the Oscilloscope part. But then you will need NI Scope and one of the same devices to run it anyway...

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 1 of 11
(3,380 Views)

What do you see if you put probes on the error wires?

0 Kudos
Message 2 of 11
(3,356 Views)

Probe the error wire on the enqueuer.  When I see an error wire feeding a shift register I first suspect the classic unhandled error looping indefinitely. 

0 Kudos
Message 3 of 11
(3,351 Views)

No error...

 

qqq2Capture.PNG

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 4 of 11
(3,340 Views)

What about the wire before the enqueue?  (Just in case it is one of those where wire for probe 6 is not coming from where it appears to be coming.)

Or perhaps a timeout value on the dequeue to see if it times out and loop around again.  (Only execute other code in no timeout case of case structure.)

 

What about a probe on the error wire in the consumer loop?  Perhaps a file error caused the loop to stop prematurely.

 

For curiosity, what if in the consumer loop you put a preview queue status with a small wait function.  Have it tell you how many elements are in the queue.  See if it freezes at a number while the producer is continuing to run.  My thought is to help determine if the issue is with the dequeue, the enqueue, or the underlying queue mechanism.

0 Kudos
Message 5 of 11
(3,329 Views)

Yeah it was working when I grabbed that screen shot, but I would have caught the error anyway

If there was one

qqq3Capture.PNG

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 6 of 11
(3,328 Views)

How much data is being written to file? Is it possible the bottom loop just hasn't iterated yet because the file write is still occuring? (Anything similar in the recording off case?)

0 Kudos
Message 7 of 11
(3,327 Views)

Just guessing here. There is obviously some weird stuff occurring.

 

  1. In Post #1, assuming all probes started at the same time, your bottom loop never executes. Wire the i iterator and see what it is doing.

You have some property nodes in your bottom loop, that use the UI thread. It is possible that the bottom loop is running in the UI thread, an earlier compiler optimization may still be in effect. Other loops may be hogging the UI thread and not letting the bottom loop execute. Try erasing the property nodes, or using local variable instead in the bottom loop.

 

mcduff

0 Kudos
Message 8 of 11
(3,316 Views)

Is that a named queue?

 

Any change the name is reused somewhere else in a running VI?

 

Named queues are usually a mistake...

0 Kudos
Message 9 of 11
(3,141 Views)

It can be seen in the 1st picture that the "name" input of the Obtain Queue function is wired so this is a named queue. Any chance you are dequeueing  on the same queue somewhere else? I would also probe the error wire on the bottom loop. Maybe that loop stopped due to an error generated by the datalog function.

Lucian
CLA
Message 10 of 11
(3,079 Views)