Hi,
We are having some problems with the read and write performance of the DIG_Out_Prt() and DIG_In_Prt() when used for sending parallel port data.
Background information:
-------------------------------------
We are using the DIO-96 PnP PCI card connected to an adapter, that among other things has a parallel port connected to the device under testing (DUT).
This parallel port is used for writing the data and control bits to the DUT, during which the control bits are also read from the parallel port in order to determine when the DUT have read one byte.
The DIO ports used for this is,
port 3 = data write (BPA Output)
port 4 = control write (BPB Output)
port 1 = control read (APB Input)
(port 0 = data read (APA Input), but it's not used.)
The ports are configured in the proper direction and handshaking is disabled, we use the traditional NI-DAQ API and C++.
After doing some special signaling, the DUT parallel port is basically in reverse ECP mode.
The process of writing one byte to the DUT parallel port is as follows,
1. The control and data bits are configured.
2. Using DIG_Out_Prt() the data and control bits are written to the parallel port.
3. Poll the control read port using DIG_In_Prt() and wait for Reverse Request bit from DUT.
4. Using DIG_Out_Prt() and the control bits to write an ack for the reverse request and to ack that there is data on the wire.
5. Poll the control read port using DIG_In_Prt() and wait for DUT to ACK that the data have been read.
6. Using DIG_Out_Prt() and the control bits another ack is written to the DUT.
7. Poll the control read port using DIG_In_Prt() and wait for DUT to signal that the cycle is complete.
And then basically it starts all over for sending the next byte.
The problem:
-------------------------------------
The problem is that sending bytes takes time, and this time seems to vary from computer to computer(!).
We send about 800 bytes and this takes about 20 seconds on my developer computer (P4 1.7Ghz), other developers have reported about 30 seconds and on the production computers it takes a staggering 50 seconds! (Those computers are P4 2.4Gz.)
The thing is that *sometimes* when rebooting the computer, or after using the Measurement & Automation test panel the time it takes to send the bytes have significantly been reduced to a few seconds, which is the time I would expect it should take.
What could be the problem? Where should I begin to look? I've examined this before but could not find anything conclusive to why this happens and how to make it run as fast as it should. Is there any configuration of the IO card that can be done that affects performance?
Is there a better way to send reverse ECP parallel port data over the same ports and directions as outlined in the description above?
Any help is appreciated.
Cheers,
Hans
