Forums

Implementing communication over RS-485

Started by mehulag September 9, 2006
Hello,

I need to implement a proprietary network of various devices connected
over the RS-485. No third party device needs to be interfaced, all the
devices will contain the firmware written by me.

1. Is there any specification which tells me how the devices can be
addressed over the network and messages can be accepted by them ? Also,
are there any error correction methods recommendable for this network.

2. I have read that may be ModBus protocol could be used. Can I
communicate directly to the RS-232 send and receive routines from the
Modbus module or do I need more layers of software in between ?

Please help.

Thanks and regards,
Mehul



mehulag wrote:
> Hello, > > I need to implement a proprietary network of various devices connected > over the RS-485. No third party device needs to be interfaced, all the > devices will contain the firmware written by me. > > 1. Is there any specification which tells me how the devices can be > addressed over the network and messages can be accepted by them ? Also, > are there any error correction methods recommendable for this network. > > 2. I have read that may be ModBus protocol could be used. Can I > communicate directly to the RS-232 send and receive routines from the > Modbus module or do I need more layers of software in between ?
I can't tell you if the ModBus protocol will work for you or how many layers you need. You have not defined your requirements at all. But I can tell you that one fundamental difficulty in working with RS-485 or any half duplex protocol is knowing when the bus is free. I once worked on an RS-485 bus where the designer of the bus did a poor job of defining how to turn the bus around. The result was that there were collision problems. Typical UARTs will tell you that the buffer register is empty (useless for this purpose) or that the transmit register is empty (the stop bit is still being timed) but they won't tell you when the stop bit has finished timing out. So most systems have to use timers and other means external to the UART to control the transmit/receive output to the driver chip. There are a few MCUs with UARTs that can directly control the RS-485 driver enable. Be sure to use one of these. The slave will also have to pad at least a bit time to make sure it does not turn on its driver before the master has disabled its driver. This is purely a software issue.
"mehulag" <mehul@hcl.in> wrote in message 
news:CNSdnRtzmY80Pp_YnZ2dnUVZ_rCdnZ2d@giganews.com...
> Hello, > > I need to implement a proprietary network of various devices connected > over the RS-485. No third party device needs to be interfaced, all the > devices will contain the firmware written by me. > > 1. Is there any specification which tells me how the devices can be > addressed over the network and messages can be accepted by them ? Also, > are there any error correction methods recommendable for this network.
There is no specification as such; how you use it is up to you. However a typical scenario would be as follows: - Each device on the bus has an address in the range 1-32 (typically set in hardware with e.g. DIP switches or a rotary switch - or in Flash so long as you have a means of setting the address before connecting to the bus). - Each transmission from the master includes the device address as part of the packet. Each device checks the address, and responds only to its own address. (You could also have a broadcast mode if you need it, so long as none of the devices are expected to reply.) - The architecture is master/slave; i.e. all comms are initiated by the master, and slaves respond only to messages addressed to them. - All messages include a checksum or CRC field to allow error-detection (not necessarily correction). You could either allow for a NAK-type response, or simply timeout (assuming the master will retry).
> 2. I have read that may be ModBus protocol could be used. Can I > communicate directly to the RS-232 send and receive routines from the > Modbus module or do I need more layers of software in between ?
Sorry, I don't know. Bear in mind that RS-485 differs from RS-232 in that you need to take care of releasing the bus (i.e. enabling/disabling the transmitters). The above scenario is effectively half-duplex, so you could use either the usual 3-wire RS-485 or the 5-wire variant a la RS-422 (but still using RS-485 transceivers - they're superior to RS-422 devices in all respects). (I have used Modbus over RS-485, but it was too long ago to remember the details...) HTH some, Steve http://www.fivetrees.com
In article <072dnaUtQIQmJp_YnZ2dnUVZ8smdnZ2d@pipex.net>, 
steve@NOSPAMTAfivetrees.com says...
> "mehulag" <mehul@hcl.in> wrote in message > news:CNSdnRtzmY80Pp_YnZ2dnUVZ_rCdnZ2d@giganews.com... > > Hello, > > > > I need to implement a proprietary network of various devices connected > > over the RS-485. No third party device needs to be interfaced, all the > > devices will contain the firmware written by me. > > > > 1. Is there any specification which tells me how the devices can be > > addressed over the network and messages can be accepted by them ? Also, > > are there any error correction methods recommendable for this network. > > There is no specification as such; how you use it is up to you. However a > typical scenario would be as follows: > > - Each device on the bus has an address in the range 1-32 (typically set in > hardware with e.g. DIP switches or a rotary switch - or in Flash so long as > you have a means of setting the address before connecting to the bus).
Please note that there are several "fractional load" transceivers on the market which allows over 100 devices to safely co-exist on an RS-485 network, so an addressing scheme should accomodate that... --Gene
mehulag wrote:
> Hello, > > I need to implement a proprietary network of various devices connected > over the RS-485. No third party device needs to be interfaced, all the > devices will contain the firmware written by me. > > 1. Is there any specification which tells me how the devices can be > addressed over the network and messages can be accepted by them ? Also, > are there any error correction methods recommendable for this network. > > 2. I have read that may be ModBus protocol could be used. Can I > communicate directly to the RS-232 send and receive routines from the > Modbus module or do I need more layers of software in between ?
Yes, ModBus is a workable solution. You will need to be able to sense when the last bit of a message has been sent so you can switch the transmitting device over to receive mode. In the past I have done RS-485 ModBus using a variant of the 16550 serial device which could generate an interrupt on "last bit sent". It all worked just fine.
"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:1157811417.323232.68980@b28g2000cwb.googlegroups.com...
> Yes, ModBus is a workable solution.
You must be joking. A protocol that relies on inter-frame times for delimiting the frames is a major PITA. It is much easier to either use escapes for frame delimiters or a 9th bit to flag an address- and end-of-frame byte. Most controllers offer a 9 bit scenario and often with automatic address recognition as well. Forget ModBus. Period. Meindert
Meindert Sprang wrote:
> "Mike Silva" <snarflemike@yahoo.com> wrote in message > news:1157811417.323232.68980@b28g2000cwb.googlegroups.com... > > Yes, ModBus is a workable solution. > > You must be joking.
No, my jokes are funnier.
>A protocol that relies on inter-frame times for > delimiting the frames is a major PITA.
This was quite simple to implement, using an available onboard timer. Not even close to "major PITA".
> It is much easier to either use escapes for frame delimiters or a 9th bit to > flag an address- and end-of-frame byte. Most controllers offer a 9 bit > scenario and often with automatic address recognition as well. > > Forget ModBus. Period.
The OP asked about ModBus. It's a workable solution. There are also other workable solutions.
"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:1157813165.393601.102470@p79g2000cwp.googlegroups.com...
> >A protocol that relies on inter-frame times for > > delimiting the frames is a major PITA. > > This was quite simple to implement, using an available onboard timer. > Not even close to "major PITA".
It costs you bandwith and it is almost impossible to implement on a UART with a fifo. And it costs a timer. Meindert
On Sat, 9 Sep 2006 16:25:05 +0200, "Meindert Sprang"
<ms@NOJUNKcustomORSPAMware.nl> wrote:

>"Mike Silva" <snarflemike@yahoo.com> wrote in message >news:1157811417.323232.68980@b28g2000cwb.googlegroups.com... >> Yes, ModBus is a workable solution. > >You must be joking. A protocol that relies on inter-frame times for >delimiting the frames is a major PITA.
It is not that bad. Point to point connections using RS-232/422 connections can be easily implemented by just monitoring the contents of the message. The traffic is half duplex after all. The multidrop master can also be implemented this way, however, when using the stupid 16550 UART series, you really have to poll the Tx shift register empty bit before turning off the RS-485 transmitter. Slaves in a multidrop network with inaccurate pause detecting will communicate reliably, as long as the master communicates with the same slave using multiple transactions. However, when the last response from slave 1 is transmitted and then the master starts to send the next command to slave 2, if slave 2 does not detect the pause between response from 1 and the next command to slave 2, it will not detect the command addressed to it. However, the master will timeout and send the command again. This kind of problems with some slaves can be avoided, if the master exaggerates the pause before sending the next command to a new slave. Some Motorola/Freescale processors contain the QUICC I/O processor, which has a nice Rx idle timeout interrupt feature and it is quite easy to get nearly perfect pause timing with it.
>It is much easier to either use escapes for frame delimiters or a 9th bit to >flag an address- and end-of-frame byte. Most controllers offer a 9 bit >scenario and often with automatic address recognition as well.
The 9 bit system is a mess, if you want to monitor the traffic on a typical PC hardware or communicate with such networks. On simple 5-8 bit UARTs, you would have to fiddle with the odd/even parity setting on a character by character basis, to select the parity bit in such a way that you get the wanted 0 or 1 into the parity bit i.e. address/data bit. On receive, you would have to detect the parity error on a character by character basis, thus making both the Tx and Rx FIFO useless. Since most UARTs have a common parity for Rx and Tx, full duplex operation would be unthinkable. Paul
Meindert Sprang wrote:
> "Mike Silva" <snarflemike@yahoo.com> wrote in message > news:1157813165.393601.102470@p79g2000cwp.googlegroups.com... > > >A protocol that relies on inter-frame times for > > > delimiting the frames is a major PITA. > > > > This was quite simple to implement, using an available onboard timer. > > Not even close to "major PITA". > > It costs you bandwith and it is almost impossible to implement on a UART > with a fifo. > And it costs a timer.
Well I have no strong feelings either way about ModBus. The product demanded it so I implemented it. Having said that, the bandwidth loss was maybe one or a few percent with our typical message sizes. The timer was free (not otherwise being used) on our micro. And the processing overhead to deal with the timeout processing on each received character was maybe a microsecond. Which is just to say (for the OP's edification) that none of these issues are deal-killers. Any serial protocol has to deal with (devote HW and/or SW to) the same issues such as what signals a new message, where is the end of the message, and is it a valid message?