Probe DQMH queue status

[Peter_B]

I would like to probe the MHL queue to see what is currently queued up.  A custom probe would work but I can't create one as the DQMH message queue  wire class/reference is private.

What is the quickest way for me to find out a DQMH queue status ?

[Darren · Accepted solution]

As a general rule, any time you need to mess with the DQMH message queue beyond enqueue/dequeue, that's considered a code smell. If you're previewing the queue, or flushing the queue, you are likely doing something wrong. Not always, but usually. That's why it's not built-in, and it requires you to really commit by implementing a child class of the DQMH Message Queue class. You can have your own "Create Message Queue" VI that you call at the beginning (instead of the built-in Create Message Queue VI) that outputs your child class queue. And then your child class would implement a method that allows you to preview the queue.

But in my opinion, you should maybe take a step back and see why you want to preview the message queue in the first place... maybe there's something in your design that should be re-examined.

[Peter_B]

Thanks Darren.

I know I have something wrong in my code design but to help me understand what I have done wrong and to facilitate me debugging it I would benefit from seeing what is queued up.  LabVIEW in general permits me to preview a queue and that functionality is helpful for debugging purposes.

The method you advise for me to implement the probe might be a slightly higher bar than me debugging it another way.  

[Peter_B]

I found my bug by probing the dequeued commands using a string history probe.  

Would I have benefited from a Queue preview feature to debug the MHL faster ?  Possibly.  The idea of limiting the scope of debug-ability of the MHL's queue in order to enforce best design practice is a reasonable goal.  It comes with a trade-off.  e.g. if I am able to make mistakes I also would like to be able to find those mistakes easily or in ways I am used to in LabVIEW.   But, I think I have now learned that private code is not intended to be probed too deeply !

[Darren]

---

@Peter_B wrote:

I found my bug by probing the dequeued commands using a string history probe.  

---

That's the same debugging mechanism I use to figure out message ordering issues in QMH-based apps.

[doyles]

Hi Darren,

Quite some time ago I created a hack vi that I added directly into to the DQMH message class to return the number of queued messages in a module (not good coding practice, I know).  The subVI simply fed a chart that was on the front panel of the module so I could see if I was having an issue before I spent more time changing the MHL actions. 

This specific module interacted with a hardware device.  I needed to understand if my MHL was getting laggy when I was initially developing it due to the speed of the steps that would be sent to it.  Not so much whether the code was slow, but whether the device was taking too long to perform the commands.  The device module is fairly well developed now, so I have not used it in a while.  Alas, having forgotten about my hack, I updated to DQMH 7.  And when I opened up that module it was broken, of course.

Not wanting to remove what had previously been a handy bit of info, I did some searching to see if that was now a part of the improvements in DQMH 7.  However, whenever I saw anyone asking about that feature, the response was always along the lines of "so what is it that you're trying to do here?".  I finally came across this more recent post where you explicitly stated that it is a code smell.

Could you provide more information (links to white papers, thoughts, etc.) on the reasons that it isn't considered good practice to read how many elements are queued?  I was unable to find anything specifically related to why it was and continues to be purposefully absent from DQMH.  I also wasn't able to find much about it in general.

Thanks,

Scott

[CyGa]

In general if the code in your MHL takes time, I would advise create a request and reply.

If you query your device at a rate it cannot keeps up with then, yes, this a code smell.

If you want to query your device at a rate it can keep up with, then you should not send more queries that it can handles. One way to do this is to wait for an instrument response, and create an R&R.

When you get the reply, you are good to go with a new query.

This has nothing to do with the queue itself, but more with how the code is architected actually.

You still have the possibility to override the queue class to add more methods if you want (like Flush for example).

[joerg.hampel]

In addition to what Cyril already said (thanks for chiming in), I want to explain that the Consortium has to weigh each new feature request and look at it from different angles. Who will benefit from it? In which cases? How often? Is there any downside? How much effort would go into the implementation/tests/documentation/support? Which other features might be more interesting? etc etc... Frankly, we find it quite challenging to make these decisions. Our Trusted Advisors are a huge help in preselecting the most promising requests during our quarterly meetings - thanks for that!! 

For the queue status, our mutual feeling here at the DQMH headquarters has always been that by providing an official API for probing and manipulating the queue, we would not only allow advanced use cases, but we would also open the doors widely for all sorts of abuse by users unfamiliar with all the caveats we discussed here.