RS-485 is a 2-wire bus. All stations use this bus for sending and 
receiving. E.g. you have to switch between sending and receiving, 
otherwise you have collisions. Your software must control this.
gk

>>RS-485 is a 2-wire bus. All stations use this bus for sending and
>>receiving. E.g. you have to switch between sending and receiving,
>>otherwise you have collisions. Your software must control this.
>>gk

I know.  I'm using off the shelf software that is doing this.

>A MODBUS slave uses the "driver output enable" pin of its RS485
>transceiver to switch between sending and receiving.
>A MODBUS slave is in receiving mode nearly all the time, which is
>accomplihed by disabling its output enable. Only if the slave is allowed
>to send the corresponding output enable is activated and the tranceiver
>is sending.

>Do you control this pin of transceiver?? Without careful control of this
>pin you will suffer from bus collisions!

As I explained in the original post, this is occurring with a RS232 to 
RS485 converter connected to to a computer, the converter's power 
supply, and nothing else.  There is nothing but a terminating resistor 
on the bus pins.  I did have a slave connected previously, but to prove 
the slave wasn't causing it, I disconnected it.

You likely need bias resistors on your RS485 line to pull the line to 
"inactive" state. Otherwise there might be a spike when your RS485 
converter turns off its line driver, which might be interpreted as a 
start bit causing the extra zero to be recieved.

See http://en.wikipedia.org/wiki/RS-485 for a simple circuit diagram. 
Basically add a 680 Ohm resistor from +5V to the RS485 positive line 
(mostly called A, but there is a standard calling the positive line B), 
and a 680 Ohm resistor from GND to the RS485 negative line (mostly 
called B).

Regards

Tassilo

>>As I explained in the original post, this is occurring with a RS232 to
>>RS485 converter connected to to a computer, the converter's power
>>supply, and nothing else.

>This is no standard Modbus setup, so the results of your "experiment"
>make no sense. A standard Modbus slave must be able to receive and to
>send. How do you want achieve this with your simple RS232 to RS485
>converter??

Achieve what?

As stated in my original post, the problem is that when I transmit 
something, even with no slave attached, the RS485-capable communications 
program (doesn't matter which one I use) immediately receives a single 
zero byte at the end of transmission.  I can't blame a slave for this, 
because there isn't one.  Had I left the slave connected, the question 
of course would immediately be "is the slave causing it?"  The answer of 
course is no, because there isn't a slave, yet I still receive this 
phantom zero.

Tassilo,

At least you are understanding the issue.  I have tried biasing the line 
as you describe, however it was with slave power.  I may try to do that 
with master power.

>>As stated in my original post, the problem is that when I transmit
>>something, even with no slave attached, the RS485-capable communications
>>program (doesn't matter which one I use) immediately receives a single
>>zero byte at the end of transmission.

>But you wrote this line as well:

>>If I do have a MODBUS device connected to the bus line, the device
>>correctly receives what the adapter transmits, only that the received
>>response is preceded by a zero byte.

>And I ask you again: How do you communicate with the slave, if you do
not control the output enable pin in your RS485 transceivers??

On the slave, I control the transmit and receive enables separately as 
required.  When transmitting I enable the transmit driver, and when not 
transmitting, I disable the transmitter and enable the receiver.  But 
the slave is not the issue.

As for the RS232->RS485 converter, the RTS/CTS lines are controlled by 
whatever Windows program I'm using.  I've tried:

Realterm, which has a setting for RS485

modpoll.exe, a free program by FOCUS Software Engineering Pty Ltd

Simply MODBUS 7.0


All three see this phantom zero immediately returned after transmitting 
something.

This is weird. I have seen a setup like yours working (RS232-RS485 
converters on PC side with Eurotherm Modubus temp controllers). The only 
pitfall with MODBUS in such a setup is that it is necessary to send all 
data bytes of a MODBUS packet to the windows driver at the same time to 
ensure the maximum char-to-char time for a MODBUS frame is maintained.

Things to try:
Are you sure the polarity of the biasing resistors is correct?
Keep in mind that sometimes the two RS485 lines are labeled A+/B- 
(common practice that A equals positive), whereas there is some ISO or 
IEC standard specifying A-/B+.

Be aware that simple converters rely on the RTS line to switch at the 
end of a PC-side transmission. Your terminal programs should have taken 
care of that, though.
To avoid the issues with the RTS-controlled line driver enable, I can 
recommend USB-RS485 converters with FTDI chipset, e.g. at 
http://www.ftdichip.com/Products/Cables/USBRS485.htm
They have worked well for me.

Regards

Tassilo

Wubbo,

Check the rs485 biasing.

http://www.avrfreaks.net/forum/modbus-checksum-errors
http://www.ti.com/lit/an/slyt514/slyt514.pdf
http://www.ni.com/support/serial/resinfo.htm

Cheers,
Tony

Hi Wubbo.

I know this is an old post, but i am experiencing the exact same 
behaviour. I wonder if you has solved the problem?


Thank you in advance.