Search code examples
can-buscanopen

What is Object dictionary in CANOpen?

I will use CANOpen in linux. In kernel, linux has socketcan and i have some questions for further implementation.

1-) How object dictionary looks like, is it a header file or EDS file?

2-) Do i need to use object dictionary for pdo and sdo configurations?

3-) Should i implement my custom canopen library which implements only required some protocols or use a library like canfestival which implements almost all protocols and object dictionary?

Solution

  • 1) The object dictionary defines a set of objects where data can be stored on a CANopen node. Objects in the object dictionary can be read and written from the CAN bus using the SDO protocol by giving an object index and sub-index. They can also be read and written from the local application on the CANopen node. You can say the object dictionary forms the API for accessing the CANopen node from other CANopen nodes.

    The EDS file contains a list of all objects present in a specific model of CANopen node, including data type, default value, min and max values and some attributes. This helps tools communicate with the CANopen node.

    2) Configuration is done over the CAN bus using the SDO protocol to write to the object dictionary of the CANopen node.

    3) If you develop a commercial product you probably want to use a commercial CANopen stack to support the full protocol. (One example is the Kvaser CANopen Stack which we maintain, but there are many others to choose from)

    If your projects licensing policy allows it you can use one of the open source CANopen stacks. CANFestival and CANopenNode comes to my mind, but there's others too.

    But if you just need minimal functionality you can also code the bare minimum from the specification. An NMT state machine, read only SDO expedited transfer, an object dictionary with the few mandatory objects and hard coded PDOs might even give you a standard compliant minimalistic node.

    The following objects are mandatory in CiA 301

    • 0x1000 Device Type (Read Only)
    • 0x1001 Error Register (Read Only)
    • 0x1017 Producer Heartbeat Time (Const)
    • 0x1018 Identity Object (Read Only)
    • In addition you need Communication Parameters and Mapping parameters for every PDO, but these are allowed to be constants.

    If you want to go a step further you might be able to pre-configure all other nodes on the network to auto start, then just send and receive fixed PDOs that the other nodes are programmed to recognize. This is not standard compliant, but might work if you do a quick hack to use in your lab.

    I did this for a prototype once, just a fixed PDO and heartbeat, then switching over to a commercial stack for the final product.