Problem with NI library function DAQmxReadAnalogF64

Dear MATLAB community, at the moment I try to acquire Data with my National Instruments Hardware SCXI 1122 with PCI 6220 via the NI library (nicaiu.dll and nidaqmx.h as header file). The reason for using the library is, that the standard DAQ Toolbox and the DAQ Session does not fully support the mentioned hardware. My actual problem is the reading of the AI channels. In the NI-DAQmx C Reference Help document the signature of the DAQmxReadAnalogF64 function is:

      %-------------- NI-DAQmx C Reference Help ---------------------------------
      % Functin to read an analog input channel
      %
      % int32 DAQmxReadAnalogF64 (
      %                                  TaskHandle taskHandle, 
      %                                  int32 numSampsPerChan, 
      %                                  float64 timeout,
      %                                  bool32 fillMode, 
      %                                  float64 readArray[], 
      %                                  uInt32 arraySizeInSamps, 
      %                                  int32 *sampsPerChanRead, 
      %                                  bool32 *reserved);
      %--------------------------------------------------------------------------

for any reason, I don't know why, MATLAB is loading the read data into the space/buffer where the pointer *sampsPerChanRead shows and not into readArray[] pointer. As far as I understand the Reference, the function is loading the number of samples which are read into the *sampsPerChanRead; so this must be then an İnteger, but the values stored in the buffer where the pointer *sampsPerChanRead shows seems to be the read values, because the values are something with: x.y*10^(-5). Due to the fact I connected an J-tye thermocouple to the channel I read (Scale: -5mV to 5mV) I think this must be the read value. Furthermore the space where the pointer readArray shows becomes in MATLAB also a pointer, but normaly this buffer (where the pointer readArray shows) must be the space for the read values of that channel.

In my example down side, I choosed as pointer:

*int32 *sampsPerChanRead => ptr_SamplesRead
float64 readArray[] => ptr_dataarray*

The spaces where the pointer shows:

*ptr_SamplesRead---->SamplesRead
ptr_dataarray---->dataarray*

Again the variable ptr_dataarray is of class lib.pointer (logic) but the space dataarray is also of class lib.pointer (not logic ?! it must be content the read values:

the variable ptr_SamplesRead is of class lib.pointer (logic) but the space SamplesRead seems to be the read values, but it must be the amount of read values (in Integer) isnt it ? (See Reference)

%% Read the analog input channel

%-------------- NI-DAQmx C Reference Help ---------------------------------
% Functin to read an analog input channel
%
% int32 DAQmxReadAnalogF64 (
%                                  TaskHandle taskHandle, 
%                                  int32 numSampsPerChan, 
%                                  float64 timeout,
%                                  bool32 fillMode, 
%                                  float64 readArray[], 
%                                  uInt32 arraySizeInSamps, 
%                                  int32 *sampsPerChanRead, 
%                                  bool32 *reserved);
%--------------------------------------------------------------------------

readtimeout=10; %timeout in seconds for the read function

% Create the buffer where the data will be stored and a pointer to this
% buffer
dataarray=zeros(samples,1);
ptr_dataarray=libpointer('doublePtr',dataarray);

%Create a buffer where number of read samples are stored and a pointer to
%this buffer
SamplesRead=0;
ptr_SamplesRead=libpointer('int32Ptr',SamplesRead);

%Create an empty buffer and a pointer to this buffer for the 'reserved'
%argument. This argument is reserved for future use and should be passed
%as NULL.
reserved=libpointer('uint32Ptr',[]);

arraySizeInSamps=uint32(1*samples);

[err dataarray SamplesRead reserved] = ...
    calllib(libalias,'DAQmxReadAnalogF64',taskhandle,int32(samples),...
            readtimeout,DAQmx_Val_GroupByScanNumber,ptr_dataarray,...
            arraySizeInSamps,ptr_SamplesRead,reserved);

DAQmxCheckError(libalias,err);

if(err==0)
        disp('The data has been read successfully!');
elseif(err<0)
        disp('An error has occured ! Data has not been read');
        %disp(strcat('Error code: ',num2str(err)));
        DAQmxCheckError(libalias,err)
end

sampleperiod=1/samplerate;
timevec=sampleperiod:sampleperiod:acquiretime;
%disp([timevec readarray]);
%plot(timevec,readarray);
%*************************************************************************%

I am using MATLAB R2012a on Windows XP 32 Bit.

I would appreciate every help and hint.

best regards, opcode_torule

Answer 1

[Walter Roberson]

In ISO Standard C, in declaring a stucture, the syntax

float64 readArray[]

does not mean the same as

float64 *readArray

The version with the * allocates space for a pointer to a float64 value.

The version with the [] after the array name is permitted only as the very last structure member, in which case it is a "flexible array declaration" , http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section 6.7.2.1, paragraph 16 (page 115 in that PDF)

when a . (or ->) operator has a left operand that is (a pointer to) a structure with a flexible array member and the right operand names that member, it behaves as if that member were replaced with the longest array (with the same element type) that would not make the structure larger than the object being accessed;

Your compiler is not diagnosing (or not creating a fatal error) for the flexible array declaration not being the last element of the struct, so when you access that flexible array you get whatever happened to be there in memory, namely the fields that follow in your struct declaration.

Answer 2

[Tugrul]

Mr. Roberson, thank you very much for your quick reply. But I am confused, because in many 'seems to be working' codes for MATLAB this decleration I mentioned ıs/was used. What is the solution now for this problem ?

best regards, opcode_torule

[Walter Roberson]

The construct is illegal in C (and C++). One would need to study the details to see what their intention was. Converting to float64* would be appropriate if the field is intended to be a pointer to an array, but if the field is intended to be the array itself then it is incompatible with the last three fields being present and so should be declared as part of a union.

I am trying to look at the explanation of the .h file on NI's site, but the network is not cooperating with me.

[Walter Roberson]

NI's NIDAQmx.h does not define any struct . I do not know if that is the same file as nidaqmx.h -- case *does* make a difference in some operating systems.

Answer 3

[Tugrul]

Now it seems to work. I just controlled with the 'libfunctionsview' in MATLAB the return values and input arguments of the function and there are five return values and not only four ! Due to this, the output were shifted.... now the function call is like this:

   [err dummy dataarray SamplesRead reserved] = ...
        calllib(libalias,'DAQmxReadAnalogF64',taskhandle,int32(samples),...
                readtimeout,DAQmx_Val_GroupByScanNumber,ptr_dataarray,...
                arraySizeInSamps,ptr_SamplesRead,reserved);

now everything fits:

err = contains the error code, in this case 0 (success)
dummy = the additional parameter which contains a pointer (class lib.pointer)
dataarray = the read data
SamplesRead = the number of read samples (in this case 25)
 reserved = empty

To verify this, I have connected a known voltage source of about 3.9V to the SCXI 1122 / SCXI 1322 Terminal Block and I measured the 3.9V with SignalExpress (Tool of National Instruments) and my code also return values of about 3.9V. But the main question is: Why in all examples , in communities, also here this function was used with four return values.

Now it is working, even with the pointer snytax I have used.

thank you for your help. best regards, opcode_torule

[Walter Roberson]

Unfortunately that is not a matter I have experience on.

People in the eastern part of North America will likely be starting to work in another 2 or 3 hours, so someone else might have an answer in a few hours.

Answer 4

[Tugrul]

Allright :-)