EDS Files Explained: How EtherNet/IP Devices Describe Themselves

By | June 19, 2026

Open Studio 5000, browse the network, find a third-party EtherNet/IP device, and click “Add Module.” If the device’s EDS file is registered, the configuration tool already knows the device’s Vendor ID, Product Code, supported connections, assembly sizes, and parameter ranges. If the EDS isn’t registered, you get a generic device entry with very little to work with.

EDS — Electronic Data Sheet — is how CIP devices describe themselves to configuration tools. It is a plain text file with a defined structure that captures everything a tool needs to know to communicate with the device: identity, supported services, assemblies, parameters, connections, and more. Every CIP device that wants to be configured by a third-party tool ships with an EDS file.

This article explains EDS files from ODVA’s CIP Networks Library Volume 1, Chapter 7. For broader CIP context, see the CIP Protocol Complete Guide and the CIP Assembly Object Explained article (since EDS files heavily reference assemblies).

What an EDS file is in one paragraph

An EDS file is a plain-text ASCII file with the .eds extension that describes a CIP device’s identity, capabilities, parameters, assemblies, and supported connections. Defined by ODVA in Volume 1 Chapter 7, EDS files follow an INI-like syntax with sections delimited by bracketed keywords ([File], [Device], [Params], [Assembly], etc.). Configuration tools read EDS files to populate device catalogs, validate Forward_Open requests, and display parameters with proper units and ranges. Every CIP-conformant device produced for the open market ships with an EDS file.

Why EDS files exist

CIP defines a rich object model — Identity Object, Assembly Object, Connection Manager, hundreds of others. But a configuration tool needs to know more than “this device implements the Assembly Object.” It needs to know:

  • Which assembly instances exist
  • How big each one is
  • What data goes into each one
  • What configuration parameters the device has
  • What units, ranges, and defaults apply
  • Which connections can be opened
  • What the device’s RPI limits are
  • Which firmware revisions are compatible

Without this information, integrating a third-party device into a system is a manual reverse-engineering project. EDS files solve this by giving every device a portable, machine-readable specification that any compliant configuration tool can read. They serve a similar role for CIP that GSD files serve for PROFINET.

The result: you download an EDS for a third-party drive, import it into Studio 5000, and the drive appears in the device catalog with all its parameters, assemblies, and connection options already documented.

The file format basics

EDS files are plain ASCII text with sections, keywords, and field values:

ini

[File]
        DescText = "1734-AENT Point I/O EtherNet/IP Adapter";
        CreateDate = 02-15-2017;
        CreateTime = 10:14:33;
        ModDate = 06-09-2022;
        ModTime = 11:22:08;
        Revision = 1.1;

[Device]
        VendCode = 1;
        VendName = "Rockwell Automation/Allen-Bradley";
        ProdType = 12;
        ProdTypeStr = "Communications Adapter";
        ProdCode = 184;
        MajRev = 4;
        MinRev = 1;
        ProdName = "1734-AENT";
        Catalog = "1734-AENT";

The general rules from Volume 1 Section 7-3:

  • Sections begin with a section name in square brackets: [Device]
  • Entries follow the form Keyword = field1, field2, ...;
  • Strings are enclosed in double quotes
  • Each entry ends with a semicolon
  • Comments start with $ and go to end of line
  • Whitespace between fields is allowed and helps readability
  • A single file must contain the entire EDS

The text-file format means EDS files are git-friendly, diff-able, and editable in any text editor — which is occasionally useful for debugging but should rarely be required.

EDS file sections

From Volume 1 Table 7-3.1, an EDS file may contain the following sections. The first two are required; the rest are optional based on what the device supports.

SectionDelimiterRequiredPurpose
File Description[File]RequiredAdministrative info about the file itself
Device Description[Device]RequiredIdentity Object content for this device
Device Classification[Device Classification]OptionalWhich CIP networks the device supports
Parameters[Params]OptionalConfigurable parameter definitions
Parameter Class[ParamClass]OptionalParameter object class metadata
Parameter Groups[Groups]OptionalLogical grouping of parameters for UI
Assembly[Assembly]OptionalAssembly instance definitions
Connection Characteristics[Connection Manager]OptionalSupported connections and their parameters
Port[Port]OptionalNetwork port descriptions for routing devices
Modular[Modular]OptionalConfiguration of slot-based modular devices
Capacity[Capacity]OptionalDevice resource limits
Connection Configuration[Connection Configuration]ConditionalConnection Configuration object support
Event Enumeration[EventEnum]OptionalEnumerated values for event reporting
Symbolic Translation[SymbolicTranslation]OptionalSymbol-to-path translation rules
Internationalization[Internationalization]OptionalMulti-language string mappings
Object class sectionsVariousOptionalObject-class-specific metadata

Some entries reference DeviceNet-specific sections ([IO_Info], [EnumPar], [Variant_IO_Info]) defined in Volume 3 — these appear only on DeviceNet EDS files.

The next sections walk through the ones engineers see most often.

The [File] section

The [File] section is administrative — it describes the EDS file itself, not the device.

ini

[File]
        DescText = "1734-AENT Point I/O EtherNet/IP Adapter";
        CreateDate = 02-15-2017;
        CreateTime = 10:14:33;
        ModDate = 06-09-2022;
        ModTime = 11:22:08;
        Revision = 1.1;
        EDSFileCRC = 0x1234ABCD;

Key keywords:

  • DescText — Human-readable description of what the file describes
  • CreateDate / CreateTime — When the file was first created
  • ModDate / ModTime — When the file was last modified
  • Revision — The EDS file format revision (typically 1.1 currently)
  • EDSFileCRC — Integrity check (some files; not all)

When you have multiple EDS files for the same device but different firmware revisions, the ModDate is what tells you which is newer.

The [Device] section

The [Device] section is the most important — it contains everything from the device’s Identity Object (Class 0x01).

ini

[Device]
        VendCode = 1;
        VendName = "Rockwell Automation/Allen-Bradley";
        ProdType = 12;
        ProdTypeStr = "Communications Adapter";
        ProdCode = 184;
        MajRev = 4;
        MinRev = 1;
        ProdName = "1734-AENT";
        Catalog = "1734-AENT";
        Icon = "1734_aent.ico";

The key fields:

  • VendCode — Vendor ID assigned by ODVA. Rockwell = 1. Beckhoff = 26. Omron = 47. Phoenix Contact = 87. Schneider = 243. Every ODVA-registered vendor has a unique number.
  • VendName — Human-readable vendor name
  • ProdType — Device Type code. Common values: 0x07 (General Purpose Discrete I/O), 0x0C (Communications Adapter), 0x02 (AC Drive), 0x22 (Generic Encoder), 0x2B (Generic Device).
  • ProdTypeStr — Human-readable device type name
  • ProdCode — Vendor-specific product code
  • MajRev / MinRev — Major and minor firmware revision
  • ProdName — The product name as it should appear in tool device catalogs
  • Catalog — Catalog or part number string
  • Icon — Path to an icon file (optional, used for UI display)

The combination of VendCode + ProdType + ProdCode + MajRev + MinRev is what electronic keying validates in a Forward_Open Connection Path. If your configuration’s EDS specifies VendCode=1, ProdCode=184, MajRev=4, MinRev=1 — but the actual device is at firmware 5.2 — Forward_Open fails with Extended Status 0x0116 (Revision mismatch). See our CIP Forward_Open Service Explained article for the full electronic keying mechanics.

The [Params] section

The [Params] section defines configurable parameters. Each parameter gets a ParamN entry where N is a sequential parameter number.

ini

[Params]
        Param1 =
                0,                          $ Reserved
                6, "20 04 24 67 30 03",     $ Link Path Size and Link Path
                0x0000,                     $ Descriptor
                0xC4,                       $ Data Type (0xC4 = DINT)
                4,                          $ Data Size in bytes
                "Filter Time",              $ Name string
                "ms",                       $ Units string
                "Input filter time",        $ Help string
                0,                          $ Minimum value
                1000,                       $ Maximum value
                10,                         $ Default value
                ,                           $ Scaling multiplier
                ,                           $ Scaling divisor
                ,                           $ Scaling base
                ,                           $ Scaling offset
                ,                           $ Multiplier link
                ,                           $ Divisor link
                ,                           $ Base link
                ,                           $ Offset link
                0;                          $ Decimal places

That’s a lot of fields. The most important ones:

  • Link Path Size + Link Path — A CIP path pointing to the attribute that holds this parameter’s value. The path is given as hex bytes separated by spaces. The example above points to Class 0x04 (Assembly), Instance 0x67 (103), Attribute 3.
  • Data Type — The CIP type code (see our CIP Data Types Reference for all codes). 0xC4 = DINT, 0xC2 = SINT, 0xC8 = UDINT, 0xCA = REAL, etc.
  • Data Size — Number of bytes
  • Name — Display name for the parameter
  • Units — Engineering units string for display
  • Help — Help text shown in the configuration tool
  • Min / Max / Default — Range constraints for value entry
  • Scaling — Optional multiply/divide/offset transforms applied to the raw value

When you import an EDS into Studio 5000 and look at a device’s “Parameters” tab, every entry you see comes from this section.

The [Assembly] section

The [Assembly] section describes the device’s Assembly Object instances. Critical for any device that exchanges I/O.

ini

[Assembly]
        Revision = 0x0001;
        Object_Name = "Assembly Object";
        Object_Class_Code = 0x04;

        Assem100 =
                "Output Assembly 100",      $ Name
                ,                           $ Path
                8,                          $ Size in bits (8 bits = 1 byte)
                0x0000,                     $ Descriptor
                ,                           $ Reserved
                ,                           $ Reserved
                8, 0xC1, 0x0000, "Bit 0",   $ Member: 8 bits as BOOL bit 0
                ;

        Assem101 =
                "Input Assembly 101",
                ,
                8,
                0x0000,
                ,
                ,
                8, 0xC1, 0x0000, "Input 0",
                ;

        Assem102 =
                "Configuration Assembly 102",
                ,
                64,
                0x0000,
                ,
                ,
                ;

Each AssemN entry describes one assembly instance, where N is the instance number. The fields:

  • Name — Display name
  • Path — Optional path reference
  • Size — Total assembly size in bits (so 8 = 1 byte, 16 = 2 bytes, etc.)
  • Descriptor — Bit flags about the assembly
  • Reserved fields
  • Member entries — Each member: bits, data_type, descriptor, "name"

For a configuration tool, the most important value here is the Size. When Forward_Open’s Network Connection Parameters specify a connection size, that size must match the assembly size. Mismatches return Extended Status 0x0109 (Invalid connection size). The configuration tool reads the assembly sizes from the EDS to pre-validate the user’s connection configuration before sending Forward_Open.

For more on what assemblies actually contain on the wire, see our CIP Assembly Object Explained article.

The [Connection Manager] section

The [Connection Manager] section describes which connections can be opened to this device.

ini

[Connection Manager]
        Connection1 =
                0x04010002,                 $ Trigger and transport
                0x00000000,                 $ Point/Multicast (defaults)
                0x44648405,                 $ Connection parameters
                10000,                      $ O->T RPI minimum (microseconds)
                ,
                "20 04 24 66 2C 67 2C 68",  $ Connection path
                "Exclusive Owner",          $ Name
                "",                         $ Help string
                "20 04 24 66 2C 67 2C 68";  $ Connection path again

Each ConnectionN entry describes one supported connection type. The fields encode:

  • Trigger and transport — Production trigger and transport class
  • Point/Multicast defaults
  • Connection parameters — Default Network Connection Parameters
  • RPI minimums — Fastest update rate the device supports
  • Connection path — The EPATH describing which assemblies this connection uses
  • Name and help strings — UI display

Common Connection entries you see in EDS files:

  • “Exclusive Owner” — The full bidirectional I/O connection (uses Configuration, Input, Output assemblies)
  • “Listen Only” — Subscribe to multicast input from an existing primary connection
  • “Input Only” — Read inputs without driving outputs
  • “Data” — Explicit messaging connection

The configuration tool uses this section to populate the user’s connection choices. When you select “Exclusive Owner” in Studio 5000, the tool builds a Forward_Open using the parameters from the corresponding Connection1 entry in the EDS.

The [Port] section

For devices that bridge or route between networks (1756-EN2T, 1756-DNB, etc.), the [Port] section describes each network port.

ini

[Port]
        Port1 =
                TCP,                        $ Port type
                "Port 1",                   $ Name
                "20 F5 24 01",              $ Port object path
                1;                          $ Port number
        Port2 =
                ICP,                        $ ControlNet
                "Port 2",
                "20 F4 24 01",
                2;

Configuration tools use this section to know which ports are available and what their CIP paths are. Routing-aware tools build Connection Paths that traverse these ports when communicating with devices on other networks.

The [Modular] section

For modular devices (a backplane with slots for various modules), the [Modular] section describes:

  • Which slots exist
  • Which modules can occupy each slot
  • How module choices affect the device’s overall assemblies

A 1734-AENT with a 13-slot backplane uses Modular sections to document which modules can be added and how the assembly sizes scale with the chosen configuration.

The [Capacity] section

The [Capacity] section documents the device’s resource limits.

ini

[Capacity]
        ConnOverhead = 5;
        Connections = 32;
        MaxIOConnections = 16;
        MaxExpMsgConnections = 8;

Configuration tools use these limits to avoid trying to open more connections than the device supports. If you try to add a 33rd connection to a device with Connections = 32, the tool can warn you before sending a Forward_Open that would fail with Extended Status 0x0113 (Out of connections).

How to install (register) an EDS file

The process varies slightly by tool, but the general flow:

Studio 5000 / Logix Designer (Rockwell)

  1. Tools → EDS Hardware Installation Tool
  2. Register an EDS file → browse to the .eds file
  3. The tool validates the EDS and adds the device to its hardware catalog
  4. The device now appears in I/O Configuration → Add Module

If the EDS fails validation (syntax errors, missing required fields, unsupported version), the tool tells you what’s wrong.

RSLogix 5000 (older Rockwell)

Same process, accessed via Tools → EDS Hardware Installation Tool.

TIA Portal (Siemens)

Siemens uses GSDML files for PROFINET, not EDS. But TIA Portal can import EDS for EtherNet/IP devices in mixed installations via specific Siemens modules.

Third-party CIP tools (e.g., Pyramid Solutions, HMS, Molex)

Most CIP-aware tools have an “Import EDS” or “Register Device” function. The mechanics are similar — point at the file, the tool parses and adds it to its catalog.

How to find an EDS file

Where to look, in rough order of reliability:

  1. The device manufacturer’s website. Search for the product part number + “EDS” or “downloads.” Manufacturers maintain current EDS files for each firmware revision of each product.
  2. The device itself. Some EtherNet/IP devices serve their own EDS file via HTTP. Browse to the device’s IP address and look for a downloads page.
  3. ODVA’s website. ODVA does not catalog all EDS files but provides some.
  4. The Rockwell EDS Hardware Installation Tool repository. For Rockwell hardware, the tool has a built-in library.

When you have multiple EDS versions for the same device, match the EDS revision to the device firmware revision (MajRev and MinRev fields). Using an EDS for firmware 4.001 with a device running firmware 5.011 risks Forward_Open rejecting due to electronic keying mismatch.

SymptomLikely causeFix
EDS install fails with syntax errorMalformed EDS file (missing quotes, semicolons, etc.)Open in text editor, find the line, fix the syntax. Or get an updated EDS from manufacturer
Device appears in catalog but Forward_Open failsEDS revision doesn’t match device firmwareDownload the EDS that matches device’s actual firmware
Forward_Open Extended Status 0x0109Assembly size in your config doesn’t match EDSUse the assembly with the matching size from [Assembly] section
Forward_Open Extended Status 0x0117Wrong assembly instance IDPick a valid instance from [Assembly] section
“Module not found” errorEDS not registered in the toolRun EDS Hardware Installation Tool and register the file
Parameter values display as raw numbersEDS missing [Params] section or wrong link pathsEDS file is incomplete or wrong — get updated EDS
Tool shows wrong icon or nameEDS file’s Icon or ProdName field is incorrectEdit EDS file or get updated from manufacturer
Multiple devices share same Vendor + Product CodeConflicting EDS files registeredUnregister duplicates, keep only the version matching your device firmware

Editing EDS files

You can edit EDS files in any text editor. You rarely should. Editing an EDS:

  • Voids any manufacturer support claims
  • Causes confusion when the next engineer wonders why their device doesn’t match the spec
  • Can cause subtle Forward_Open failures if you edit fields incorrectly
  • Doesn’t change what the device actually does — it only changes what the configuration tool thinks the device does

The legitimate cases for editing an EDS:

  1. Fixing an obvious typo in a help string or description
  2. Adding parameter scaling for a measurement that the manufacturer documented incorrectly
  3. Generating a custom EDS for a development device

For everything else, contact the manufacturer for an updated EDS rather than editing.

Reading an EDS file by hand

When troubleshooting a “device not found” or “wrong assembly size” issue, opening the EDS in a text editor is fast. Look for:

  1. [Device] section — Confirm VendCode, ProdCode, MajRev, MinRev match the actual device (read its Identity Object via Get_Attribute_Single)
  2. [Assembly] section — Find AssemN for the instance you’re using; confirm Size matches what your tool is sending
  3. [Connection Manager] section — Find the matching Connection entry; check the path and parameters
  4. [Params] section — If a parameter isn’t showing right, find its ParamN entry and verify the Link Path

This is a powerful technique. The EDS contains the device’s complete configuration model in plain text. Most “why isn’t this working” problems become obvious in 5 minutes of reading.

How EDS relates to other CIP concepts

EDS files reference and document everything else:

  • Identity Object (Class 0x01) content → [Device] section
  • Assembly Object (Class 0x04) instances → [Assembly] section
  • Parameter Object (Class 0x0F) content → [Params] section
  • Connection Manager (Class 0x06) supported connections → [Connection Manager] section
  • Port Object descriptions → [Port] section
  • CIP Data Types used in parameters → type codes referenced in [Params]

This is why EDS files matter in the larger CIP ecosystem: they are the bridge between the device’s runtime objects and the configuration tool’s user interface. Without EDS, configuration tools would have to read the device’s objects byte by byte to discover its capabilities — which is slow and works only when the device is online.

Frequently asked questions

What is an EDS file in EtherNet/IP?

An EDS (Electronic Data Sheet) file is a plain-text ASCII file that describes a CIP device’s identity, assemblies, parameters, connections, and other attributes. Configuration tools like Studio 5000 read EDS files to populate their device catalogs and validate configurations. Every CIP-conformant device ships with an EDS file. The format is defined in ODVA’s CIP Networks Library Volume 1, Chapter 7.

What sections are in an EDS file?

An EDS file may contain the following sections (Volume 1 Table 7-3.1): [File] (required), [Device] (required), [Device Classification], [Params], [Assembly], [Connection Manager], [Port], [Modular], [Capacity], [Connection Configuration], [EventEnum], [SymbolicTranslation], [Internationalization], plus DeviceNet-specific sections like [IO_Info] and [EnumPar]. Most EDS files use [File], [Device], [Params], [Assembly], and [Connection Manager] at minimum.

How do I install an EDS file in Studio 5000?

In Studio 5000: Tools → EDS Hardware Installation Tool → Register an EDS file → browse to the .eds file → Next through the wizard. The tool validates the EDS and adds the device to its hardware catalog. The device then appears in I/O Configuration → Add Module. Older RSLogix 5000 uses the same procedure.

Where can I download EDS files?

The most reliable source is the device manufacturer’s website — look for the product page’s downloads section. Some devices serve their own EDS via HTTP at the device’s IP address. ODVA provides some EDS files but doesn’t catalog all devices. Match the EDS revision (MajRev/MinRev) to your device’s actual firmware revision to avoid electronic keying issues.

What does the [Device] section contain?

The [Device] section contains the device’s Identity Object information: VendCode (Vendor ID), VendName, ProdType (Device Type code), ProdCode (Product Code), MajRev (major firmware revision), MinRev (minor firmware revision), ProdName, and Catalog (part number). The combination VendCode + ProdCode + MajRev + MinRev is what electronic keying validates in Forward_Open Connection Paths.

What is the [Assembly] section in an EDS file?

The [Assembly] section describes the device’s Assembly Object instances. Each AssemN entry documents one assembly instance: its name, total size in bits, and member structure. Configuration tools use these entries to know which assembly instances exist on the device, how big each one is, and what data each member represents. Mismatches between EDS assembly sizes and Forward_Open connection sizes cause Extended Status 0x0109 errors.

What is the [Connection Manager] section in an EDS file?

The [Connection Manager] section lists the connections that can be opened to this device. Each ConnectionN entry describes one supported connection: trigger type, transport class, default Network Connection Parameters, minimum RPI, connection path (referencing which assemblies it uses), and display name. Common entries include “Exclusive Owner,” “Listen Only,” “Input Only,” and “Data.” Configuration tools use this to populate the user’s connection options.

Why does my EDS install fail with a syntax error?

EDS files have strict syntax — sections must start with bracketed keywords, entries must end with semicolons, strings must use double quotes, and each entry must have the correct number of fields for its keyword. Syntax errors usually come from manual editing or corrupted downloads. Re-download the EDS from the manufacturer rather than trying to fix it manually.

Can I edit an EDS file?

Technically yes — EDS files are plain text. But editing them is rarely a good idea. Edits can void manufacturer support, cause confusion for future maintenance engineers, and create subtle Forward_Open failures. The only legitimate cases are fixing obvious typos in display strings or generating custom EDS for development devices. For production issues, contact the manufacturer for an updated EDS rather than editing.

What is the difference between an EDS file and a GSD file?

EDS files describe CIP devices (EtherNet/IP, DeviceNet, ControlNet) and are defined by ODVA. GSD files (specifically GSDML in modern PROFINET) describe PROFINET devices and are defined by PI (PROFIBUS & PROFINET International). They serve the same conceptual role — letting configuration tools know how to talk to a device — but use different formats and reference different protocol object models. For more on the PROFINET side, see our PROFINET vs EtherNet/IP Comparison.

What does Extended Status 0x0117 have to do with EDS files?

Extended Status 0x0117 (Invalid produced or consumed application path) appears when a Forward_Open Connection Path references an assembly instance that doesn’t exist on the device. The fix is in the EDS — open the [Assembly] section and verify which instance numbers are actually defined. Configuration tools usually pull the right values automatically when an EDS is properly registered, but custom code or older configurations can use wrong values.

Where can I find the official EDS file specification?

The EDS file format is defined in ODVA’s CIP Networks Library Volume 1: Common Industrial Protocol (CIP) Specification, Chapter 7 (Electronic Data Sheets). The current edition is 3.3 (2007). ODVA members can access the full specification at odva.org. DeviceNet-specific EDS sections are documented in Volume 3 (DeviceNet Adaptation).

Author: Zakaria El Intissar

I'm an automation and industrial computing engineer with 12 years of experience in power system automation, SCADA communication protocols, and electrical protection. I build tools and write guides for Modbus, DNP3, IEC 101/103/104, and IEC 61850 on ScadaProtocols.com to help engineers decode, analyze, and troubleshoot real industrial communication systems.