Determine allowable SampTimingTypes for a given device?

[micahsimonsen]

I'm sure this should be simple but I'm having trouble finding the correct way to determine whether a given device supports DAQmx_Val_OnDemand timing. For instance, I can get a list of supported sample modes using DAQmxGetDevAISampModes; is there an equivalent for timing types? 

In the end I am doing simple analog sampling and would like to use On Demand timing whenever it's available, Sample Clock timing elsewhere. Thank you in advance for any tips!

[QueenSelene]

Hi micahsimonsen

If by on demand timing you mean software timing, any DAQ device will support this, there is a bit of information about that here: http://zone.ni.com/reference/en-XX/help/370466Y-01/mxcncpts/hardwresoftwretiming/

Hope this helps!

Selene v.

Applications Engineer

National Instruments 

[Roohcifer · Accepted solution]

QueenSelene,

This is actually not completely true.  DAQ devices will generally support static/On Demand/software-timed acquisition on analog I/O if they have SAR ADCs.  Devices that contain dela-sigma ADCs fall into two categories: slow sampled (typically for DC measurements of strain, temperature, voltage, current, etc.) and fast sampled (typically for dynamic measurements of audio, vibration, bridge sensors, etc.)

Slow sampled delta-sigma devices can often be software timed (on demand).  Fast sampled delta-sigma devices are usually not able to support this mode.

micahsimonsen,

I do not see an immediate way to query the task for this timing mode because, from the DAQmx driver perspective, On Demand timing is not a timing mode, but rather a lack of a timing mode.  If you were to query for the property you mentioned in your post and got no valid results, you could typically assume that On Demand timing is supported because the device will need to support at least one mode of operation (else you couldn't use it).  However, if you did receive valid results (Sample Clock, HWTSP, etc.), it would be indeterminate as to whether or not your device would support On Demand because at least one other valid mode of operation exists.

Is there a particular set of devices you are trying to cover in this application?  You could always query the task for the device name and, knowing what you know about individual devices or device families, determine whether On Demand timing is supported.  For example, 60xx, 61xx, 62xx, and 63xx devices (to the best of my knowledge) should always support On Demand timing, whereas most 44xx and 43xx devices will not.  C Series gets much more complicated in terms of numbering schemes, but you could apply a similar methodology of maintaining a list of devices that do support it and comparing against that list.  Depending on the breadth of device coverage you want your application to have, the complexity of your comparison algorithm could be minimized.

Another potentially more robust way to handle this might be to run a dummy task that reads/writes a single On Demand sample to see if the task errors with a particular code indicating that On Demand timing is not supported.  You could handle that error and proceed accordingly.

Regards,

[micahsimonsen]

Thanks to you both for the info! Yes, it's an NI 9239* that I'm working with and in fact my current approach is just to try to start the task as on demand, and if I get an error back from that, I revert to sample clock timing. I wanted to see if there was a more elegant way but it sounds like this is about right so I'll commit the code as it is with no worries. Thanks again!

*And yes, we are radically underutilizing the 9239, but it was supplied in place of a 9215 in order to meet a competitive spec