Drawing graphs in LabView - CPU load

[sergey 671]

Platform: LabView 6.0i, Win2K.

In my data acquisition application a user can open several windows with an XY graph in each one. The CPU load is high (~ about 80-100%) and quite a bit of it is due to the GUI activity. If one just minimizes the GUI windows - the CPU load drops some 20-30%, so I guess that the resources are spent on the rendering. Important: I DO NOT use the "synchronous display" option.

I wonder if a display adapter with some kind of rendering acceleration could help and perform some work that CPU does now. If so, what type of acceleration ? Which adapters support it ?

Thank you,
Sergey.

[Labviewguru]

Perhaps NI can chime in on this one, but it is my belief that most of your processing is probably coming from the GUI itself.

Post either the diagram or a screenshot of the diagram of the GUIs so we can get an idea of what is going on. You may be overloading the CPU because of the user input, polling, or some other processing in your diagram.

[altenbach]

Graphs are relatively expensive front panel objects, especially if they contain a lot of points, are set to auto-scale, overlap with other objects, etc.

Even without syncronous display, you might want to put the graphs into case structures and only send data to them if necessary (e.g. max 2/sec and only if the data has changed) and not at each loop iteration. Don't autoscale (or autoscale only at longer intervals).

Use simple lines and dots instead of fancy filled circles for the points.

Some of my old LabVIEW applications are still running on P100 machines without significant load on the CPU. They key is in the programming technique. It is virtually never necessary to constantly throw newer and faster CPUs at the problem, even if it is able to temporaril
y mask poor programming.

[Roy Richter]

sergey wrote in message news:<50650000000800000012500000-1023576873000@exchange.ni.com>...
> Platform: LabView 6.0i, Win2K.
>
> In my data acquisition application a user can open several windows
> with an XY graph in each one. The CPU load is high (~ about 80-100%)
> and quite a bit of it is due to the GUI activity. If one just
> minimizes the GUI windows - the CPU load drops some 20-30%, so I guess
> that the resources are spent on the rendering. Important: I DO NOT use
> the "synchronous display" option.
>
> I wonder if a display adapter with some kind of rendering
> acceleration could help and perform some work that CPU does now. If
> so, what type of acceleration ? Which adapters support it ?
>
> Thank you,
> Sergey.

Sergey, I
believe the problem is with the DAQ sources you are using,
NOT the GUI. If you want the application to function properly without
having too much CPU load, REMOVE ALL DAQ parts from the app.
Afterwards, it will have no more problems.

Glad to be of service,
Your good friend Roy.

[Ben]

HI Sergey,

I agree that the CPU load is due to the graphics.

I believe a good video adapter will help. Get the best adapter availalbe that will support the display you are using.

Afterwrds make sure you have the latest and greatest video adapter and make sure hardware acceleration is set to max.

One more thought.
Is your machine set for 16-bit color?
LV 6 started using all 16 bit graphics.

Ben

[altenbach]

A typical sized x-y graph is no problem for even the cheapest recent graphics card.
This is not a 3-D game with tens of MB of textures and 3D transformations, but a simple, flat 2-D object and you definitely don't need 80 updated frames/second.

Especially if you use application builder to distribute the program, you should keep the hardware requirements absolutely minimal. The secret to well running applications is in your code, not in the hardware. Remeber, at a later time you might also want to run several other of your LabVIEW programs at the same time, e.g. for post processing. This does not work well if each application is a CPU hog.

[wiebe@CARYA]

Hi,

Do you update the graphs with terminals, locals, or attribute nodes? If it
it last, that's the problem.

Regards,

Wiebe.

"sergey" wrote in message
news:50650000000800000012500000-1023576873000@exchange.ni.com...
> Platform: LabView 6.0i, Win2K.
>
> In my data acquisition application a user can open several windows
> with an XY graph in each one. The CPU load is high (~ about 80-100%)
> and quite a bit of it is due to the GUI activity. If one just
> minimizes the GUI windows - the CPU load drops some 20-30%, so I guess
> that the resources are spent on the rendering. Important: I DO NOT use
> the "synchronous display" option.
>
> I wonder if a display adapter with some kind of rendering
> acceleration could help and perform some work t
hat CPU does now. If
> so, what type of acceleration ? Which adapters support it ?
>
> Thank you,
> Sergey.

[jim c]

Sergey,
You are correct in stating that your multiple XY Graphs are taking a considerable amount of resources on your computer. Updating a GUI can sap resources just like gathering user input and other processor intensive operations. You will want to make sure that you are only writing to the graphs at the slowest speed necessary and if possible only show one or two graphs at a time. If you allow the user to open several different windows, you could programmatically close the others to only allow one open at a time. I think that it is more important to make your code more efficient, rather than buying newer hardware. Best of luck!

Jim Cahow
Applications Engineer
National Instruments

[sergey 671]

To my pity, if I do not allow to open several windows simultaniously, my clients will throw me downstairs. I know that writing efficient code is important, but both LabView as a development tool and the multiwindow GUI (usually 8-10 graphs), were predefined by the client.

To reformulate my question: can some (and what) hardware help, given PRESENT application spec and code, written by now ?

Thank you,
Sergey.

[Ben]

HI Sergey,

A good graphics adapter will help.
You could also try to "defer panel updates" before writting to graphs, then un"defer panel updates" after the update.

This is a quick change and WILL help (can't say how much).

Not having video display set for 16-bit color will hurt you.

Shutting down auto-scaling will also help.

Ben