搜索
bottom↓
回复: 36

[PLC]开个简单讨论会—— CAN vs 485

[复制链接]

出0入0汤圆

发表于 2008-5-21 08:06:30 | 显示全部楼层 |阅读模式
我们都知道CAN性能应该是优于485的,实际比较的结果是什么样呢?

我先放点找到的资料,大家一起讨论讨论
CAN
CAN Versions
NOMENCLATURE STANDARD         MAX. SIGNALING RATE IDENTIFIER
Low–Speed CAN ISO 11519         125 kbps          11-bit
CAN 2.0A ISO 11898:1993          1 Mbps            11-bit
CAN 2.0B ISO 11898:1995          1 Mbps            29-bit
Maximum Signaling Rates for Various Cable Lengths
BUS LENGTH(m)   SIGNALING RATE(kbps)
30                   1000
100                   500
250                   250
500                   125
1000                  62.5
The ISO 11898 standard specifications are given for a maximum bus length of 40 m and
maximum stub length of 0.3 m with a maximum of 30 nodes. However, with careful design,
longer cables, longer stub lengths, and many more nodes can be added to a bus—always with a
trade-off in signaling rate. A transceiver with high input impedance such as the HVD230 is
needed to increase the number of nodes on a bus.

485
Standard and Features
RS-485 is an electrical-only standard. In contrast to complete interface standards, which define the
functional, mechanical, and electrical specifications, RS-485 only defines the electrical characteristics of
drivers and receivers that could be used to implement a balanced multipoint transmission line.
This standard, however, is intended to be referenced by higher level standards, such as DL/T645, for
example, which defines the communication protocol for electronic energy-meters in China, specifying
RS-485 as the physical layer standard.
Key features of RS-485 are:
· Balanced interface
· Multipoint operation from a single 5-V supply
· –7-V to +12-V bus common-mode range
· Up to 32 unit loads
· 10-Mbps maximum data rate (at 40 feet)
· 4000-foot maximum cable length (at 100 kbps)

(原文件名:422485.JPG)


再放两个CAN和485芯片的资料对比

(原文件名:230.JPG)


(原文件名:485.JPG)

(以上资料均来自 TI 德州仪器,www.ti.com.cn)
-----------------------------------------------------------------
个人的一些评论,
CAN和485采用基本相同的传输方式,一样的差分传输,相近的差分信号电平。所以在传输速率、传输长度上应该也不会有本质上的大变化。
也就是说,对于数据通讯本身,485和CAN是差不多的。
CAN增加了识别码、以及硬件的保护,这个对于CAN网络的易用性有明显的提高。485需要软件协议参与,才能做到识别码、多主多从。
这方面而言,CAN确实有优势。

总体评价,在数据传输本身,CAN相比485基本差不多,在数据传输之外,CAN增加了不少辅助的东西。

出0入0汤圆

发表于 2008-5-21 08:56:51 | 显示全部楼层
CAN 吧。

STM32F本身就集成了CAN 接口,我们需要的只是增加一个CAN收发芯片。
而且整个通讯过程更加容易操作和控制

出0入0汤圆

发表于 2008-5-21 09:15:56 | 显示全部楼层
1楼正解,CAN可以多个设备同一时刻发送不同电平,而485是不行的。
另外CAN依靠控制器可以对时隙进行同步,保证所有发送的同步,而485没有这个功能。

出0入137汤圆

发表于 2008-5-21 09:27:44 | 显示全部楼层
还是用can吧,485没什么意思
上传一个can的入门资料

点击此处下载 ourdev_288863.pdf(文件大小:1.87M) (原文件名:CAN总线入门.pdf)

出0入8汤圆

发表于 2008-5-21 10:57:11 | 显示全部楼层
用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动。

出0入0汤圆

发表于 2008-5-21 10:59:34 | 显示全部楼层
用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动。

回音,回音而已……:D

出0入0汤圆

发表于 2008-5-21 11:33:49 | 显示全部楼层
占个位,向大家学习!!!

出0入0汤圆

发表于 2008-5-21 11:54:08 | 显示全部楼层
最好加上CAN.学习一下 。

出0入0汤圆

发表于 2008-5-21 12:01:37 | 显示全部楼层
can有几点说明下:
1.波特率与传输速度:虽然can的最大速率为1Mbps,但由于有效数据占实际通信比例是比较低的,
  根据帧的类型而定,像扩展帧的ID和8个字节数据总共占实际通信的70%左右。
2.仲裁方式:非破坏性总线仲裁虽然不错,但是一些can驱动单元的实现对于重发是有限制的,如果数据量大而多次重发超上限就失败了,
  而有些芯片对这类失败没有标志位,会丢帧。
3.多个节点接收:一个帧如果由多个节点接收,那么根据can2.0协议,只要一个节点物理上应答了,那么发送方控制器就认为发送成功了。
  所以,对发给多个节点的帧,如果要确保受到,必须在应用层查询实现。

can的通信效率取决于应用层实现。

出0入8汤圆

发表于 2008-5-21 12:27:31 | 显示全部楼层
回楼上的:
1、需要用PLC上的CAN Bus来传语音或视频数据吗?

2、重发次数限制是为了不要过长时间占有总线,浪费通讯效率!对于进入被动模式的CAN Model应该是在应用层上软件来做修正,任何一个CAN Bus都会有发送错误计数器的,当达到128次,进入被动模式是都是可以通过计数器查到的。不可能存在丢帧,只能说应用层软件没有考虑发送错误计数器的使用规则。

硬件提供的仅是可靠的通讯通道,而不是可靠的通讯规约!

3、这一点是应用层的问题。

出0入0汤圆

发表于 2008-5-21 12:45:34 | 显示全部楼层
【10楼】 Grant
我提出这几个问题就是让入门者在应用时要注意can的应用范围和芯片的can控制器特性。
因为我工作中曾看到有人只看到波特率而不顾can的实际通信能力而提出要求的。
发送错误计数,一般can控制器里是有的。can的驱动及应用层协议编写要求还是比较高的。
至于can的可靠性高是没什么疑问的。

出0入8汤圆

发表于 2008-5-21 12:56:37 | 显示全部楼层
Re 11
我补充是因为看了你的回复觉得有些话有点片面,对入门者在应用时产生不必要的误导。你说不是吗?我不是针对你个人,别介意。

1、CAN不身的用途就是用来在恶劣环境传输信号而不是数据的,不是吗?要更快的速度应该是Freescale提出的那个Flexy什么总线来着。

2、既然你也确认一般CAN 控制器都有发送错误计数器,何来丢帧?如果在应用层意识到这个计数器的作用。CAN丢帧是协议手册规定的,但要丢弃帧之前是要发送错误计数器达先后达到两个条件,一是过127;二是255。

3、这一点我也认同。

给张图看看:

(原文件名:1.jpg)

出0入0汤圆

发表于 2008-5-21 13:30:45 | 显示全部楼层
关于can通信效率方面,我觉得并没什么误导,因为实际通信中还伴随各种延时的存在(can物理层本身的、mcu处理速度等)。
而应用层协议部分,信号终究还是以ID+数据方式传输的,如果算上各种管理用的帧(心跳等之类),真正用于信号通信部分的数据在固定时间内的比例是7成左右。
项目对于通信量一般要有个预估,根据实时性的指标来确定,我给出的值是估算用的。

出0入0汤圆

发表于 2008-5-21 13:40:46 | 显示全部楼层
不用比较,毫无疑问,CAN比485强很多,而且CAN也是一种趋势,尽早CAN会替代485!

出0入0汤圆

 楼主| 发表于 2008-5-21 14:07:54 | 显示全部楼层
485迟早会被取代,但是取代者是不是CAN,目前也还不得而知。

CAN出来也不少年了,对于485的冲击一直不是很大。

所以我才发起这个讨论

出0入0汤圆

发表于 2008-5-21 14:10:44 | 显示全部楼层
大家都说CAN好
我也觉得CAN好

不过
CAN贵。。。

出0入0汤圆

发表于 2008-5-21 14:13:36 | 显示全部楼层
【17楼】 jjldc 九九
        大家都说CAN好
我也觉得CAN好

不过
CAN贵。。。

======================

对于内置CAN控制器的设备来说,CAN不比485贵……

出0入0汤圆

发表于 2008-5-21 14:56:04 | 显示全部楼层
好像大家都比较倾向于用CAN。
但是实际上的工业现场CAN对485根本构不成威胁。
虽然好处多多。

出0入0汤圆

发表于 2008-5-21 16:05:45 | 显示全部楼层
【18楼】 watercat
对于内置CAN控制器的设备来说,CAN不比485贵……


问题是如果需要和其他设备互联的时候,特别是PLC作为通讯控制器 与底层的传感器执行器互联的时候,每个节点的成本都是要考虑的啊
不单单是硬件成本(底层设备一般都是简单的MCU) 还有通讯协议等设计的成本

出0入0汤圆

发表于 2008-5-21 21:52:34 | 显示全部楼层
个人感觉,就收发器来说,485和CAN的价格差不多。他们的价格差异主要是在控制器上。
CAN控制器足够满足简单的命令数据传送,485只是硬件层的协议,MCU需要额外的时间处理传输层(如果通信量大,MCU需要大量的时间处理通信),而CAN控制器内置的过滤功能可有效减少MCU开销。
对于通信效率来说,CAN并不比485效率低多少。如果采用485主机轮询或令牌方式传输,总线上将出现大量的轮询请求或令牌,也无法有效支持优先级。对应的,CAN控制器从协议上就支持多主多从设备和按位仲裁(优先级),因此总线上都是需要传输的数据,这样的话,相对的传输效率并不低于485总线。

出0入10汤圆

发表于 2008-5-21 21:54:58 | 显示全部楼层
支持使用CAN。。。

出0入0汤圆

发表于 2008-5-21 22:05:35 | 显示全部楼层
哈哈,画PCB画晕了,溜进来,看看~~
说下我的感受……
前段时间,实验室里有项目转为CAN控制,花了比较大的精力去实现了软件的控制,看上去软件控制很舒服,通讯协议也很好,爽。拿到工业现场,还是485的节点居多……,最后不得已在设计上重新加上了485……
而后我又发现,使用CAN和485的比例在1比5……后来就在大批量的生产中去掉了CAN
因为,
1、两种接口有成本
2、很多场合只能用485……

所以,这只是我的实际经验,比较有局限性,仅当参考了

我的建议是,还是保留485为好,就算是不焊也行……留出位置就好了

出0入0汤圆

发表于 2008-5-21 22:24:21 | 显示全部楼层
RS485的成本优势很大,基本上但CAN控制器的MCU价格都不低,外接CAN控制器更贵。
从编程上来讲,和usart的编程更容易些,CAN就不一样了,讲究挺多。

出0入0汤圆

发表于 2008-5-21 22:49:59 | 显示全部楼层
留住485吧,这么个项目一下子就到了CAN 的程度也太快点了。当然,做为技术研讨的现在,为什么不呢!

出0入0汤圆

发表于 2008-5-21 22:54:46 | 显示全部楼层
【23楼】 kingofkings 技术火腿(KoK)
        哈哈,画PCB画晕了,溜进来,看看~~
说下我的感受……
前段时间,实验室里有项目转为CAN控制,花了比较大的精力去实现了软件的控制,看上去软件控制很舒服,通讯协议也很好,爽。拿到工业现场,还是485的节点居多……,最后不得已在设计上重新加上了485……
而后我又发现,使用CAN和485的比例在1比5……后来就在大批量的生产中去掉了CAN
因为,
1、两种接口有成本
2、很多场合只能用485……

所以,这只是我的实际经验,比较有局限性,仅当参考了

我的建议是,还是保留485为好,就算是不焊也行……留出位置就好了

=========================

用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动

另外,开源项目两样都有貌似并无问题……反正那串口闲着也是闲着……

出0入8汤圆

发表于 2008-5-21 23:44:10 | 显示全部楼层
用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动

另外,开源项目两样都有貌似并无问题……反正那串口闲着也是闲着……


学楼上的,继续回音,呵呵

PCB上都留着位置就是,那点空间相信还是省得出来的。

出0入0汤圆

发表于 2008-5-22 08:44:14 | 显示全部楼层
哈哈,是的,我就是那个意思,预留两种接口的位置,485可以不焊,但是预防万一~~

出0入0汤圆

发表于 2008-5-22 13:00:12 | 显示全部楼层
预留吧,还是要考虑一下国情...

出0入0汤圆

发表于 2008-5-22 13:00:32 | 显示全部楼层
最好2种都有,485支持MODBUS RTU协议,CAN最好也支持CANOPEN协议,这样产品更有竞争力

出0入0汤圆

发表于 2008-5-23 13:23:05 | 显示全部楼层
哈哈!主板上搞个转换短接插件,两种不就都有了。

出0入0汤圆

发表于 2008-5-23 16:06:45 | 显示全部楼层
就使用来说,CAN比485还是有很大优势的。不是说485的性能不行,而是CAN控制器将数据链路层的东西都处理掉了。这样,开发的时候只要关注应用层,开发来说简单很多。或是说,要将485做的CAN的性能,需要投入更多的开发精力。

出0入0汤圆

发表于 2008-5-23 16:12:47 | 显示全部楼层
从我们公司的产品来看,CAN其实使用起来很简单,可能用好很难,但是上手很容易,一点都不复杂,而且很容易就将性能做的很不错。
对于实际的应用来说,还是应该保留485的,毕竟现在国内485还是很多,特别是工控。
其实我觉得并不是CAN在工控领域对485没什么影响,而是一般工控上的产品,生命周期都很长。
就像是变频器,以前大多一个Modbus接口,现在往往都会加上一个CANOpen了。

出0入0汤圆

发表于 2008-6-19 14:59:28 | 显示全部楼层
485可以用来和上位机通讯,CAN留着将来做主从式的PLC时的内部总线,这种方法比较常用。

出0入0汤圆

发表于 2008-6-19 15:15:28 | 显示全部楼层
支持RS485,CAN贼贵

出0入0汤圆

发表于 2008-6-19 15:23:07 | 显示全部楼层
485 用起来简单些,can使用的起点要高些,为了让更多的人容易使用,485还是有必要的。
个人建议,纯属放屁.
回帖提示: 反政府言论将被立即封锁ID 在按“提交”前,请自问一下:我这样表达会给举报吗,会给自己惹麻烦吗? 另外:尽量不要使用Mark、顶等没有意义的回复。不得大量使用大字体和彩色字。【本论坛不允许直接上传手机拍摄图片,浪费大家下载带宽和论坛服务器空间,请压缩后(图片小于1兆)才上传。压缩方法可以在微信里面发给自己(不要勾选“原图),然后下载,就能得到压缩后的图片】。另外,手机版只能上传图片,要上传附件需要切换到电脑版(不需要使用电脑,手机上切换到电脑版就行,页面底部)。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

手机版|Archiver|amobbs.com 阿莫电子技术论坛 ( 粤ICP备2022115958号, 版权所有:东莞阿莫电子贸易商行 创办于2004年 (公安交互式论坛备案:44190002001997 ) )

GMT+8, 2024-5-10 05:06

© Since 2004 www.amobbs.com, 原www.ourdev.cn, 原www.ouravr.com

快速回复 返回顶部 返回列表