fast updating intensity graph

[WernerGobel]

We are using an intensity graph for displaying data that is read out from a digital board (NI PCI 6534) at time steps of typically 2ms for one line of data, corresponding to one column of the intensity graph (using the DIO Read vi). To display our data, we use a while loop with a shift register, initialized to an array that corresponds to the size of the intensity graph. Every line, that is read out, is inserted into this array at the right column position. For updating the intensity graph a local variable is used. For a column size of 64 (with an array of 64 x 64 pixels) this works fine, with a higher column size however the updates are slowing down the while loop resulting, the data in the input buffer is no longer read out fast enough and the scan backlog is permanently increasing.
Is there any possibility to circumvent this problem and at the same time get a fast update rate of the intensity graph, which would be very critical for us.

Thanks a lot for your help!

[johnsold]

The details of your program are not clear from your description, so you may already be doing some of these things, but here are the ideas which come to mind.

1. Put the data acquision and display into separate, parallel loops Each loop must have a wait function (even zero ms wait allows the parallelism to work). Communicate between the loops with queues or functional globals.

2. Do not attmpt to update the display for each acquisition. A display with a 75 Hz frame rate updates every 13.3 ms. Writing new data to the graph more often than that accomplishes nothing. Update the array as data comes in and then update the display 5-10 times per second. The observer cannot perceive or respond to more frequent updates.

3. Try to keep the OS from doing anything which will interfere with your process. Disable any non-essential background processes and programs.

If you continue to have problems, post a simplified version of your program so that we can look at it and perhaps offer other suggestions.

Lynn

[Ben]

Lynn gave some excellent suggestions.

The graphics work is costly. The more pixel the more work that needs done.

Make graph smaller.

Watch your Task Manager > Perfromance

and try different settings in your hardware graphics acceleratio settings and color depth.

I would argue updates more often than 30 times a second are wasted.

Try backing down updates to 10 updates a second or less.

Another technique that reduce redraw demands is "defer front panel updates".

This works good if the data being applied to a FP object can change a bunch of times real fast. This is tiypical when you start to "batch' the FP updates.

Defer Fp updates stops all FP updates until "un-defered". While defered, updates take place in the background and the "pixel work" is skipped.

There is one note that goes with this, that being, in LV 7.X the "defer" forced a screen update once just prior to the deferment becoming active.

Oh, and one more thing. If you defer, make sure you "un-defer".

The defer property is found under

VI reference > Panel > DeferPnaUpdts

True = Stop screen updates
False = Allow FP updates

Ben