post processing using NI6225

[Kevin_Price]

(part 1 of 2 due to 5000 char limit)

Maybe I still am fundamentally missing the needs of your app...

You've made reference to 50 kHz signals being (possibly) present on each of 960 channels.  You also talked about reading only 1 channel at a time from each of 12 boards, then reprogramming to read a different 1 channel at a time, etc.  I had assumed that this approach was a compromise -- that what you would like ideally is to get enough samples from all 960 channels each 0.5 seconds to do your RMS evaluations, but that there was no way to get there with 10x (or even 2x) oversampling.

What I suggested was a way to get all 960 channels worth of data each 0.5 seconds, but it's only valid if the signals have no appreciable sub-50 kHz freq content.

Since I don't want us to just talk past one another, let me ask some specific questions:

1. What kind of external signals are you acquiring?  Are they a simple functional shape (sine, square, triangle, sawtooth, etc.) of pretty constant frequency?  Are they fairly predictable?  What will they typically look like?

2. It sounds like you only care about a very limited amount of information from these 960 AI channels.  As far as I've made out, you're just planning to measure their RMS voltage levels, compare to a threshold, and turn on an LED if they exceed the threshold.  (You further would like to indicate green vs. red to tell whether the LED "should" have been on).  Is it correct that you only need to compare RMS to a threshold and you don't need the actual waveform samples for any other purpose?

3. You'd like to perform the evaluation in 0.5 seconds or less.  Would you prefer the ability to update all 960 channels every 0.5 seconds?  Or are you equally happy to update only 12 channels (1 per board) "simultaneously", then reprogramming before updating the next 12, and so on?

4. Did my previous post (where I suggested UNDERsampling) make sense?  Are there specific reasons you think that wouldn't work for your app?

One other unconventional idea:  I assume you've chosen RMS rather than the faster Mean calculation because you have bipolar signals that produce both + and - voltages.  That kind of situation can produce a mean value near 0 even when the amplitude is large.  If indeed this is the case, you may be able to trick your data acq card into helping you.  If you configure a unipolar voltage range like 0 to +10 volts (instead of the default -10 to +10 volts), then anytime your signals dip below 0 volts, the A/D conversion will produce a 0.  Then a simple Mean calculation may reveal sufficient info about the waveform's amplitude.

-Kevin P.

[Kevin_Price]

(part 2 of 2 due to 5000 char limit)

Now, back to your most recent questions:

 Can I "DAQmx" create virtual ch.vi, Timing.vi, start task.vi only once thru out this 500 msec for each of the 80 ch or 12 cards? Thus saving setup time?

I can't test on my LV PC now.  I am not certain how much can be configured ahead of time to save "setup time" each 500 msec.  Considering any single board,

I suspect you could get through create channel and Timing, but I am 100% certain you cannot Start Task on more than 1 AI task per board simultaneously.  You would need to at least Stop Task and possibly (?) Clear Task before you could Start a different task on that board.  Also I'm not certain that you'll be able to DAQmx create a total of 960 channels at once.

Using that example and my explaintion at the top for my application:  Freq of interest: 50 khz.  50 khz x 10 =500 ksamples/sec.......can't do.  Beyond the 6225 capability use the max of 250 ksamples/sec.  Remember, we're only going to read 1 channel ( by configuration) at a time on EACH BOARD IN EACH SLOT.  One waveform is 20 micro secs long.  We'd like 2 waveforms=40 micro.  100 samples/250kS/s=400 micro which will give us 20 waveforms.  400 microS* 960 chs=~400 msec . 100 msec less than what I need.  Is this reasonable and "do-able"??

The calculations make sense as far as they go, but in real life it is absolutely NOT do-able because you would also need to perform 960 "reprogrammings" (at minimum a call to Stop Task then another to Start Task) in that other 100 msec.   I would guess that those are going to actually require something in the order of seconds.  If you also have to call Create Virtual Channel or Clear Task, it gets much worse.

The suggestion I gave tried to eliminate the reprogrammings, the tradeoff being that you would have to UNDERsample the data.  So far, it still sounds to me like your actual measurement needs may be able to handle the inevitable information loss that comes with undersampling.

-Kevin P.

[Clint Eastwood]

Kevin,

I'm adiment about this because the Lead Engnr on this project was told by National that this could be done.  We've also purchased all the hardware.  It now appears from all the discussions from all the different Engrs at National it may not be possible.  At least w/o some extensive programming from an expert.

What kind of external signals are you acquiring?  Are they a simple functional shape (sine, square, triangle, sawtooth, etc.) of pretty constant frequency?  Are they fairly predictable?  What will they typically look like?  Its a sine wave at a constant 50 khz at a constant amp for a defined period of time.  I don't know how "pure" (THD). See attached.

 It sounds like you only care about a very limited amount of information from these 960 AI channels.  ( yes) As far as I've made out, you're just planning to measure their RMS voltage levels, compare to a threshold, and turn on an LED if they exceed the threshold.  (You further would like to indicate green vs. red to tell whether the LED "should" have been on).  Is it correct that you only need to compare RMS to a threshold and you don't need the actual waveform samples for any other purpose? Yes !  Thought I'd take this in steps and worry about post processing later.  Right now I'm just trying to get the data to the DAQ Boards.

You'd like to perform the evaluation in 0.5 seconds or less.  Would you prefer the ability to update all 960 channels every 0.5 seconds?  Or are you equally happy to update only 12 channels (1 per board) "simultaneously", then reprogramming before updating the next 12, and so on?  Whatever is the least complex and I get all 960 chs in less than 500 msec.

 Did my previous post (where I suggested UNDERsampling) make sense?  Are there specific reasons you think that wouldn't work for your app?  Didn't understand the explanation.  I crunched the numbers and couldn't see where you got ( or why) some of the numbers.

Thanks for everyones patience !

[Kevin_Price]

I had a limited opportunity to do some very crude time-trial testing.  I had only 1 DAQ board and a 2 GHz Pentium.

First test was call DAQmx Create Virtual Channel and DAQmx Timing to pre-define 16 tasks (1 for each unique AI channel on the board).

Then I made a double-nested FOR loop.  The outer loop ran 60 times, the inner loop ran 16 times per outer loop (once for each pre-defined task), making a total of 960 iterations.  The only thing I did in each loop was call DAQmx Start and then DAQmx Stop on the same task.  There were no calls to Read or Clear.  In your real app you'd be trying to call DAQmx Stop on one task then DAQmx Start on another.  There were a total of 16 unique tasks which were each cycled 60 times.  On my system this took about 1300 msec.

Better than I had expected, but then I decided to check the effect of overloading the DAQmx driver with lots of separate tasks.

So I tried pre-defining 960 tasks.  Since I only have 16 channels, each set of task settings was re-used 60 times.  Again, 960 separate tasks in an array, but only 16 unique settings.  This time the outer loop ran only 1 time while the inner loop ran 960 times (once for each task).  This time my system needed about 11 seconds for all the reprogramming.

Bottom line: avoid all the stopping and starting!  You really need a solution where each board has a single 80-channel task that starts just once at the beginning of the program.  During all the middle, you can read the data that's being buffered by the hardware and do your evaluations without stopping the tasks.

Now, the fact that your signals will be sine waves at a constant frequency is great news!  I'm quite sure now that the UNDERsampling idea should work for you, once I explain it more understandably.  Please try reading it carefully again and post back with specific questions where I'm not clear.

-Kevin P.

[Clint Eastwood]

Let me revisit the undersampling and get back to you.  Can you check this Discussion Grp periodically ?

Clint E.

[Clint Eastwood]

I've been working with another engineer that has some expertise in DAQ and undersampling.  He explained it well enough and gave me a demo that I think the undersampling technique will work.  Thanks everyone for your help and patience, although I don't think this is far from over.

Clint Eastwood

[Kevin_Price]

Glad to hear that your making progress on your project...

-Kevin P.

[Clint Eastwood]

Using 12 DAQ NI6225s with 80 channels I have 960 elements.  On my front panel vi I have an array of 960 LEDs.  Until I spoke to the hwd engr I thought "ch0 card 0" corresponded to element (0,0) of my LED array.  It doesn't !!  LED (0,0) may "map" to Ch 25 of DAQ card 10.  If I know the mapping, is there an (easy) way of doing this ?

[Kevin_Price]

I think you'll want to group your AI data points (after RMS calcs, etc) into a 960x1 array.  Then you'd use a pre-defined 960x1 "mapping" array to move the values from the hw-based channel order (Dev1/ai0:79, Dev2/ai0:79, ... or whatever) to the desired display order.  The mapping array should hold each value from 0 to 959 to define how the channels get moved around. 

Here's an example using an 8x1 input array so you can watch how it works.  Note the use of the shift registers -- this way you're sure to keep re-using the same memory space so you won't get bogged down by memory allocation / deallocation that could happen if you create the output array from scratch every time.

2 further notes: the mapping subvi writes the index mapping array to a local variable every time.  I put this in ONLY so that the front panel value would always show you what's going on.  For speed/efficiency, it should be removed before real use.  Also, the way the mapping works could have been done differently, depending on what makes more sense in your head.  Basically you could do either:

output( map(i) ) = input(i)     OR    output(i) = input( map(i) )

-Kevin P.