Device Configuration

Understanding EDS & XML Device Files: Configuring PLCs and Field Devices

Every time you add a drive, sensor, or I/O module to your PLC network, you need a device file. Learn what EDS, GSD, GSDML, and IODD files are, how to read them, and how they configure your fieldbus devices.

2026-03-08 · 17 min read

EDS
XML
GSD
GSDML
IODD
Device Configuration

What a device description file is

When you add a VFD, an I/O module or a smart sensor to your PLC network, the engineering software has to know what data the device sends, which parameters you can configure and which communication settings it supports.

A device description file holds those answers. It is a standardized text or XML file, supplied by the device manufacturer, that describes the device's communication interface. Without it, your PLC does not know how to talk to the device. Each fieldbus has its own format:

File Type	Protocol	Format	Used By
EDS	EtherNet/IP, DeviceNet	INI-style text	Allen-Bradley, ODVA devices
GSD	PROFIBUS DP	Text (key=value)	Siemens, PROFIBUS devices
GSDML	PROFINET	XML	Siemens, PROFINET devices
IODD	IO-Link	XML	IO-Link sensors/actuators
ESI	EtherCAT	XML	Beckhoff, EtherCAT devices

EDS files for EtherNet/IP

An EDS (Electronic Data Sheet) file describes a device on an EtherNet/IP or DeviceNet network. It is a plain-text file with an INI-like structure, split into bracketed sections:

The sections of an EDS file

$ EDS File for ACME VFD Model 500
$ Created: 2026-01-15
$ Vendor: ACME Drives Inc.

[File]
    DescText = "ACME VFD Model 500 AC Drive";
    CreateDate = 01-15-2026;
    CreateTime = 10:30:00;
    Revision = 1.2;

[Device]
    VendCode = 999;               $ Vendor ID assigned by ODVA
    VendName = "ACME Drives";
    ProdType = 2;                 $ Product type: AC Drive
    ProdTypeStr = "AC Drive";
    ProdCode = 500;
    ProdName = "VFD Model 500";
    Catalog = "VFD-500-EIP";

[Device Classification]
    Class1 = EtherNetIP;

[Connection Manager]
    Connection1 =
        04040002,                 $ Trigger & transport
        44640405,                 $ Connection parameters
        ,Assem101,                $ Input assembly (from drive)
        ,Assem102,                $ Output assembly (to drive)
        ,Assem103;                $ Config assembly

Assemblies: the I/O data layout

An assembly defines the I/O data layout, meaning which bytes the PLC and the device exchange on every cyclic I/O update. The connection in [Connection Manager] above points at three of them:

[Assembly]
    Assem101 =                    $ Input Assembly: Drive → PLC
        "Input Data",             $ Name
        ,                         $ Path
        16,                       $ Size in bytes
        0x0004,                   $ Descriptor
        ,                         $ Reserved
        2,                        $ Number of members
        StatusWord,               $ Member 1: Drive status (WORD)
        ActualSpeed;              $ Member 2: Speed feedback (REAL)

    Assem102 =                    $ Output Assembly: PLC → Drive
        "Output Data",
        ,
        8,                        $ Size in bytes
        0x0001,
        ,
        2,
        ControlWord,              $ Member 1: Drive command (WORD)
        SpeedReference;           $ Member 2: Speed setpoint (REAL)

What the assemblies become in your PLC code

Each assembly member ends up as a tag at a fixed byte offset. Read the offsets carefully: in this example the WORD sits in bytes 0-1, but the REAL starts at byte 4, not byte 2.

// The EDS file tells us:
// Input assembly (101): 16 bytes
//   Bytes 0-1: StatusWord (WORD)
//   Bytes 4-7: ActualSpeed (REAL)
// Output assembly (102): 8 bytes
//   Bytes 0-1: ControlWord (WORD)
//   Bytes 4-7: SpeedReference (REAL)

PROGRAM EDS_DataMapping
VAR
    // These tags map to the assembly data
    // In Allen-Bradley: auto-created from EDS import
    // In CODESYS: manually mapped to EtherNet/IP adapter
    
    Drive_StatusWord    : WORD;     // Input, bytes 0-1
    Drive_ActualSpeed   : REAL;     // Input, bytes 4-7
    Drive_ControlWord   : WORD;     // Output, bytes 0-1
    Drive_SpeedRef      : REAL;     // Output, bytes 4-7
END_VAR

The parameters section

An EDS file also defines configurable parameters (CIP attributes), which you read and write with explicit messaging rather than in the cyclic I/O:

[Params]
    Param1 =
        0,                        $ Reserved
        ,,                        $ Link/size
        0x0006,                   $ Descriptor (read/write)
        0xCA,                     $ Data type: REAL
        4,                        $ Data size
        "Motor Rated Current",    $ Parameter name
        "A",                      $ Units
        "0.1",                    $ Minimum value
        "999.9",                  $ Maximum value
        "12.5",                   $ Default value
        ,,;                       $ Reserved

    Param2 =
        0,,,
        0x0006,
        0xC8,
        4,
        "Acceleration Time",
        "s",
        "0.1",
        "600.0",
        "10.0",
        ,,;

GSDML files for PROFINET

A GSDML (General Station Description Markup Language) file is the XML description of a PROFINET device. It carries more detail than an EDS file:

<?xml version="1.0" encoding="utf-8"?>
<ISO15745Profile>
  <ProfileHeader>
    <ProfileIdentification>PROFINET Device Profile</ProfileIdentification>
    <ProfileRevision>1.00</ProfileRevision>
    <ProfileName>Device Profile for ACME Sensor</ProfileName>
  </ProfileHeader>

  <DeviceIdentity VendorID="0x0999" DeviceID="0x0042">
    <InfoText TextId="DeviceName">ACME Temperature Transmitter TT-200</InfoText>
    <VendorName Value="ACME Instruments"/>
  </DeviceIdentity>

  <!-- Module Description: defines I/O data structure -->
  <ModuleInfo>
    <Name TextId="Mod1">4-20mA Temperature Module</Name>
    <OrderNumber Value="TT-200-PN"/>
  </ModuleInfo>

  <!-- Submodule: actual I/O data -->
  <SubmoduleItem ID="1" SubslotNumber="1">
    <IOData>
      <Input>
        <DataItem DataType="Float32" TextId="Temperature">
          <!-- 4 bytes: REAL temperature value -->
        </DataItem>
        <DataItem DataType="Unsigned8" TextId="Status">
          <!-- 1 byte: sensor status -->
        </DataItem>
      </Input>
    </IOData>
  </SubmoduleItem>

  <!-- Parameters configurable via record data -->
  <RecordDataList>
    <ParameterRecordDataItem Index="100">
      <Name TextId="UpperRange">Upper Range Value</Name>
      <Ref DataType="Float32" Default="200.0"/>
    </ParameterRecordDataItem>
    <ParameterRecordDataItem Index="101">
      <Name TextId="LowerRange">Lower Range Value</Name>
      <Ref DataType="Float32" Default="0.0"/>
    </ParameterRecordDataItem>
  </RecordDataList>
</ISO15745Profile>

The GSDML elements a programmer reads

You do not need to read the whole file. These are the elements that tell you what ends up in your program:

XML Element	What It Tells You
DeviceIdentity	Vendor ID and Device ID for hardware catalog
ModuleInfo	What slots/modules the device supports
SubmoduleItem / IOData	The I/O data layout: sizes, types, order
RecordDataList	Parameters you can read/write during commissioning
InterfaceSubmoduleItem	Network settings (IP, ports)

IODD files for IO-Link sensors

An IODD (IO Device Description) file describes an IO-Link sensor or actuator. Process data is exchanged every cycle, while parameters such as a switching point are read and written by acyclic access:

<?xml version="1.0" encoding="utf-8"?>
<IODevice xmlns="http://www.io-link.com/IODD/2010/10">
  <DocumentInfo version="1.1"/>
  
  <ProfileBody>
    <DeviceIdentity vendorId="999" deviceId="12345">
      <VendorName>ACME Sensors</VendorName>
      <DeviceName>ProxSwitch PS-100</DeviceName>
    </DeviceIdentity>

    <!-- Process Data: exchanged every cycle -->
    <ProcessDataCollection>
      <ProcessData id="PD_In">
        <ProcessDataIn bitLength="16">
          <Datatype xsi:type="UIntegerT" bitLength="16"/>
          <Name>Distance</Name>
          <Description>Measured distance in 0.1mm</Description>
        </ProcessDataIn>
      </ProcessData>
    </ProcessDataCollection>

    <!-- Parameters: read/write via acyclic access -->
    <ParameterCollection>
      <Parameter id="P1" index="64" subindex="0">
        <Name>Switching Point 1</Name>
        <Datatype xsi:type="UIntegerT" bitLength="16"/>
        <DefaultValue>1000</DefaultValue>
        <ValueRange lowerValue="0" upperValue="5000"/>
      </Parameter>
      <Parameter id="P2" index="65" subindex="0">
        <Name>Hysteresis</Name>
        <Datatype xsi:type="UIntegerT" bitLength="16"/>
        <DefaultValue>50</DefaultValue>
      </Parameter>
    </ParameterCollection>
  </ProfileBody>
</IODevice>

Using a device file, step by step

From download to tags

Download the EDS, GSDML or IODD from the manufacturer's website. It is usually in the product's support or downloads section.

Install it in your engineering software:

- TIA Portal: Options → Manage GSD files → Install → Browse to GSDML - Studio 5000: Tools → EDS Hardware Installation Tool → Add - CODESYS: Tools → Device Repository → Install

Add the device to the hardware configuration. It now appears in the hardware catalog, so drag it into your project's network view.

Map the I/O. The software creates I/O tags from the assembly or module definitions in the device file, and those tags are the variables you use in code.

Set the device-specific parameters defined in the device file, such as scaling, filtering and communication settings.

// After importing EDS and adding device to hardware config:
// The I/O tags are automatically created:

// EtherNet/IP (from EDS assemblies)
Drive1_Input.StatusWord       // Mapped from Assembly 101
Drive1_Input.ActualSpeed      // Mapped from Assembly 101  
Drive1_Output.ControlWord     // Mapped to Assembly 102
Drive1_Output.SpeedRef        // Mapped to Assembly 102

// PROFINET (from GSDML submodules)
TempSensor_1.Temperature      // Mapped from Submodule 1, Float32
TempSensor_1.Status           // Mapped from Submodule 1, UINT8

// IO-Link (from IODD process data)
ProxSwitch_1.Distance         // Mapped from ProcessDataIn, UINT16

Common problems and fixes

Most device-file problems come down to a file that does not match the hardware in front of you, so check the revision and part number first:

Problem	Cause	Fix
Device not found after EDS install	Wrong revision or file corruption	Download fresh from manufacturer
I/O data size mismatch	Firmware version differs from EDS version	Match EDS revision to device firmware
Parameters won't write	Device in wrong mode	Check if device needs to be in config mode
"Module not compatible" error	GSDML for different hardware variant	Get the exact GSDML for your part number
Communication intermittent	IP conflict or wrong subnet	Verify network settings match GSDML defaults

The five file types side by side

File Type	Protocol	Key Content	Where to Get It
EDS (.eds)	EtherNet/IP	Assemblies, parameters, device identity	ODVA or manufacturer website
GSD (.gsd)	PROFIBUS	Modules, I/O config, baud rates	Manufacturer website
GSDML (.xml)	PROFINET	Submodules, I/O data, record parameters	Manufacturer or PI website
IODD (.xml)	IO-Link	Process data, parameters, diagnostics	IODDfinder (ioddfinder.io-link.com) or manufacturer
ESI (.xml)	EtherCAT	PDOs, SDOs, distributed clocks	Manufacturer website

A device file translates the manufacturer's hardware design into your PLC's software model. When the I/O size or a tag looks wrong during commissioning, open the file and read the assembly or submodule definition: it tells you the exact byte layout instead of leaving you to guess at the I/O mapping.