If PC signal RTS gets low, it stays low.

[AndJ]

I use VISA Open. Property node is set to CTS/RTS flow control at 57600 bps. On some computers, the RTS gets low after receiving about 100 characters, and the sending unit stops. The problem is that the RTS is never asserted again to allow further communication. I use 4096 bytes of software buffer and checks the number of bytes received (using property node/Asrl Avail Num) before trying to read them. If I monitor the RTS state from labView, it reports that it is high when it is in fact still low. Adding extra stop-bits on the sending unit did not help (the unit still accepts 1 stop-bit for PC data flow).

This behaviour occurs in labView 5.1.1 both in windows and in linux. I have done the loopback-test using Hyperterminal with
local echo ON, failing to produce two characters on screen for each key pressed. Therefore, I assumed a PC hardware problem. However, today I was told that there was a bug in Windows98 Hyperterminal and that the computers fully passes the loopback test using Hyperterminal 6.3 from Hilgraeve.

Has anyone heard of RTS bug in the VISA driver? Maybe I should try an older VISA version, from the ages when computers needed the RTS signal more frequently? The VISA files needed are
serpdrv (perhaps not a VISA file)
visa32.dll
niviio.dll
nivisv32.dll

Is there a way to slow down a modern computer so that it is forced to use the RTS signal? That way I could see if the problem in fact occurs on all computers.

Regard,
Anders Jansson
Piezomotor AB
Sweden

[Chris_Rake]

RTS/CTS flow control is handled at the driver level, and VISA simply tells the serial device driver to enable flow control. What type of serial interface hardware are you using? After checking to see how many bytes are present in the read buffer, are you reading the data clear the stop condition?

[AndJ]

Serial hardware is standard RS232, supposedly 16550 UARTs. When there is no more bytes comming for 1 sec, I read the bytes available in the software buffer. This does not help. Supposedly, the stop condition occurs at the UART, and should be cleared by driver.

As I understand it, if the driver doesn't fetch characters fast enough, putting them in the 4096 byte software buffer, the UART gets full (more or less, depending on setting) and lowers its RTS. When the driver has emptied the UART, it is ready to receive characters again. I believe the UART takes care of the RTS signal automatically, or is it the driver that fails to reset the RTS signal when the UART is empty?

/A.J

[Chris_Rake]

This depends on how RTS/CTS flow control is implemented. If the RTS bit is set/cleared by the driver, then it is the responsibility of the driver to determine to set RTS when it has read enough data (where "enough data" is some value defined by the driver). If the RTS/CTS bit is set/cleared by the UART itself, then the status of RTS is automatically controlled by status of the FIFO.

I suspect that there is a problem with your serial hardware - who is the vendor?

[AndJ]

The problem has occured on at least three different computers. Two laptops (same model) here at Piezomotor and at least one laptop and one stationary computer at two of our costumers. I am beginning to think that the RTS line gets stuck whenever a computer need to use the hardware flow control.

All the characters transmitted can be read from the software buffer, so the UART must supposedly be empty.
Can I determine if the UART is set to clear the RTS automatically?

/Anders.

[Chris_Rake]

Taking a look at the files you've listed, it looks like you have NI-VISA 2.0.x, and I recommend that you upgrade to NI-VISA 2.6. The newest version includes several bug fixes - some of which are related to flow control. In addition, I recommend increasing the the VISA receive buffer (maybe to 16kB?).

With regards to determining what type of flow control is set, you can use the VISA property node in LabVIEW.

[AndJ]

Hello Chris,

I hope You are still out there!

I tried NI-VISA 2.6 and it was all the same. However, the run-time files I listed still seem to be the 2.0 version.

I downloaded and installed NI-VISA 2.6 Full development version, recompiled the application and tested the new stand alone program on a troublesome computer. An error occured because a VISA library were missing. The name of the missing file was not mentioned, so I copied the newest versions I could find of the VISA files niviio, nivisv32 and visa32 from the computer with VISA2.6. The program then worked, but no better than before.

Since it works, I suppose the VISA files needed are the same as before, but from Your answer I expected new 2.6 files wit
h other names to be needed.

The VISA property node does not show if it is the UART or the serial driver who are responsible for clearing RTS signal. The status of RTS signal reported from within labView are incorrect!

I have not tried to enlarge the VISA buffer since the error occures after only about 100 bytes transferred.

/Anders.

[Chris_Rake]

One more thought - you definately don't want to use an older version of NI-VISA! Features haven't been removed in the newer versions, but bugs have been fixed!