How can I write a CANopen stack?

Question

I have a similar problem to 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 BeagleBone Black with QNX. QNX has a generic CAN library I think, but it is 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 two RPDOs and four TPDOs, transmission is synchronous, there is no stopped mode (so no heart-beat and node guarding) and all message information are stated (size, format, related node IDs, etc.)

Answer 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: GPLv2.
• 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.

Answer 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).

Answer 3

I'm from Embedded Office. The reason why we didn't put drivers into the canopen-stack repository is the complexity of embedded software development on multiple targets with multiple compilers and my goal to provide running software wherever possible. With just a library, it is hard to identify problems during usage.

The good news, I set up an environment to get the different targets and compilers manageable by a single maintainer (me). So the canopen-stack is developed with LLVM on host machines, and a first demo is provided for STM32F7xx microcontrollers. More is coming, so stay tuned :-)