Local echo from virtual COM port requires two reads to flush buffer and is causing problems!

[wsitch]

Hi everyone, we have an instrument with both a GPIB and USB port.  We can communicate just fine through GPIB.  All commands work, the instrument responds as expected, life is great.  

Our engineers designed the instrument so that we communicate over USB by setting up a virtual COM port.  We're using an FTDI virtual com port driver.  This driver makes the USB connection appear to be a COM port.  When I load NI MAX, I see "COM8", and it appears to be working fine. 

We're experiencing an annoying local echo problem that's stopping us from using the same LabVIEW code (written with VISA read/writes) with either a GPIB address or a virtual COM port address. 

When I load NI VIC and write "*IDN?\n", the first read returns "*IDN?\n", and a second read returns the correct IDN string.  Similarly, when we use PuTTY or hyperterminal to read/write from the COM port we get the same problem.  PuTTY and hyperterminal have a local echo setting that eliminates the first return string.  I can't figure out how to do this with VIC or LabVIEW VISA commands or attributes or anything.

Any ideas?  We're quite frustrated.  We're using an ancient version of LabView 6.1 and the latest VISA libraries.  VIC is recent.

Thanks,

Will

707.292.3669

[Broken_Arrow]

Interesting. I've never experienced this, as far back as LabVIEW 6.i. It seems like you have a loopback AND you're getting the proper response after the loopback. I would suspect the virtual com port.

Get something that uses a normal serial rs-232 port and communicate to it, and see if you get the echo.