Implementing communication over RS-485

>
>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.
>
>

Thanks for your valuable suggestions.

Can you let me know of some other workable solutions which are easier to
implement. I just read about Modbus being used for RS485 and asked. I dont
know of it's advantages and disadvantages. Also if you know of any
controllers which offer RS485 support, please let me know.

Thanks and regards,
Mehul

On 2006-09-09, Meindert Sprang <ms@NOJUNKcustomORSPAMware.nl> wrote:

>> 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.

Or use async-hdlc framing like PPP does.  That's simple.

> Forget ModBus. Period.

Agreed.  Unless you want to do ASCII mode.

-- 
Grant Edwards                   grante             Yow!  over in west
                                  at               Philadelphia a puppy is
                               visi.com            vomiting...

On 2006-09-09, Mike Silva <snarflemike@yahoo.com> wrote:
>
> 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.

It burns a lot of CPU at high baud rates since you've got to
run an interrupt-per-byte.  If you've got to do multiple
interfaces at high baud rates, it starts to seriously suck.

> 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?

Most of them are a lot lower overhead than Modbus.  If you've
few interfaces, plenty of CPU time and timers to burn, then
Modbus isn't too bad.

-- 
Grant Edwards                   grante             Yow!  MERYL STREEP is my
                                  at               obstetrician!
                               visi.com            

"mehulag" <mehul@hcl.in> wrote in message 
news:oqudnVQsvqtXbZ_YnZ2dnUVZ_s6dnZ2d@giganews.com...
>
> Thanks for your valuable suggestions.
>
> Can you let me know of some other workable solutions which are easier to
> implement. I just read about Modbus being used for RS485 and asked. I dont
> know of it's advantages and disadvantages.

Don't let the details here put you off. A roll-your-own RS-485 system isn't 
hard - yes, there are a few pitfalls for the unwary, but nothing really 
hard. I've dealt with this stuff a lot, as have others here. If you have 
specific questions, ask away.

> Also if you know of any
> controllers which offer RS485 support, please let me know.

RS-485 is a hardware standard, so it's nothing really to do with the 
controller as such. Beyond what you'd need for RS-232, you'd need a line to 
turn the bus around (which you might have needed for h/w handshaking 
anyway), and you'll almost certainly need a timer. Otherwise, it's just 
plain-vanilla async serial NRZ comms.

Steve
http://www.fivetrees.com 

Grant Edwards wrote:
>
> It [ModBus] burns a lot of CPU at high baud rates since you've got to
> run an interrupt-per-byte.  If you've got to do multiple
> interfaces at high baud rates, it starts to seriously suck.

Well, you have to compare the interrupt-per-byte loading with the
message-processing loading.  If you've got high-speed messages coming
and going on multiple interfaces, you've got to devote more CPU time to
processing these messages anyway.  The interrupt-per-byte cost is going
to remain nearly the same relative to the message-processing cost
regardless of how high or low your baud rate, or how many ports you're
running.  So the key question is, how much processing time does the
average message require?  Once you attach a number to that, you can get
an idea how much more your interrupt-per-byte will cost you.

Grant Edwards wrote:

> Or use async-hdlc framing like PPP does.  That's simple.

Yep. PPP HDLC solves frame delimiting, error detection,
and transparency issues.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

> 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.
>

One possibility is to use a time slot bus.
The time slot bus consists of

* a clock
* a frame sync
* data

Each device is allocated a time slot where it will drive the bus.
A master will drive the clock and the time sync signal and the devices will 
then
drive the data output during its allocated time slot.

A typical example are the E1 bus used in European Telecom equipment - also 
called 30B + D running at 2,048 MHz.
The data is divided into frames of 256 bits (and you get 8000 frames per 
second)
Each 256 bit frame is divided into 32 timeslots of 8 bits.
1 timeslot (T0) is used for sync, 1 timeslot for internal communication 
(T16) using the HDLC protocol
and on top of the HDLC, a higher level protocol called SS7.
The remaining 30 timeslots are for telephone calls using PCM coded Audio..

.
The number of nodes and communication speed will determine if this is a 
useable approach.
The SSC of the AT91SAM7 family and certain Telecom oriented PowerPC woudl be 
useable for this.

If you just want RS-485 over UART, then maybe the AT91 UART still can be 
interesting
due to its H/W support for the RS-485 enable signal.
It supports manchester encoding as well.


> 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
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Ulf Samuelsson wrote:
> > 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.
> >
>
> One possibility is to use a time slot bus.
> The time slot bus consists of
>
> * a clock
> * a frame sync
> * data
>
> Each device is allocated a time slot where it will drive the bus.
> A master will drive the clock and the time sync signal and the devices will
> then
> drive the data output during its allocated time slot.

Doesn't this type of shared bus have at least a separate data and clock
and often a separate frame sync signal?


> A typical example are the E1 bus used in European Telecom equipment - also
> called 30B + D running at 2,048 MHz.
> The data is divided into frames of 256 bits (and you get 8000 frames per
> second)
> Each 256 bit frame is divided into 32 timeslots of 8 bits.
> 1 timeslot (T0) is used for sync, 1 timeslot for internal communication
> (T16) using the HDLC protocol
> and on top of the HDLC, a higher level protocol called SS7.
> The remaining 30 timeslots are for telephone calls using PCM coded Audio..

Yes, but E1 is not a multipoint bus.  The signal is unidirectional with
multiple sources being multiplexed through a device, sharing a single
bus to the destination where the bus is broken out into multiple
signals again.  This is way beyond the type of RS-485 application I
think the OP is asking about.


> The number of nodes and communication speed will determine if this is a
> useable approach.
> The SSC of the AT91SAM7 family and certain Telecom oriented PowerPC woudl be
> useable for this.

How would you make this work with even just three nodes, each having a
single serial port connected to a shared RS-485 bus?

On the other hand, while E1 would be very impractical to implement, a
round robin approach could be used if you did not want to have a single
bus master.  Each node would have a unique address.  The address is
used at the start of a header for a message to be sent.  Each node
sends a message when it is their turn, even if it is a NULL message.
If a node does not respond to its timeslot, the next node times out and
sends a message.  The node at time slot 0 would be able to recognize
the size of the network and respond with its message when the last node
in the system had transmitted.  An enumeration scheme could be
implemented at this boundary time to allow a new node to join the
network and have a node number assigned dynamically.  Even the
assignment of a node number assignment "master" could be done when the
system is turned on.  Each node would wait a random amount of time
(beyond some minimum) and the first one to query the network would be
node 0.  The next one would be node 1, etc.

I am sure there would need to be a bit more detail ironed out, but I
think this would allow for nodes to be added and removed dynamically
and automatically.

"rickman" <gnuarm@gmail.com> wrote in message 
news:1157836725.357645.139340@d34g2000cwd.googlegroups.com...
<snippety>
> I am sure there would need to be a bit more detail ironed out, but I
> think this would allow for nodes to be added and removed dynamically
> and automatically.

This is often a pain in "straight" RS-485 networks. Usually, the master has 
to be told the bus population, or have a start-up poll phase. Simply waiting 
for a node timeout on every possible address quickly stacks up to 
$stupid_time.

However, I think there are simpler ways...

Steve
http://www.fivetrees.com 

On Sun, 10 Sep 2006 00:09:58 +0100, "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote:

>"rickman" <gnuarm@gmail.com> wrote in message 
>news:1157836725.357645.139340@d34g2000cwd.googlegroups.com...
><snippety>
>> I am sure there would need to be a bit more detail ironed out, but I
>> think this would allow for nodes to be added and removed dynamically
>> and automatically.
>
>This is often a pain in "straight" RS-485 networks. Usually, the master has 
>to be told the bus population, or have a start-up poll phase. Simply waiting 
>for a node timeout on every possible address quickly stacks up to 
>$stupid_time.

This may seem to be a problem from the application layer point of
view, however, the application layer that will process the data must
know what type of devices there are on the bus. This usually requires
some configuration in the application layer, so the node numbers can
also be decided in advance. Thus, you can simply set the address for
each node (e.g. with DIP switches), before connecting the node to the
line.

Polling all possible addresses would be useful only if all the
possible devices respond with a type code or serial number which is
available from a well known address in each slave. For PLCs and other
programmable devices, you would also have to obtain the information of
what software each devices are running and if multiple nodes with the
same software, into which real word sensor cabling each device is
connected. From this, the application layer can then build a map,
which node number is connected to which external sensor cable. To be
practical, this would require reserving some PLC input pins just for
identification by wiring some jumpers differently in each sensor
cabling.

While most fieldbus systems have a well specified way to identify the
device type (usually device profile) by inquiring it on-line, for
instance in Modbus RTU, devices have no standard way to identify the
device type, so a lot of heuristics is usually needed to find out
which device is which, even from a limited selection of types.

Thus, whatever you do, you have to configure the node information in
one way or other. Thus, specifying the node numbers in the application
and setting the device physical address accordingly is still a viable
option and no polling for nev nodes is required.

Paul