6024E multiplexed analog inputs - how do they function?

[parsec]

Hi,

I've already used 12 of the 16 analog input channels on the card and have a further 12 signals to acquire. I'm wondering what the best strategy is in terms of multiplexing the additional 12 signals into the remaining 4 channels.

Does the card do its own internal multiplexing in sequence (i.e. scan each of the 16 channels into the one a/d in order), or is the order and sample rate for each of the channels arbitrary (e.g. can one input be polled for more time than the others)

I'm unsure as to whether there is any advantage to multiplexing 3 signals into each of the 4 remaining channels, or just multiplexing all of the 12 signals into one channel (or more practically six each into two channels, so that cmos 4 bit mux packages can be used).


Thanks,

Rehan.

[devchander]

---

Does the card do its own internal multiplexing in sequence (i.e. scan each of the 16 channels into the one a/d in order), or is the order and sample rate for each of the channels arbitrary (e.g. can one input be polled for more time than the others)

---

yes it does have an internal multiplexing sequence.

A single ADC is shared by all your 16 AI channels.

All channels in the scan list that you specify, will be scanned at a fixed interval. So, you cannot have a differrent sampling rate for each channel

And I am not sure if you will be able to multiplex 3 signals into each channel and read them 

( The only way I can think of doing this would be to use a SCXI chassis and multiplex those modules to one channel of your DAQ card).

I have not done the same thing using a cmos 4 bit mux package. So, not sure about that part

Let's hear from others

Message Edited by devchander on 09-19-2006 10:57 PM

[parsec]

So i guess that means by the same token i can't sample one of the multiplexed channels multiple times for every one time that the other channels are sampled?

I am unfortunately limited to the hardware i have (i'm an undergraduate who has recieved the hardware as a loan).

The idea behind using the cmos mux packages is i use the card's digital outs to drive the mux... So labview controls the switching of the mux through the digital port and correspondingly routes the sampled input into different variables/arrays/data lines.

Ideally I could sample the first 12 inputs straight off the card's mux, then spend the same amount of time acquiring an additional 12 samples off the remaining inputs whilst labview switches the external cmos mux and appropriately files the data.

If i am limited by the card's internal mux scan being inflexible, i guess that would mean that i need to use all of the remaining inputs (3 signals into each of the 4 channels) and live with the fact that the remaining 12 signals will be sampled 3 times slower.

Message Edited by parsec on 09-19-2006 11:45 PM

[Otis]

Hi parsec,

There is actually a way that you can read the same channel multiple times within a task. Realistically though if you are using external hardware this will be difficult at best.

If you want multiple sampling rates (which is really what you're saying you need), then the following information might help you.

You can develop this type of NI-DAQmx application if all sampling rates have a common divisor and the sampling rates remain within the limits of the device specifications. Otherwise, it is not possible to have different sampling rates.

When the rates have a common divisor, you can choose the common divisor as the sampling rate and create as many local virtual channels as you need for each sampling rate.

For example, to sample channel 1 at 300 S/s while sampling channel 2 at 500 S/s, complete these three steps:

1. Set the sampling rate to 100 S/s.
2. Add to the task three local virtual channels that point to channel 1.
3. Add to the task five local virtual channels that point to channel 2.

The LabVIEW 7.0 Express example (linked below) illustrates this principle.

Note: Each local virtual channel must have a unique name because NI-DAQmx does not allow two virtual channels with the same name in the same task.

The problem with this is that there is a sample clock and a convert clock with each AI read.  The Sample Clock says how often to take all the measurements.  The Convert Clock determines when the ADC actually latches the values. 

However, with the older E Series board that you are using then the digital lines are only software timed which means that while you could try to multiplex the data externally you couldn't do it for certain (deterministically) at the right time.  You may want to see if there is ANY other equipment that you could use (particularly NI equipment), such as an SCXI system or even an old AMUX-64T.  Maybe you could even find another professor that would be willing to let you borrow another board. 

Spending this amount of time developing your own solution will most likely lead to frustration, particularly considering that somebody near you at your university likely has the solution that you need.

Regards,

[devchander]

---

Spending this amount of time developing your own solution will most likely lead to frustration, particularly considering that somebody near you at your university likely has the solution that you need

Like my Friend (a Product development manager) would put it " why reinvent the wheel??"

[parsec]

Thanks for the example. That seems pretty straightforward.

Unfortunately i don't think i have the time to borrow any additional hardware. The board i'm currently using is actually a loan from the NI oceania office. My university has much older boards (pre pci old).

A couple of questions:

If i were to create a task in MAX, is this the same as using the create channel modules you've used in the example?

Is it nescessary to use the AI start task and stop task vis?


How I envisioned external multiplexing functioning is:

A single DAQmx read VI is presented with an array of the first 12 virtual channels to sample, which it does in sequence. A digital port write VI then switches the first mux and is then led (using error lines to dictate the execution hierarchy)to an a second read VI which then samples a 13th input.

The process is duplicated so that digital switching occurs directly before a read process within the code.

This would all occur within a while loop, so that after the loop has executed, a sample will have been read from the first 12 inputs, and the second set of 12 inputs will have been sampled through the mux switching process.

This of course puts an upper limit on the sampling speed (i.e. the loop execution time), but i don't require more samples than this anyway.

In this scenario, is there any advantage to using all of the remaining inputs on the board, or will i get the same results from using one input and multiplexing all of the signals into this one input (and having multiple DAQmx read VIs configured for the same input, using different virtual channels)


Am i correct in assuming that i'm able to force determinism this way through the code? I assume i would run into problems only if i were trying to read multiple samples for each loop iteration (i.e. using the N samples or continuous sampling features).

Thanks again,

Rehan.