What kind of signal do you want to send on the line ?
Frequency range, distance, error rate ?

If just inside, I would use fiber optics...

<nbucska@pcperipherals.com>

Just normal serial data up to 38.4 kpbs

Thanks

Sorry, max length of say 100 feet

I agree with nbucska and would personally recommend fibre-optic cabling as the most robust interconnection system in this sort of noise environment.

If you want to use conventional cabling, apart from the obvious point of using fully shielded cabling, you would be advised to mount the various circuitry which will generate/use the data in totally screened boxes or compartments. The connectors should be of the type that have in-built filters in the pins so that minimal r.f gets into any of the screened boxes. Ideally you should use opto-isolators as well, to prevent ground loops between screened sections.

cont ...
about the shielded box: The shield/connector GND must not be connected inside the box but to the outside for even
a 1/2 inch wire inside can act as a coupling loop and bring
the HF into the box...

You may want to add filter. So it can be done but I think
you will spend many times on labor what you save on the fiber parts.

<nbucska@pcperipherals.com>

OK, thanks guys.  I hadn't considered fibers.

If you go with regular cabling, there is not too much difference between CAN and RS485 regarding noise immunity, it is more a matter of convenience.
Both use twisted pair and differential drivers (CAN over fiber is possible, btw.)

CAN has the protocol handling already built into the CAN engine of your micro. With RS485 you would need to define your own protocol and error handling in software, therefore CAN is a lot more convenient. It uses a 16bit CRC over the max. 8 byte long message. Of course, if you implement your own protocol in RS485 you can have 128byte messages with 32bit CRC or whatever you desire, it is just more work.

Just try CAN with completely optoisolated nodes and shielded twisted pair and proper grounding structure.

Use a CANalazyer (e.g.Kvaser) to check for errorneous messages, otherwise you won't know how good the connection is. CAN is a very robust protocol, and the CAN engine tries a number of times to get the message through. The first indication of a problem is an inexplicable connection slowness.

Thanks VolkerR.  Actually what we are looking at doing is a bit of a fiddle.   We are going to use our own protocol either way.  We are trying to decide which to use based purely on the merits of the electrical interface of each.  So I guess that is actually the question I am asking.  

In that case, it doesn't really matter.
The main differences between a CAN and a RS485 transceiver:

The CAN transceiver works like a RS485 transceiver, just with a dominant '0' and a recessive '1' state. The RS485 transceiver has both states dominant, therefore only one transceiver at a time is allowed to transmit, which results in the typical RS485 master/slave bus configuration. CAN is a multi-master protocol.

(Dominant means that a transceiver is forcing the line to a certain state; any attempt of changing the state before the transceiver releases the line means short circuiting it, which is obviously not good.)

Theoretically, you can use CAN transceivers for RS485 networks (just don't mix RS485 and CAN transceivers on the same line). Likewise, you can create your own recessive/dominant bits with a RS485 transceiver, by tieing the TX line to the desired state and using the TX_enable line for signal transmission, e.g what the National DS36277 does for J1708 communication.

If you use RS485, be aware that you will have to implement all the low level protocol stuff in software, e.g.
- creating data packets from raw data,
- implementing a CRC (not a checksum) with a tested polynomal
- re-requesting errorneous data
- error handling

RS485 will also limit you to a master/slave protocol, i.e. one computer in your network will be the master that polls all the other nodes.

How many nodes will your system have?

If it is just a point to point connection between two computers, then you are actually looking for RS422, not RS485.