VIs menu reacting too slow

[MartinP]

I have used the menu option in my LabVIEW programs for decades, and it has worked out quite well. Right now I have a large program that seems to have a problem with the menu, as it takes 3 seconds between I click on my meny before the menu pops up. This might sound as a small issue, but it leaves an impression of a poorly designed program, and it is an irritating issue.
I use the Current VI's Menubar.vi to establish connection with the menu, and then I check the Get Menu selection.vi 20 times a second, with a 10 ms timeout.
I have tried to change the VI properties - Execution - Priority, and tested all variations without any improvement. Same thing with the various Preferred Execution System, I tried them all but still the menu uses 3000 ms before it pops up.

Anybody - anything ?

Martin

[billko]

---

@MartinP wrote:

I have used the menu option in my LabVIEW programs for decades, and it has worked out quite well. Right now I have a large program that seems to have a problem with the menu, as it takes 3 seconds between I click on my meny before the menu pops up. This might sound as a small issue, but it leaves an impression of a poorly designed program, and it is an irritating issue.
I use the Current VI's Menubar.vi to establish connection with the menu, and then I check the Get Menu selection.vi 20 times a second, with a 10 ms timeout.
I have tried to change the VI properties - Execution - Priority, and tested all variations without any improvement. Same thing with the various Preferred Execution System, I tried them all but still the menu uses 3000 ms before it pops up.

Anybody - anything ?

Martin

---

I hate to say it, but unless you are using LV 6.0 it isn't just an impression.  Why are you essentially polling the menu select?  It should an event in itself, waiting for a menu change.

Or maybe I misunderstood you.  We need to see some code to help prevent such misunderstandings.

[altenbach]

---

@MartinP wrote:

I use the Current VI's Menubar.vi to establish connection with the menu, and then I check the Get Menu selection.vi 20 times a second, with a 10 ms timeout.
I have tried to change the VI properties - Execution - Priority, and tested all variations without any improvement. Same thing with the various Preferred Execution System, I tried them all but still the menu uses 3000 ms before it pops up.

---

Your descriptions just sounds convoluted and I think you are looking in all the wrong places for a solution. Firstly, why are you turning vi names into broken web links??? Is this running in the development environment or as a built executable?

How (and why??) exactly are you polling every 50ms with a 10ms timeout? What else is running in parallel? How busy is the UI thread?

Messing with priorities will most likely make it worse, because higher priorities tend to elevate computational tasks while neglecting the UI even more. You should not even touch these options!

Once you attach a simplified VI showing what you are doing, we can attempt to troubleshoot and suggest fixes.

[MartinP]

Bill 

Thank you for a constructive suggestion. I transferred my complete state machine into av event structure as you suggested.

Unfortunately it made no difference. My hypothesis would be that the issue here is not directly related to my programming

regarding the menu-handling itself, but rather that my program is a large and complex one, and the resources handling 

the graphical user interface, menu etc seems to be a bit overloaded. That was why I have tried various options of the

VI Properties & Execution.

Martin

[Yamaeda]

Do you have lots of property nodes or random Waits/time outs that could cause it to be sluggish?

[UliB]

I don't know if this is important for your case, but did you read about the Root Loop?

http://www.labviewcraftsmen.com/blog/the-root-loop

https://www.genuen.com/blog/the-ui-thread-root-loop-and-labview-what-you-need-to-know/

[billko]

---

@UliB wrote:

I don't know if this is important for your case, but did you read about the Root Loop?

http://www.labviewcraftsmen.com/blog/the-root-loop

https://www.genuen.com/blog/the-ui-thread-root-loop-and-labview-what-you-need-to-know/

---

I don't know if it helped the OP but it could very well explain stuff I am seeing with my code.

[mcduff]

From https://lavag.org/topic/23800-dynamic-calling/

There's obscure "Run At Any Loop" option, being activated with this ini token:

showRunAtAnyLoopMenuItem=True

This open a context menu for an open VI reference in the right-click menu; might be able to avoid the root loop. 

[MartinP]

UliB

One thing stands out after reading these refs; "

The trick to understanding the UI thread is knowing the basic processes that will require the thread, which are listed below:

• Screen drawing ...."

My LabVIEW program fills a 3840x2160 monitor, uses a tabulated control that covers much of the GUI to display a lot of controls and indicators.

When updating all indicators once a second, I do use DeferPanUpdts=T while writing them, but still. Maybe it is just screen drawing all objects could be the source of the problem here ? That this takes up to much of the UI thread ? How could I reveal this , how can I establish if this is the real problem or not ?

Martin

[Yamaeda]

---

@MartinP wrote:

I do use DeferPanUpdts=T while writing them, but still. Maybe it is just screen drawing all objects could be the source of the problem here ? That this takes up to much of the UI thread ? How could I reveal this , how can I establish if this is the real problem or not ?

Martin

---

Changing that property also forces a redraw, so it's not necessarily faster. I did have a program that took 1 second to show/hide some controls, it proved to be due to some redraw race issue, wiring the error wire so they showed and hid in order made it fast.