Queued Message Handler SubVI causing issues

[Brown@KTR]

LabVIEW community, 

I've been trying to learn how to use the Queued Message Handler architecture over the last couple of months but I'm running into an issue that is causing me grief.  I've gone through the template that ships with LabVIEW and I've also tried to create my own "custom messaging VIs" from scratch in an attempt to know exactly what I'm using rather than just use the template blindly.  However, I must be missing something.

In the attached .zip file, the QMH Test MAIN VI gets hung up if the message queues cluster is wired to the "test loop subVI".  If I delete the wire, then my Queue1 will work and I can execute Test1 and Test2 and the values update in Loop1.  But since the test loop subVI isn't wired properly I can't terminate the VI properly without using the abort button. 

I'm trying to mimic a VI that I'm currently working on with this simple VI. Is there an issue with have a Dequeue function inside my test loop subVI? I basically just want the test loop subVI to go from "Init" to "Idle", send an "Idle" message to Loop1 and then just sit there until the exit command is pressed.  I seem to be having an issue with the Dequeuing even though there is only one dequeue function per queue.

Any help would be greatly appreciated.  I am in a pinch to get my real VI working but need to overcome this issue first. The VIs were created with LV2017.

Cheers, 

-MB

[Gregory]

Can you save for 2016 or earlier?

[Brown@KTR]

My apologies.  I should have done this in the first place.  However, I'm not sure if I did it properly.  I tried to save for previous version and chose 2012 (as this is the version I was using before moving to 2017) but there was a warning.

Please let me know if there are any issues and I can tried to save and upload again. 

Thanks, 

MB

[Kyle97330 · Accepted solution]

Your dequeue VI wrapper can only run at one place at a time because it's not reentrant.  Either make it reentrant or switch to using the primitive instead of the wrapper with the built-in un-bundler.

[Gregory]

As Kyle mentioned, you have locked up your VI because two functions are trying to call Dequeue Message at the same time. Unfortunately, the first one has nothing to dequeue because you've set it up so that your "QHM Test Loop" will enqueue data. Although setting Dequeue Message fixes your immediate problem, you are setting yourself up for a hard time debugging by having the loops send data back and forth to each other. A much easier approach is to have almost all of the data going "one-way" with a single "smart loop" that knows what's going on. There will be times when you need to get the data out of the loop, and I would suggest taking a look at how DQMH does it, by setting up a temporary notifier.

[Brown@KTR]

This makes a ton of sense...I only checked the enqueue wrapper for re-entrant behaviour in the template VI and foolishly assumed that the dequeue wrapper was the same. 

Thank you very much. Makes me wish I came to the forums earlier.

Cheers, 

MB

[billko]

---

Brown@KTR wrote:

This makes a ton of sense...I only checked the enqueue wrapper for re-entrant behaviour in the template VI and foolishly assumed that the dequeue wrapper was the same. 

Thank you very much. Makes me wish I came to the forums earlier.

Cheers, 

MB

---

It's good to try it out yourself before coming here, though.  🙂

[Brown@KTR]

Gregoryj, 

Thank you for the suggestion.  I created this test VI so that I could upload it to the forum.  In my real VI, I have an Event Handling loop, a control loop, a logging loop and a display loop.  The Control loop is close to your "smart loop" suggestion.  All of the messages from the event handling loop are dequeued there and then sent to the other loops.  The only things I send back to the control loop are errors.  

I haven't looked into the DQMH yet but I will certainly do so.

Cheers, 

MB

[Brown@KTR]

Bill, 

I totally agree.  However, it would have been nice to sleep for more than 3 hours last night. 

Thanks again NI community.