Intermittent VISA errors -10073807194 'connection for given session has been lost'

[zalusky]

I am using a USB/Serial converter with FTDI chipset (VCP configured) to communicate with a serial device. There is an intermittent problem where the connection disappears, and the VISA error '10073807194' is generated. I have read carefully through the other threads related to this error, but still do not have a solution. Some background information on my set-up:

1) NI VISA 5.1.2

2) LV 2010

3) Windows 7 - 64 bit

Could windows be dropping the connection for the FTDI device when communication errors occur? Has anyone had this experience? We were previously using a prolific converter, and were encountering other communication errors where the read would timeout or only partial responses would be returned, but the VISA connection was not lost. I know the prolific converters can be problematic on 64 bit windows, so I was hoping the new converter would solve the problems.

I will post the code tomorrow, but I open the VISA session and configure the port on start up and close it when the application exits. I am using the bytes at port with the VISA read. However, the code I have has been running fine on two test machines in our office for several months. The above issues have been occuring at a customer's site overseas. We have not been able to reproduce the above problems here. There may be environmental factors at play (improper grounding, noise, etc.)

I should also mention that the original setup has this USB converter running through a hub, but the hub on their setup had to be removed due to reoccurring communication problems with this serial device, as well as other connected devices. We are going to get them to try installing a serial port on one of their PCs, and see if it eliminates the issue.

In the mean time any experience/help troubleshooting would really be appreciated.  Thank you!!!

[JÞB]

Well, I saw your Kudos to this post

Using "Bytes at port" on the FTDI driver can be very problematic and is the likely culprit for the behavior change.  If there is any way to use a term char with the serial protocol change this.

The FTDI driver does have control of the buffer size and latency timer.  Read through the documentation in this link.  At the very least your polling rate for "Bytes at port" should be greater than the latency timer setting if the expected transfer is less than the buffer size. (shorten the timer )