EDS and DCF file tool for CANopen®

What an EDS file is in this tool

An EDS file is the electronic data sheet for a CANopen device. It names objects, data types, and default values. Import it from the Start page or from the Object Dictionary and the dictionary stops being a list of bare indexes.

A DCF file is a device configuration file. It carries a configured view of the same kind of data, including PDO mapping. The suite imports DCF as well as EDS, and PDO mapping can export a DCF after you change the map.

This is an EDS file viewer and a working dictionary, not a free-form hex editor. You search, favourite, Read All, import, and export. Professional can also validate, compare, and score the file. None of those steps rewrite the file in place.

From the file to the Object Dictionary

After import, the Object Dictionary search box finds an object by name or index. Favourites keep the handful of objects you actually touch. Read All walks the dictionary on a connected node and fills in the live values beside the file defaults.

Export writes an EDS back out of the dictionary. Use that when the project should carry the names you have been working with, or when another tool needs a sheet from this project. The export is a file write. It is not a test report.

Network Explorer can match a scanned node to the loaded EDS. A match tells you the file and the node agree on identity. It does not certify the device.

PDO mapping and the DCF export

PDO mapping lists TPDO and RPDO entries and shows the bit budget so a map that no longer fits is visible before you write it. When the project is connected, the map can be written to the node. The PDO monitor then shows the process data that results.

Export DCF from the mapping screen when the configured map should travel with the project. The SDO client remains the path for objects that are not in the map. The guide on SDO and PDO explains which service to use for which job.

If two sheets need a side-by-side look, that compare view is Professional only, along with EDS quality and the compliance dashboard. Light still imports, browses, exports, and maps.

A practical file workflow

Start with the sheet the device vendor shipped. Import it. Connect with Virtual CAN if you are only checking the dictionary, or with a compatible USB-CAN adapter if the node is on the bench. Read All to see live values.

Map the PDOs you need, check the bit budget, and export a DCF if the configuration should be saved. Open the PDO monitor to confirm the frames. If a finding appears in Network Diagnostics, it names the node and a next step.

Light is $800 once and Professional is $1,400 once. The 28-day trial needs internet for the session. The current release is Classical CAN. For a plain-language definition of the file itself, read the EDS guide.

What this file tool will not do

It will not rewrite an EDS in place. Professional validation, compare, quality, and the compliance dashboard are read-only views of the sheet. If the sheet is wrong, the fix is a new export or a file from the device vendor, not a silent change inside the viewer.

It will not invent objects the file does not contain. Search finds what the import loaded, or what Read All returned from the connected node. A missing object stays missing. The dictionary is not a place to bolt a private protocol onto CANopen.

An EDS match in Network Explorer means the scanned identity lines up with the file you loaded. It is an identity check. Node-ID and bitrate, when the node still needs them, belong to the LSS wizard. The PDO map, with its bit budget, belongs on the mapping screen. Use the file to name the work, and the connected screens to do the work. A second file, for a second device in the same project, is imported the same way. Each dictionary stays with its device description, and Network Explorer matches a scanned node to the sheet you loaded for it.

Questions engineers ask