LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

porblems with queues and notifiers as members of a cluster

Agree that the problem may well be with the timing of local variables, but I have another note on named queues that hasn't been explicitly mentioned...

 

The lifetime of a named queue is until one of 4 things occurs:

1. Your entire program completes.

2. The VI at the top of the hierarchy where the queue was first created ends.

3. The "Release queue" node is run on a queue the same amount of times as the "Obtain queue" node was run on it.

4. The "Release queue" node is run with "Force destroy" set to True.

 

#1 is obviously not causing your error.

#2 is generally only a potential problem if you are running VIs asynchronously from each other, causing multiple VIs to be at the top of multiple hierarchies and messing things up.

#3 or 4 could be a problem, we can't see your code to check, but it seems unlikely.

 

As such, the chance that you're simply getting the reference from somewhere before using it is the most likely.

 

I would ask about your use case... is there a reason you need to pass a queue between VIs, like if you have some data you want to send to a queue but you don't know which queue you will want to send it to so it needs to have that queue as an input to it?  Or is it just a way to pass the reference to the queue all over the place?

 

Unless you have code that needs to run on an arbitrary queue, I might recommend replacing your queue creation with a subVI that looks like this:

Kyle97330_0-1743194814669.png

It's pretty simple.  If the queue either never existed or is invalid, it creates it.  If it does exist and is valid, then the "False" case just passes the reference from the feedback node through untouched in the "False" case.  If you always get the reference from here (and not from any stored references) and never release it, then it's impossible to not get a usable reference.  If you think your queue is dying and causing data loss, add code to generate a log whenever "Created new" happens after the first call, and then track backwards to see what killed the queue.

 

Message 11 of 12
(81 Views)

My process is linear, but if queue operations are asynchronous or otherwise don't terminate before my code proceeds to the next routines then it could cause problems.  I did assume that the code waits until the queue operation is finished before executing the next commands.

0 Kudos
Message 12 of 12
(48 Views)