Queue Refnum Invalid After Enqueue from Event Case

[shangchi]

Hi all,

I'm facing an issue with queues in LabVIEW, and I need help understanding what I'm doing wrong.

My Architecture

• I have a Queue Manager implemented as an FGV.

• On initialization, I create multiple named queues and store their refnums inside the FGV.

• After initialization, I can read all queue refnums and they are valid (probed output from the FGV).

• Different parts of the application enqueue to these queues, and another loop dequeues them.

The Problem

Whenever I enqueue data inside an Event Structure (or even from another subVI), the enqueue function fails.

• The error I get is something like:
  “<Queue Name> does not exist”
  or
  “Not a refnum” or Enqueue Element in Controller Enqueue.vi->Main screen.vi->Main screen.vi.ACBRProxyCaller.4DE0000C

• Probing the queue wire at the Enqueue node shows “Not a Refnum”.

• But when I open my Init subVI, all queues are created properly and the FGV still outputs valid references.

Important Notes

• The Queue Manager FGV works perfectly right after INIT — all queue refs are valid.

• The issue only appears after an Event Case enqueues OR when a different VI tries to dequeue.

• If I bypass the event structure and call enqueue directly, same issue occurs sometimes.

• No Release Queue is called anywhere except on application exit.

• This happens even though I use named queues and always request refs from the FGV.

What I Need Help Understanding

Why does the queue refnum become invalid (Not a Refnum) when:

• Enqueue is called inside an event case, OR

• Enqueue/Dequeue is called from another VI?

Is this a wiring/tunnel issue in the Event Structure, or a reentrancy issue, or something wrong with using an FGV as a queue manager?

Any suggestions or examples of proper multi-queue management with FGVs would be greatly appreciated.

Thanks in advance!

[GerdW]

Hi shangchi,

---

@shangchi wrote:

• I have a Queue Manager implemented as an FGV.

• On initialization, I create multiple named queues and store their refnums inside the FGV.

• After initialization, I can read all queue refnums and they are valid (probed output from the FGV).

• Different parts of the application enqueue to these queues, and another loop dequeues them.

What I Need Help Understanding

Why does the queue refnum become invalid (Not a Refnum) when:

• Enqueue is called inside an event case, OR

• Enqueue/Dequeue is called from another VI?

---

• Where do you do that "initialization" of the queue references?
• I suspect a race condition: you read the "q ref" before the message handle loop, but the FGV read operation has NO DATA DEPENDENCY and so it will run (most probably) right after start of the VI! Is the FGV already initialized before you read the ref?

[shangchi]

Q initializing VIq initialising is in this vi and and it lauch main vi asynchronously. in main vi i created a panel closing event at that time the i enqueue "exit" state to the previously created q namely " controller" and it will be dequeued in controller vi and goes to exit state

[GerdW]

Hi shangchi,

---

@shangchi wrote:

q initialising is in this vi and and it lauch main vi asynchronously. in main vi i created a panel closing event at that time the i enqueue "exit" state to the previously created q namely " controller" and it will be dequeued in controller vi and goes to exit state

---

As suggested before: there is a clear RACE CONDITION between your "INIT" VI and the "Q Manager" FGV call where you read the "Controller" queue ref!

Solution: call the FGV AFTER you call the INIT VI. Use wires to enforce DATAFLOW…

(Most problems are solved in LabVIEW by "THINK DATAFLOW!"…)

[shangchi]

Thanks for the response. I tried accordingly but when I run the program on the first try it won't execute as expected but if I abort and run again, it will execute without errors.

[MECSO]

Hi shangchi,

sounds that you still have a race condition. That it workes second time, can indicate that the queue refnums are not closed correctly in first run, so they are still available in second run and already open.

[billko]

---

@MECSO wrote:

Hi shangchi,

sounds that you still have a race condition. That it workes second time, can indicate that the queue refnums are not closed correctly in first run, so they are still available in second run and already open.

---

Especially the part about it working after it aborted. Things don't get closed when the VI is aborted.

[shangchi]

But in some Vis the Q is read without error. The error is on the "Panel Close" event. while panel close im sending "process kill" to another vi and from there all vis will be stopped. This is the scenario. Im launching 3 vis and dequeuing ststes without error but while panel close event happens - the Q is not read poperly!

[GerdW]

Hi shangchi,

---

@shangchi wrote:

The error is on the "Panel Close" event. while panel close im sending "process kill" to another vi and from there all vis will be stopped. This is the scenario.

---

Again: RACE CONDITION!

You call that "Exit Main" subVI, that seems to flush/release the queues. And (again) you call a subVI without enforcing execution order using DATAFLOW!

---

@shangchi wrote:

But in some Vis the Q is read without error.

---

"Some VIs without error" is an indication of race conditions: sometimes the code may work, othertimes it may fail…

Did you even try to debug your FGV?

Can you verify WHEN you release the queues and WHEN you call the FGV with it's "read" command?

[shangchi]

This is vi where the Q is read and dequeued for the corresponding sates (now - EXIT)