Your basic problem is thus:

The PC sends the command request to a particular slave on the half duplex RS485 bus.

Slave device gets the command and asserts his driver onto the half duplex bus to send back the reply to the PC.

Meanwhile your PC software has taken its sweet time about getting the RTS line turned off to disable your PC adapter transmit driver.

The PC gets around to actually getting the driver disabled some time after the remote microcontroller has begun to send the first byte of its reply. Obviously this creates a collision on the half duplex lines while both transmitters are on.

There are several methods to try to get this problem under control. I will discuss each here.

1) Arrange some very tight code in the PC around the transmission of the last byte of the request packet. Immediately upon the byte being completed then deassert the RTS state to disable the driver. This approach would be feasible in a DOS type environment wherein the application program could directly poll the serial port or have its own interrupt service routine for the serial port. Under a Windows environment this is not at all feasible.

2) Get a different type of RS485 adapter for the PC end of the cable that has a provision for a SEND-DATA-CONTROL of the RS485 driver. In this type of adapter there is an internal re-triggerable one-shot timer circuit that looks for transitions on the TxD line from the PC comm port. Whenever it sees a transition from the idle line state to the start bit level it triggers the timer chip. The output of this timer chip is designed enable the driver onto the RS485 bus when the timer has been triggered. Each additional transition on the TxD line will re-trigger the one-shot again thus extending its enabling of the driver onto the RS485 bus. This timing circuit has a resistor and capacitor that determines how long the timer stays active after the last trigger transition it has received from the TxD line. It is normal that these SEND-DATA-CONTROL type drivers have to have the resistor and/or capacitor values adjusted so that the control mechanism works correctly according to the baud rate in use. Often these are set so that the trigger pulse time is on the order of about 1.1 character times after the last TxD transition. This type eliminates the need to mess around with RTS enabling, however it does not always work correctly if the device on the other end of the RS485 bus tries to send data back too quickly. (There are also some special types of send data control RS485 adapters that are a bit more sophisticated in how they implement the driver enable. In this type the one-shot timer is designed to have its time trigger delay set for 1.5 bit times at the baud rate in use. The driver enable is then a combination of the timer being trigger OR the TxD line sitting at the start bit level. These work much better in tight timing situations). I have also encountered a third type of RS485 adapter wherein there is no re-triggerable timer at all. In these the driver is simply activated ON whenever the TxD line goes to the start bit level and then becomes tristated again when the TxD line pulses to bits at the stop bit level. These offer the tightest timing control but depend completely on the termination resistors on the RS485 bus to pull the lines to the stop-bit or idle line state. I have found them to be useless on long RS485 busses or at fast baud rates at say over 38.4K baud.

3) You could arrange to have the slave device provide for a "turn-around-delay" such that the slave device intentionally delays sending a reply for some number of milliseconds after it has recognized a valid request. During this turn-around-time the PC has time to de-assert its RTS line before the slave begins transmitting. I recently worked on an application that had the PC talking to several slaves over RS485 half duplex at 19.2K baud. The PC end software was written in Visual Basic 6 and on a Win2K or WinXP machine running at 933MHz or better I found that it was possible to get the RTS handshake de-asserted to the RS485 adapter within 20 to 30 milliseconds. So we arranged to have the slave devices insert a 50 millisecond turn-around-time.

Hope this helps and gives you some ideas

Michael Karas