CPU Over Load Waveform graph x.scale

[Johnny1986]

I needed a program that show a XY Graph of 4 plot but I must have a cursor, this is the reason I use waveform Graph and not the XY Graph.

My problem is when I change the view of the graph my CPU is over load, I want the x scale size to be fix and just move "right" every new sample.

In the VI that I uploaded my CPU rise up to 21% and when I stop the graph from moving (pot my mouse over the graph), stop write to the "XScale.Range" ,the CPU decrease to 6%.

On my full program the CPU rise to 50% and Labview crash, I refresh the graph ever 1000ms. Without refreshing the graph(no writing to "XScale.Range") in the full program the CPU rise up to 12%.

Hope you can help or tell me if there is a better way to do what I wanted to do

[TBirkulosis]

Add a Wait (ms) in the while loops. This allows time for the CPU to proccess other events while the code is running. When I added this, I saw a drastic decrease in CPU usage (63% reduced to 16%).

As a general suggestion, use a Queue to pass data between the two loops, instead of local variables. A good starting point is the Event-Driven Producer Consumer project template.

[Johnny1986]

Thanks for the replay

I do have a wait in the upper while loop, in the lower while loop I think that I don’t have to add a Wait(ms), correct me if I wrong, the event loop is wait until an event is happening  

I have a questions about efficiency

1. This is better to work with queue or notifier will work in the same?
2. Working with "reference" will slow the program, if yes then creating the reference before the loop will help speed up the program?
3. Split the main VI to small VI will speed up the program?

[TBirkulosis · Accepted solution]

1. Queue or notifier will work fine.
2. Yes, we recommend opening and closing references outside the loop.
3. Using subVIs can increase performance because LabVIEW can reclaim subVI memory when subVIs are not executing. Using subVis is typically for memory management rather than speed, but the two are related.