可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):
问题:
I have a similar problem with this. How to program a simple CANopen layer . I read the answers but I have to program a CANopen layer on my own I cannot get a commercial one. So are there any basics of writing a CANopen stack (or layer I'm not certain about the difference)? I don't know even where to start..
If it's required here's some information :
My master device is a beagle bone black with QNX. QNX has a generic CAN library I think but not specific to CANopen. And my slave is a militarized brushless motor controller. I'm writing in C++. I have a documentation about the general requirements of my system. There are 2 RPDOs and 4 TPDOs, transmission is synchronous, there is no stopped mode( so no heart-beat and node guarding) and all message informations are stated (size, format, related node IDs etc.)
回答1:
There are actually at least 4 open source projects that implement CANopen:
- CanFestival is the oldest and might be the most mature solution. License: LGPLv2.
- CANopenNode is aimed at micro-controllers. License: LGPLv2.
- Lely CANopen is a library for implementing CANopen masters and slaves. License: Apache version 2.
- openCANopen is a master that runs on Linux. License: ISC. Note: I am the author of this project.
I would have posted links, but apparently I don't have enough "reputation".
openCANopen also includes some utilities such as a daemon for forwarding traffic over TCP and a program that interprets and dumps CANopen traffic to standard output.
Lely CANopen is actually of pretty decent code quality and I might have used it if it'd been available when I started writing my own implementation. However, I have not tried using it, so I can't really say which implementation is "better". I can only say that they are different and one or the other may suit your needs better.
Now, I doubt that any of those implementations will work straight out of the box on QNX. They will either have to be adapted or you can copy individual parts of the code into your own implementations. At least that should save you some time.
回答2:
The quick and dirty work-around is to only implement the bare minimum (just don't market it as CANopen or claim CANopen compliance):
- Support for those specific RPDOs/TPDOs that the other node will send/expect to receive. Use fixed COBID (CAN identifiers). Forget about PDO mapping and PDO configuration, use fixed settings.
- Implement a NMT bootup message.
- Implement NMT state transitions between pre-operational and operational (your node needs to respond to these from the NMT master).
- Implement some means to set the node id. Easiest might be to hard code it as a program constant.
If you are lucky, this is all that is needed. If you are unlucky, there will be SDO commmunication, meaning you will have to implement the SDO protcol and also the whole Object Dictionary. Otherwise, the above is fairly straight-forward and not that much work.
In case you need the Object Dictionary, then there might be no other way around getting a full-blown protocol stack. You'll also need to apply for a vendor id from CAN-in-Automation, but it's a one-time fee (no royalties).
