High CPU usage drawing XY Graph
in [LabView]
|
Prev: Internal Error drawmgr2.cpp, line 349, LabView 8.5
Next: Re : Re: Re : Re: Re : Re: Re : Re: Setting Up Labview 7.1 withTektronix TDS3034B
From: Ben on 26 Jun 2008 16:10 It sonds like the issue is when you have over-lapping points. Try using the property "defer front panel updates" to defer updates (T) before the data is presented to the graph and then undefer (F) after the update. Ben
From: StevenA on 26 Jun 2008 18:10 I have experienced high CPU usage on XY graphs in the past... I know there are ways to try and manipulate the data you put on the graph to make it less intensive on your cpu, but I would like to see NI work on making this more effecient. I ran the posted example on my machine ( 3 GHz Dual Core Xeon with 3 GB ram and a 256MB Quadro FX 3500 video card) and it brought it to it's knees.
From: johnsold on 27 Jun 2008 09:10 It may be an OS issue, at least in part, or a video driver. I ran the posted VI on my Dual G5 (PPC) Mac. The CPU usage does increase with Interpolation On, but the program remains responsive. I ran an heavy duty number cruncher simultaneously and did not notice any sluggishness in either VI. Other (non-LV) programs also have normal responsiveness while it runs. Both VIs are running while I type this. (It does not make my typing any better, though!) Lynn
From: Ben on 27 Jun 2008 09:10 Again, defer Front Panel updates before the data is presented to the graph. <img src="http://forums.ni.com/attachments/ni/170/335635/1/Perf_Graph.PNG"> Region A did not use defer FP updates. Region B DID use defer FP updates This is the code I used. <img src="http://forums.ni.com/attachments/ni/170/335635/2/Defer_FP_Updates.PNG"> BenMessage Edited by Ben on 06-27-2008 08:00 AMMessage Edited by Ben on 06-27-2008 08:00 AM Perf_Graph.PNG: http://forums.ni.com/attachments/ni/170/335635/1/Perf_Graph.PNG Defer_FP_Updates.PNG: http://forums.ni.com/attachments/ni/170/335635/2/Defer_FP_Updates.PNG
From: crcragun on 27 Jun 2008 12:40
Ben, The "Defer Front Panel Updates" is a great suggestion! I have used this property, but never in a situation like this where it is called twice every 200ms. Do you see a fundamental problem with calling this property with such frequency? In addition, the VI that I posted represents the simplest example that captures that displays the problem. My full application includes several other screens that are all open at the same time and include parallel running loops as well as communications with an RT. The VI that includes this Graph also has many Event states driven from front panel buttons. Will defering the front panel updates cause any issues with capturing any of these events? I am sure that I can evaluate your suggestion in my full application based upon CPU usage alone, but is there anything else that I should also look at to ensure that the evaluation is comprehensive? Lynn, Since the various data channels provide a very wide range (~100dB) of signal levels, it would be tricky to detect at what point the graph is displaying meaningless data. Steve I agree that it would be best if XY Graph could simply (some how) deal-with this situation. This would clearly rest at the feet of the LabVIEW developers. Thanks for all of your feedback!! |