why Screen Activity or screen updates slows the labview code?

[dmoradi]

Hi,

I am using the Labview for a quite long time. recently i found out that screen updates slows down the code excecution. is there any way that i can eliminate the delay that i am getting because of the screen updaes or changes?

[johnsold]

Maybe.

Without knowoing more about how your program is designed, it is hard to give specific advice.

Look at the Producer/Consumer archtecture. This uses parallel loops to isolate slow activities from more time-critical ones. The basic concept is that things which need to be fast are put in the Producer loop while things which may take longer or things which are not adversely affected by extra delay are put in the Consumer loop.

In a typical program which includes data acquisition (possibly at high rates), display of data on the front panel, and saving data to files the data acquisition is in the Producer loop. The data is enqueued as soon as it is read. Nothing else is in that loop. The Consumer loop dequeues the data and places it in a shift register buffer. At time scales appropriate to users (a few times per second) the front panel is updated. Similarly data is written to files when a suitable size chunk has been accumulated (~64 kB on many systems) or a time interval has elapsed.

Lynn

[Zwired1]

Also make sure you don't have a lot of front panel objects on top of each other (even just at the corners).  I understand this causes LV to spend a lot of extra cycles trying to figure out what thing is actually visible.

If you're having issues and it's slowing down a critical process you could try deferring panel updates.  Hard to say without more information. 

[natasftw]

Why wouldn't that cause some delay?  Drawing something on the screen will always require some computation time.

If you want to get around it, there's two realistic options: look at the code and determine if you really need to be updating things like you are now.  It's possible you're updating indicators that you don't really care about.  Do you have controls that could be constants?

Zwired mentioned deferring updates.  You can use a Property Node to defer the front panel updates.  Set it to true, run some code, set it to false.  Everything is computed by nothing is updated until the false is read into the Property Node.

[Zwired1]

Way it was explained to me was for each indicator that is involved in an ovelap has to figure out whether the image portion is on "top" (and visible) or not.  It's not as simple as eveythign drawing on the screen every time and whoever is on top "wins" and is visible.  

In trying to find a definitive explanation I ran across this.  Seems like a reasonably comprehensive list of things to check, in lieu of information from OP.

[JÞB]

---

@Zwired1 wrote:

Way it was explained to me was for each indicator that is involved in an ovelap has to figure out whether the image portion is on "top" (and visible) or not.  It's not as simple as eveythign drawing on the screen every time and whoever is on top "wins" and is visible.  

In trying to find a definitive explanation I ran across this.  Seems like a reasonably comprehensive list of things to check, in lieu of information from OP.

---

---

Nice start to your homework

The easy explaination is: If objects overlap they all need to be redrawn whenever any of them are redrawn.

[dmoradi]

I dont know which property node to use to defer the front panel updates.

[RavensFan]

Go to View >> Class Browser

Pick all classes in VI server library and search for panel.

The property is Defer Panel Updates and is part of the Panel class.

[altenbach]

---

@dmoradi wrote:

Hi,

I am using the Labview for a quite long time. recently i found out that screen updates slows down the code excecution. is there any way that i can eliminate the delay that i am getting because of the screen updates or changes?

---

Your question is really way too generic to give a clear answer. You already got qute a few hints at various aspects, but I think you need to define the problem in much more detail before we can give a solution.

• How do you measure the speed, and how do you compare the speed with and without front panel updates?
• What is on your front panel? Do you have graphs with billions of points? Huge arrays? Overlapping elements? etc.
• How fast do your loops spin?
• What are the execution priority settings of the VI (a high priority setting will emphasize code speed over FP updates, thus making the VI feel sluggish to user intereaction even though the code itself is fast).
• Does your code spend excessive amounts of time in the UI thread (e.g. overuse of property nodes, etc.).
• Are the front panels of subVIs closed unless they absolutely need to be visible? Do they contain code that forces the FP to be in memory (e.g. do they contain certain property nodes, etc.)?

Can you show us some code?

[dmoradi]

Hi, 

thnak you very much for the very specific question that you are asking about my problem. and here are some answers:

• How do you measure the speed, and how do you compare the speed with and without front panel updates?

I have a couple of while loops and I measure the time intervals between each execution. 

i am using a Tab control to organize my controls and indicators, when i select the tab that has more indicators and are changing frequently, I can see that measured time goes for axample from 10 ms to 100 ms.

• What is on your front panel? Do you have graphs with billions of points? Huge arrays? Overlapping elements? etc.

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

• How fast do your loops spin?

without screen updates delay (when the front panel is in a page with no indicator to change) is about 2-3 ms

• What are the execution priority settings of the VI (a high priority setting will emphasize code speed over FP updates, thus making the VI feel sluggish to user intereaction even though the code itself is fast).

all of them are using normal priority

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