View previous topic :: View next topic |
Author |
Message |
tEaM
Joined: 29 Nov 2013 Posts: 26
|
RS-485 architecture |
Posted: Sat Dec 07, 2013 5:17 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Sat Dec 07, 2013 6:45 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
tEaM
Joined: 29 Nov 2013 Posts: 26
|
|
Posted: Sat Dec 07, 2013 8:33 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Sat Dec 07, 2013 9:30 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19360
|
|
Posted: Sat Dec 07, 2013 9:30 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
tEaM
Joined: 29 Nov 2013 Posts: 26
|
|
Posted: Sat Dec 07, 2013 10:08 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Dec 07, 2013 10:23 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
jgschmidt
Joined: 03 Dec 2008 Posts: 184 Location: Gresham, OR USA
|
|
Posted: Sat Dec 07, 2013 10:30 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
John P
Joined: 17 Sep 2003 Posts: 331
|
|
Posted: Sat Dec 07, 2013 1:51 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
gpsmikey
Joined: 16 Nov 2010 Posts: 588 Location: Kirkland, WA
|
|
Posted: Sat Dec 07, 2013 3:24 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Dec 07, 2013 3:26 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Dec 07, 2013 3:34 pm |
|
|
gpsmikey wrote: | 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 |
It's surprisingly much more robust than I anticipated. Before accepting my current position I had actually developed a few different products based on CAN, but all in an electrically quiet environment and with relatively short cable runs (all linear). Our current product is actually more of a spider web layout with a lot of long stubs all connected to a central hub, with the 65' cable bundled with the welding leads being the most concerning and surprising aspect. Our system was designed by someone unfamiliar with CAN (they didn't read the spec), but in spite of all it does "wrong", it still works and works well.
That said, I've designed a new version of the product as a whole that does actually linearize the CAN network. As good as the old one is, the new version is definitely better/much more noise immune.
Edit: our welding waveforms aren't standard short-arc either. Computerized ball/spray metal transfer with really complex welding waveforms. Not just ordinary high Idc. Lots of noise. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9170 Location: Greensville,Ontario
|
|
Posted: Sat Dec 07, 2013 3:47 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Dec 07, 2013 4:02 pm |
|
|
Newguy, you did well. I liked your write-up. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Sat Dec 07, 2013 4:27 pm |
|
|
PCM programmer wrote: | Newguy, you did well. I liked your write-up. |
Wow, high praise! Thanks PCM - you're very generous with your time here and you're a wealth of knowledge. I know you've helped me quite a few times and I surely appreciate it. I'm glad that I can likewise contribute from time to time. |
|
![](templates/subSilver/images/spacer.gif) |
|