Resolving Sysmac Studio CIP Safety EDS File Missing Errors

Problem Overview

Engineers transferring an Omron Sysmac Studio project that contains a CIP Safety configuration frequently encounter a state where the standard PLC program opens without issue, but the safety task is reported as missing, unreadable, or unloadable. The visible symptom is a dialog stating that the safety device configuration cannot be resolved, often accompanied by a request for a specific Electronic Data Sheet (EDS) file that matches the safety slave. This is fundamentally different from the well-documented EtherCAT ESI handling, and it requires a manual EDS placement strategy that Sysmac Studio does not automate through its import dialog.

The failure mode is platform-specific to CIP Safety devices (e.g., ABB CIP Safety robot controllers, safety I/O terminals, safety drives, third-party safety slaves) configured against an NX-SL5700 or NX-SL5500 Safety Control Unit on an EtherNet/IP safety network. The same workflow also applies to NX-SL3300 and earlier CIP Safety capable controllers when safety slaves are present in the project.

Symptoms and Error Surfaces

• Sysmac Studio opens the .smc or .csm project but the Safety Task tree node is empty or displays a red warning icon.
• Build produces an error such as: "The device configuration cannot be loaded because the required EDS file is not installed."
• Compare/Merge and online edit functions are unavailable on safety programs until the safety EDS is matched.
• The Device List in the Safety Device Configuration shows the slave as "Unknown" or with a generic placeholder name.
• Going online results in a verification error because the offline EDS revision does not match the device revision embedded in the project.

Root Cause Analysis

Sysmac Studio treats CIP Safety EDS files as a pre-installation requirement rather than a self-contained asset of the project file. When the original programmer saved the project, the safety slave device was resolved against a specific EDS revision installed locally on the source workstation. If that exact EDS revision is not present on the new workstation at the moment the project is opened, Sysmac Studio cannot reconstruct the safety device's parameter set, connection path, or assembly layout.

The behavior is documented in the Omron KB: Unable to open SYSMAC CIP Safety Program article, which states explicitly: "SYSMAC Studio requires safety EDS files to be pre-installed when opening a safety program for NX-SL5700 or NX-SL5500 with custom EDS files." Unlike EtherCAT ESI files — which are embedded into the project and can be carried across installations — CIP Safety EDS files are referenced from the local EDS registry. The project only stores the device revision and vendor/content identifiers; the full parameter, diagnostic, and assembly definitions live in the EDS on disk.

This is the underlying reason engineers observe "This is one of the big failures of Sysmac Studio. It can handle including EtherCAT ESI files with ease, why can't it deal with CIP Safety EDS files in the same way." The platform limitation is structural, not user error.

Sysmac Studio Version Compatibility

EDS file handling and CIP Safety stack validation have been incrementally hardened between Sysmac Studio releases. The version on which the project was originally created and the version on which it is being opened both matter.

If the project was originally saved on a version newer than the one currently installed, the safety task cannot be downgraded without an explicit export. Always confirm both the Sysmac Studio version and the controller firmware revision on the source machine before attempting migration.

Required Files and Registry Layout

The CIP Safety EDS files must reside in the same absolute path used by the original workstation. Sysmac Studio resolves safety EDS references by canonical path rather than by querying the global EDS registry used by third-party tools, which is the single most common reason manual copying is required.

Resolution Procedure

1. Identify the required EDS. On the source workstation, open the same project and navigate to Configurations and Setup → Safety Device Configuration. Right-click the affected safety slave and select Properties. Record the Vendor ID, Device Type, Product Code, and Major/Minor Revision. These four identifiers uniquely fingerprint the EDS revision needed.
2. Locate the EDS on the source machine. Browse the paths in the table above until the slave's catalog entry is found. EDS files are standard .eds text files with CIP-compatible sections, but they must match the exact revision recorded in the project.
3. Copy the EDS to the destination. Transfer the file to the identical absolute path on the target workstation. If directory layouts differ, replicate the structure exactly. For multi-vendor safety slaves, copy each vendor's EDS into the CIPSafety folder.
4. Refresh the EDS index. Close Sysmac Studio, delete the user cache at %APPDATA%\OMRON\Sysmac Studio\SafetyEDS\, then restart Sysmac Studio. This forces a rescan of the safety EDS repository on next project open.
5. Verify revision binding. Re-open the project. The Safety Task should now display its full structure. In the Safety Device Configuration, confirm that the slave shows a known vendor name and that the connection assembly parameters are populated.
6. Validate safety signature. If the project carries a locked safety signature, Sysmac Studio will still display the program but may mark parameters as read-only until the safety signature is unlocked by an authorized user with the correct password.
7. Synchronize and verify online. Connect to the controller, perform a Compare, and resolve any parameter differences before attempting a download.

Verification Checklist

• Safety Task tree node displays all program POUs (Program Organization Units) without warning icons.
• Safety Device Configuration enumerates each slave with vendor name, product name, and revision matching the source workstation.
• Build completes with zero errors and zero warnings related to EDS or device resolution.
• Going online prompts only a standard safety lock/unlock dialog, not an EDS-resolution error.
• Safety I/O assemblies show populated connection points in the I/O Map view.

NX-SL5700 / NX-SL5500 Context

The NX-SL5700 and NX-SL5500 Safety Control Units are CPU-class safety controllers that share the standard NX-series backplane but implement CIP Safety on EtherNet/IP (SL5500) and dual-protocol CIP Safety over EtherNet/IP and CIP Safety on EtherCAT (SL5700). They require a Safety CPU Unit, a Safety I/O System, and explicit binding of each safety slave's EDS revision in the offline project. For full hardware and commissioning details, consult the NX-series Safety Control Unit User's Manual (Z930).

Key safety parameters stored in the EDS include:

• TUNID (Target Unique Node ID) and SNN (Safety Network Number) defaults.
• Produced and consumed assembly instances with safety connection format codes.
• Vendor-specific configuration assembly parameters.
• Required safety I/O connection timeout multiplier and RPI limits.

If the EDS revision in the project is older than what the physical slave accepts, the controller will reject the safety connection at runtime with a CIP Safety error code (commonly 0x01 General Status with extended codes in the 0x8000–0x80FF range indicating configuration mismatch). The EDS revision must therefore be both installed locally for offline use and uploaded from the physical device before download.

Field-Proven Caveats

• Revision drift is silent: Sysmac Studio does not warn when the installed EDS is newer than the revision recorded in the project. The project will appear to load but parameter values may differ.
• Multi-vendor robots: For an ABB CIP Safety robot, the EDS is typically shipped with the robot's CIP Safety option package. If you only have the standard CIP EDS (visible in the EDS library for non-safety services), you are missing the safety-specific variant. The non-safety EDS will allow the standard logic to load but will not satisfy the safety device configuration.
• Trial license limitations: Sysmac Studio trial installations can open safety projects but may not allow program modification or safety-signature operations. Confirm the license state on both source and destination machines before planning a code change.
• Path case sensitivity: Windows paths are case-insensitive but Sysmac Studio's safety EDS cache has been observed to bind case-sensitively on some 1.6x builds. Match the source path's casing exactly.
• User Account Control (UAC): Writing into Program Files (x86) requires elevated privileges. Run Sysmac Studio as administrator or place the EDS in the per-user %APPDATA% location as a fallback.

Troubleshooting Matrix

Best Practices for Multi-Machine Engineering Teams

1. Maintain a versioned, centralized repository of CIP Safety EDS files keyed by Vendor ID and revision. Treat EDS files as controlled engineering artifacts with check-in/check-out.
2. Document the Sysmac Studio version and controller firmware version inside the project documentation, so that any future workstation re-creation can match the environment exactly.
3. Use a workstation provisioning script that copies the canonical EDS folder set, ensuring every engineering seat loads projects without manual intervention.
4. Schedule periodic upgrades to the current Sysmac Studio release to stay inside the support window; projects older than two major revisions may require manual data conversion.
5. Before opening any safety project on a new machine, verify both the CIPSafety folder contents and the %APPDATA% cache state.