From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

why Screen Activity or screen updates slows the labview code?

Solved!
Go to solution

If you're seeing time between 10ms and 100ms for an iteration of a loop, that's not entirely surprising.  Windows runs tasks as it sees fit and can often add that kind of delay even without a front panel.  If that's too long, you should consider looking at a RT system.

0 Kudos
Message 11 of 16
(885 Views)

Hi, 

I am using a Tab controls to organize my controls and indicator on different pages. If I go to a page without any indicator, the execution speed is Ok, when i change the page I am getting a big delay (probably because the whole screen changes), or when I switch to a screen with some indicators that are changing frequently I am getting a bit of delay (10-40 ms).  

0 Kudos
Message 12 of 16
(884 Views)

rignt now i am using a IPC for my application. i use it as the controller and my user interface. can i run the RT on it and still use it for user interface as well?

0 Kudos
Message 13 of 16
(882 Views)
Solution
Accepted by topic author dmoradi

@dmoradi wrote:

 

  • Does your code spend excessive amounts of time in the UI thread (e.g. overuse of property nodes, etc.).

I think so, for this project I have used lots of property nodes to read and write to variables.

 


Local variables are alot faster than property nodes, like 100x, though both indicates a bad design if used too much. As a test you can change some to Locals, but i think a redsign might be in order.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 14 of 16
(858 Views)

"I think so, for this project I have used lots of property nodes to read and write to variables."


 

 

This is a major part of your problem. Property nodes are the slowest way to move data and force the code to run in the UI thread. Look at a parallel loop architecture like the Producer/Consumer which uses queues to move the data. It also allows the loops to each run at speeds appropriate to the tasks they perform. There is no need to update the front panel more than 5-10 times per second unless you are displaying video and even then 2-3 ms is way too fast. 


 

 

 

"I dont have graphs, but I have 1 dimentional arrays with 1000 elements.


How many elements are visible at any one time?  Again, an alternative UI design which only updates what the user can see and interpret might be better.

 

 

Note that in LV the variable is the WIRE. The indicator is simply a display of the data (or a portion of it). Property nodes and [misnamed] local variables are not variables at all but are merely remote access methods for the indicator terminals.  Learn to think of the data and the DISPLAY of the data as two separate things.

 

Lynn

 

Message 15 of 16
(817 Views)

@johnsold wrote:

"I think so, for this project I have used lots of property nodes to read and write to variables."


 

 

This is a major part of your problem. Property nodes are the slowest way to move data and force the code to run in the UI thread. Look at a parallel loop architecture like the Producer/Consumer which uses queues to move the data. It also allows the loops to each run at speeds appropriate to the tasks they perform. There is no need to update the front panel more than 5-10 times per second unless you are displaying video and even then 2-3 ms is way too fast. 


 

 

 

 

"I dont have graphs, but I have 1 dimentional arrays with 1000 elements.


How many elements are visible at any one time?  Again, an alternative UI design which only updates what the user can see and interpret might be better.

 

 

Note that in LV the variable is the WIRE. The indicator is simply a display of the data (or a portion of it). Property nodes and [misnamed] local variables are not variables at all but are merely remote access methods for the indicator terminals.  Learn to think of the data and the DISPLAY of the data as two separate things.

 

Lynn

 



Well said Sir!

 

Learn to think  in LabVIEW... It is another Language and, like spoken languages, fluency often comes with both thinking in the language and dreaming in it.  When you go to work one morning and look at your monitor before coffee and notice that the code you were sure you wrote last night did not autosave --  (Yup, it happens, Dream coding!)  -- You at least have the memory of an example to work from!

 

Watch out for those nightmares where you dream you are beeing chased across a buggy spaghtti BD executing with Highlight Execution on!Smiley Wink


"Should be" isn't "Is" -Jay
0 Kudos
Message 16 of 16
(802 Views)