6215 suitability questions

[JonHendry]

Hi,

We're considering moving our lab from ITC A/D boxes to NI, specifically the 6215, and I've been tasked with obtaining more information to determine whether it would suit our needs.

After looking over the 621x manual and the specifications, we still have the following questions. (NB: we would be using the C libraries from our OS X application, rather than LabView)

1. Buffering: the specifications list a 4,095 sample buffer under "Analog Input". Is that used for AO, DI, and DO also? If so, is buffer memory shared transparently, or is contention an issue the developer has to work around? (The ITC-18 boxes we have been using have a 1024 kilosample FIFO buffer)

2. Can the 6215 perform DI and/or DO operations at the same time it is doing AI/AO? Asynchronously?

3. Our Analog Input requirement is for two channels, sampling at 1 kHz for spans of 10 s. At the same time we require a 2 bit Digital Input 

4. We also require AO of 50kHz for 250 ms at a time, with a digital gate and digital pulses that fire periodically during the 250 ms of AO.

Any advice or clarification would be appreciated.  

Thanks! 

[John_P1]

Hi Jon,

Thanks for considering NI products.  Let me first address your questions:

1.   Each subsystem has its own buffer.  This includes (on the 621x):

•  4095 sample AI FIFO (shared among channels)
•  8191 sample AO FIFO (shared among channels)
•  1023 sample Counter FIFOs (each counter)
•  The digital data lines are software timed, so there is no FIFO for DI and DO on the 621x boards.

2.   Again, the DI and DO on the 621x are software timed.  You can update the digital lines asynchronously of your AI and AO, but you cannot use a clock to do so.  You may use the counters to generate digital pulses, but I am not sure if this would be sufficient for what you need to do.

3.   Two channels of AI at 1 kHz is not a problem at all.  I can't say for sure if software timed digital inputs will be sufficient for what you need without more information.

4.   Two channels of AO at 50 kHz should also not be a problem.  Depending on the nature of the gate and pulses, you may want to use the counter outputs for this to achieve deterministic signals.

So, each subsystem can be run with independent timing and triggering.  My biggest potential concern about the 6215 (or any 621x) is that it lacks hardware timed digital I/O.  This means that your update rate is controlled completely by your loop rate in software.  Other boards do offer the capabilities of hardware timed digital I/O.  You may want to check out the M Series User Manual's section on counters to see if these would be sufficient for your application.  Here is a link:

Bus Powered M Series User Manual

If you post back with more information about the digital requirements of your application, I would be more than happy to help you narrow down suitable hardware.  Thanks for posting and welcome to the NI forums!

-John

Message Edited by John P on 08-10-2009 06:30 PM

[JonHendry]

Hi John,

Thanks for the information. That was very helpful.

One last item before we place an order. Are we correct in thinking that, in order to get a 'timestamp' of sorts when we read an incoming digital pulse, we could pull something off the counter/timer FIFO?

Thanks! 

[John_P1]

Hi Jon,

You could use the counters to measure the time difference between digital pulses, is this what you need to do?  The initial timestamp value would have to come from the OS, but the relative timestamps would be accurate based off of timebase of the DAQ device.  You can also use the counters to measure pulse width, duty cycle, frequency, period, etc.

I'd like to verify the requirements for your digital signals using the 621x.  What kind of data from the digital signals do you need to bring into software?  What digital data do you need to generate?  If software-timed digital I/O plus the two counters is sufficient, then the 6215 sounds like a good choice.  If you do need hardware-timed digital I/O, the USB 6221 offers similar specs (but no isolation, among other differences).

-John

[JonHendry]

Hi John,

As far as digital in goes, what we would like to do with a counter is set it up to count up from zero, incrementing once a millisecond, and then have it load the counter value (a timestamp) into the FIFO every time the 621X gets a pulse (~1 us) on a some TTL input line.  We would collect the counter values from the FIFO (if any) periodically, perhaps every 25-50 ms.

[John_P1]

Hi Jon,

Thanks for the clarification--this would be doable--the 1 kHz clock would have to come from another subsystem (or external)--there are a few options here.  You might want to use FREQ_OUT to generate a 10 kHz clock signal (it can't generate as low as 1 kHz).  You would use the external pulse as the "sample clock" for the counter, sampling the count register whenever an event occurs to give the amount of time that has elapsed since the counter was started.

The data from the on-board FIFO is actually transferred behind the scenes to a buffer in your computer's memory, so you do not need to read directly from the FIFO--when you call the Read function in your ADE this transfers the data from the PC buffer to Application Memory.  This reduces the possibility of an on-board FIFO overflow (although the PC buffer is a finite, user-configurable size so this still has the potential to overflow if you do not read data fast enough).

-John

[JonHendry]

Hi John,

I'm finally getting around to implementing this. I think I have a pretty good idea about how it'd work, but I'm not sure how to implement it in C using NIDAQ mx base. Specifically, FREQ_OUT doesn't seem to be exposed in the C api, so I'm not sure how to set it to 10khz, or how to feed it into a counter as the sample clock. 

According to the docs for the 6215, FREQ OUT should default to PFI 6.

If I build the mx base example cntDigEvents.c, with the counter being /Dev1/cnt0 (with a signal generating box feeding in a signal to that pin), it works.

If I try to set a clock for the task, using 

char freq_out[] = "/Dev1/PFI6"; 

DAQmxErrChk (DAQmxBaseCfgSampClkTiming(taskHandle,freq_out,10000,DAQmx_Val_Rising,DAQmx_Val_ContSamps,10000));

I get "DAQmxBase Error -89136: <err>Specified route cannot be satisfied, because the hardware does not support it." 

I suspect I'm hitting a limitation of the USB-6215, or of nidaq mx base, or (hopefully) I'm just configuring it wrong.

Thanks,

Jon 

[John_P1]

Hi Jon,

My mistake, forgot you were using DAQmx Base--the ability to use FREQ OUT isn't currently exposed in the DAQmx Base driver (although product suggestions are always welcome so we know what features are in high demand for the driver).

The hardware should still be capable of what you need using DAQmx base.  For example:

1.  Use counter 0 to generate your 1 kHz "timebase".

     see the genDigPulseTrainCont.c example

2.  Count the edges of this timebase using counter 1.

     see the cntBuffCont.c example

3.  Use the external TTL signal as a sample clock for the counter 1 task and for the analog input task.

That should get you started in the right direction, if you run into any issues or have questions about it don't hesitate to ask.  Sorry again for the confusion, looking back at your first post you did mention you would be using DAQmx Base.

Best Regards,

John

Message Edited by John P on 10-29-2009 01:17 PM

[JonHendry]

John,

Thanks!

So, to be clear, I'd create a task for counter 0, a task for counter 1, and a task for the analog input, set up appropriate channels for each task, and read counter 1 and the analog input in a loop?

It's not quite clear how I'd feed ctr0 into ctr1 in mx base.

Thanks,

Jon 

[John_P1 · Accepted solution]

Hi Jon,

Exactly--you'll have three seperate tasks (one for each counter, and one for the analog input).  You would then read from each of the two input tasks inside a loop.

To feed ctr0 into ctr1 you can just connect the two terminals externally (ctr0 out into ctr1 source--PFI 4 to PFI 3).  The hardware does allow for an internal connection between the two counters, but unfortunately the routing options in DAQmx Base are still a bit limited (this could potentially be another product suggestion).  The issue with the Base driver is that you can't change the default terminals for the counters, so we can't configure the device to count an internal signal using DAQmx Base.

Best Regards,

John

Message Edited by John P on 10-30-2009 05:54 PM