01-23-2017 12:16 PM - edited 01-23-2017 12:18 PM
So I am trying to wrap my head around the Queued Message Handler following NI's example in LabVIEW Core 3 Exercises. The "Boiler Control" has many of the same aspects my current project has so I would like to learn how to program and debug this architecture.
I followed the course and built my program but my GUI becomes unresponsive. From what I gather that is not supposed to happen with a QMH, in fact that is one of the main points of using a QMH.
Also the "Status" and booleans on the display never update, except for VI Stopped
I don't even know where to begin troubleshooting this.
I am open to suggestions, but I can not attach any code beyond single vi's as something is blocking all my attempts to upload the project in a ZIP file.
01-23-2017 03:19 PM
Have you tried lightbulb mode? (Hilight Execution.)
01-23-2017 03:38 PM
@billko wrote:
Have you tried lightbulb mode? (Hilight Execution.)
Yes but I still can not see why the UI seems locked. The "EHL" is supposed to queue up the UI events, so I would expect that when I press a button on the front panel it would imminently see that and react. But I literally have to hold buttons for several seconds before anything happens. It acts like it is polling the UI and off doing something else leaving me to hold the button until it comes around to check it.
01-24-2017 05:58 AM
Hello,
It depends when are you interacting with the software because if you click on Start, it call a series of states, if you try to click elsewhere during those events the software won't be responsive. Once it finishes all the states called by the start button, it should return to respond to user events.
The way to override this is to use the priority enqueue so the last states goes to the front of the queue instead of the end.
It all depends on what do you want to accomplish.
Place an indicator in message to check which state is running.
01-24-2017 07:26 AM - edited 01-24-2017 07:27 AM
@Guilherme_Correa wrote:
Hello,
It depends when are you interacting with the software because if you click on Start, it call a series of states, if you try to click elsewhere during those events the software won't be responsive. Once it finishes all the states called by the start button, it should return to respond to user events.
The way to override this is to use the priority enqueue so the last states goes to the front of the queue instead of the end.
It all depends on what do you want to accomplish.
Place an indicator in message to check which state is running.
Well, the way you worded it is a little misleading - if constructed properly, the UI will always be responsive to user input - but the application, itself, may be slow to respond to the queued-up events. Is that what you were trying to say?
If queued up responses are a dangerous thing, you could always throw up the busy mouse cursor until the lagging states have completed, and that will disable user input to the application until it is ready to accept input again. It will also signal the user that your application is... well... busy.
Enqueueing from the opposite end should be a last resort and not a first. It should be reserved for an emergency override kind of thing.
01-24-2017 12:45 PM
Are you using Fixed Sized Queues? If so, then your Enqueues could be blocking until another item is dequeued.
Personally, I do not use a second loop just to handle messages to update the display or just pass the message on to who actually cares about it. I find it to be more trouble than it is worth. Just do all of that in the Event Structure and use the User Events to have the controller loops send update messages to the GUI loop.
01-24-2017 01:04 PM
A couple of tools to help debug QMH applications:
1. The Event Inspector Window, which will help you make sure the EHL is handling the events you expect it to.
2. Probing the dequeued message string in the MHL with a History Probe to detect any unexpected messages being handled.
10-10-2018 12:32 PM
I had the same problem. In Fuel Control Value Case of the MHL (Exercise Manual Fig 6-42), I didn't have the data wire going from the Variant to Data to data input of the Enqueue Message vi.
Your attached vi doesn't have anything on the data input, looks like you made the same mistake.
I'm sure you solved the problem but maybe this will help someone who went down the same path as I did.