Fast, small-byte reads and writes.

[kemlab101]

I am trying to communicate with a third-party counter using a 1 byte "start" command followed by reading a 4 byte number.  I would like to perform this read/write pair as fast as possible as I will be using count-times on the order of microseconds repeated millions of times.  Our first attempt used USB but the latency in the bus was way too slow at 1ms.  We spent more time waiting than counting. We are currently considering GPIB since the latency should be only 30 microseconds but we're concerned that the overhead from labview will prevent us from reading and writing that fast.  Another idea we had was to use digital I/O channels to create our own parallel port to by-pass the USB bus.  Can anyone comment on a good solution for low-latency small-byte reads and writes from labview? What type of hardware is recommended and can labview support programmatic reads-writes on the order of microseconds? Thanks!

[tst]

When using a standard OS (like Windows), there is no way to get deterministic performance of any sort, and LV is limited to milliseconds. The OS is also responsible for the actual control of the hardware, which adds another layer between your code and the hardware.

There is a real-time version of LV, and it can also be run on some desktop computers, but I assume that the speed of the communication part depends mainly on the RTOS. You can try asking at the real-time board to see if anyone there has any experience with this.

[Scott_Jordan]

Theoretically GPIB is capable of very good latencies, as you say on the order of usec.  But in the real world using real PCs running real operating systems and connected to real instruments, the latencies seem to cluster around 2-5msec, in my experience.  The issue isn't LabVIEW so much as all the stuff through which instrumentation interactions must filter, including background processes, screen updates and all the rest of the activities which consume the processor's bandwidth.  Some instruments allow you to buffer and interpret the next command while the current one is underway, then trigger it, which saves latency.  Also keep in mind that your GPIB network will only be as responsive as the least-well-behaved instrument on the bus.