Why does DIO6534 behaves differently from its lesser relatives?

Question

I am developing under LabWindows/CVI some code for the DIO 653X family. It's almost two years since I started working with'em, so it's disappointing the problem I'm talking about.
This is the guilty code:
DIG_Grp_Config(DIO_BOARD, 2, 2, 2, 0);
DIG_Block_PG_Config(DIO_BOARD, 2, 1, 0, rtimebase, rreqint, 0);
DIG_Block_In(DIO_BOARD, 2, in_conf_buff, 1281);
do {
status = DIG_Block_Check(DIO_BOARD, 2, &rem);
} while (rem);
It is used to read in pattern generation 1281 samples, 16 bits each, on group 2
The code runs OK on DIO 32-HS and on DAQCard 6533, but it faults on DIO 6534.
Provided that rtimebase e rreqint are correctly defined and that in_conf_buff is wi
de enough to contain all the acquisition, the problem is: come to the do-while loop that worries about controlling that the acquisition is running OK by the DIG_Block_Check instruction, the program remains in the loop, with a single sample to be read (rem = 1), only with DIO 6534.
I made some trials to get out of the mess, so that I found that the error happens when I use an odd number of samples, not when I use an even number. But the REQ pulses number are needed to drive a read-out chip, so I can't simply reduce or increase by 1 the samples number, as this would leave the chip in an umpredictable state.
Who can help me?

Answer 1

Hi medihelp,
Because the 6534 always performs DMA transfers in 32-bit even for 16-bit input groups, there will be "stranded" data if the number of data transferred is not a multiple of 4 bytes. This different behavior (compared to the 6533) is due to the addition of onboard memory to support high speed transfers. At the end of the DMA transfers, the stranded data will be retrieved manually, and status should be updated to indicate that the tranfer is truly finished. There is a bug in the NIDAQ driver that fails to update the status flag, causing the return value of DIG_Block_Check to get stuck at 1, even though all data has been acquired. The fix for this problem will be made available to all users very soon. In the meantime, I would recommend that you either make the
sample count a multiple of 4 bytes, or change the condition of the while loop to break when DIG_Block_Check returns 1 instead of 0.