Above the tool
An EDS file is a plain text device description. Your configuration tool reads it, builds a device profile, and hides everything behind a wizard. When the device does not come online, you need to see what is actually in that file.
This viewer opens both kinds of EDS you run into on an industrial job:
- CANopen EDS and DCF — the electronic data sheet format defined in CiA 306, used by every CANopen slave.
- EtherNet/IP EDS — the ODVA format shipped with adapters, drives, and I/O blocks so a scanner can build a connection.
Drop the file in. The viewer detects which one it is and lays out the contents. Everything runs in your browser, so vendor files never leave your machine.
What the viewer shows
CANopen files
Overview pulls the file header and device header into one place: vendor number, product number, revision, order code, supported bit rates, and whether LSS is supported. The revision number is split into major and minor so you can compare it against what the device reports on the bus.
Object dictionary lists every index and sub-index in the file. Object type and data type codes are resolved to names, so 0x0007 reads as UNSIGNED32 instead of a number you have to look up. Each index carries a tag for its area — communication profile, manufacturer-specific, or device profile — which tells you at a glance whether an object is standard or vendor-invented. Filter by index, name, or access type, and export the whole table to CSV.
PDO mapping is where most commissioning problems get solved. For every RPDO and TPDO in the file, the viewer shows:
- The COB-ID, with
$NODEIDexpressions resolved. Set the node ID at the top of the tab and the COB-IDs update. Bit 31 and bit 30 are decoded, so a disabled PDO is labeled as disabled rather than shown as a large hex number. - The transmission type in words — synchronous acyclic, cyclic every n SYNCs, asynchronous event driven, and so on.
- Inhibit time converted from 100 µs units to milliseconds, and the event timer.
- Every mapping entry broken into index, sub-index, and bit length, with the mapped object’s name pulled from the dictionary.
- A running total of mapped bits, flagged if it goes past the 8-byte CAN data field.
Raw sections shows the file as parsed, section by section, if you want to check something the tables leave out.
EtherNet/IP files
Overview gives you the identity a scanner uses for the electronic key: vendor code and name, device type, product code, and major/minor revision. Get any of these wrong in the scanner configuration and the connection fails on key mismatch. The device type code is resolved to its CIP name.
Parameters parses each ParamN entry into a readable row — data type, size, default, minimum, maximum, units, and path — with enumerated values listed underneath the parameter they belong to. Help strings are collected into their own table so long text does not wreck the layout. Exports to CSV.
Assemblies shows each assembly instance with its size, path, and member list. Each member is listed with its bit size and the parameter it references, and the members are totaled so you can check them against the declared assembly size. This is the fastest way to work out what the input and output data actually contains before you write a single rung.
Connections and ports lays out each connection entry field by field, with the ODVA field labels applied, plus the port table.
Reading COB-IDs written as $NODEID
CANopen EDS files rarely hardcode COB-IDs. They write them as expressions, because the same file has to work for every node on the bus:
DefaultValue=$NODEID+0x200That is the default RPDO1 identifier. On node 5 it resolves to 0x205. On node 12 it resolves to 0x20C. The viewer does that arithmetic for you — set the node ID and read the identifier you should actually see on the analyzer.
If a COB-ID looks wrong on the wire, this is the first thing to check. A node that was configured through LSS or a DCF may not be using the identifier its EDS suggests.
When the file will not load
| What you see | Cause | Fix |
|---|---|---|
| Format not recognized | The file is a GSD, GSDML, or IODD, not an EDS | Those are different formats with different parsers |
| Format not recognized | The file is compressed or wrapped in an installer | Extract the .eds from the archive first |
| Odd characters in vendor names | The file uses a legacy 8-bit encoding | The viewer falls back to Windows-1252; the parse is still valid |
| Object dictionary looks short | The file uses CompactSubObj | Compact sub-objects are flagged; sub-indexes 1…N are implied, not listed |
| Assembly members look shifted | The vendor left optional fields empty | Check the raw section against the table |
Frequently asked questions
What is an EDS file?
An electronic data sheet. It is a plain text file, INI-style, that describes what a device is and what it can do. A CANopen EDS lists the object dictionary and PDO structure. An EtherNet/IP EDS lists the identity, parameters, assemblies, and supported connections. Configuration software reads it so it does not have to know your device in advance.
Is a DCF the same as an EDS?
Close. A DCF is a device configuration file — an EDS with actual configured values written in, for one specific node. The format is the same, so this viewer opens both.
Does the file get uploaded anywhere?
No. Parsing runs in JavaScript in your browser. Nothing is sent to a server, which matters because vendor EDS files are often under NDA.
Why does the mapped bit total matter?
A classic PDO holds 8 data bytes. If the mapping entries in a single PDO add up to more than 64 bits, the device will reject the mapping — usually with an SDO abort you then have to trace. Checking it in the file first saves that trip.
Can I edit the file here?
No. This is a viewer. Editing an EDS by hand is possible but risky; the CRC and object counts have to stay consistent with the content, and most vendor tools will refuse a file they did not write.
What is the difference between a CANopen EDS and an EtherNet/IP EDS?
Only the name is shared. Both are INI-derived text, but the section names, the field layouts, and the meaning of the content are completely different. CANopen describes an object dictionary addressed by index and sub-index. EtherNet/IP describes CIP objects, assemblies, and connection parameters. The viewer detects which one it has and switches parsers.
My device works but the EDS shows objects it does not support.
Common. Vendors ship one EDS across a product family and leave the unsupported objects in place. The device itself is the authority — read object 0x1000 and 0x1018 over SDO and compare.