User Interface on Front Panel Locks up When Running LabVIEW Application

Issue Details

• My User Interface (UI) on the Front Panel locks up when using Event Structures. All my controls seem disabled and my graphs and indicators don't seem to update. My stop button does not stop the program from executing. Why is this happening?
• I notice when running my LabVIEW application, the Front Panel locks and I can not move anything such as Splitter Bars that I had added to the Front Panel. Why is this?
• I am using a Queued Message Handler (QMH) but my producer loop is not registering Front Panel control events. What could cause this?

Solution

While the Front Panel appears to be frozen or disabled, it is possible that the event registered in the Event Structure queue has not finished executing.

To check this, right-click the Event Structure and open the Event Inspector Window to see if there are multiple events loaded into the event queue. Figure 1 below demonstrates that the "stop 47.2" boolean was clicked 9 times, causing multiple events to be triggered and loaded into the queue. As a result, the User Interface will be locked until all events have been handled.
 
Some common scenarios that cause the Event Structure queue to fill up quickly can be found below:

1. Rapidly clicking a control that is also registered as a "value change" event.
2. Multiple Event Structures in a While Loop and mistakenly assigning multiple identical events for a Front Panel control.
   • Even if the second structure is not entered until later, the queued event will be triggered upon its occurrence.
   • This is highlighted in the Caveats and Recommendations when Using Events in LabVIEW help documentation in further detail.
3. Implementing the Event Structure in a state machine architecture while not regularly returning to the "Waiting" state for the Event Structure to process the user inputs.
4. If a QMH architecture has been implemented, it may be that the message queue has reached the maximum number of elements that it can contain.
   • To verify if this is the case, locate the Obtain Queue function in the project and make a note of the value assigned to the max queue size input. Note that a value of -1 indicates that the queue can hold unlimited elements.
   • Place a Get Queue Status function in the producer loop before any elements are dequeued. Ensure that the return elements? (F) input is set to true and then place an indicator on the # elements in queue output. Verify that the maximum number of elements has not been reached.
   • If the queue is hitting it's maximum capacity, consider adding timing to the producer loop to control the rate at which messages are queued and dequeued.

While these solutions may work, a better solution for programs with time intensive processes is to implement the project using a Producer/Consumer architecture.

 

Additional Information