CAN和CANopen的关系
CAN最初是由德国的BOSCH公司为汽车控制系统而设计,并在1993年成为国际标准。之后因其所具有的高可靠性和良好的错误检测能力受到重视,现在已经扩展到医疗、交通、运动控制、工业自动化多个领域。
CANopen是CAN应用层。它是在1995年由欧洲的CIA协会推出第一个标准版本,其后五年在应用中不断完善,现在使用的主要是1999修订的标准。
2.为什么需要CANopen
由于CAN在定义之初并未定义标准的应用层,导致在实际应用中各个厂家对应用层的定义各不相同,这导致同样的CAN报文却因应用层对其解释的不同而产生了不同的功能含义,使其不能相互直接通信,阻碍了CAN网络设备在不同厂商品牌之间的兼容性。为此欧洲专门成立了CIA协会,负责CANopen应用层的推广。另外,CANopen专门针对有同步、实时控制要求的设备开发了PDO报文,大大提高了报文发送的效率。相对于devicenet(CAN的另一个应用层标准),CANopen报文更为简洁和开放,因此CANopen更值得推广。
其实,将报文格式及其实现方式(通信层)标准化还不够,还需要将报文参数和设备的功能参数的对应关系统一起来,以变频器为例,设定频率的参数对应报文中的哪个参数如果不统一,用户使用时仍会因各个厂家对此定义的不同而限制于某个厂家的设备。为此CIA专门针对各类设备也定义了该类设备的标准,例如编码器有CIA 406标准,各个IO模块有CIA 401标准,运控方面的驱动设备有CIA 402标准。这样,只要用户购买的设备遵从这些标准,那么就无需担心该设备是否和其他厂商设备的兼容或相互通信的问题,也就是说,同样的报文指令可以在不同厂商的设备中实现相同的功能,真正做到了与厂商无关。这也是CANopen有更大潜力的主要原因。
3.使用CAN卡或USB-CAN可以收发CANopen报文吗
正如可以用第三方电报机接收他人发送的电报一样,用普通的CAN接口板卡(PCAN-PCI等)或USB-CAN(PCAN-USB/CANUSB/CAN232)可以正常接收各类CANopen报文,但其具体含义就需要你了解CANopen报文的格式规范才能将其看懂了,类似战争中接收电报用的密码本。同样,用户也完全可以将CANopen报文按其规范写好后发给其他标准的CANopen设备。另外,由于PDO报文需要预先对接收和发送双方配置,所以CAN接口的设备不能直接发送PDO报文。如果需要解析和发送CANopen的报文,需要借助PCANopen Magic或者CANreport等分析软件,包括快速导入设备的EDS文件并作修改等。
4.使用支持CANopen解析的软件能否侦测到发送CAN报文的节点信息
由于有些CANopen软件不能识别CAN报文代表的含义,因此也不能识别该只支持CAN协议的节点。(注:它只能识别移植了标准CANopen协议的节点,而应用层无CANopen协议的CAN节点往往不能被识别)。而且CAN报文协议没有一个统一标准,各个设备厂家都可以定义自己的CAN协议。这样同一设备厂商的所有设备都可以互相识别和通讯,但一旦某个设备出故障需要检测或替换时便限制于该厂家,因为该CAN报文的含义是他自己定义的,用户即使能用USB-CAN捕捉到该报文,但需要费很大功夫和时间才能分析出各条报文的功能,而如果是标准的CANopen报文,则无需担心这些问题,这也是CANopen近年来迅速发展的原因。
5.在CAN基础上加入CANopen是否增加了报文的收发时间
这一点是不用担心的。CANopen代码通常是由经验丰富的厂商专门编写,且经过CIA和实践的验证,CANopen专门开发的PDO功能用于运动控制的多轴同步控制及其他实时性要求高的场合也证明了他并没有影响报文执行的实时性。另外,相对于分散的厂商各自编写的应用层(对CAN报文的格式及含义赋予自己习惯的功能),CANopen不仅功能全面(覆盖设备状态检测、错误报告、网络管理报文),且各类报文的实现方式是欧洲多方共同研究的结果,报文的实现效率更高。
CANCANope 相关文章:
- Windows CE 进程、线程和内存管理(11-09)
- RedHatLinux新手入门教程(5)(11-12)
- uClinux介绍(11-09)
- openwebmailV1.60安装教学(11-12)
- Linux嵌入式系统开发平台选型探讨(11-09)
- Windows CE 进程、线程和内存管理(二)(11-09)