How to find out that the card in a given NIDAQ slot is a DSA card?

[Dr_Flow]

In the description of DAQ_Op(...) function in the traditional NIDAQ function reference one reads:

"buffer" is an integer array. "buffer" has a length equal to or greater than count.
When DAQ_Op returns with an error number equal to zero, buffer contains the acquired data.

For DSA devices, buffer should be an array of i32. These devices return the data
in a 32-bit format in which the data bits are in the most significant bits.

Question 1: How to find out programmatically that the card in a given NIDAQ slot is a DSA card?

Question 2: How many MSB carry the information? How do I find out bit-ness of the card (programmatically)?

The obvious solution to create and keep updated the table/fil
e with the data for all existing DAQ cards is unacceptable. This could be maintained by NI itself, but not by 3rd party developpers, like me.

[duncan carter]

One method is to get the device type code for the device by using someing like:

Get_DAQ_Device_Info (ADHardware->iDevice,ND_DEVICE_TYPE_CODE,&device_type_code);

Unfortunately, NI does not maintain such a table/file except for their own internal purposes. Several years ago, I started one for my own uses which I am attaching. When I started the file, I was targeting E series boards that could sample a simgle channel at at least 200 kHz but since then, I've also added 447x series boards. Elsewhere on this site, there is a searchable list of device type codes for most other boards that doesn't include the latest boards. You can use this list and look at the spec sheets for boards that might be missing from my list. In my case, I needed the sing
le channel sample rate, the gain table, and the number of bits.

[Dr_Flow]

Well, as I told above, this solution "does not extend itself into the future", i.e. software cannot automatically understand the situation if the card didn't exist by the time of compilation. This, in turn, violates the main paradigm of NIDAQ -- to provide unified API regardless of particular hardware.

What about the following: if the card supports gain=0 (dB), then it is DSA card. Is this statement true?

Example:
status=DAQ_VScale(..,gain=0,..)
if(0==status)
//this is DSA
else
//this is not DSA

[duncan carter]

I don't know the answer to this and I think you might not get to this stage if you used the wrong size buffer for integer data storage before calling DAQ_VScale. The 447x series has fixed gain and 24 bit resolution, the PXI-4461 DSA has 24 bits and adjustable gain, and the older 4451 and 4452 have 16 bits and adjustable gain so there are DSA boards with 16 bits and 24 bits and fixed and adjustable gain versions of DSA boards. I think you would want to test any solution that you use and I have no way to test the DSA boards other than the 447x series.

I understand your concern about extending into the future. NI sales has told me about some future DSA products but details that might affect programming weren't available.

[Dr_Flow]

may be NI-people would like to comment on this?

[duncan carter]

One thing that I forgot to mention is that some of the new products will require DAQmx. In the case of my product, this means that I must support DAQmx and traditonal NIDAQ in the some software.

There is also another complication. Some boards such as the 447x series support essentially sampling rate within a specified range; other boards, I think including older DSA boards, only support sampling rates in increments of frequency.

[Dr_Flow]

I had this solution for some time as well.....but in one year I realized that I have to update it all the time. What is worse, I had to recompile my application every time.

At the moment I ended up with more elegant solution. My application looks for a file nidaq.ini which should be located in the same folder where the executable is. nidaq.ini is a text file which has the following structure:

[241]
name=PCI-6110E
gains=0.2, 0.5, 1, 2, 5, 10, 20, 50

[244]
name=PCI-6111E
gains=0.2, 0.5, 1, 2, 5, 10, 20, 50
ADC.MinReading=0
ADC.MaxReading=4095
ADC.ZeroReading=2048
ADC.ZeroShift=2048

...

The number in the square braces is card-id as returned by Get_DAQ_Device_Info(). The advantage of this approach is that THE USERS can fix the pro
blem themselves by adding few lines in nidaq.ini or I cat tell them what to add without recompiling. I am also trying to update this file once in a while.

On the other hand, I think this is idiotism that thousands of developpers should maintain this kind of file (each developper in his own format!). NI has all this info and should provide just few NIDAQ API functions to have access to it. In fact, nidaq.dll contains all this info in some form, because it needs it to check the validity of arguments and return error code if needed.

So, NIDAQ developers, help!!!!!!!

I attach my full nidaq.ini

[duncan carter]

essentially any sampling rate...

[Bryan F]

Hello Dr. Flow and Duncan --

I have read through your exchange and passed your suggestions to the NI-DAQ software developers at NI. I agree with you that it is not always as straightforward as it could be to programmatically "learn" about the configuration and features of a given DAQ device, whether it is a DSA board or something else.

In regards to your questions:

Question 1: How to find out programmatically that the card in a given NIDAQ slot is a DSA card?
For this, you do need to maintain a table of device IDs as you and Duncan discussed.


Question 2: How many MSB carry the information? How do I find out bit-ness of the card (programmatically)?
The 4472 utilizes 24-bit converters. Each sample is transferred along PCI as 32 bits, although only
the 24 most significant bytes actually contain meaningful data. You are correct that a your software buffer should be an array of i32, and you will need to typecast the buffer point to *i16 when passing it to the DAQ_Op function.

In this discussion you pointed out that one of the fundamantal goals of NI-DAQ should be to maintain a similar SW interface for wide variety of devices, and we at NI certainly agree! DAQmx (as opposed to Traditional DAQ) offers some improvement here. If you use DAQmx in C or LabVIEW to transfer scaled data as f32, this will work fine for 12-bit MIO, 16-bit MIO, or 24-bit DSA.... all the math is handled under the hood for you.

Thank you for your devloper exchange contributions -- you bring up some excellent points.

Bryan Fry
DSA Product Support Engineer
National Instruments

[Dr_Flow]

Bryan, thanks for your answer.

I hope that my NIDAQ-wish-list will not only reach NIDAQ developers but some of it will be implemented in the next versions of NIDAQ.

I should say that I am quite pessimistic because I was sending similar requests via German support few YEARS ago and I am still even do not know whether they reached developers or not. Even if yes, the present NIDAQ still does not have these functions and this means that NI takes 2..4 years to react on the feedback.

At the moment I have no choice, and I do maintain self-made info file (nidaq.ini). But beleive me, it is a pain in the @ss to scan help files and manuals of the DAQ cards which I've never seen just to include info in nidaq.ini. And when my customers of a brand new NIDAQ ca
rd call and wonder why the card is not reacognized by my application correctly, I tell to them that this is basically fault of NI. Because NI provides no way to get card info. I am doing my best analysing error codes, but it does not help in all cases. Sorry, guys, but you left no choice to me.

As for NIDAQmx, this is not a solution either. I am not going to rewrite my existing and working rather big application. It could be a good suggestion for those who just starts developing a new applications from the scratch, but not for those who almost finished it. Even for those who begin now, NIDAQmx may not be a good choice, because, as I saw in this forum, it does not support all cards that are supported by NIDAQ. It also looks like that instead of improoving, developing and fixing NIDAQ, NI dicided to change API completely. It is not yet clear to me whether NIDAQmx is supposed to substitute NIDAQ in the future or not. If not, I would concentrate on improoving trad. NIDAQ. If yes, it wou
ld be a disaster for many developers. 😞

Anyway, I hope that the interaction between NIDAQ team and application developpers will be improoved, and we will see some results of this feedback.