LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queue's wont release if they've been enqueued

So I've been banging my head against this for two days now, including reading multiple posts here about this.  I'm using a QMH structure to run producer and consumer loops.  The problem is that if I engueue either queue, it wont release when i stop.  As you can see, i want the Acquire Data loop to run immediately, but the Test Data loop wont run until I press start.  If I then press Stop (without having pressed Start), the program continues in the Acquire Data loop.  If i press Start then Stop, both the Acquire and Test Data loops will continue to process.  I thought when pressing Stop, both queues would be released and those errors processed into the other loops that are running and then they would stop, but that is not happening.  I added the Flush Queue and Force release to no effect.  Only a queue that has not been enqueued seems to process the Release Queue error.  attached is the simplified program.  I am forced to do this on LabVIEW 7.2 for compatibility reasons.  Thanks for any help. 

 

 

0 Kudos
Message 1 of 11
(1,439 Views)

There's a lot of code smell with this one.

 

First, I can tell you are using a really old version of LabVIEW because of the pink error wire.  Like LV 7.1 or earlier.  Not that in itself is a problem.

 

The second is that architectures that are heavily stacked,  e.g. loop in a case structure in a loop, are more likely to cause problems.

 

Third is you are using a local variable top get data from the bottom loop to the middle loop.

 

Your problem is you need to take those tutorials that have been around for decades since your VI was written, and learn about data flow.  Your inner while loops only stop if there is an error.  If you dequeue something, then there is no error,  the case structure will run, the inner while loop will start with a No Error value on that tunnel, then run forever because you'll never get an error.  Even if you upper loop kills the queues causing the dequeue to output an error, you don't read that error again until your inner loop stops, the case structure ends, and the outer loop finishes that iteration to come around again.

Message 2 of 11
(1,432 Views)

@RavensFan wrote:

First, I can tell you are using a really old version of LabVIEW because of the pink error wire.  Like LV 7.1 or earlier.  Not that in itself is a problem.


I'm fairly confident that it's LabVIEW 7.2 😁

 

@CDC1 wrote:

 I am forced to do this on LabVIEW 7.2 for compatibility reasons.


 

0 Kudos
Message 3 of 11
(1,354 Views)

wiebe@CARYA wrote:

@RavensFan wrote:

First, I can tell you are using a really old version of LabVIEW because of the pink error wire.  Like LV 7.1 or earlier.  Not that in itself is a problem.


I'm fairly confident that it's LabVIEW 7.2 😁

 

@CDC1 wrote:

 I am forced to do this on LabVIEW 7.2 for compatibility reasons.


 


I missed that statement.

 

But I'm 100% confident it is NOT LabVIEW 7.2.   7.2 didn't exist.  It went from 7.1.1 to 8.0. 😉

(But I couldn't remember if the mustard-colored error wire was introduced in 8.0 or perhaps 8.2)

 

That screenshot shows 2 fairly simple improvements to LabVIEW that helped a lot.

1.  Getting rid of the pink for error wires because it looked just like a regular cluster wire.  Now it is easier to find the error wire change in a block diagram full of cluster wires.

2.  Getting rid of the T/F boolean constant and just showing its current value.  Thanks to Altenbach's Idea Exchange submission.  Though small, it takes up less screen space, and also easier to see right away if it is True  or False.

 

 

0 Kudos
Message 4 of 11
(1,334 Views)

@RavensFan wrote:

wiebe@CARYA wrote:

@RavensFan wrote:

First, I can tell you are using a really old version of LabVIEW because of the pink error wire.  Like LV 7.1 or earlier.  Not that in itself is a problem.


I'm fairly confident that it's LabVIEW 7.2 😁

 

@CDC1 wrote:

 I am forced to do this on LabVIEW 7.2 for compatibility reasons.



I missed that statement.

 

But I'm 100% confident it is NOT LabVIEW 7.2.   7.2 didn't exist.  It went from 7.1.1 to 8.0. 😉


I saw that one coming. I also don't recall a 7.2 version.

0 Kudos
Message 5 of 11
(1,322 Views)

7.1.1 was the last of the 7x. versions.  I have to say that 7.1 was one of those "golden" versions that just worked as advertised.  Like Windows XP, or Windows 7.  (While LabVIEW 8.0 was a lot like Windows 8.0.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 11
(1,312 Views)

wiebe@CARYA wrote:

 

But I'm 100% confident it is NOT LabVIEW 7.2.   7.2 didn't exist.  It went from 7.1.1 to 8.0. 😉


I saw that one coming. I also don't recall a 7.2 version.


Your winky emoji might have been signalling the joke.  I didn't pick up on that nuance if you were. 🙂

 

@billko wrote:

7.1.1 was the last of the 7x. versions.  I have to say that 7.1 was one of those "golden" versions that just worked as advertised.  Like Windows XP, or Windows 7.  (While LabVIEW 8.0 was a lot like Windows 8.0.)

I think 8.2 (or 8.20 as they called it) was a pretty decent recovery over 8.0

0 Kudos
Message 7 of 11
(1,294 Views)

@RavensFan wrote:

wiebe@CARYA wrote:

 

But I'm 100% confident it is NOT LabVIEW 7.2.   7.2 didn't exist.  It went from 7.1.1 to 8.0. 😉


I saw that one coming. I also don't recall a 7.2 version.


Your winky emoji might have been signalling the joke.  I didn't pick up on that nuance if you were. 🙂

 

@billko wrote:

7.1.1 was the last of the 7x. versions.  I have to say that 7.1 was one of those "golden" versions that just worked as advertised.  Like Windows XP, or Windows 7.  (While LabVIEW 8.0 was a lot like Windows 8.0.)

I think 8.2 (or 8.20 as they called it) was a pretty decent recovery over 8.0


7.1 was very good, indeed.

 

AFAIC, 8.0 should never have been released.

 

8.2 was OK-is. The project explorer was a good reason to use it anyway.

 

New features and dramatic changed get released fast. Maybe too fast. That's probably why 8.0 was so bad. There where too many changes. In a way, it was simply not tested well enough. But probably the only way to really test it is to launch it (after a beta). In newer versions, this is less problematic, as the new features are mostly additions. If they don't work (correctly, yet) you can simply not use them.

 

After 11, every version I used was pretty good. I used 13 for a long time, then straight to 18 and 20. 20 is good, but newer features still have some quirks. That's acceptable.

Message 8 of 11
(1,277 Views)

If you run your code in highlight mode it should be pretty obvious.

Your inner loops in the consumers never end. 

You're right in that releasing the queue should generate an error and stop the loops, but as you never end the inner loop, well ... (As your error wire is wired in, it's only the initial value thats active and it'll never change)

Just remove the loops and it'll work mostly as you want. If you want to aquire data every 100ms you can use a 100ms timout on the read queue.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 9 of 11
(1,253 Views)

@Yamaeda wrote:

If you run your code in highlight mode it should be pretty obvious.

Your inner loops in the consumers never end. 

You're right in that releasing the queue should generate an error and stop the loops, but as you never end the inner loop, well ... (As your error wire is wired in, it's only the initial value thats active and it'll never change)

Just remove the loops and it'll work mostly as you want. If you want to aquire data every 100ms you can use a 100ms timout on the read queue.


We took over the thread. I think the first reply covered took care of the answer.

Message 10 of 11
(1,244 Views)