We are encountering severe problems while reading from the digital port on our PXI-6221 M-Series DAQ device using an external sample clock.
Let me quickly introduce our application:
We have a laser-distance-meter which communicates with our PXI process controller via a synchronous serial protocol. With our M-Series DAQ device, we create a 1 kHz clock, which is used as our primary control cycle. Our application is timed to that clock using the Wait For Next Sample Clock.VI.
In addition, that clock is exported to one of the PFI (PFI 1) lines of the DAQ device in order to trigger the data transfer between our laser-distance-meter and our DAQ. The answer of the laser-meter consists of two elements:
- a data clock line on which a puls train of 24 cycles is send upon the trigger-impulse, we connected that line to PFI 2 of our DAQ device.
- a data line which holds the 24 bits (serial) correspondig to the 24 clock impulses on that clock line, connected to DIO 0 of the DAQ device.
This transfer method is also known as synchronous serial transfer.
We have configured a DaqMx Task within Labview in order to read those 24 bits with our PXI-6221 DAQ-device:
Since the data on the clock line of the laser-meter is set every rising edge of the data clock, and therefore is surely stable at tha falling edge of that data clock, we configured a clocked digital input task to read the data at that falling edge. Let me just sum up the task properties we chose:
- digital input, single line (DIO 0)
- continuous acquisition
- external sample clock (PFI 2)
So this way, whenever a clock impulse appears on PFI 2, the DAQ should take the actual value on DIO 0 and transfer it into the DAQMX buffer. Of course the data clock is fast enough for the 24 bits to be finished comfortably within each control cycle (again: 1ms). Therefore, on every new control cycle we completely read out that buffer (DaqMxRead with number of bits set to -1) and therefore should get the desired 24 bits of the laser meter.
Now the trouble:
Whenever we get an extra, unwanted clock impulse due to any em-disturbance, of course we than might have 25 bits instead of 24 and get a wrong reading once. This is what we understand. The ackward behaviour is that whenever such a disturbance occured, all next readings are wrong as well, more precisely: our bits are shifted in their position within the desired 24 bits, so if we originally should read (8-bit example): 00101000 we then read for example 00001010. This wrong reading stays stable even if the source of noise on our data clock line has been removed.
It seems that when we read the buffer with our DaqMXRead command there is partly new data and partly old data in that buffer. We cannot understand that behaviour since after we read the buffer it should be completely empty until the next data transfer starts and we execute that read after the data transfer should be finished. Is there another low-level mechanism, for example the transfer of the bits from the hardware into the DaqMX driver's buffer, that screws up this acquisition? If yes, how can we influence that?
The described method to read the data from our laser meter has been an advice from a NI support engineer, by the way, and we already spent way to much time for the development of that trivial communication-task.
