From: Ben on
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.
From: StevenA on
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
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
Again, defer Front Panel updates before the data is presented to the graph.
<img src="">
Region A did not use defer FP updates.
Region B DID use defer FP updates
This is the code I used.
<img src="">
BenMessage Edited by Ben on 06-27-2008 08:00 AMMessage Edited by Ben on 06-27-2008 08:00 AM


From: crcragun on
The "Defer Front Panel Updates" is a great suggestion!&nbsp; I have used this&nbsp;property, but never in a situation like this where it is called twice every 200ms.&nbsp; Do you see a fundamental problem with calling this property with such frequency?&nbsp; In addition, the VI that I posted represents the simplest example that captures that displays the problem.&nbsp; My full application includes several other screens that are all open at the same time and include parallel running loops&nbsp;as well as communications with an RT.&nbsp; The VI that includes this Graph also has many Event states driven from front panel buttons.&nbsp; Will defering the front panel updates&nbsp;cause any issues with capturing&nbsp;any of these events?&nbsp; I&nbsp;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?
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.
I agree that it would be best if XY Graph could simply (some how) deal-with this situation.&nbsp; This would clearly rest at the feet of the LabVIEW developers.
Thanks for all of your feedback!!