Private CANopen device-description preflight

CANopen EDS / DCF Object Dictionary Inspector

Open or paste an Electronic Data Sheet or Device Configuration File to inventory its object dictionary, reconcile the declared object lists, and decode RPDO and TPDO mappings without connecting to a CAN bus or changing the device.

Local text source

Choose or paste a device-description file

No local file selected.

Maximum 5 MiB, 100,000 lines, and 20,000 sections. Files are decoded as UTF-8 and stay in this tab.

Choose a file or paste device-description text to begin.

Device identity, object dictionaries, PDO mappings, filenames, and configuration values stay in this browser tab. Nothing is uploaded, written to a device, or sent on a CAN bus.

What this CANopen EDS inspector checks

The parser reads the INI-like section structure, retains unknown vendor sections, detects duplicate sections and keys, inventories base objects and subobjects, checks common object metadata, and reconciles MandatoryObjects, OptionalObjects, and ManufacturerObjects with actual object sections. It recognizes the common basic datatypes and VAR, ARRAY, and RECORD object forms while leaving unfamiliar codes visible.

How PDO mappings are decoded

Mapping objects at 1600h–17FFh describe receive PDOs and those at 1A00h–1BFFh describe transmit PDOs. Each active 32-bit mapping entry identifies a 16-bit object index, 8-bit subindex, and 8-bit length. The audit resolves that coordinate, checks PDOMapping=1, compares known datatype widths, finds missing active entries, and totals the classic 64-bit PDO payload. It does not infer dynamic mappings absent from the file.

EDS versus DCF

An EDS describes a device’s capabilities and object dictionary. A DCF uses the same general representation but can add commissioned network settings and configured parameter values. This inspector prefers ParameterValue over DefaultValue when both are relevant to a decoded entry, reports either spelling of the common commissioning section, and never applies those values to hardware.

CANopen safety and conformance boundary

A clean report is not CiA conformance certification and is not permission to operate machinery. This bounded preflight does not implement every CiA 301/306 profile rule, parse XDD/XML, validate device-profile semantics, prove an EDS matches firmware, open an interface, transmit SDOs or PDOs, calculate COB-IDs, or establish safe commissioning. Validate with the device vendor, the exact controller/configuration suite, the applicable CiA specifications and profiles, and a controlled hardware test.

Frequently asked questions

Does the tool connect to CAN hardware?

No. It only reads local text in the browser. It cannot scan nodes, upload a configuration, or change an object dictionary.

Why can a valid vendor file still show warnings?

EDS generators and vendor extensions vary. Missing recommended metadata, unlisted objects, or unfamiliar datatypes deserve review but are not automatically treated as fatal unless a relationship is structurally contradictory.

Does an active PDO mapping prove the device uses it?

No. The file’s default or configured value may differ from the live node, and runtime remapping can change it. Read the actual device state with appropriate engineering tools before relying on it.

Are strings and DOMAIN objects assigned a bit width?

No. Their stored or mapped size can depend on declarations outside the bounded basic-type table, so the inspector leaves the width unknown instead of guessing.

Format references

The data model follows the canopen-python object-dictionary documentation and its open EDS parser implementation. Object types and datatype codes are cross-checked against the CANopenNode editor schema. These implementation references do not replace the applicable CiA specifications.

Audit a Modbus register map · Inspect a JTAG SVF file · Browse electronics tools