Multi-chasis, how to log slower than hardware's minimum sample rate, timing critical

[NIerrors]

Hello,

Hardware: 2 - USB cDAQ 9178 chassis

                    6 - NI9227 cards

                    4 - NI9229 cards

I have always used the Write to Measurement File sub VI to log data before. Using NI's multi-chassis example proved to run into problems collecting data. I have since switched to writing to a text file. This works great to log data. I do not have a timing column now which I'll write another post about, but I need to be able to sample slow. These cards have a minimum sample rate > 1k/s. Some of my tests I need to sample slow say around 10/s. How can I log a sample from every channel at a constant rate slower than the card's minimum sample rate?

I have attached the current VI that I am using. Thank you for reading this. If other forms of data are easier to accomplish this, I am open to it. My VI based solely off of the multi-chassis using 9469 card example, and wrtie to text file sample.

[GerdW]

Hi NIErrors,

How can I log a sample from every channel at a constant rate slower than the card's minimum sample rate?

You need to decimate your data.

From sample rates of 1kS/S to 10S/s you need to decimate by a factor of 100…

[Bob_Schor]

There are (at least two) ways to take a signal sampled at 1KHz and output a sample at 10Hz:  save every 100th point (sometimes called "decimating") or save the average of those 100 points (sometimes called a "box-car filter").

I encountered this with a display -- we were acquiring data at 1KHz, but wanted to display 20 points/second.  I "cleverly" displayed the average of 20 points, and was told "but now we can't tell anything about the noisiness of the channel!".  So I just displayed every 20th point, and everyone was happy (except for me, I suppose).

Bob Schor

[NIerrors]

Bob,

I have used the decimate before, but we ran into problems displaying a time element to it. Event using the dt element the timing column wasn't displaying correctly. I can't do the average option either. Do you know of an example that I could look at to learn if the decimate is still an option?

[Bob_Schor]

Am I correct that you are generating Waveforms?  If your Waveforms have a "nice" length, it is an easy "exercise for the reader" to take a Waveform collected at, say, 1KHz and containing, say 1000 points (that's one of the "nice" lenghts to which I referred) and return an equivalent Waveform "masquerading" as though it was taken at, say 10Hz (and, accordingly, containing 10 points).

You know, of course, that a Waveform is merely a Cluster, having a t0 element (time of sample), a dt element (sampling time), and an array of data.  I'm sure you can figure out the algorithm for yourself, but here are a few hints:

• t0 in = t0 out.
• dt out is whatever you want it to be.  For 10Hz, it is 0.1.
• The (integer) ratio of dt out / dt in gives you the number of data points at a time of the Input array that you must average (or decimante) to create a single point of the output array.

Give it a try.  I was going to say "For Extra Credit", but instead, an additional requirement is that you write this as a Sub-VI with two inputs (Waveform In and Reduction Factor, 100 in the above example) and one output (Waveform Out).  When you make the sub-VI, be sure to create an Icon for it (a simple rectangle with the words "Reduce WavFrm" will fit, and will be mnemonic).

Bob Schor

[NIerrors]

Gerd,

I have tried decimate in the past. While it worked enought to get by, it had several problems. One is that it strips data from all the channels. Secondly, I no longer have an actual timing column. When I had an appliation engineer help me with this a time column was added, but it repeat certains times depending on how much I was decimating it by.

I have attached what I did use then for decimating, maybe there was a simple way to improve that.

[GerdW]

Hi NIerrors,

I don't see any place where the dt of the waveforms is corrected according to decimation factor. Maybe it's hidden in one of the missing subVIs…

several problems. One is that it strips data from all the channels.

Yes, that's how your code works. When you want different behaviour you need to change your code.

Secondly, I no longer have an actual timing column.

Why not? You still use waveforms!?

When I had an appliation engineer help me with this a time column was added, but it repeat certains times depending on how much I was decimating it by.

I cannot comment on code you aren't willing to show us…

But with waveforms you should not have "repeating times"…

[NIerrors]

Gerd,

I am completely willing to show you the code, this is why I had the vi attached and showed a picture incase you weren't somewhere where you could open it. This decimate was/is completely over my head. This is what the application engineer aided me with. What this vi does is decimate, and adds a time column but it does repetitive points.

Example depending on what it is decimating by the time column will have say 0.005 repeated ten samples then jump to another time for ten samples. It is timed, but anything inbetween the repeated time stamp is unknown.

If you have another idea by all means. I have had four application engineers review this, and have been all over the spectrum, but nobody seems to get it quite right. Usually it is just jumping idea to idea rather than fine detailing a vi.

All I'm trying to get is log samples slower then the 9227 and 9229 cards are sampling. I would like the channel names to stay, but if I must I will fill them in later. The complicated portion it seems is the time column. I need to have a time column similar to what the Write to Measurement File VI provides. A constant time interval of when the sample was collected.

[GerdW]

Hi NIerrors,

this is why I had the vi attached and showed a picture

We are still missing the subVIs…

This decimate was/is completely over my head.

You really should understand whats going on in your VI. Or do you want to keep developing your VIs always with the help of the NI forum?

[NIerrors]

Gerd,

I agree I should understand what is going on in my VIs. We attempt to learn, but we have no experts here so it is very slow paced. We learn by trying to go through the online training. The basics get us by, and we are not allotted much time to really learn LabVIEW. We need something "new" in LabVIEW maybe one every year or two were we are allowed to really dive in otherwise testing wouldn't get done. Unfortunately you lose a lot of what you learn at this pace.

Okay, an application engineer came up with this solution. I'm mostly happy because first it works and it is simple. I know this isn't optimized, and typically the Write to Measurement File.VI shouldn't be in the loop. This allows me to test though. I do want to understand it though, and think of ways to make it better.

1) It is still using Write to Measurement.VI so I'm not going to be to sample fast. This is still a problem, but an accurate time column trumps this.

2) Why does this only work if I use .xls formatted files?

Does anyone see a problem with this, and/or have any suggestions? This allows me to log slower than the cards sample.