LabVIEW
How to slow down my program using DRV ?
Solved!
@Yamaeda wrote:
Install G# from VIPM and you'll have an excellent usage of DVRs. 🙂
The only time I have found I needed to use a DVR was along the same lines: I needed a By-Reference object (multiple objects needed a reference to the same object). Other than that one time, I have not used DVRs.
Can we stop the DVR discussion and go back to the original problem, which was already perfectly answered by Tim. The slowdown is 100% cause by excessive data in the xy graph, overloading the UI thread and thus stalling all front panel interactions. Nothing on the diagram side can cure that, not even a DVR!
Stop the insanity to graph massive amounts of data on a graph with an area of 1/4 postcard. You only have ~250 pixels in each dimension!
What is the data? Is it really arbitrarily spaced in time or are the time points equally spaced? How many points are there? How big are the files? You are duplicating a lot of identical x data. Maybe you can bring all to a common equally spaced axis by resampling, then use a plain waveform graph with custom x0,dx.
It would be nice if graphs handled this under the hood, but alas they don't (maybe a Qcontrol ;))
You basically want to send less data to the graphs so they don't have to hold as much information. Only you can make the call as to what that means specifically. Here are some ways to do it- you basically need to take a block of n points (where n is your reduction factor, for example use blocks of 10 points to reduce your data by 1/10th) and then:
-Use only the first element of the block (useful for viewing trends over time, very simple algorithmically)
-Average the data and use that (more accurate than the first, but takes a little more time)
-Calculate the max and min values for each block, and send both of those points (useful if you need to see every peak and valley in the data)
Those are just some options. You can keep all of the data stored in a shift register, then when the user zooms in on a section, repeat the decimation algorithm on only the displayed subset, but with an appropriately smaller decimation factor- this way the user can still zoom in on the plot and see everything that way, but not all of it is displayed at once, which is causing the slowdown.
They are hammering the UI thread. I don't think we can learn more. We don't really need to ask if the glass is half full or half empty if it is located at the bottom of the ocean. 😄
Yes, the code obviously stinks, but I'll wait until we know more about the data structures (see my post #14) before deciding on a better solution. 🙂
