View previous topic :: View next topic |
Author |
Message |
aaronik19
Joined: 25 Apr 2011 Posts: 297
|
canbus vs rs485 |
Posted: Sat Aug 02, 2014 9:05 am |
|
|
Dear Friends,
I am going to start a new project and I need to decide which newtwork i am going to use. I have two choices: CanBus or RS485. For basic network, to send commands from slave to master which is less complicated? What I know is that CAN bus has more distance coverage than RS485. Can you please give me more clear picture of this?
In my project I just have 8 keypads and one power controller, so 8 slaves and one master. The user needs to select an option from keypad and the master perform the action.
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
Posted: Sat Aug 02, 2014 9:56 am |
|
|
Actually, depending on the speed, RS485 has the longest distance
coverage, is easier to troubleshoot, has the highest possible data rate
and is far easier to implement hardware wise.
CAN is much more complex from the hardware and programming standpoint.
CAN bus does have the advantage of implementing the signaling
standard and the bus protocol where RS485 is just a signaling
standard and you have to handle all the bus protocol.
A lot depends on distance, what you plan to send, how fast
and how many nodes. I have an RS485 network in my house that ties my
HVAC zones together and also communicates almost 1/4 mile to various
other home automation nodes in my house and yard (remote buildings etc).
For something that simple I would go RS485 half duplex and send simple
ASCII based commands. _________________ Google and Forum Search are some of your best tools!!!! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Sat Aug 02, 2014 11:00 am |
|
|
A comment here, has to be 're-iterated'.
RS485, is just a signalling standard.
CAN, is a protocol, _and_ a signalling standard (actually the original definition was just a protocol, but this was then expanded to include the signalling standard - the 'physical layer).
CAN is designed for shorter distances, vehicles originally.
CAN is very much more complex, but a large part of the complexity is automatically handled by the hardware.
If you need a lot of devices, and full 'network' communication, CAN handles this.
How complex RS485 becomes, depends on the protocol chosen. For single master/slave, this can be very simple indeed.
You can quite easily go to 1km with RS485, and speeds like 100kb/sec. However as you get to longer distances and to more hostile environments, the error checking in the protocol, and recovery mechanisms become more essential. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Sat Aug 02, 2014 1:08 pm |
|
|
If those are the ONLY 2 choices, then RS-485 is the winner.
Easier to implement
Cheaper to implement
There's probably a dozen more reasons why though neither would be my choice if given a 3rd option.
hth
jay |
|
![](templates/subSilver/images/spacer.gif) |
jgschmidt
Joined: 03 Dec 2008 Posts: 184 Location: Gresham, OR USA
|
|
Posted: Sat Aug 02, 2014 1:20 pm |
|
|
I like CAN because I don't have to invent any YAP (Yet Another Protocol). The hardest part (about CAN) for some users is getting comfortable with the Publish/Subscribe model as opposed to a Master/Slave approach.
For example, any CAN node can publish a "Turn On Porch Light" message. Only the porch lights subscribe to this message, turn on, and in turn publish a "Porch Lights On" message. Any node that subscribes to it will respond. One node, a switch panel, will turn on the appropriate LED. Another node, the logger, will record the time the lights were turned on. Works great within a building. (I haven't tried it between buildings yet.) The protocols for this are built into the hardware. Using CAN-enabled PICs, sample code from the CCS CAN development kit and the CAN driver chips, I was able to get a serious system working in a few evenings. The hardest part is deciding on message formats but you need to do that in any case. A major downside to CAN is the short message lengths. If you need to send lots of data that might not work for you.
Look at what you need to do and the number and complexity of the messages. Search on CAN and RS485 in this forum and you'll find more comparisons and suggestions. _________________ Jürgen
www.jgscraft.com |
|
![](templates/subSilver/images/spacer.gif) |
aaronik19
Joined: 25 Apr 2011 Posts: 297
|
|
Posted: Sun Aug 03, 2014 4:39 am |
|
|
thanks for all your reply. I choose Can bus or RS485 since in lighting automation it is the most common. Does someone has any idea what the MCP25050 do? I read all the datasheet but I am still confused. It is a microcontroller or just a peripheral like I2C controller? |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19368
|
|
Posted: Sun Aug 03, 2014 6:18 am |
|
|
It's a smart peripheral.
Understand that with CAN, the devices need small micro-controllers to handle the interface. This is a peripheral, with a CAN controller built on the die. You could actually build an almost identical device using a CAN PIC... |
|
![](templates/subSilver/images/spacer.gif) |
dyeatman
Joined: 06 Sep 2003 Posts: 1924 Location: Norman, OK
|
|
![](templates/subSilver/images/spacer.gif) |
jgschmidt
Joined: 03 Dec 2008 Posts: 184 Location: Gresham, OR USA
|
|
![](templates/subSilver/images/spacer.gif) |
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE: |
Posted: Sun Aug 10, 2014 9:30 pm |
|
|
For lighting automation and HVAC, DALI (digitally addressable lighting interface) could also be used.
thanks
a |
|
![](templates/subSilver/images/spacer.gif) |
|