Systec CANopen Manager Source Code CiA 302

A CANopen network usually consists of several devices with different functionality. One main function is the NMT master which shall exist in every CANopen network. Its task is to control and monitor the NMT state of all NMT slaves. Commonly, the CANopen device which controls the system from an application point of view implements the NMT master also, e.g. a PLC.

The CANopen Manager according to CiA 302 combines the NMT master with additional functionalities and implements processes in a standardized way, e.g. the boot-up of the network. This boot-up consists of the scan for expected CANopen devices and their configuration by the Configuration Manager.

Furthermore the CANopen Manager may implement the SDO manager which is responsible for dynamic establishment of SDO connections. This means, that SDO connections do not have to be configured when installing the system, but CANopen devices are able to request SDO connections to other devices at run time. These CANopen devices which are the counterpart of the SDO manager are called “SDO requesting device”. The SDO manager ensures that the same SDO server of a CANopen device is not used by two SDO clients at the same time, if and only if no SDO connections are established dynamically by CANopen devices themselves.

A CAN driver porting, implementing of specific demo projects or adaptation of the CANopen software to processors that are not directly supported can be carried out in a few days. Please contact SYS TEC for further information on the available adaptation services.

Modular, Scalable and Portable

The continuous modularization of the functionalities and implementation in ANSI-C make possible simple porting to different target systems. Great importance was set on scalability and performance. Highly optimized memory management and zero-copy implementation prevent unnecessary copying of data. With our CANopen Source you can just as cost-effectively create single-chip solutions and complex, multi-channel master applications. Our CANopen protocol stack was successfully ported, along with a number of microcontrollers, to a DSP.

The CANopen software is organized into individual modules. Some modules can be incorporated into or removed from the project, depending on the required functionality. The modules do not cross-call functions to another module but only functions from subordinate or superordinate modules (as Callback function). There are no cross-references of global variables between the modules. A central software layer, called "CANopen Controlling Module" (CCM), provides a simplified API of the CANopen functions to the application layer and controls the interaction of the individual modules. Furthermore, the hardware specific implementation is clearly decoupled from the CANopen protocol stack, resulting in a minimum effort required for porting to a new target platform.

No Royalties on Deployed Products

We offer an attractive pricing structure. You get the complete source with project examples on every purchase as Buy-Out license for an economic one-time fee. There are no royalties on your deployed products.

The license is location-bound and can be used for various targets, projects and products by your engineers without further license fees.

Through a license extension, development partners and other sites of their company can use the source code.
Our update and support services can be renewed annually - so your stack is always up to date.