I think CAN is as well not a very high level protocol. On top
of it people can use different application layer (?) like
CANOpen or other proprietary protocols.

For example, Pepperl+Fuchs is using CAN as the based protocol
for the RPI (remote process interface) modules with proprietary
application layer. The RPI gateway will translate the CAN signal
inside the "RPI module network" (5-pin DIN rail connected
bus, +24V, GND, CAN+, CAN- and Collected Error) to outside world 
like MODBUS/Profibus/Foundation Field Buss/...

The advantage is savings in cabling, which can be a good part
of investment in big industrial projects. With RPI/IS-RPI, 
instead of point to point connection of the field sensors
or transmitters to the PLC, we can have bus to point (PLC I/O
modules). From there, P+F have developed bus to bus product 
as well (FieldConnex). I do not know the exact details though
since I am not longer working in that division (Process Automation).

Regards,
Xiaofan

----------------------------------------------
Xiaofan Chen
R&D Engineer, Photoelectric Sensor Development
Pepperl+Fuchs Singapore
http://www.pepperl-fuchs.com
Signals for the world of automation
--------------------------------------------

-----Original Message-----
From: olin_piclist@embedinc.com [mailto:olin_piclist@embedinc.com]
Sent: Tuesday, August 23, 2005 10:09 PM

RS-485 is the old way to do this.  CAN is usually better for new designs.
It is differential with good noise immunity like RS-485, but the lowest
level protocol is not only specified but implemented in hardware.

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist