Frequently asked questions

Here are some frequently asked questions. If you can’t find your answer here, please check out our Gitter room.

What is Lely CANopen?

A high-quality, feature-rich, open-source implementation of the CANopen protocol, including several tools to help develop and debug CANopen applications. The project is actively developed, with over 250 commits in 2019 and over 500 commits in the first three quarters of 2020.

Who is using it and why?

As the name implies, Lely CANopen is primarily used by Lely, a large robotics company in the Netherlands. It is also used by several of its suppliers as well as in multiple projects, open-source and otherwise, all over the world. Most recently, the European Space Agency has investigated it for possible use in satellites. We’re currently working together with N7 Space to create an ECSS-compliant version of the stack.

At Lely, we started using it because we were dissatisfied with the commercial CANopen implementations we were using and thought, perhaps naively, how hard can it be to write our own? At the time (2015) none of the open-source implementations met our needs. Since writing a CANopen stack is not our core business — although it is mission-critical for our products — we decided to make it available to the open-source community. Over time it has grown to incorporate many features not available in other stacks.

Which platforms are supported?

Linux is the best supported platform, not least because CAN bus support is available in the mainline kernel through SocketCAN. Windows 7 and later are supported, but only IXXAT CAN adapters have a built-in driver. The stack also supports bare-metal platforms, using the Newlib C library, but you have to write the CAN driver yourself (see here for an example).

All Lely core libraries are written in pure and compliant C99 and C++11, with a few features from POSIX. Emulation of those features is provided for non-POSIX platforms. This means that, in general, it is quite easy to port the stack to a new platform, as long as a conforming compiler is available. We have done this recently for the C2000 microcontrollers from Texas Instruments using their code generation tools.

How do I get started?

Follow the installation instructions, if you haven’t already, and dive into the command-line tutorial or C++ tutorial.

Where is the documentation?

The API is documented with doxygen and can be found here. On this site you can find an overview of the tools and libraries, as well as some information about the internals of the CANopen stack.

What is the roadmap?

New features can be proposed and tracked in the issue list. The most important planned features are:

  • Add “logical drivers” for the most used device profiles (CiA 401 and 402 at least). Include mock slave implementations of those profiles for testing and demonstration purposes.
  • Add a tool to scan a CANopen network, configure node-IDs and update the configuration and firmware of the slaves (see issue #41).
  • Create an example project for ROS 2, with a master and a (mock) slave communicating over a virtual CAN bus.
  • Add support for Zephyr.
  • Add support for running wihthout dynamic memory allocation.
  • Add TCP and UDP support to the new asynchronous I/O library and migrate CAN-to-UDP, so the old I/O library can be removed.
  • Improve the test coverage.