Dequeue Message.vi blocking and not timing out.

[VinnyAstro]

Hi.

Long story short: I have a SubVI (CoG.vi) based on the NI QMH template and at some point the Dequeue Message.vi in the processing loop is blocking while having its Timeout input wired to 50ms without generating any errors. I spent hours trying to understand what can cause it, and surely I'm missing something dumb but I can't figure it out...

It's very tricky to share any any code as I would end up sharing almost the whole project for it to work, but here is a summary of my problem: 

• Two VIs at stake: main.vi and CoG.vi. Main is calling CoG under user request and isn't blocking Main (takes 1 input, has no output)
• 4 loops: Event, Control, UI, and Trigger loop (this one regularly send a "request for update" message into the control queue) 
• 4 Queues:
  • Control and UI Queues (created, managed and released withing CoG.vi)
  • Main WifiComms Queue (Created and released in my main.vi, wired as input to one terminal of CoG.vi and is used to communicate Commands from CoG to main.vi
  • Platform Queue (created and released in main.vi, named queue as in it is not a threaded inout to CoG.vi but is called by it in the init process, serves as Data transfer from main to CoG.vi. I was talking about this in this Thread.

Here is the general idea: 

- When called, CoG.vi inits Control, UI and Platform queues and starts the different loops.

- The trigger loop sends the message "Update Attitude" in the Control Queue.

- Control Loop dequeues it and send a message with an appropriate command into Main WifiComms Queue and "awaits" an answer from Platform Queue (Timeout of 0 ms, will read next iteration if empty at the execution)

- Main.vi dequeues this message, process the command and then sends back appropriate data over the Platform Queue (via a data management loop)

- CoG.vi receives this data and process it accordingly.

All of this goes fine and you can see it in the following screenshot:

The CoG.vi

The main.vi comms loop:

Now, whenever I click on the Lasers Button for instance, for some reason the Dequeue Message.vi in the Control Loop will block. It won't generate an error (I know, I don't have any error management yet, but I checked) it won't timeout. In debug mode I can see the green arrow showing that it is executing.

After clicking on the emergency button, this one sends a command directly to the Main WifiComms Queue (not the control queue) which, for some reasons, suddenly unblock the Dequeue Message.vi in Control Loop and starts dequeuing all element in the queue.

I have thought of various possibilities causing this:

• problem of non-reentrant execution in the Dequeue Message.vi
  But I'm using only this one in this library so Idon't think so (+ it is executiong according to the debug mode)
• I'm using a lot (?) of queues and some of them (The data ones) are actually taking in arrays growing over time. Could it be that I have a memory issue? But then why an "external trigger" would suddenly unblock the Control Queue? Also, this happens quite early after starting my program (As I'm testing it) so the arrays don't really have time to get big...

I really don't get it...

Am I missing something obvious you could help me with or is it something more complex I need to dig in?

I'd like to point out that while not a complete beginner, I am lacking experience 🙂

Thanks a lot in advance for any help.

Vinny.

[Gregory]

In LV 2016 the dequeue doesn't have a timeout input. Did you add this yourself? Did you wire up the timeout inside the subVI?
It's really hard to debug a picture. Can you make a copy, strip out everything hardware related / proprietary, and zip it up?

[FireFist-Redhawk]

Wire up a "Get Queue Status" (and wire true to the return elements input) and look at the number of elements in the queue.

[VinnyAstro · Accepted solution]

Yes I did add the timeout myself. I needed it somwhere else.

And actually I finally found my issue, and it is a very dumb mistake ...

So I wanted my UI loop to execute only when there is something to process ... So put the dequeue message timeout to -1. Turned out as long as nothing was asking to update the UI, the Dequeue Message exection was stuck in there and it is non-reentrant .....

I am ashamed, but I can finally go home.

If it can save someone's afternoon: if you introduce a timeout to your dequeue function, remember to either never put it to -1 or to execute as reentrant...

Thanks anyway greg for taking the time.

[crossrulz]

---

@VinnyAstro wrote:

If it can save someone's afternoon: if you introduce a timeout to your dequeue function, remember to either never put it to -1 or to execute as reentrant...

---

Slight correction here: It should ALWAYS be set to be reentrant.  Any VI that does a Dequeue and possibly some parsing to the received message needs to be reentrant, regardless of the timeout.  I go so far as to make them inlined in most cases.

[VinnyAstro]

Yep well I learned the hard way... 

As for the parsing I do that in another loop to free as fast as possible the wifi communication (which I need to benchmark because my comms loop gets saturated with only 3 commands every 500ms, that's not normal, either the wifi.vi or the queue is slowing down)