[PLC]开个简单讨论会—— CAN vs 485
我们都知道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)
http://cache.amobbs.com/bbs_upload782111/files_10/ourdev_288804.JPG
(原文件名:422485.JPG)
再放两个CAN和485芯片的资料对比
http://cache.amobbs.com/bbs_upload782111/files_10/ourdev_288805.JPG
(原文件名:230.JPG)
http://cache.amobbs.com/bbs_upload782111/files_10/ourdev_288806.JPG
(原文件名:485.JPG)
(以上资料均来自 TI 德州仪器,www.ti.com.cn)
-----------------------------------------------------------------
个人的一些评论,
CAN和485采用基本相同的传输方式,一样的差分传输,相近的差分信号电平。所以在传输速率、传输长度上应该也不会有本质上的大变化。
也就是说,对于数据通讯本身,485和CAN是差不多的。
CAN增加了识别码、以及硬件的保护,这个对于CAN网络的易用性有明显的提高。485需要软件协议参与,才能做到识别码、多主多从。
这方面而言,CAN确实有优势。
总体评价,在数据传输本身,CAN相比485基本差不多,在数据传输之外,CAN增加了不少辅助的东西。 CAN 吧。
STM32F本身就集成了CAN 接口,我们需要的只是增加一个CAN收发芯片。
而且整个通讯过程更加容易操作和控制 1楼正解,CAN可以多个设备同一时刻发送不同电平,而485是不行的。
另外CAN依靠控制器可以对时隙进行同步,保证所有发送的同步,而485没有这个功能。 还是用can吧,485没什么意思
上传一个can的入门资料
点击此处下载 ourdev_288863.pdf(文件大小:1.87M) (原文件名:CAN总线入门.pdf) 用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动。 用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动。
回音,回音而已……:D 占个位,向大家学习!!! 最好加上CAN.学习一下 。 can有几点说明下:
1.波特率与传输速度:虽然can的最大速率为1Mbps,但由于有效数据占实际通信比例是比较低的,
根据帧的类型而定,像扩展帧的ID和8个字节数据总共占实际通信的70%左右。
2.仲裁方式:非破坏性总线仲裁虽然不错,但是一些can驱动单元的实现对于重发是有限制的,如果数据量大而多次重发超上限就失败了,
而有些芯片对这类失败没有标志位,会丢帧。
3.多个节点接收:一个帧如果由多个节点接收,那么根据can2.0协议,只要一个节点物理上应答了,那么发送方控制器就认为发送成功了。
所以,对发给多个节点的帧,如果要确保受到,必须在应用层查询实现。
can的通信效率取决于应用层实现。 回楼上的:
1、需要用PLC上的CAN Bus来传语音或视频数据吗?
2、重发次数限制是为了不要过长时间占有总线,浪费通讯效率!对于进入被动模式的CAN Model应该是在应用层上软件来做修正,任何一个CAN Bus都会有发送错误计数器的,当达到128次,进入被动模式是都是可以通过计数器查到的。不可能存在丢帧,只能说应用层软件没有考虑发送错误计数器的使用规则。
硬件提供的仅是可靠的通讯通道,而不是可靠的通讯规约!
3、这一点是应用层的问题。 【10楼】 Grant
我提出这几个问题就是让入门者在应用时要注意can的应用范围和芯片的can控制器特性。
因为我工作中曾看到有人只看到波特率而不顾can的实际通信能力而提出要求的。
发送错误计数,一般can控制器里是有的。can的驱动及应用层协议编写要求还是比较高的。
至于can的可靠性高是没什么疑问的。 Re 11
我补充是因为看了你的回复觉得有些话有点片面,对入门者在应用时产生不必要的误导。你说不是吗?我不是针对你个人,别介意。
1、CAN不身的用途就是用来在恶劣环境传输信号而不是数据的,不是吗?要更快的速度应该是Freescale提出的那个Flexy什么总线来着。
2、既然你也确认一般CAN 控制器都有发送错误计数器,何来丢帧?如果在应用层意识到这个计数器的作用。CAN丢帧是协议手册规定的,但要丢弃帧之前是要发送错误计数器达先后达到两个条件,一是过127;二是255。
3、这一点我也认同。
给张图看看:
http://cache.amobbs.com/bbs_upload782111/files_10/ourdev_289106.jpg
(原文件名:1.jpg) 关于can通信效率方面,我觉得并没什么误导,因为实际通信中还伴随各种延时的存在(can物理层本身的、mcu处理速度等)。
而应用层协议部分,信号终究还是以ID+数据方式传输的,如果算上各种管理用的帧(心跳等之类),真正用于信号通信部分的数据在固定时间内的比例是7成左右。
项目对于通信量一般要有个预估,根据实时性的指标来确定,我给出的值是估算用的。 不用比较,毫无疑问,CAN比485强很多,而且CAN也是一种趋势,尽早CAN会替代485! 485迟早会被取代,但是取代者是不是CAN,目前也还不得而知。
CAN出来也不少年了,对于485的冲击一直不是很大。
所以我才发起这个讨论 大家都说CAN好
我也觉得CAN好
不过
CAN贵。。。 【17楼】 jjldc 九九
大家都说CAN好
我也觉得CAN好
不过
CAN贵。。。
======================
对于内置CAN控制器的设备来说,CAN不比485贵…… 好像大家都比较倾向于用CAN。
但是实际上的工业现场CAN对485根本构不成威胁。
虽然好处多多。 【18楼】 watercat
对于内置CAN控制器的设备来说,CAN不比485贵……
问题是如果需要和其他设备互联的时候,特别是PLC作为通讯控制器 与底层的传感器执行器互联的时候,每个节点的成本都是要考虑的啊
不单单是硬件成本(底层设备一般都是简单的MCU) 还有通讯协议等设计的成本 个人感觉,就收发器来说,485和CAN的价格差不多。他们的价格差异主要是在控制器上。
CAN控制器足够满足简单的命令数据传送,485只是硬件层的协议,MCU需要额外的时间处理传输层(如果通信量大,MCU需要大量的时间处理通信),而CAN控制器内置的过滤功能可有效减少MCU开销。
对于通信效率来说,CAN并不比485效率低多少。如果采用485主机轮询或令牌方式传输,总线上将出现大量的轮询请求或令牌,也无法有效支持优先级。对应的,CAN控制器从协议上就支持多主多从设备和按位仲裁(优先级),因此总线上都是需要传输的数据,这样的话,相对的传输效率并不低于485总线。 支持使用CAN。。。 哈哈,画PCB画晕了,溜进来,看看~~
说下我的感受……
前段时间,实验室里有项目转为CAN控制,花了比较大的精力去实现了软件的控制,看上去软件控制很舒服,通讯协议也很好,爽。拿到工业现场,还是485的节点居多……,最后不得已在设计上重新加上了485……
而后我又发现,使用CAN和485的比例在1比5……后来就在大批量的生产中去掉了CAN
因为,
1、两种接口有成本
2、很多场合只能用485……
所以,这只是我的实际经验,比较有局限性,仅当参考了
我的建议是,还是保留485为好,就算是不焊也行……留出位置就好了 RS485的成本优势很大,基本上但CAN控制器的MCU价格都不低,外接CAN控制器更贵。
从编程上来讲,和usart的编程更容易些,CAN就不一样了,讲究挺多。 留住485吧,这么个项目一下子就到了CAN 的程度也太快点了。当然,做为技术研讨的现在,为什么不呢! 【23楼】 kingofkings 技术火腿(KoK)
哈哈,画PCB画晕了,溜进来,看看~~
说下我的感受……
前段时间,实验室里有项目转为CAN控制,花了比较大的精力去实现了软件的控制,看上去软件控制很舒服,通讯协议也很好,爽。拿到工业现场,还是485的节点居多……,最后不得已在设计上重新加上了485……
而后我又发现,使用CAN和485的比例在1比5……后来就在大批量的生产中去掉了CAN
因为,
1、两种接口有成本
2、很多场合只能用485……
所以,这只是我的实际经验,比较有局限性,仅当参考了
我的建议是,还是保留485为好,就算是不焊也行……留出位置就好了
=========================
用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动
另外,开源项目两样都有貌似并无问题……反正那串口闲着也是闲着…… 用了STM32F103不用CAN Bus实在浪费,虽然我没有参加活动
另外,开源项目两样都有貌似并无问题……反正那串口闲着也是闲着……
学楼上的,继续回音,呵呵
PCB上都留着位置就是,那点空间相信还是省得出来的。 哈哈,是的,我就是那个意思,预留两种接口的位置,485可以不焊,但是预防万一~~ 预留吧,还是要考虑一下国情... 最好2种都有,485支持MODBUS RTU协议,CAN最好也支持CANOPEN协议,这样产品更有竞争力 哈哈!主板上搞个转换短接插件,两种不就都有了。 就使用来说,CAN比485还是有很大优势的。不是说485的性能不行,而是CAN控制器将数据链路层的东西都处理掉了。这样,开发的时候只要关注应用层,开发来说简单很多。或是说,要将485做的CAN的性能,需要投入更多的开发精力。 从我们公司的产品来看,CAN其实使用起来很简单,可能用好很难,但是上手很容易,一点都不复杂,而且很容易就将性能做的很不错。
对于实际的应用来说,还是应该保留485的,毕竟现在国内485还是很多,特别是工控。
其实我觉得并不是CAN在工控领域对485没什么影响,而是一般工控上的产品,生命周期都很长。
就像是变频器,以前大多一个Modbus接口,现在往往都会加上一个CANOpen了。 485可以用来和上位机通讯,CAN留着将来做主从式的PLC时的内部总线,这种方法比较常用。 支持RS485,CAN贼贵 485 用起来简单些,can使用的起点要高些,为了让更多的人容易使用,485还是有必要的。
个人建议,纯属放屁.
页:
[1]