fast XY graph updating using Labview 6.1

[keng]

Hi All,

I am plotting Torque Vs Speed, Current, Power and Efficiency data onto and XY graph and in real-time (during a dynamometer test).

I do use autoscaling for some of the data.

However, I am having problem with the graph updating speed. It is slowing down my program.

To elaborate furhter, my programs gets all the readings from GPIB hardware and stores them into the array. Next, all the readings in the array is updated automatically onto the XY graph.

How can I achieve fast updating to an XY graph without adding further delay time on my overall program timing?

I use a scheduler time to handle the reading the data back and plotting onto the graph event.

Thank you,
keng

[Greg_McKaskle2]

> I do use autoscaling for some of the data.
>
> However, I am having problem with the graph updating speed. It is
> slowing down my program.
>
....

> How can I achieve fast updating to an XY graph without adding further
> delay time on my overall program timing?
>

My first comment is a shot in the dark, but worth mentioning. Are you
using local variables or property nodes. You don't mention how you are
updating the graph, but graphs generally update somewhere in the 10 to
20ms range if you simply write to the terminal or local variable. It
sounds like you might be doing an incremental update in a loop, and the
good way of doing this is to use a shift register to take the previously
plotted data, append new data, then send the data to the terminal. The
not-so-good way is to use the value property or local to read from the
graph, append and write to back to the graph. Basicaly, property nodes
update the screen after each time set. Terminal and local writes
amortize the screen updates to no more than about 50ms. Reading back
from a graph results in extra buffer copies and more memory management
than using a shift register.

Independent from the above. A graph update is governed by a few things.
The time for erasing the drawing area and drawing the grid if necessary.
The time per wired point to do floating point math to map and decimate
the data. The time bounded by the size of both data and width for
drawing the lines. Large graphs take longer to update than small ones.
Graphs with a reasonable amount of data update faster than graphs with
millions of points, and graphs with simple drawing style update faster
than those with grids, thick or dashed lines, or point markers. Grids
also take longer.

Finally, don't forget that overlapped controls update more slowly. Many
people take the graph plot legend and place it on top of the graph and
are surprised that this slows down the updates.

If doing benchmarks to see how long the graph updates actually take and
how much these changes affect it, be sure to turn on
Advanced>>Synchronous display, and be aware as to whether or not you are
including the time to produce the data to plot. Also keep in mind that
there is more jitter in measuring how long it takes to draw random data
-- the lines tend to be all different lengths, and until they get
statistically valid, they have more jitter.

If you still have questions, please be more specific as to the times you
are trying to achieve on what class of machine, or include a VI that
shows your timings.

Greg McKaskle

[keng]

Hi Greg,

Thanks for answering. There are some points here which I agree with you. Yes, I can try to make my graph panel smaller or cut down on the "cosmetic" decoration (ie. grids) on the graph.

However, I would like to inform you about some minor points on how I update my XY graph. Pls see diagram 1.


1.The "Torque Vs Speed.vi" graph is in a case statement which is pre-determined by a scheduler of greater or equal to 500 ms. I am doing this because this is the "best" timing I could get from the old GPIB hardware. (IEEE 488.1??). Pls see diagram 2.

Objective:

Codes in case statement are executed within greater or equal to 500 ms.

Problem encountered:

However,Codes in case statement takes "longer" to be executed than expected which
is in between 799 ms to 1300 ms.

Problem found:

Updating to graph in "real-time".



2.Readings taken from GPIB hardware are stored in a global array. Please see diagram 3

3. The values in the global array are then indexed and update to the graph. Pls see diagram 4

And, if you think somewhere in my code or the way I write my code is "wrong" which could cause memory usage high, pls do correct me on the methods or the better way to do things.

I have attached here a snapshot of my code. I could not upload the code because it is quite big.

Once again thanks.
keng

[Ben]

Hi Keng,

I am short on time so this answer will be brief.

Every time you read from the global, you are copying the entire content from one plac to another! Look into Functional globals (see DR VI on LV zone).

As greg mentioned graph updates can tak on the order of 20-50 ms depending on the graph etc.

You are attempting to do something that takes 20 ms every 10 ms!

Decrease your sceen updates to twice a second.

That's it for now,

I hope this helps,

Ben

[Greg_McKaskle2]

After looking at the images, I agree with Ben that the globals could
indeed be wasting lots of time. Capture is reading from the global and
appending back to it. Then the graphing VI reads the global again, rips
it apart and puts it back together for the graph. For small arrays,
this isn't such a big deal, but as the arrays grow, this could take lots
of time. Plus, this also means you are plotting lots of data.

You might want to copy your graph to a small test program to measure it
independently, as it shouldn't take more than 100ms, and likely much
less. Also keep in mind that if you have subVIs open or unsaved, they
will slow down execution as their panels update or the data is copied
about in case they are later opened.

Greg McKaskle

[keng]

Hi Greg and Ben,

Thanks for your thoughts in dianogsing my problem.

Yes, I will make a point to try to use "better" way to store my data in a global without doing "reading and appending back to it". By the way, do you know where I can find example to write "better" building array.vi?


For your information, I just found out that the graph panel has a function called "anti-aliased". It seems that this function is also causing my program to slow down. I disabled that function and program runs faster although there is room for improvement.

Anyway, thanks for your help!!
keng

[Steve at Ixia]

Is your problem that the graph is slowing down you data acquisition timing? Would you be happy if the graphs were not truly updated in real time, as long as the acquistion timing was good?

If so, then I have a suggestion. This worked for me a couple of years ago on a really tough problem. I think I was using LabVIEW 5.

1. Make the data-acquisition and graph-updating into separate, concurrent processes. So there would be one while-loop (or event loop if you're using LV6) that is gathering data at regular time intervals, and a separate while-loop that updates the graph when there is time.

2. Pass data from the acquisition loop to the graph update loop through a FIFO sub vi rather than a global variable. So the acquisistion loop fills the FIFO at it
s own pace, and the update graph loop empties the FIFO at its own pace.

3. Make the acquisition loop into a sub vi, and then go to its VI properties and assign it "time critical priority (highest)". You can also have this sub vi run on a separate thread.

This approach is really good for applications where there can be bursts of data. When I used it, I was monitoring a vibration test. We set an oscilloscope to trigger whenever there was a glitch on a particular signal. The VI had to grab the data from the scope and re-arm it as quickly as possible so that we wouldn't miss the next glitch.

I hope this helps
Steve

[Greg_McKaskle2]

> For your information, I just found out that the graph panel has a
> function called "anti-aliased". It seems that this function is also
> causing my program to slow down. I disabled that function and program
> runs faster although there is room for improvement.
>

Yep, I didn't even think to mention anti-aliasing. This feature draws
smoother lines with fewer jaggies. It works pretty well with data that
naturally has smooth curves, and makes less sense for noisy data.
Either way, it takes much longer to draw those lines as they are done in
SW OpenGL.

The best way to determine the costs for various VI elements is using the
profiler and separating them into manageable experiments.

Greg McKaskle

[keng]

Hi Steve,

My problem was that the graph uses the "anti-aliased" function to smooth the line the during the test. Therefore, it decreases my program performance during the test.

Now, I have disabled this function. It works better but I know there could be improvement into it.

However, I do need to plot the readings onto the graph in real-time.

Hmm...your suggested idea could be useful for my next project which is a water pump flow test. In this project, I do not require real-time plotting to graph. But I do have multiple threads doing data acquisition.

Well, thank you for your suggestion.

Keng