extra IBF pulse in block read input

[Mike_Swann]

I am attempting block read input on a PXI6508 with LabWindows CVI V6.
After I have configured the block read using DIG_SCAN_Setup, I initiate the read using DIG_Block_In. Data is already present on my external device, and when the DIG_Block_In function is called IBF goes low (which clockes data out of my device), then about 27us later the block of data is read. For example, if I set up for a block of 128 reads, I see one IBF pulse then a delay of 27us then my 128 read pulses seperated by 5us each. The array the bloack of data is sent to only has the data associated with the 128 read pulses in it. So I basically lose the first data. Each time Dig_Block_In is called the result is the same, one pulse, 27us delay, then the requested n
umber of read pulses.
Do you have any idea why this occurs.

Regards

Mike

[rgharrison]

Hi Mike,

I'm not sure if I understand your setup correctly but correct me if I'm wrong. You have an external device that communicates using a handshaking protocol. Do you keep the /STR line low? Are you handshaking or just acquiring input? Final question, is your /IBF line low to begin with or does the DAQ board start high pulse low, wait 27us and then pulse low 128 times for 5us each time?

I've included example code that ships with NI-DAQ to input using handshaking and the 8255 DIO chipset. Try running a derivative of that code to see if there is a difference in operation. Hope that helps.

Ron

[Mike_Swann]

Hi Ron

My external device communicates using a handshaking protocol.
/IBF starts high as there is data available from my device and /STR starts high. When I initiate the block read /IBF goes low about; 20ns after the falling edge of an /IBF my /STR goes low for 120ns to clock in the next lot of data. The second /IBF pulse occurs 27us after the first, the subsequent /IBF pulses are spaced by 5us.
I modified your example code for my hardware, and set it to perform a block read of 10 reads. There were 11 /IBF pulses measured in total. The array has the correct data in it, but the extra /IBF at the end of the block read clocks one too many bits of data out of my hardware, which is lost. I increased the size of the target array, still keeping the number
if reads at 10, and the extra data that read (ie clocked out of my hardware) is not written to the array (the extra elements are zero).
Basically it appears that if you select "n" reads for a block read the 8255 chip produces "n+1" reads (/IBF pulses).

Regards

Mike