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
(1,003 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
(1,002 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
(1,000 Views)
Solution
Accepted by 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
(976 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
(935 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
(920 Views)