x series analog out

[kimkimdad]

Dear All,

I have two questions regarding streaming multichannel analog out data from a X-series board. The waveform is a large buffer, usually > 1 MSample, cyclical and sent at a high rate (~ 1 MSample/second, typically). In addition, the analog out data has to be occasionally substituted at a precise time with another buffer, then updated to the original content after a preset time interval.

(1) Although the values sent represent voltages, I'd like to write unsigned 16-bit data directly to the board for performance reason, since a Float64 buffer would eat up several additional megabytes of RAM compared to an integer array.

Can I use a simple linear conversion (e.g., one gain, one offset obtained with DAQmxGetAODevScalingCoeff) from F64 scaled to int16 and assume that the data remains calibrated? I hope that integer DAC values in X- series boards do not have to go through the ringmarole of converting them using a 3rd order calibration polynomial like the one for ADC values.

(2) The NIDAQmx functions to achieve what I described above are very difficult to find in the documentation, which is, unsurprisingly, totally confusing. What I hope to do is to set up a callback after n samples, then stuff the new buffer in the outgoing data stream. I'm concerned with latencies. Does the data stream out buffer need to be at least twice as large as the number of new samples in order to prevent a stall?

Also, in the documentation:

- Is is possible to use regeneration (DAQmx_Val_AllowRegen) and still write to the data out buffer? 

- In the functions DAQmxGet/SetWriteRelativeTo, the offset refers to a buffer. Is that buffer the data output DMA buffer?

- What is the usefulness of DAQmxGet/SetWriteMode?

Thanks for the answers.

Best regards,

[Dan_K]

Hello kimkimdad,

For your first question, yes, the DAC scaling coefficients are the linear coefficients returned from DAQmxGetAODevScalingCoeff, with the first element being the y-intercept and the second value being the slope.

For your second question, I would have a, and forgive the pun, buffer for your analog output data. For example if you are performing the callback after generating 100k samples I would write 200k samples before starting the task and have 100 ms of latency (assuming a 1 MS/s update rate). This would reduce the chance of running out of samples in your analog output task.

As for regeneration, it is possible to still write to the buffer while allowing regeneration, but the transition point from the old waveform to the new one is not deterministic. When you call the write in this case DAQmx will overwrite the current buffer in chunks, writing the first part over a section of the buffer several samples ahead of the current write position and then finishing the write after the write position has finished generating the last samples before it gets to the new waveform. This doesn't sound like a good idea in the application you have described.

The buffer referred to by the WriteRelativeTo functions is the DMA buffer located on the host.

As for Get and SetWriteMode, I am unsure of exactly which functions you are referring to, are you sure you weren't referring to Get/SetWaitMode? If so, this property is useful only if you are using your write function as a blocking function instead of using callbacks. In your case, you probably wouldn't want to worry about the Wait Mode property.

Let me know if any of this is unclear or if you need any additional explanation.

[kimkimdad]

Thanks for the answers. They clarify quite a few things.

It would be great if NI could post a technical note regarding the low-level implementation of DMA-dependent data transfer in NIDAQmx with regards to kernel driver issues, MiniMITE and STC capabilities etc...

It is difficult to understand and use the full capabilities of certain boards when they are grouped with others under the same software common denominator. NIDAQmx, in my opinion, hides too many details by trying to be device-agnostic: it's a Microsoft-inspired, "universal managed code" view that may satisfy software-minded people (e.g., those who dislike hardware details) but is eventually self-defeating, because this approach cripples performance by having too many layers of abstracting software on top of hardware.

Sorry if I sound pretentious; at any rate, I think that NI is doing a superb job with its hardware.

Best regards,

[aNIta B]

Hi kimkimdad,

        That's a very valid suggestion you have regarding the DAQmx driver and its documentation.  If you'd like, you can report those ideas in a product suggestion- which is monitored by R&D (I would put it as a MultifunctionDAQ suggestion).  Thanks again for your feedback!