Searching \ for 'RS485 Bus Industrial Application' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'RS485 Bus Industrial Application'.

Truncated match.
PICList Thread
'RS485 Bus Industrial Application'
1998\01\24@205347 by Keith Howell

picon face
Somebody mentioned they were using PICs to communicate over RS485
in an industrial control situation, and requested comments.

I have a little experience of this sort of thing.
I'm not sure which level to pitch this post at, but as it may be read by
all sorts, here goes.

Just as a single ethernet cable has replaced many RS232 cables in an
office environment, so people have looked for similar networked control
solutions in industrial control systems. Unfortunately, several different
solutions have been designed and none has become a de-facto

Modbus is an early design. It runs at common baud rates so you can drive a
modbus network from a PC. You need an RS232<->RS485 interface so that
you can talk to more than one slave. Einstein said "make things as simple
as possible, but no more". Modbus is an example of something that is too
simple to work rigourously. It's one of these protocols that looks like it
and does most of the time, but when you design something you really need
to bombard it with miserable nit-picking pedantic pessimists full of nasty
awkward questions like "but what happens if a slave starts listening
through a message? How does it tell where it is in the message?" etc.
In practice you have to cheat and fudge.

Profibus. This uses an RS485 network running much faster than standard PC
baud rates. As you might expect of German engineering, it is a very well
disciplined specification. If new slaves join the bus, they have a time
in which they can join. The specification is several inches of A4 paper

CANbus is not RS485 based. Arbitration is done bit by bit, with a dominant
over-riding a recessive level. In this respect, it  borrows ideas from
where the dominant level is 0V. Because of this, it is deterministic.
i.e. conflicts guaranteed to be settled non-destructively, and within a
finite time.

Profibus is not arbitered at the bit level, but this does not mean it is
deterministic. If you think carefully, and design protocols well, it is
to produce a robust protocol.

There is another fieldbus which is not so much as a bus but a daisy-chain.
It works much like a giant shift register with a strobe signal.
The advantage is simplicity in some respects, but has disadvantages in that
slaves have a physical position in the chain which the controller has to be
aware of. If one slave screws up, it may break the chain.
It routes the bus through each slave unit, with one sex of DB9 connector
going in and the other going out.

>From what I could see of all the common fieldbuses, it really is bedlam.

Most fieldbuses use twisted pair cable for cheapness.
Now you have to solder it into D-types.
DB9 connectors are common and cheap, but a bugger in the field.

Okay, lets say you don't  use D-types, just phoenix screw terminals.
You have to remember whether the red wire is the 'A' signal and
black is the 'B', or not depending on the standard. Or if the chap
who did the cabling got it the right way round. And you the designer
have got to make damn sure you get the signals the right way round
when you do the circuit of the RS485 driver.

If you read the specs of your RS485 driver chip, note that the differential
inputs A and B are not allowed to go outside finite limits (typ. -5V or
of the chip's local ground. How are you going to stop that happening?
Yep, you need to tie the grounds of all your nodes in a 485 system together

to limit common mode problems.

Now you have to tell your tight-fisted techno-incompetent boss that the
system really needs more than a twisted pair of wires.
You're more likely to get a shielded twisted pair than a twisted trio.
Oooh-er, now you find your fieldbus standard quite reasonably thinks
Ground and Shield are not the same thing. And you ain't got a ground wire!

I know you're thinking "I'll soldering the two together - maybe a bit
but I'll get away with it". Not so fast! That looks like it's a
path for nasty voltages to push charge through a finger-heart-genitals-feet
path to ground. Try a 1M/100nF RC parallel circuit between the two.
Now all those nasty high-voltage DC static charges can leak away safely,
and it still looks like a short-circuit to those RF EMF interference

Where should you put this RC network?
I'd say inside your gadget, between the shield and the ground.
You can put this on the PCB if you like, using SMT parts.
The alternative is to put it in the D-type.
Fiddly to a chap like you who knows how worthwhile it is.
Fiddly enough that you can't rely on anybody else doing it.

Of course you've used a sheilded case for your gadget,
not much point in shielding the RS485 signal wires if the gadget
they connect to is not shielded. Even if it is not a metal case,
some kind of Faraday caging is desired.

On the subject of sheilding, you'll need shielded D-types.
Not so cheap are they now eh?
You may trust the user to connect the braided shield to the metal shell,
but what about anything else? Try this, see how fiddly it is, and imagine
doing it for up to 32 gadgets at every site. This is another good reason
putting the RC network between sheild and ground inside your gadget.

>How critical is the 32-nodes-per-bus limit?

Well how critical is your insurance?
If you sell it and say it works, and it doesn't, you may be liable.
If the component data sheet says it is designed to meet the RS485 spec
which describes up to 32 nodes, and you exceed this, YOU have
exceeded the component parameters which is YOUR fault.
The RS485 driver may guarantee operation <32 slaves.
Beyond that, you have to. Even if it works okay, you may have to prove it.
If a product kills someone and it was not your fault, are you negligent
because you did not do all the tests to satisfy reasonable doubt?

You may know of systems where 100+ devices hang off the single network,
apparently without problems. A guy I met said he knew loads of people
who did heroin and were not terminally addicted. I pointed out that this
not give heroin a 100% safety record. Those with a contrary experience
were not always around to present it!

>What kind of protection is advisable at the input of each slave?

Use as much as you can within reason. If you are automating a factory
producing BMWs,  alarm bells go after 5 mins. The MD is got out of bed
after 15 mins. The factory loses huge amounts of money every minute.
Do you want to explain to these people why you thought it was wise to
save a dollar on that input circuit? Repeat after me the 64th rule
of data acquisiton: "A covered arse gathers no dick".

> Is termination really necessary?

Termination depends on the speed and length of the network.
At 1200 baud, you can get away without it for a fairly long network.
At 1 Megabaud (as used by profibus), you need it sooner.

Finally, be aware of EMC rules and regs. These have the purpose of
- electromagnetic interference does not come out of your gadget.
- electromagnetic interference  does not get into your gadget and stop it
- unwanted competition from countries not meeting our EMC rules

A good tip that you'll spend ages discovering:
Keep your PCB tracks of the A and B signals similar.
If they are well matched, any incoming EMF sees the same impedance
and thus suffers matched distortion. Even if the EMF is big, it will be
when it reaches the A and B signals at the RS485 transceiver.
If the tracks are msi-matched by a few percent, then the A and B signals
at the RS485 transceiver will see a differential signal which is a few
of the big common-mode signal. This will be enough to swamp the
desired true differential signal.

Best of luck, KH

1998\01\25@001814 by Steve Baldwin

> >How critical is the 32-nodes-per-bus limit?
> Well how critical is your insurance?
> If you sell it and say it works, and it doesn't, you may be liable.
> If the component data sheet says it is designed to meet the RS485 spec
> which describes up to 32 nodes, and you exceed this, YOU have
> exceeded the component parameters which is YOUR fault.

If you are going to point fingers with capital letters, you should remember
that the spec defines Unit Loads. Not nodes. A typical CMOS trans/receiver
is 0.1 Unit Load. However, the cable, data speed termination and other bits
and pieces hanging off the bus also fall into the equation.
So you could have 128 nodes and meet the spec and/or you could have two and
exceed it.

As a designer, you're at the mercy of the end user anyway. They may buy a
1000m reel for a 100m run and not want to cut the cable (for future
expansion) and coil up the extra in the space under the MIG welder.


1998\01\25@104607 by John Griessen

National Semi's AN-1057 is good explanation of rs485.

It's on their web site, or reply to me and I'll send a pdf file.

>Somebody mentioned they were using PICs to communicate over RS485
>in an industrial control situation, and requested comments.

John Griessen  CIBOLO Metal Works
512 451-8207 FAX 451-0753

1998\01\26@062004 by Keith Howell

Steve Baldwin wrote:
> If you are going to point fingers with capital letters,

I did not mean to point (my Mum said it's rude,
and I could have someone's eye out).

I merely wished to emphasise responsibility.

If you take care to satisfy all the electrical constraints,
as you rightly mentioned re. unit loads etc, then you have
taken all proper steps to produce a robust product.
As befits a good engineer.

If the user is not such a good engineer and decides to
do something iffy, then it's their responsibility.

Just mentioned this because industrial malfunctions are
potentially fatal, litigatious, and expensive.

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