Searching \ for 'RS485 protocol suggestions please' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rs485
Search entire site for: 'RS485 protocol suggestions please'.

Truncated match.
PICList Thread
'RS485 protocol suggestions please'
1998\09\01@190010 by Phil Tipping

flavicon
picon face
I have been reading this list for a few weeks now with great interest. I'm
in the final stages of designing a system for the school I work at that
requires a multi-drop RS485 network and while I understand the hardware side
of the standard, I could use some pointers on protocols.

I understand the basics of packet and Ethernet but all I want to implement
in this system is (hopefully) a simple master/slave arrangement with small
amounts of data (10 bytes every few seconds). There is no requirement for
slave/slave transmissions. I am using a 16C74 at 4Mhz as I need the I/O and
therefore have the UART available.

What is common practice for RS485, to use ASCII for data to distinguish it
from commands,  unique preambles that are unlikely (or disallowed) from
normal data, fixed length packets? Any tips on building a reliable protocol
would be much appreciated.

Thanks for any help,


Phil Tipping   G8RCP
IT Systems Manager
spam_OUTphilTakeThisOuTspamalperton-school.demon.co.uk

1998\09\01@220420 by thomas

flavicon
face
RS-485 is an electrical standard, not a software one.  i.e. RS-485
spec calls for lines under 4000 m, half-duplex, <10Mbaud, etc., but
does not specify even the number of bits per byte, collision
detection, etc.  Technically, it could be used to create a very
remote switch or pass TTL level signals between chips located
1000's of meters apart.

As for "common" practices and protocols, most are proprietary,
such as Allen Bradley's DH-485, (although a copy of their spec can
be found on their web site.)

I would suggest checking out the Modbus spec (it's an open
standard) at  http://www.modicon.com/techpubs
It's a standard that has been around for quite a while and is fairly
simple to implement.  Most if not all, MMI software and PLC's can
talk via Modbus, so you can plug into a whole industry.

As for interfacing, I would suggest a borrowing from an appnote on
the DS36277 at National Semiconductor's site.  (Try a search on
the part number)  Basically, it is a 75176 with an inverter on the DE
(transmit enable.)  The UART Tx line is connected to the DE pin.
The DS36277 transmit pin is tied to ground.  The purpose of this
scheme is to eliminate the need for an extra data direction pin and
allow collision detection.

It would be cheaper to use a standard 75176 with a NPN transistor
and 2 resistors to create an inverter.  Optionally, the output of the
inverter could also be tied to the /RE to suppress the receiver when
you are transmitting.

regards
Thomas J Macauley, KD7BDW
.....thomasKILLspamspam@spam@advancedcontrol.com
(208) 362-5858

1998\09\02@070047 by Mark Willis

flavicon
face
I've seen RS232/422/485 protocols as simple as:

Command:   Cncdddd{ddd}x

 i.e. a command starts off with a 'C' start of command byte, then
further ASCII characters:
 n = node the packet's addressed TO
 c = ascii command character (t=read thermistor, v=read volume, etc.)
 dddd{ddd} = variable length data, if any (Easiest if this is fixed
length for each command!)
 x = checksum hash

Response:  Rncdddd{ddd}y
    {or}  Nny

 Responses have 'R' to begin with, the node identifies itself & the
command being responded to, and return the requested data (if any), plus
a (different than the 'C' packet's) checksum.  Or an 'N' packet ("Nak")
with their node number, and a checksum.  (You can calculate this NAK
checksum ONCE, no need to re-calculate that, as you know the node number
at startup time, hopefully!)

 Checksumming's good as any noise can be detected;  If you get
non-ascii (usually I've limited it to just 'A'-'Z', '0'-'9', and '.') in
a packet, you know you have a noise problem and can NAK the packet;  The
slave tells the controller "I received command c and this is the
response for that" - you need to still handle timeouts, over-runs, etc.
but a simple protocol that meets your needs, is very robust, and has
multiple redundancies can save you a LOT of hair-pulling during
debugging time - as it's unlikely that a command can be mis-sent (due to
the checksumming etc.)

 Nothing wrong with developing your own, **Well-Documented**, standard
and using that;  Just make sure you have one master copy of the standard
if you can possibly arrange that <G>

 Mark Willis, mwillisspamKILLspamnwlink.com

Phil Tipping wrote:
{Quote hidden}

1998\09\02@070114 by Keith H

flavicon
face
As Tom says, RS485 is not a protocol, just as RS232 isn't.

What do you wish to do with your system?

Presumably you have a PC master talking to one PIC slave.
What is the nature of the data?
Monitoring a science experiment?

Modbus is a really half-assed protocol riddled with
fundamental flaws that people have to 'cheat' around.
It was probably cobbled together by people with no
appreciation of networking protocol problems.
For example there is no unique character or other way of
identifying a packet start, so if a slave wakes up
halfway through a message it cannot tell if a byte is
part of the packet frame or the payload. It can run in ASCII
or binary chars, opening up more opportunity for
incompatibility.

There have been many control buses invented for automating
processes like factories. They're called fieldbuses.
They all have pros and cons, with no clear leader.
Profibus is one of the better designed ones, and uses RS485.
The spec for this is several inches thick of A4 paper!
So beware, inventing good protocols is not trivial,
and seldom worth re-inventing. Check out:

http://www.profibus.com/
http://www.softplc.com/splchist.htm

1998\09\02@101740 by David Blain

flavicon
face
Take a look at: http://picpoint.com/picpointnet/

1998\09\02@120233 by myke predko

flavicon
face
Phil,

Check out Jan Axelson's "Serial Port Complete", it has answers to all your
questions.

myke

{Quote hidden}

Check out the "Handbook of Microcontrollers" as a reference for embedded
microcontrollers including information on the Intel 8051, Motorola 68HC05,
Microchip PICMicro, Atmel AVR and Parallax Basic Stamp:

http://www.myke.com/#MCUHand


Hunter S. Thompson's quest for the American Dream, this week in the Book Room.

http://www.myke.com/Book_Room/book1a.htm

1998\09\04@124428 by thomas

flavicon
face
> Modbus is a really half-assed protocol riddled with
> fundamental flaws that people have to 'cheat' around.
> It was probably cobbled together by people with no
> appreciation of networking protocol problems.

Your criticism is easy to make with 20 years of hindsight.  Modbus
was invented by Modicon when they were the leader in PLC's.  It
probably predates RS-485.  Profibus didn't come until 20 years
later and is more complex.  Modbus is a standard that both simple
and adequate.

> For example there is no unique character or other way of
> identifying a packet start, so if a slave wakes up
> halfway through a message it cannot tell if a byte is
> part of the packet frame or the payload.

Huh?  Isn't the Modbus packet start character ':' a unique
character? :-)  No protocol, including PPP or ethernet will allow a
slave device to wake up in the middle of a packet and properly
handle what it didn't receive.  i.e. special state-change characters
such as start of packet, end of packet, or next character is special


Thomas J Macauley, KD7BDW
thomasspamspam_OUTadvancedcontrol.com
(208) 362-5858

1998\09\07@053245 by Keith H

flavicon
face
> Your criticism is easy to make with 20 years of hindsight.

True. I never claimed otherwise.
This does not make my criticism invalid.

> Modbus is a standard that both simple and adequate.

Simple - True.
Adequate - False if you cannot tolerate its flaws.

I would not get in a plane that used Modbus for fly by wire.
I would not bet millions of dollars automating a factory with it.
If it were adequate, nobody would bother designing anything else.

> Profibus didn't come until 20 years later and is more complex.

True, that's because designing a robust protocol (that has mechanisms to avoid
uncomfortable worst-case and  what if' scenarios) is a complex problem.
A good spec goes into all the details so that everyone designing for it
does not have to provide them or worse not work them out at all.

> Isn't the Modbus packet start character ':' a unique character?

True - in ASCII mode
False - in Binary mode and your data payload can contain this byte

>  No protocol, will allow a slave device to wake up in the middle of a packet
> and properly handle what it didn't receive.

True - I never claimed it should.

A protocol should be able to assume the start character will never appear
in the middle of a packet. For example, X25 uses bit-stuffing to ensure this.

Arcom Control Systems Ltd wrote a booklet entitled
"Everything you need to know about Modbus but were afraid to ask"
describing all its foibles and how people usually worked round them.

Hope this helps!

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...