Hardware Timed Single Point Data Acq with PCI-6143

[RVallieu]

Hello,

I am trying to perform a hardware timed single data point collection at specific hardware timed digital marks.

The system I am using is a PCI-5412 Function Generator, feeding into an SCXI-1142 filter card, which is digitized by a PCI-6143 in parallel mode.  The PCI-5412 is connected to the PCI-6143 through the RTSI cable.

I am using the F_Gen to create a Square Wave signal using the arbitrary function generation ability so that I can use the marker function.  I am creating a waveform for the High segment, and the Low segment of the Square wave, breaking that in to 100 points, and calculating the dT per segment waveform based on T = 1/f (f is the desired frequency of the output wave).  I have this part working beautifully.  I can see the timing marks in MAX when I use the 6143 counter to monitor the RTSI channel where the marks are being routed by the FGen vi that I created.  The timing is just how I want it.

My next goal is to acquire 1 reading per marker pulse on all 8 channels of the S-Series 6143.  I am attemping to use Hardare Timed Single Point data acquisition.  The maximum frequency I am trying to test is only 48,000 Hz for the markers (which corresponds to a 24,000 Hz Square Wave).

The first step I undertook was to create the DAQmx channels in MAX.  I created them referencing the 1142 device, and then tried using 6143 as the reference device.  When I set up the channels in MAX and then create a task with all 8 channel and try to test them by hitting the "test" button for the task, I get the following error:

"Error -200010 occurred at S_Daq0-7 - DAQ Assistant

Possible Reason(s):

Onboard device memory overflow. Because of system and/or bus-bandwidth limitations, the driver could not read data from the device fast enough to keep up with the device throughput.

Reduce your sample rate, alter the data transfer method (from interrupts to DMA), use a product with more onboard memory, or reduce the number of programs your computer is executing concurrently.

Device:  S_DAQ"

I get this error for both tasks.  I tried creating a vi in LV 7.1 originally before testing this in MAX and I got the same error.  I'd think it was my LV code if I didn't get the error in MAX as well.

Does anyone have any advice on how to go about acquiring the 1 sample triggered by the Marker signal?  It seems like this should work to me, as the 6143 has a maximum sample rate of 250 MS/s.

Thank you,

Ryan

[Ryan_V[DE]]

Ryan,

This rate is probably too fast for hardware timed single point acquisitions. When using this method, one sample is transfered from the card into LabVIEW memory on each read, which requires a large amount of overhead. With other activity on the PCI bus, this could cause the error. Would it be possible to use a continous acquisition and transfer multiple samples at a time, less frequently?

Hope this helps,

[RVallieu]

As long as I can aquire the points based on the marker from 5412 I would be happy - it doesn't have to transfer every single point at each read.  I don't want to miss any data either.

Can you recommend a method that will sample based on the Sample Clock that is driven by the markers?

Ryan

[Ryan_V[DE]]

Ryan,

Absolutely... If you set up your task as Continuous, the "Samples to read" parameter will determine how many samples to read at a time (I would suggest something around 1000, depending on what else your software is doing). You also want to set the clock type to External and chose the appropriate RTSI line so that the external clock will be used instead of an internally generated one. The Rate parameter will be used to set internal buffer size.

If you would like see the LabVIEW code for this acquisition, put a Task constant on the block diagram then right click and select Generate Code -> Configuration and Example. This will automatically generate code to perform this type of acquisition. Please let me know if you require any further clarification.

[RVallieu]

When you send a "Samples to read" per reading of 1000 - what is the timing of the points read?

I am basically going to subtract 1 low point from 1 high point.  As you described I would have 1000 readings averaged for each point, which would be ok as long as the sample time for the 1000 points didn't interfere with the next read.

Thanks for the help, I will try this and let you know how I make out.

Ryan Vallieu

[Ryan_V[DE]]

Ryan,

My apologies, I was unclear in my explanation of the continuous acquisition. When you set the number of samples to read to 1000, you are indicating that you want to transfer 1000 points at a time. This transfer will occur after these samples have been acquired at a rate of the provided external RTSI clock. Before they are transferred, these samples will be stored in a buffer on your card. Does this answer your question?

Regards,

[RVallieu]

Ah yes that does answer my question - so it will buffer 1000 of the RTSI driven readings, taken at the interval specified by the sample clock, which I am wiring in externally from RTSI 4.  RTSI 4 is routed to my FGen marker signal.

I would have to set the DAQmx Read.vi output type to Analog:1D Waveform NChan, Nsamp.

With that I should expect an array for each channel of 1000 points each on every reading back?

Now on to the sample rate input to theDAQmx Timing.vi where I am setting all this up (RTSI clock ref, Samples per read, etc.).

This is supposed to be only a "buffer" size, set to the maximum frequency expected when I am running an external clock - but if I change the number the dT on the waveform appears to change - when I expect it to be driven by the RTSI Marker signal.  Is this not the true dT of the signal?

I appreciate the help.

Ryan

[Ryan_V[DE]]

Ryan,

You are spot on, now. With the DAQmx Read VI configured as you describe, you should get out an array of waveforms. A waveform data type is similar to a cluster with a 1D data array, t0, and dt.  This brings us to our next point. When using an external clock, the DAQ device does not perform any frequency measurements on this signal. It merely relies on the rate you specify in the DAQmx Timing VI. For instance, if you specified a clock frequency of 100Hz, but actually supplied a 6kHz clock, your LabVIEW application would display a "minute's worth of data" every second.

In order to format this data properly, you could perform a frequency measurement on one of your S Series counters. From this measurement, you could update the waveform's dt property. Alternatively, you could just read the data as a 2D array of doubles and ignore time altogether.

Finally, I would like to ask why you are using your ARB as the clock source. With the counters and internal timebases on your S Series device, 20MHz timing resolution can be obtained with a variety of sampling options. Perhaps if you explain a little more about your application, I could suggest a simpler (single card) configuration.

Hope this helps,

[RVallieu]

I can't go into too much detail since this is a customers project - but the basic idea is to do an on the fly Ohm's Compensation, where you take the "high" voltage and subtract the "zero offset" voltage to bring you closer to the true voltage.  The 24,000 HZ signal (and thus the 48,000 Hz segment markers) are for power line averaging.

I'll probably just bring the data in as a 2D array of Double then, and work out my "timestamps" somehow else - the exact time is not important as the data spacing and collection at the peak and trough.

Thank you for the help.

Ryan

[RVallieu]

For future reference for myself - is PXI architecture better able to handle the Hardware Timed Single Point Data acquisition when connected to the PC via MXI?