RS-485 architecture

[tEaM]

Hi,

I need to create a network of communication between 10/15 devices. The distance between the devices is 20/30 meters...
What is the recommended architecture? RS-485?
Or should I choose other architecture more recent?

Best Regards
tEaM

[temtronic]

RS-485 is a well proven, reliable method.Components are cheap, software is compact.You'll be able to get very good support on this forum with it. CCS supplies examples in the examples folder !

Any of the 'newer' methods like Bluetooth, XBEE,etc. are more money for hardware and software is bigger both in code size and 'overhead'.

I'd start with 2 devices,cut code,test,then add another,cut code,test,then and another,cut code,test,then etc... It's best to start out small,get familiar with the code and hardware and build from KNOWN! Don't try to hookup 15 devices and expect it to work.....

hth
jay

[tEaM]

Thanks for your opinion ...
I already have some experience in RS-485. But I'd like to switch to a more recent technology. I am thinking of testing CAN ...
It will be a good bet?

Regards

[temtronic]

Why ? Costs more,need bigger PICs,code hungry,time waster.
You've already got some RS485 experience under your belt,just carry on with it...go with what you know, and grow.
Sure you can go with CAN(check specs for distance/speed),or probably a dozen more choices.There are benefits to hardwired vs. wireless that you should consider.The 'learning curve' for any system can be a killer on your time!
I'd grab a piece of paper make a grid of technologies versus requirements of what you NEED to do or have.Fill in the blanks and see what looks best. Odds are using RS485 will be #1 choice.

I'm all for learning some new stuff ,if it's a mind challenge,and not a commercial product.I've got some XBEE modules here but for short( less than 14 miles) distances, solid copper wire has been ultra reliable for 20+ years.

hth
jay

[Ttelmah]

You are confusing a signalling standard, with a protocol.
A CAN transceiver, is half an RS485 transceiver, with the built in biasing to take the line to a dominant '0' state. The key point is that CAN is a complete protocol, where RS485, is only a signalling standard. If you are looking at going into something like an industrial location, then you should look at things like Modbus over RS485. CAN tends to be reserved for where devices talk amongst themselves, but not in general to the outside world. So 'entities' like cars, boats, and aircraft.

Best Wishes

[tEaM]

temtronic, What are the XBEE modules do you use? Wireless is also a good choice...

Ttelmah, I agree with you. CAN is not indicated for industrial environments.

I am undecided if I will use RS485 or wireless ...

Regards

[newguy]

Go with CAN. Regarding "industrial environments", we use 250kbps CAN networks in industrial welding shacks with no issues AND we have a 65' (approx. 20m) CAN cable bundled with 4 welding leads and 4 welding grounds, with each carrying anywhere from 130A to 275A depending on the pass.

In my opinion, CAN is the ideal standard. Data transmission, reception, retries, arbitration, errors, CRC, etc. are all handled for you in hardware. All you have to do is drop your message in the "mailbox", and some super reliable and diligent "thing" picks up the message and delivers it to your intended recipient with no effort on your behalf.

If you decide to roll your own protocol, then you will quickly find that it's all in your hands (CRC, errors, arbitration, retries, transmission, reception, etc.).

CAN is far more reliable and noise immune than you think.

[jgschmidt]

I also started out with RS485 and had to deal with developing my own software protocols to handle bus availability, collisions, etc. Most of my projects are one-offs so I do what I can to reduce development time. With CAN the basic protocols are built in. One of the CAN development kits from CCS is a great place to start. Microchip has a set of CAN bus monitoring boards which I found useful as well: MCP2515DM-BM
Downside of CAN vs RS485 is shorter distance. CAN is great for vehicles or small buildings. Both have a linear topology which can be challenging when you're laying out your cables. You'll need to consider that when you evaluate alternatives. I've used a star repeater for RS485 and it worked fine at low speeds.

I have a list of CAN resources at the bottom of this page:

http://jgscraft.com/microchip.php
_________________
Jürgen
www.jgscraft.com

[John P]

One thing you have to consider is what the direction of data flow is. Do the units typically send data to each other arbitrarily, or is there a "master", which may be a computer or connected to one? If you can be sure that units on the network only have to be addressed by the master, and only transmit to the master, then it's a much easier project. Yes, it might be a little more inspiring to think about complex timing and addressing, but good engineering means you don't build more than the job requires.

[gpsmikey]

Obviously I need to look into CAN stuff - anything that can survive being bundled with welding cables with that kind of current and strange arc induced spikes has to be pretty robust!!

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3

[newguy]

Good engineering also can be interpreted as never having to touch a project again. In other words, do it right the first time, ensure expandability/new functionality can easily be implemented by the customer/end user without board revs or new firmware, all while spending the bare minimum of time actually creating the project.

3 years ago I was asked to create a cable tester capable of handling all the cables in a certain product. Instead of hard coding the expected connections of all the different cables, as I was asked to do, I spent a couple more days making the system scalable. Cable connections are specified in txt files stored on a SD card. New cable? Create a new cable test txt file. Still on rev 1.0 of that FW and we're now using it to test a whole host of cables from other products and new cables added to the old (original) product. If I hadn't done it this way, we'd be on at least the 20th FW rev, and I would have spent a lot of time supporting it.

CAN is supposed to be a linear topology but short stubs are okay (the Bosch spec dictates acceptable stub lengths), so you can have what is essentially a bottle brush layout (main spine with lots of perpendicular ribs) with no issues. The nicest thing about CAN is that there is no such thing as a master or a slave. It's essentially a telephone "party line" with polite speakers/users. Depending on how you interface to the project, having a bunch of peers may or may not be advantageous.

[newguy]

[temtronic]

One key 'teck spec' to consider with any 'network' is what happens when the wire breaks? While I don't use CAN, I know the typical RS-485 system is down when one of the 2 signalling wires breaks, so I assume CAN is no different in that respect. RF systems might have the 'edge' for reliability though the single wire system I used 20+ years ago is still up and running.You can disconnect any slave and the master still sees all the others on either side of the line break.
RF does entail more software overhead,thus speed/throughput may be reduced depending on amount of data to be transferred.

food for thought
jay

[PCM programmer]

Newguy, you did well. I liked your write-up.

[newguy]