A TwinCAT machine can fail at two separate points after configuration activation: the runtime can restart against the wrong Ethernet adapter, or the EtherCAT chain can remain in SAFEOP because the configured device list does not match the installed rack. Trace those paths separately: first the physical connection and selected network interface, then the master-to-slave configuration and license state.
Where does configuration activation stop along the machine path?
The EtherCAT data path starts at the controller’s EtherCAT master, passes through the Ethernet interface selected in the active configuration, travels over the cable to the first EtherCAT device, and continues through the configured device chain. The PLC runtime depends on that path being available after activation. If the project is bound to a different adapter than the cable uses, the master cannot use the intended path; a restart error after activation can therefore point to adapter selection rather than PLC logic.
A second failure point is farther downstream. The master may reach the bus but find that the actual rack differs from the configuration. One commissioning case stayed in SAFEOP until technicians found an extra module at the end of the rack and a license module whose part number and performance level did not match the machine. That is not the same failure as a wrong NIC: the first is a host-to-network binding problem, while the second is a physical-to-configured topology or licensing discrepancy.
| Observed stop | Path segment to inspect first | Deciding check |
|---|---|---|
| Runtime error after activation or restart | Controller to selected Ethernet adapter | Does the active EtherCAT master use the interface connected to the bus? |
EtherCAT chain remains in SAFEOP
|
Master to physical device chain | Does the configured device sequence match the installed rack, including the end device and license module? |
| License status is unclear | License storage or dongle to runtime | What state does the TwinCAT License Manager report for the installed license source? |
Do not treat a runtime restart error as proof of a bus fault, or SAFEOP as proof that the NIC is wrong. Check the interface binding first for a host-side stop; check the actual topology and license module when the master has reached the chain. Check: identify the failing segment before changing the project or replacing hardware.
Which Ethernet adapter should the EtherCAT master use?
Start with the physical layer. Trace the cable from the controller to the intended port, identify that port in the engineering station, and then compare it with the adapter assigned to the EtherCAT master in the configuration being activated. Machine builders that reuse a PLC or service project across machines can overlook this binding: the adapter may need to be selected again for a different target, and a forgotten selection can appear as a runtime error at restart.
Selecting an Ethernet adapter by name can make configuration reuse easier, but the name must be the same on every machine that uses the project. A name that differs between engineering or controller systems does not identify the same interface consistently. For CX PCIe interfaces, the PCIe address is already used to address the interface; Ethernet ports can be selected by name. Use the identity available for the interface type, then verify the effective binding in the activated configuration rather than relying on a remembered selection.
| Interface identity | Use and constraint | Commissioning check |
|---|---|---|
| Ethernet adapter name | Can be used for adapter selection; the name must match across machines using the configuration. | Compare the configured name with the actual interface connected to the EtherCAT cable on this target. |
| PCIe address on a CX interface | The CX PCIe interface is addressed through its PCIe address. | Confirm the active interface is the one connected to the intended EtherCAT segment. |
| MAC-based selection | Reselecting an adapter when changing PLC targets has been a commissioning failure point. | After changing target or activating a different configuration, inspect the selected interface again. |
Do not treat a network-interface naming option as a substitute for checking the actual path. A name can be consistent and still refer to the wrong physical port if the wiring or machine image differs. Check: with the configuration activated on the intended target, confirm the selected adapter is physically cabled to the EtherCAT chain before investigating slave states.
Does the configured EtherCAT topology match the wired rack?
Compare the physical chain with the project’s configured device list before changing runtime settings. A manually assembled rack configuration can preserve assumptions from another machine or bill of materials. In the reported case, the rack was built manually while the panel was being assembled rather than scanned from the bus; an additional module at the rack end was not reflected in the expected configuration. The discrepancy was not apparent from the initial cryptic runtime and EtherCAT errors.
- Inspect the installed chain from the master’s first connected device through its final module. Record the actual order and the identity shown for each device.
- Compare that observed chain with the configured EtherCAT device sequence and the machine’s bill of materials. Resolve extra, missing, or substituted devices rather than editing the configuration to make an error disappear.
- When the hardware and tooling allow it, scan the bus and compare the scan with the manually entered configuration. A scan provides a direct check against the installed chain; it does not decide whether a component is correct for the machine’s performance level.
- Repeat the comparison after panel changes or machine upgrades, especially when the project is reused across machines.
Keep the physical inventory separate from the engineering expectation. The rack can be wired correctly for one machine and still be wrong for a configuration copied from another machine. Check: the installed sequence and the active project sequence agree device for device, including the last module in the chain.
Is the license module the exact device specified for this machine?
Check the license module as a hardware identity and performance-level item, not just as a general license status. A module copied into a bill of materials from a different machine had the wrong performance level; the correct part number required the -0033 suffix. The rack remained in SAFEOP until the discrepancy was found in the License Manager. This makes the License Manager a necessary diagnostic stop when topology inspection does not explain the state.
Compare the installed module’s full part number with the machine-specific bill of materials, including suffixes. Then compare the required performance level with the project and intended machine. A part number that looks nearly identical can represent a different license level. Do not substitute a module from another machine based on appearance or a partial part number.
Keep the diagnosis evidence-based: an incorrect license module was part of the cause in this commissioning case, but SAFEOP can arise for other reasons in the device chain. Read the license state and the EtherCAT device state independently, and correct each mismatch at its source. Check: the License Manager recognizes the intended license arrangement and the installed module’s complete part number and level match the machine documentation.
Where does EtherCAT stop when the chain remains in SAFEOP?
Inspect the state of each device in order rather than relying on one summary runtime message. EtherCAT devices move through initialization and pre-operational states before reaching SAFEOP and then OP. In SAFEOP, the chain has not completed the transition required for normal operational I/O exchange. The state identifies the point to investigate; it does not by itself name the cause.
Find the first device that has not reached the state expected by the active machine configuration. Compare its identity and position with the scanned or observed topology, then check the adjacent physical connections and the configuration details for that device. If the last item or a license module is unexpected, revisit the rack and bill of materials. If the device sequence agrees, inspect the device’s detailed diagnostic state and the configuration values shown by TwinCAT rather than guessing from a generic error message.
A cryptic message is a prompt to collect the device-level status, not a reason to replace the controller or reinstall the engineering environment. Preserve the exact diagnostic text and the first device that fails the transition so that a change can be evaluated against the same baseline. Check: every expected device reports the operational state required by the machine; when the application requires cyclic I/O, verify the chain reaches OP.
Could license storage make the runtime fault look different?
Separate license source from license identity. Licenses stored on the controller have been reported to deactivate or become corrupt in the field, while license issues were reported less often when dongles were used. Remote service matters because a controller located far from the service team can be costly to return for reactivation. For either arrangement, inspect the actual license state in the License Manager before concluding that a runtime or bus failure is purely a hardware fault.
A dongle-based license may wait for its dongle rather than enter a missing-license state. Consequently, the absence of a missing-license entry is not sufficient proof that the expected license is ready for the runtime. Confirm that the intended dongle is present and that the License Manager shows the expected license state. For a controller-stored license, check the on-device state directly and record any activation or corruption condition before attempting recovery.
Do not use repeated configuration activation as a licensing test. First establish which license source the machine uses, then check its state and relationship to the installed module. That prevents a silent licensing condition from being mistaken for an adapter or EtherCAT topology fault. Check: verify the exact license source and readiness in the License Manager, including dongle presence where applicable.
Did a TwinCAT version or package migration change the failure?
When service work includes a software change, record the engineering environment, target runtime, compiler compatibility, and installed package state before changing the EtherCAT configuration. A separate reported service issue involved the Remote Manager for 4020 and a compiler incompatibility; updating older machines to 4024 was used as a workaround and added four to eight hours of service work. Treat that as a version-specific path to check, not as a universal remedy for an adapter or SAFEOP fault.
A migration from 4024 to 4026 has also been associated with package installation or upgrade failures, including installs that appeared to fail silently. In that case, the command-line package-manager view exposed the problem. If the symptom started during an upgrade, inspect the installed package state and use the command-line view to reveal installation errors before repeating the migration. Do not assume that an upgrade completed merely because the normal installation path returned without a clear failure.
Keep version changes isolated from topology corrections. If the project uses TwinCAT HMI, regression-test its objects after a version update; broken HMI objects have been reported across updates. Establish a working baseline for the current target first, then evaluate the software migration as a separate change. Check: confirm the expected runtime and package state are installed and compatible with the service project before reactivating the EtherCAT configuration.
How can you prove the active configuration works end to end?
Recheck the data path from the host interface to the PLC application after correcting the adapter, rack, or license mismatch. A passing engineering compile alone does not prove that the active runtime uses the correct port or that the installed devices match the project. Verify each hop using the target machine and the configuration that will remain in service.
- Trace the cable to the intended controller port and confirm the active EtherCAT master is bound to that adapter. For adapter selection by name, verify the name matches the target machine; for a CX PCIe interface, verify the intended PCIe-addressed interface.
- Compare the active configured device order against the actual rack, including the end module and the full license-module part number and performance level.
- Check the License Manager for the expected license readiness. If the machine uses a dongle, confirm the dongle is present rather than relying only on a missing-license message.
- Activate the corrected configuration and restart the runtime. Inspect the master and each device state, identify any first device that fails its expected transition, and resolve that device-specific fault before proceeding.
- Run the intended PLC I/O function and confirm the expected devices exchange data in the operational state required by the machine.
Final check: capture the selected adapter, observed rack sequence, license state, runtime result, and EtherCAT state from the same active configuration; return the machine only after the intended path reaches the required operational state and the PLC I/O behaves as expected.
Which TwinCAT adapter and SAFEOP questions come up most?
Can I select an EtherCAT adapter by name?
Yes. Keep the adapter name consistent on every machine using the project, then verify the active binding after changing targets or activating another configuration.
Should I select a CX PCIe interface by name?
CX PCIe interfaces are addressed through their PCIe address. For Ethernet ports, adapter names can be used, but check the actual port connected to the EtherCAT chain.
Can an extra rack module keep TwinCAT in SAFEOP?
A configured-to-physical rack mismatch was found in a machine that remained in SAFEOP. Compare the active device sequence with the installed chain, including the last module.
Does a license dongle prevent every TwinCAT license problem?
No. Dongle-related license issues were reported less often, but confirm dongle presence and license readiness in the License Manager rather than treating the dongle as a guarantee.
What is the final check before returning the machine?
With the final active configuration, verify the selected adapter, actual rack sequence, license readiness, runtime restart, and required EtherCAT operational state; then confirm the PLC exchanges the expected I/O data.