A CODESYS V3.5 project reportedly generated device.xml after importing an EtherCAT ESI file. After user-specific parameters were added to that XML and it was imported again, the parameters did not appear, and no expected Parameters tab was visible. The evidence confirms the symptom but does not establish whether device.xml is an editable device description source, a generated artifact, or the correct extension point.
Separate Confirmed Behavior from Assumptions
| Item | Evidence status | Engineering decision |
|---|---|---|
| Environment | CODESYS V3.5 | Keep testing within the same installed version and device repository. |
| Initial input | EtherCAT ESI file | Retain the original ESI as the baseline. |
| Observed output | A file named device.xml was created |
Do not assume this generated file is intended for manual modification. |
| Modification | User-specific parameters were added to device.xml
|
Validate whether the added XML is part of the schema that CODESYS processes. |
| Result | Parameters were not visible after reimport | Treat successful import and parameter presentation as separate checks. |
| Expected interface | A Parameters tab was expected | Do not treat the tab as guaranteed without confirming the required description structure. |
Isolate the ESI-to-Device-Description Path
The central ambiguity is whether CODESYS consumes the manually edited device.xml during reimport. A file being created during ESI import does not, by itself, prove that editing and reimporting that generated file can extend the device model. The missing parameters could therefore reflect an unsupported edit path, unrecognized XML placement, or failure to replace the previously imported description; the evidence does not distinguish among these hypotheses.
- Preserve the original ESI file and the unmodified generated
device.xmlas control artifacts. - Import the unmodified description and record the device views that CODESYS V3.5 presents.
- Apply one parameter-only change, reimport through the same path, and confirm that CODESYS is processing the changed file rather than an existing repository copy.
- Compare the device views with the control result. If nothing changes, stop editing parameter content and first verify that the modified description is actually being selected.
Define the Verification Criteria
Do not use import completion alone as proof that the customization worked. Verification requires the modified parameter to appear in the device interface and retain its configured value after the project or device is reopened. If the parameter remains absent, return to the original ESI and obtain the applicable CODESYS device-description schema or supported extension procedure before making further XML changes.
The available evidence provides no schema element, namespace, package layout, error message, or confirmed workaround. It therefore cannot support a specific XML correction or a claim that manually modifying device.xml is either supported or prohibited.
FAQ
Why are custom EtherCAT parameters missing in CODESYS V3.5?
The reported parameters were added to device.xml but did not appear after reimport. First verify that CODESYS is processing the modified file and that its parameter structure belongs to the supported device-description schema.
Can I manually edit the device.xml created from an EtherCAT ESI file?
The evidence does not confirm that the generated device.xml is an editable extension point. Preserve the original ESI and validate the supported CODESYS device-description workflow before relying on manual edits.
Should CODESYS show a Parameters tab after importing device.xml?
A Parameters tab was expected but was not visible in the reported CODESYS V3.5 case. Its presence cannot be guaranteed without evidence that the imported description contains a recognized parameter definition.