LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

QMH UI becomes unresponsive

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.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 1 of 8
(3,371 Views)

Have you tried lightbulb mode?  (Hilight Execution.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(3,306 Views)

@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.

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 8
(3,298 Views)

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.

Guilherme Correa
0 Kudos
Message 4 of 8
(3,267 Views)

@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.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 8
(3,257 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 8
(3,228 Views)

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.

0 Kudos
Message 7 of 8
(3,222 Views)

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.

0 Kudos
Message 8 of 8
(2,552 Views)