Workaround for displaying a very long period of time in a chart.

[DuffmanSays]

You're right, my link does appear to be broken. When I posted last, the link correctly located a knowledgebase discussing the chart history. I have re-linked that knowledgebase, but the URL is listed below incase there is still some problem. This knowledgebase should address the meaning of chart history for waveforms. I hope this is useful for this discussion. Sorry again for the confusion!

http://digital.ni.com/public.nsf/websearch/6685B295992F6F338625718C00606500?OpenDocument

[DFGray]

You can still use a Waveform Graph, but the data you send it will be a bit different.  Instead of a single waveform, you will use an array of waveform datatypes.  You will also need to set the graph so it does not ignore the timestamps (right-click, unselect the ignore timestamps option, reformat X axis if desired).  The max-min decimation techniques in the article I referenced previously will handle the 1 pixel wide waveform problem easily.

Note that timestamps do not have to be the current time, if you don't want them to be.  You can add and subtract them to make them relative to a specific time.  They can be extracted and overwritten.  For example, if you want to use relative time, you would extract the timestamp of the first waveform and replace it with zero.  On subsequent waveforms, the timestamp is extracted, the first timestamp subtracted from it, and then replaced with the result.

Good luck.

[Marc_A]

I know I can send more than one waveform to a chart or graph. The problem with a graph is that you can't stack the plots. When viewing more than one channel on a graph, they are all on the same plot. A chart can be stacked so that each channel is its own plot, this is why I need to use a chart.

Also, I got something working where if the display length is longer than 1000 seconds (about twice the number of pixels), only the max and min will be stored for each second of data. This downsamples the data to 2 Hz.

I read that article and that's exactly what I was looking for that I saw once before. There is a problem though. I need to do all of this as I take data and display it. The techniques they describe are for displaying a set of data that you already have. What I might do is keep a counter and determine when I have 1 pixel of data, then decimate that as it's running. All of that takes time, though.

[DFGray]

My apologies.  I misinterpreted stacked plots as overlaid plots and gave you a completely wrong set of info.

I believe you have figured out your problem, though.  If you have a set amount of decimation you want to do, you can do it on the fly by checking for when you have enough data to plot something.  You are correct - it will take a bit of time.  However, given your slow data rates, you shouldn't have a problem with a reasonably modern computer.  Make sure you do your data collection in one loop and your decimation in another to allow the processor to use the time the DAQ board is acquiring to decimate the data.  If you have never done this sort of thing before, queues are a convenient way to pass data from one loop to another.

You can still use a graph, for better control of the buffers, but you will probably want to use 32 graphs stacked on top of each other for the same look (you only need to show one X axis if they are all the same).  Alternately, you can use a single graph and add an offset to your data for the different waveforms.  I would not recommend this, since you would then have to do autoscaling yourself and the Y axis values would be off for all but the base graph.

Once again, my apologies for misinterpreting your previous question.  Let me know if you still need help.

[Marc_A]

Thanks for your help.

I am comfortable with concurrent loops, queues, and all that jazz. The biggest problem with this now is that I would have to rewrite a lot of the program to get it working the way I would like it. It was one of the first programs I wrote while learning LabVIEW over a year ago, so I look at it now and just shake my head.

I'm not planning on devoting a lot of my time to this right now, so the way I'm getting around the problem will have to do for the time being. Thanks again for all the replies, and no worries about the misunderstanding, DFGray.