Embedded Systems Academy

We are pleased to introduce the latest software update for the CANgineBerry, which now includes a Python example aimed at simplifying network management for developers working across Linux, Windows, and macOS. This new example uses the provided CANopen Manager firmware as an efficient way to visualize and manage devices on a CANopen network.

Unlike basic CAN interfaces (only passing through CAN frames), the CANgineBerry handles the entire CANopen Manager functionality. This allows the module to automatically scan the network, identify new devices, and configure the appropriate Process Data Objects (PDOs) without requiring manual intervention. Through this automated functionality, users can directly access the Object Dictionary entries for both the Manager and the connected devices, reducing the need for writing complex code.

The Python example showcases these features through a lightweight graphical user interface (GUI). Once connected to a CANgineBerry, the script accesses detected devices, retrieves their details on demand, and presents them in an intuitive display. No matter the platform—Linux, macOS, or Windows—this tool provides rapid access to multiple devices on your CANopen network.

By delegating low-level CANopen management tasks to the CANgineBerry, developers are free to concentrate on higher-level application development. The Python-based GUI makes the configuration and monitoring of CANopen networks easy and gives you instant control over your devices.

This update further reinforces CANgineBerry’s position as more than a CAN bus interface. It remains a robust solution that simplifies CANopen network management, providing both flexibility and user-friendliness for embedded systems developers.

To download the example, go to: https://cangineberry.com/

Today we released a new version of our Micro CANopen source code. Updates and changes made include requirements from the latest CANopen conformance test as well as updates to the CiA 447 specific examples. Besides two bug fixes, the changes are:

Device switch themselves automatically to pre-operational when they detect a loss of a heartbeat that they are consuming. In the past this was application code specific, but as the conformance test requires it, we moved this function into the stack. In CiA 447 this is only done for the loss of the gateway’s heartbeat. Reaction to other heartbeat losses remains application code specific.

For CiA 447 devices, the shut down sequence is now also initiated if a gateway is not present. As before, devices wait for the next wake-up message before they try to communicate again.

Micro CANopen customers with a current maintenance and support contract may download this latest version from our servers as described on the delivery note for each product.