Reposting this from the general DQMH forums:
Today I ran into my first instance of what is likely a common problem where my helper loop swamped the MHL with more requests than the MHL could handle (because of a hardware timeout problem). Since this was my first foray into Helper Loops, it took me a bit to track the problem down, using cumbersome history probes on DQMH Enqueue Message and DQMH Dequeue Message.
What would have helped a lot would be an additional output terminal on DQMH Dequeue Messages that told how many items were still in the queue (using Get Queue Status). A person could ignore this terminal, probe it, or put in some code to check it and generate an error if too many messages built up. If I understand correctly, all that would be needed is a Get Queue Status in DQMH Dequeue Message wired to any of the free terminals. Making this change would not enable any forbidden manipulation of the queue itself; it would simply provide a sometimes-critical piece of information about the health of the module.
Some previous discussions of similar requests are here and here.
Accepted.
We'll assess if this creates a measurable overhead calling the Dequeue VI. In that case we would create an extra VI. Otherwise we can create an extra output terminal to the existing Dequeue VI.