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

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
works,
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
halfway
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
slot 
in which they can join. The specification is several inches of A4 paper
thick!

CANbus is not RS485 based. Arbitration is done bit by bit, with a dominant
level 
over-riding a recessive level. In this respect, it  borrows ideas from
I2Cbus,
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
intrinsically 
deterministic. If you think carefully, and design protocols well, it is
possible
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
+12V)
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
naughty
but I'll get away with it". Not so fast! That looks like it's a
low-impedance 
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
signals.

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
for 
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
did 
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
ensuring:
- electromagnetic interference does not come out of your gadget.
- electromagnetic interference  does not get into your gadget and stop it
working.
- 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
equal 
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
percent
of the big common-mode signal. This will be enough to swamp the 
desired true differential signal.

Best of luck, KH