How to Verify a Device EDS or GSD File Version
A device that faults on connection, refuses to configure, or exposes the wrong parameters is often a version mismatch between the EDS or GSD file in your project and the firmware actually running in the field. The description file must match the device revision closely enough for the controller to trust it. This page walks the checks in order: read the real device revision, read the file's declared revision, and confirm the project references the right catalog entry before you chase a wiring ghost.
Verify EDS or GSD File Version in one line: To verify an EDS or GSD file version, read the actual major and minor revision from the physical device (its identity object or nameplate and firmware), then read the revision the description file declares, and confirm your engineering project references the catalog entry that matches. An EtherNet/IP EDS and a PROFINET GSD/GSDML each pin a device revision; if the project's file is older or newer than the field firmware, the device faults or mis-configures.
What You Need
You need read access to the physical device's identity - for EtherNet/IP the Identity object reports vendor, product code, and major/minor revision; for PROFINET the device reports its identity and you also have the nameplate and firmware version. You need the EDS file (EtherNet/IP) or GSD/GSDML file (PROFINET) currently registered in your engineering tool, and the vendor's catalog of available file versions so you can find the right one if the current file is wrong.
The core idea is that these description files are not generic - an EDS or a GSD is tied to a specific device revision and tells the controller what objects, modules, and parameters that revision exposes. The reference material on each file explains this: see what a GSD and GSDML file are for PROFINET, and note that EtherNet/IP EDS files play the equivalent role for CIP devices.
Read the Actual Revision From the Field Device
Start with ground truth: what revision is the device actually running. For an EtherNet/IP device, read the Identity object's major and minor revision, which is the authoritative number the controller compares against. For a PROFINET device, read its device identity and firmware version. Do not rely on the nameplate alone, because firmware can be updated in the field after the label was printed, and it is exactly that field firmware update that most often creates the mismatch you are chasing.
Note vendor ID and product code too, not just revision, because a description file is matched on all of these. A file for the right product but the wrong revision, or the right revision but a different product variant, will both cause trouble. Writing down the full identity (vendor, product code, major and minor revision) from the live device gives you the exact target the file must match.
Read the File's Declared Revision and Compare
Now read what the description file claims. An EDS file declares the device revision it supports in its identity/device section; a GSDML declares the device and its firmware/version attributes. Compare the file's declared revision against the field device's actual revision. A major-revision difference is the serious one: EtherNet/IP treats major revision as a compatibility boundary, so a device running one major revision generally needs a matching EDS, and the controller may reject a connection when they disagree. A minor-revision difference is usually more forgiving but can still expose the wrong parameter set.
Interpret the direction of the mismatch. If the field firmware is newer than the file, the project was built with an older description and does not know about newer parameters or objects. If the file is newer than the firmware, the project expects capabilities the device does not have. Either way the fix is to align them: obtain the file version that matches the field revision, or where appropriate update the device firmware to match a validated file - a decision that depends on your change-control and validation state.
Confirm the Project References the Right Catalog Entry
A correct file registered in the tool does no good if the project's device instance points at the wrong catalog entry. Open the device in the engineering project and confirm the catalog number and revision it is configured as exactly match the file you verified and the field device. It is common to find the right EDS registered but the device added from an older catalog entry, so the instance still carries the wrong revision. Re-select the device against the correct entry if needed and re-download.
After aligning, register or update the description file in the tool's library if it was missing or outdated, then confirm the device instance rebinds to it cleanly. Keeping the registered file, the project instance, and the field device all on the same revision is the whole job - a mismatch at any one of the three reproduces the fault.
Verifying the Result
Download the corrected configuration and confirm the device establishes its connection and comes online without a revision or configuration fault. Then spot-check that the parameters and modules the tool now shows match what the device actually exposes - a device that connects but shows parameters that do not exist or omits ones that do still has a lingering version gap. A clean connection plus a matching parameter set is the proof the versions are aligned.
Finally, record the verified triple - field firmware revision, description file version, and project catalog entry - in the machine documentation. The next person to replace this module or open this project needs to know which file version is correct, and a device that was silently on a mismatched-but-working combination is a trap waiting for the next download.
Common Mistakes
Trusting the nameplate over the live identity is the classic error, because a field firmware update changes the real revision without touching the label - always read the device's reported revision. The second is registering the right file but leaving the project instance on an old catalog entry, so the mismatch persists invisibly. The third is treating a major-revision gap as harmless: on EtherNet/IP the major revision is a compatibility boundary, not a cosmetic version number.
Also avoid grabbing any file with the right product name from a download page without checking its declared revision, and do not update device firmware to force a match without confirming the new firmware is validated for your application. When a device faults on connection, verify the version triple before you suspect cabling - a wrong EDS or GSD version looks a lot like a network problem but is fixed at the desk, not in the field.
Frequently Asked Questions
Why does a major-revision mismatch matter more than a minor one?
On EtherNet/IP the major revision is treated as a compatibility boundary. A change in major revision signals that the device's interface may have changed in a way that breaks an older description, so the controller generally needs an EDS whose major revision matches the device, and it may reject the connection outright when they disagree. A minor-revision difference usually indicates a compatible update and is more forgiving, though it can still expose or hide the wrong parameters. Match the major revision first; align the minor revision to be safe.
The device connects but shows the wrong parameters - is that still a version problem?
Very likely yes. A device can establish a connection while the engineering still holds a description file that does not match the running firmware, so the tool displays a parameter set that does not line up with what the device actually exposes - missing parameters, extra ones, or wrong defaults. Read the device's actual revision, read the file's declared revision, and confirm the project instance points at the matching catalog entry. Aligning all three usually resolves the parameter discrepancy that a bare connection test would miss.
Should I change the file version or the device firmware to fix a mismatch?
It depends on your change-control state. The lower-risk fix is usually to obtain the description file version that matches the firmware already validated in the field, so nothing on the running device changes. Updating device firmware to match a newer file is appropriate when the new firmware is itself validated for your application and you can follow proper change control, but firmware updates carry their own commissioning and validation burden. Align to the version that is already proven in service unless there is a specific reason to move the device.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.