DAQmx 7.5 bug report (C++)

[toni.zeitler]

I am currently developing my first little application with DAQmx 7.5 (C++). As this application should be able to cope with all NI DAQ devices (different customers have different requirements), I try to make it flexible. This leads to some problems (all already solved) which I want to report here:

BUG: bug
INC: inconvenience
SOL: solution

---
INC: There is no property telling you the number of channels of a device.
SOL: Open channels one by one until you recieve an error.
---
INC: There is no property telling you possible terminal configurations for a channel.
SOL: Try it and see if you recieve an error.
---
INC: There are only few properties telling you about capability xy of a device.
SOL: Try it and see if you recieve an error.
---
BUG: DAQmxGetReadAvailSampPerChan() often returns rubbish (always 0, or continuously
     >0 after task has stopped long ago), seems to depend on the device and sample
     mode, tested with multiple analog input channels and multiple devices at once.
SOL: Don't use it. Always try reading with DAQmxReadAnalogF64().
---
BUG: DAQmxGetReadCurrReadPos() sometimes returns rubbish when task was stopped or
     reaches end of finite sample count. Seems to be the last position ignoring the
     last read operation.
SOL: Don't use it. Create your own read position indicator.
---
BUG: DAQmxReadAnalogF64() sometimes returns rubbish and non-existant data when task
     was stopped or reaches end of finite sample count.
SOL: Carefully count how much data should be there and only read when you are sure.
---
INC: DAQmxRegisterEveryNSamplesEvent() is nearly unuseable, you have to create VERY
     rounded buffer sizes/n-th intervals (eg. 1000, 10000 etc.) to be able to activate
     it. It also somehow depends on sampling rate and number of channels in the task.
     I could not figure out a working formula to get this running. This prevents a
     customer from using arbitary sampling rates. But 10^x seems to work...
SOL: Don't use it. Implement your own multithreading environment.
---
BUG: DAQmxRegisterEveryNSamplesEvent() mostly reports you should use an even multiple
     of buffer size as interval, even if buffer size is an extreme even multiple
     of the given interval. Somehow corresponds with the problem above.
SOL: Don't use it. Implement your own multithreading environment.
---
BUG: All "samples per channel" values I used up to now refer to "all samples together"
     instead of "per channel". Please notify me when you change this in future versions,
     I will have to adapt some buffer conditions and calculations then.
SOL: Ignore "per channel".
---

[cpede]

It was also a big surprise for me to discover that NI made a driver supporting all kinds of boards, but you are not able to read the properties of the boards from the driver, making it impossible to make a flexible driver solution.

I wrote my own routines looking at the return values to determine the number of AI channels, max. sample frequency, terminals, polarity, gain etc.

So good luck

-cpede