Overview  |  Quick Start  |  Samples  |  Architecture  |  CoSlave  |  CoMaster  |  Listeners  |  Object Dictionary  |  Configuration  |  Eds2Od

Eds2Od — the object dictionary generator

Eds2Od is a command line tool that generates a CANoopEn object dictionary class (C++) from a standard CANopen EDS file (CiA 306). It is part of the CANoopEn project and lives in the canoopentools repository.

The EDS file is the single source of truth for your device’s object dictionary: maintain it with any EDS editor — for example the free graphical CANeds from Vector — and regenerate the C++ class after every change. Your application accesses the generated dictionary in a fully type-safe way (see Object dictionary).

Download

Ready-to-run executables for Windows and Linux are published on the GitHub releases page:

The executables are self-contained single files — no .NET runtime or any other installation is required. Eds2Od --version prints the tool version.

Usage

Eds2Od <eds-file> <output-cpp> <output-hpp>

Example:

Eds2Od MyDevice.eds MyDeviceOd.cpp MyDeviceOd.hpp

First run: default files

When the output files do not exist yet, Eds2Od generates complete default files: a class named after the header file, deriving from CoObjectDictionary, with a constructor taking the ICoObjectDictionaryListener&, all entry members and all registrations. These files are yours — adapt them freely: change the namespace, add custom members and methods, wire values in the constructor.

Regeneration: the generated code markers

On every later run only the content between the markers

// *** BEGIN GENERATED CODE (Eds2Od) ***********************************************
// *** END GENERATED CODE **********************************************************

is replaced. Everything outside the markers is preserved — your custom members, methods, includes and constructor code stay untouched, so generated and hand-written code live side by side in the same class. The samples show this pattern: after the generated registrations, the constructor sets the software version of object 100Ah manually.

What the generator emits

• One typed entry member per EDS object (CoOdEntryUnsigned16, CoOdEntryVisibleString, …) with index, sub-index, default value and access type from the EDS; string entries get a 128-byte buffer.
• All AddEntry calls plus the PDO mapping registrations: mapping parameter objects (1600h–17FFh, 1A00h–1BFFh) become CoOdPdoMappingParameter members, including the MPDO addressing mode derived from sub-index 0 (FEh = SAM, FFh = DAM).
• A NumberOfOdEntries constant with a static_assert against CoSettings::MaxNumberOfOdEntries — a dictionary that outgrows the configured capacity is a compile error, not a runtime surprise.
• $NODEID+... default values become expressions of the constructor’s uint16_t nodeId parameter (e.g. nodeId + 0x600), so COB-ID objects are initialized with the device’s actual node id — pass the same node id you hand to CoSlave/CoMaster.