Async Read by external REQ1 line got wrong data

[J_K]

Hi,

I am new to NI-DAQ C programming and we have a PCI-6534 card for data aquisition.

I started with an included example and try to work my way out. Essentially, we are dealing with a sensor chip which generates data (about 2 MHz 8-bit) and provide a data latching signal (RE).

During data aquisition, we want to make the PCI-6534 work like a slave and just listen to the data port (port A) and latch the signal according to the follwing edge of the RE output from the chip. The RE is connected to the 6534's REQ1 pin. There will be about 400K byte data for each of operation and the data does not need to be realtime.

My question is, which flow should I use. From the user manual, I picked the "level-ACK" hand shaking flow. Though "ACK" is not connected in our case, I assume it can still listen to the REQ1 pin. Here is our code:

----Start Here----

static i16 piBuffer[400000] = {0};
u32 ulCount = 400000;
u32 ulRemaining = 1;
(....chip initialization & register read/write...)

iStatus = DIG_Grp_Config(
iDevice,
iGroup, // 1: Port A
iGroupSize, // 1: 8-bit
iPort, // 0: Port A
iDirIn);

iStatus = DIG_Grp_Mode(
iDevice,
iGroup,
0, // Protocol: 0 = level-ACK
0, // Edge: 0 = leading edge
1, // reqPol: 1=active low
0, // ackPol: (don't care)
0); // ackDelayTime (don't care)

iStatus = DIG_Block_PG_Config(
iDevice,
iGroup, // 1: Port A
iPgConfig, // 1: "0" does not work
iReqSource, // 1: from REQ pin
iPgTB, // 3 (don't care)
iReqInt, // 10 (don't care)
iExtGate // 0 (don't care)
);

iStatus = DIG_Block_In(
iDevice,
iGroup,
piBuffer,
ulCount
);
while ((ulRemaining != 0) && (iStatus == 0)) {
iStatus = DIG_Block_Check(
iDevice, iGroup, &ulRemaining);
iRetVal = NIDAQYield(iYieldON);
}

(.... Access data at piBuffer...)

---- End Here ----

With the above program, data capture ran through but the data itself has some problems. Seems like the same data pattern repeats itself several times before having a different data set, which is not the way it should be. Seems like the DAQ card does not really wait for the data latching signal from REQ1 to capture each data. Did I do anything wrong?

We have another LabView program running and we used that to verify the device can capture data correctly. However, we just can't do the same thing on C (The LabView program was prepared by a very remote team and we cannot have easy access to their knowledge).

Thanks.

Regards,
JK

[mhaag]

JK,

Thank you for contacting National Instruments. First if it is possible to take a look at the LabVIEW code that performs the data acquisition that you are trying to accomplish with C, then I would try to simply imitate the VIs used with the NI-DAQ functions. The general flow of the C functions you will use should almost exactly match the VIs in the LabVIEW program.

From your description of the problem, I was a little unclear as to whether the data was just being latched more times than expected or whether the data latching signal on REQ1 was just not working at all. From the snippet of code you included, it looks like you are using the correct functions and that the flow of the program is correct. One thing you will want to verify is that the size of your buffers and the constants in the example that you are basing this program off of are correct and not to large - this could cause the data to be latched again in order to fill the buffer up and complete the DIG_Block_In function.

The example that I looked at that mimics your code and may be what you based it off of is DIsingleBufPatternGenExtClock653x.c. You might try to run the shipping example again and modify the constants and buffer sizes, so that it will acquire the data that you want.

If you are interested in reading a little bit more about the various Digital I/O protocols that are available, then please take a look at the following link for some more information:

http://zone.ni.com/devzone/conceptd.nsf/webmain/467ed254f3a30b1286256a6f00720951

Another option that you can look at is that if you are wanting to latch data coming into your device on every falling edge of the data latching signal (which should just be a clock) you can look into the Synchronous Burst Mode protocol. In this protocol you can use a burst mode input that will latch data on every falling edge of the external clock as long as ACK and REQ are both set high.

If you have any further questions or if you are still having problems acquiring the correct data, then please let us know and we help you out further.


Regards,
Michael Haag
Applications Engineer
National Instruments
1-866-ASK-MYNI