Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong Analog Output using Every_N_Samples with NI-9263 on cDAQ-9172 chassis (works with cDAQ-9178 chassis)

Solved!
Go to solution

Hi,

 

The NI-9263 analog output voltage geberation works correctly with the NI cDAQ-9178 chassis but gives wrong output using the NI cDAQ-9172 chassis.


In the code example attached, a single cycle of a sine wave is composed of 40000 samples and is output in background mode using Every_N_Samples at an output rate of 5000 samples per second.

The output buffer size is set to 10000 samples.

 

We prime the buffer by writting the 1st 10000 samples, then write the remaining data in background mode using the Every_N_Samples callback.
 
Bug: Using the cDAQ-9172 chassis, at the sample rate of 5000 S/s using an external scope (or through loopback to another AI), we observed the 1st 10000 samples are output twice, followed by the rest of waveform. The last 10000 samples are never output. If working correctly, we would expect to see 1 full cycle of a sine wave.

The bug does not happen with the NI cDAQ-9178 chassis. I'm using the NIDAQmx Driver v9.2.1f0 on Windows XP
The bug does not happen with simulated devices, so you will need to use real harwdare to reproduce it.

 

Please find attached a C code example based off of the NI example program "ContGen-IntClk.c" to reproduce this bug.

 

Thanks,

 

whemdan,

The MathWorks

 

0 Kudos
Message 1 of 3
(3,323 Views)

Hi,

 

Thank you for posting on National Instrument's Forum.

 

I found the same issue but not the same divice. The problem may be setup in MAX.

 

http://forums.ni.com/t5/Measurement-Studio-for-VC/Error-229665-when-run-ContGen-IntClk-c-example-fil...

 

I Hope helping.

 

 

Brice S.
National Instruments France

0 Kudos
Message 2 of 3
(3,305 Views)
Solution
Accepted by topic author whemdan

Hi whemdan,

 

By default DAQmx will regenerate the old samples if no new data is available.  To give the correct behavior, you can either:

 

        Use DAQmxSetWriteRegenMode to disable regeneration (DAQmx_Val_DoNotAllowRegen).  In most cases this is recommended if new data is continuously being written to the buffer as the generation is taking place.

 

        If you just need to generate 40k samples, you could just write them all at once rather than in 10k chunks (but the code you attached is probably just an example, so I'll assume you have a reason to write the data in chunks in your actual code).

 

 

I think the difference in behavior between the 9172 and 9178 can be explained by the different way buffering is implemented on each product.  The 9172 uses an 8k buffer (on the STC2) in all cases (source).  The 9178 uses an 8k buffer (on the STC3) if you are using on-board regeneration, but uses the 127-sample cartridge FIFO if you are not using on-board regeneration (source). 

 

So... on the 9172, 8191 samples are immediately transferred to the FIFO.  By default, the hardware will request new data when the FIFO is less than full (this is configurable with DAQmxSetAODataXferReqCond).  I'm not sure what the data transfer request size is in your case (you can set the maximum with DAQmxSetAOUsbXferReqSize), but evidently it's larger than the remaining 1809 samples that you have not yet sent to the board from your first write.  At this point, the driver will regenerate the existing 10k samples so that enough data will be present to fulfill the data transfer request.

 

The 9178 on the other hand is using the smaller 127 sample FIFO so you won't have the same behavior in your case.

 

 

In summary, the behavior is explainable by the difference in hardware.  If you want to avoid regenerating old samples, you should disallow regeneration using DAQmxSetWriteRegenMode.

 

 

Best Regards,

John Passiak
0 Kudos
Message 3 of 3
(3,287 Views)