X-Series PCIe-6321 crashes DAQmx program, M-Series PCI-6221, PCIe-6259 and USB-6259 do NOT crash

[Bill_Anderson]

I have a program written in C++Builder and DAQmx.

All the M-Series boards tested (PCI-6221, PCIe-6259 and USB-6259) run the program fine for many hours.  In contrast, on at 4 different computers, the X-Series PCIe-6321 board crashes the program at 1hr 29 min.  The bug has appeared in Windows XP and 7, and DAQmx versions 9.1, 9.2 and 9.4.

The bug appears to be due to calling the DAQmx function DAQmxSetReadOffset() when it is >= 214,752,000
    int32   DAQmxInternalAIbuffer_Offset;
    ...
    DAQmxInternalAIbuffer_Offset = BufferToRead * 4000;
    DAQmxErrChk( DAQmxSetReadOffset(hAItask,DAQmxInternalAIbuffer_Offset));
    ...
    DAQmxErrChk (DAQmxReadBinaryI16(hAItask,4000,10.0,DAQmx_Val_GroupByScanNumber,AIbuffer_ContAcqPlot,20000,&NumAIsamplesPerChRead,NULL));
    ...
 Error:
    if ( DAQmxFailed(error) )
        DAQmxGetExtendedErrorInfo(errBuff,2048);

This is the information when the program crashed after running 1:29 hr:min
    "Some or all of the samples requested have not yet been acquired. ...
    Property: DAQmx_Read_RelativeTo
    Requested Value: DAQmx_Val_FirstSample
    Property: DAQmx_Read_Offset
    Requested Value: 214752000
    Device: Dev1
    Task Name: _unnamedTask<6>
    Status Code: -200284"

Since the M-series PCIe-6259 runs fine and the X-series PCIe-6321 does not, the problem does not seem to be in the PCI express bus, but in the X-series implementation.

This bug is very similar to the other bug I reported when the int32 DAQmxInternalAIbuffer_Offset overflowed and went into a negative number after 14hrs 54min. 

    32-bit lmitation of the NI-DAQmx int32 DAQmxSetReadOffset() function

and the Data Acquisition Idea Exchange

   Increasing the 32-bit NI-DAQmx int32 DAQmxSetRe​adOffset() function to 64-bits

In fact the  Requested Value: 214,752,000 in this bug is just a little more than ONE-TENTH the int32 overflow value of +2,147,483,647, and 1hr 29min is one-tenth 14hrs 54min.

My guess is that for the PCIe-6321 (and other X-series boards?), the int32 value passed to DAQmxSetReadOffset(..., int32) is internal multiplied by 10 and copied to another int32 variable which then erroneously overflows when greater than +2,147,483,647.

I think this bug is serious, and may have not been found by others because most dont use DAQmx_Read_RelativeTo and DAQmx_Val_FirstSample.  My best guess is that this error is in new X-series DAQmx code, but not in the similar older M-series DAQmx code.  Any help would be appreciated.

Thanks,

Bill Anderson

[Mcdan]

Hi Bill,

I'm going try and reproduce the issue.  I'll let you know what I find.

Dan

[Mcdan]

Bill,

I was able to reproduce this issue.  I have filed CAR 311245.

Interestingly enough, when using a single channel, I reproduce this on read offset 1,073,744,000 (5 times the offset that you observed with 5 channels).  Without looking at our code, I would guess that we're taking the read offset as an i32 and multiplying by bytes per sample (10 bytes in the 5 channel case).  I suspect that when this calculation exceeds i32 max we're erring as observed.  I'll see about getting a test for this added to our automated test suite once the CAR is resolved.

Dan

[Bill_Anderson]

Hi Dan,

Thanks for being able to reproduce this bug so soon!  Being able to reproduce this bug is very good news.  Funny how this bug is not there for the M-series boards but is for the X-series boards.

I presume the fix will be added to a newer version of NI-DAqmx.  Do you have any idea when this will be available?  My users are starting to buy the new X-series boards, and running an experiment for 1.5 hrs is not uncommon at all (whereas for 15hrs is rare).

Cheers,

Bill

[Mcdan]

Bill,

Sorry, I had a reply typed up yesterday, but I guess I forgot to hit the 'post' button.  My plan at the moment will be to get this fixed for the next DAQmx release.  Unfortunately I don't have an estimate of when that will be available.  I'll certainly let you know if I can find a work-around for you in the short term.

Dan

[Bill_Anderson]

Hi Dan,

If it will be in the next DAQmx, 9.5, that would be great.  Since there were 4 months between 9.3 and 9.4, I suspect it will be of similar time scale.

A temorary fix would be great if you could do it.  I dont know how hard it would be.  But it would be good for those who have already bought a PCIe-6321 instead of a PCI-6221.

Thanks,

Bill

[Mcdan]

Hi Bill,

In my investigation, it appears as though we are using the read position and offset to index into the raw data buffer calculating the index using a signed integer that is 'pointer width' wide (over-simplified, but this is the general idea).  What that means is that for 32 bit applications, the integer is 32 bits wide.  For 64 bit applications, the integer is 64 bits wide.  If I take your code and build a 64 bit executable, I no longer get error -200284 at read offset 2,144,000,000.  If this is an option for you, it could be a work-around for those users of yours who run 64 bit Windows.

Hope that helps,

Dan

[Bill_Anderson]

Hi Dan,

My current C++Builder compiler is 32-bits only.  When upgrading to 64-bits I would have to be very careful not to introduce new errors, ie making sure my longs, ints and __int64's work correctly.  Plus, a good half of my users are still on Windows XP.  So that is not really a good solution.  But I will keep this in mind as a possible solution.

I know that 

    DAQmxSetReadOffset(hAItask, int32_variable)

takes an int32 variable, so I guess with your 64-bit compiler you are passing an int variable.  I dont imagine it would be possible to pass an __int64 variable with my 32-bit compiler?

I am recommending to my users if they are buying a new board to buy an M-series PCI-6221, and if they have already bought an X-series PCIe-6321 to hold on and keep their experiments less than 1.5 hrs (or automatically restart their experiments at 1.5 hrs) until a new NI-DAQmx driver is available.

Cheers,

Bill

[Mcdan]

Bill,

You are correct that with a 64 bit compiler DAQmxSetReadOffset still passes offset as an int32.  It would take a change to the DAQmx API (as you recommended) to allow this to be specified as an int64.  For now, it sounds like recommending M Series is a good approach.

Sorry for the inconvenience,

Dan

[Bill_Anderson]

Hi Dan,

So I guess there will be an internal fix in the DAQmxSetReadOffset() to use 64bits internally and therefore work with X- as well as M-series board, but still have an int32 value passed to it.  And this will be available in DAQmx version 9.5 in a few months.  That's OK, I can live with that.

Cheers,

Bill