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

[Bill_Anderson]

I have a data acquisition NI-DAQmx/C++ program where I am continuously acquiring 5 channels of data at 40KHz/channel and reading them in 0.1 second chunks.  This successfully works perfectly for over 14 hrs continuous acquisition, but at 14hrs, 54 min and 47 seconds the program hangs up due to an overflow in the int32 DAQmxInternalAIbuffer_Offset value sent to the DAQmxSetReadOffset() function.  In the DAQmxSetReadRelativeTo() function, I set the offset relative to the first sample using DAQmx_Val_FirstSample.  (See "32-bit lmitation pof the NI-DAQmx int32 DAQmxSetReadOffset() function?")

It would be very helpful for the DAQmxSetReadOffset() offset value to be 64-bits rather than the current int32 value.  This would make this function analogous to the DAQmxGetReadTotalSampPerChanAcquired() which returns a 64-bit value.  I understand that the offset is maintained internally as a 64-bit value, so perhaps this would not be too difficult to do.

I hope that National Instruments fixes this limitation in their API, not just for 64-bit Windows, but also for 32-bit Windows because a lot of us are still using 32-bit compilers and our users are using Windows XP.  Perhaps it could be implemented as a separate DAQmxSetReadOffset64() 64-bit function for the 32-bit Windows.

Thank you,
Bill Anderson

[Brad_K]

Here's a link to the original post: 32-bit lmitation of the NI-DAQmx int32 DAQmxSetReadOffset() function?

Also, a clarification: the read position is a 64-bit value, but the read offset is currently pointer-sized (e.g. intptr_t). The DAQmx API doesn't directly expose the read position; rather, you indirectly control the read position by setting the ReadRelativeTo and ReadOffset properties and then performing a read. They are only equivalent when you read relative to the first sample (which is exactly what Bill's program does).

[Kevin_Price]

Agreed on the need for a higher bit count on the Offset value to maintain symmetry with TotalSampPerChan.   I'd probe at this a little further though and ask why some of the DAQmx read/write property nodes return integer quantities as 64-bit *floating point* values?

Namely, CurrReadPos, CurrWritePos, and TotalSampPerChanGenerated.

I suspect they were made into 64-bit floats as a way to count higher than 2^32 back before 64-bit ints were supported at the application level.  I'm guessing they're implemented as ints down in the driver level, so is there any reason they couldn't also become 64-bit ints in the API now?

-Kevin P

[Brad_K]

That's right: before LabVIEW supported 64-bit integers, DAQmx used double precision floating point to represent integers up to 2^53. Now LabVIEW has a U64 type, but these properties are still DBL. Removing the DBL properties would break compatibility with EXEs built against previous versions of DAQmx, but it may be possible to add new U64 properties and hide the old DBL properties. Or just have both versions show up in the property node (e.g. CurrReadPos and CurrReadPos64).

[Bill_Anderson]

Hi Brad and/or Kevin,

Has there been any progress improving on this limitation in the past 8 months?  Is there now a DAQmxSetRe​adOffset() 64-bit function that receives a 64-bit integer rather than a 32-bit long?  And out of curosity, has the internal timing at least been switched from using a 64-bit floating point value to a 64-bit integer? 

Thanks,

Bill Anderson