Error with Thor Labs piezo controller in LabVIEW

[sth]

Jeff,

I have been in discussion with the FTDI folks.  The minimal latency for the two chip sets I am testing is 2 mS.  I have been informed that reducing it to 1 or 0 is "not possible" for these chip sets.  They are the USB 1 and USB 2 versions of the chip sets.

So for these devices I have set the latency to 2 mS by tweaking the Info.plist file in the kernel extension.

Now when I communicate and for example send 100 million bytes through the port one byte at a time with a loop back connector.  I get a timeout occasionally.  This is with a 16 mSec VISA timeout which should be sufficient.  When it times out the byte is not transferred and I get a buffer count mismatch.

I maintain that this is not a device but a VISA error (and I think I will start a new thread on this).  I believe that the byte is transferred within the timeout period but when VISA checks to see if the byte is there, it first checks the timeout and returns an error and no byte.  Even in the reverse order it can be a problem.  This is a bit tricky since if VISA gets the CPU taken away there may be significant time between checking the byte and checking the time.  For example:

For example, at T=0 a byte is sent and then read at the loop back connector.  Timeout value set to 4 mS

T= 1mS     VISA checks if byte is available (NO)

T= 1.1 mS OS takes CPU away from VISA for other system tasks

T= 2mS     Byte arrives at input buffer

T=10mS    VISA gets control back and checks time, Time now exceeds timeout and VISA reports error and timeout

In this case the character arrived well within timeout period but VISA was unable to verify that a true timeout occurred but reported one anyway.

Attached is a histogram of visa write/read events.  I had set the VISA timeout to 16 mS so I got a lot of errors where 1 byte was sent and none received.  I beleive that there was 128 million tests run (about 4 hours).

I could set the timeout larger but I think that just makes the problem rarer and does not solve the underlying issue.  It is more reliable but still not fixed.

I believe this is getting a little OT and should go to a new thread.  I should repost this in a thread of its own.

[sth]

I forgot to mention.  I don't think the buffer size can be tweaked in the Mac OS X drivers from FTDI.  However I ran a check on the interrupt and scheduler latency for 18 hours and never found any interrupt latency of more than 3.078 mS pretty much evenly distributed across the multiple CPUs.  Scheduler latency was never more than 163 microseconds.  It is not the OS that is causing these big latencies.

Also using the Keyspan adaptors gives similar results but the parameters of the driver cannot be tweaked AFAIK.