Problem Details
A Productivity CODESYS P2CDS-622 controller that was previously discoverable stops appearing in the CODESYS Device tab scan. Observed symptoms in this failure pattern:
- The controller responds to
pingfrom a Windows command prompt on the wired Ethernet segment. - Standard scan in the CODESYS Communication Settings tab returns no nodes.
- Extended Scan (scan by explicit IP/name) also returns nothing.
- The AutomationDirect firmware update tool lists no devices, although the controller's Ethernet port LED flickers each time Refresh is pressed — proof that the tool's discovery frames physically reach the port and the link is up.
- Reconnecting over the USB programming port does not restore discovery.
- Setting the
P2CDS_NetConfig"adjust Ethernet settings" parameter back toTRUEand downloading has no effect.
Preceding events matter: the fault appeared after work on a CodeMeter licensing error that blocked download of a project containing a visualization, and after inspecting/modifying the certificate store on the controller. Both areas touch the runtime's communication and security layer, not just the project.
ping exercises ICMP in the controller's TCP/IP stack. CODESYS discovery uses the gateway's block-driver name-resolution service over UDP, and the firmware update tool uses its own UDP discovery. A device that pings but does not enumerate has an IP stack that is alive while the discovery/UDP path or the runtime's communication server is blocked, filtered, or shut down.Root Cause Candidates
| # | Candidate cause | Evidence that points to it |
|---|---|---|
| 1 | Windows firewall / third-party endpoint security blocking UDP broadcast and the CODESYS Gateway service | Ping (ICMP) allowed, UDP discovery silently dropped; both CODESYS and the vendor update tool fail identically |
| 2 | Wrong or extra network adapter used by the gateway (USB RNDIS adapter, VPN, Hyper-V/VMware virtual switch) | Broadcast leaves on an adapter that is not on the controller's subnet; PC has multiple active NICs |
| 3 | Controller security settings changed while inspecting certificates (encrypted-communication enforcement, device user management, or a damaged/expired device certificate) | Failure started immediately after certificate work; runtime refuses the unencrypted or unauthenticated channel and never answers the scan |
| 4 | PC and controller on different subnets/masks so the directed broadcast never reaches the port | Ping still succeeds if a route exists, but broadcast-based discovery does not cross subnets |
| 5 | Runtime not fully started (stopped/exception state) after the last power cycle, while the boot stack still answers ICMP | Device was powered down mid-troubleshooting; nothing answers on any tool |
| 6 | Duplicate IP address on the segment | Ping may be answered by the wrong host; scans find nothing at that address |
Diagnostic Sequence
-
Confirm what is actually answering the ping. With the controller powered off, ping the same address. If it still replies, another node owns that IP and the whole diagnosis has been chasing the wrong device. Also check
arp -aand compare the MAC to the label on the P2CDS-622. - Reduce the PC to a single active adapter. Disable Wi-Fi, VPN clients, Hyper-V/VMware/VirtualBox host adapters, and any USB RNDIS/USB-Ethernet interface you are not using. Multiple active interfaces are the most common reason a broadcast scan finds nothing while ping still works through the route table.
- Identify the second interface. If the adapter you configured is the USB network device created by the programming cable rather than the physical Ethernet NIC, discovery is being sent on the wrong path. Set the USB network adapter back to Obtain an IP address automatically (DHCP) and let the driver assign the link-local/host address it expects, then rescan.
-
Verify subnet math. Put the PC NIC on a static address in the same subnet as the controller, for example PC
192.168.1.50 / 255.255.255.0for a controller at192.168.1.x. Both must share the same mask. Discovery broadcasts do not route between subnets. - Disable Windows Defender Firewall on all profiles temporarily. If discovery immediately works, re-enable it and add inbound/outbound allow rules for the CODESYS Gateway executable and the firmware update tool, plus UDP on the private profile. Corporate agents (EDR, NAC) can drop broadcast without logging anything visible to the user.
- Check the CODESYS Gateway service. The gateway must be running locally and reachable. In the project's Communication Settings confirm the gateway shows a green indicator. Restart the gateway service, or restart the CODESYS IDE entirely, then scan again.
- Bypass discovery with Extended Scan by IP. In Communication Settings → Scan Network → Extended Scan, enter the controller's IP address directly. This uses a targeted request instead of a broadcast. Success here isolates the fault to broadcast filtering; failure here points at the runtime's communication server or the security layer.
- Cross-check with the firmware update tool. Run the vendor tool with the PC on the same subnet, all other adapters disabled, and the firewall off. The tool is the correct place to discover and reassign controller network settings when the CODESYS project cannot connect. The port LED flashing on Refresh confirms transmission; a still-empty list after firewall and adapter isolation shifts suspicion to the controller side.
- Direct point-to-point cable. Connect the PC NIC straight to the controller Ethernet port with no switch, no managed VLAN, and no IGMP/storm-control in the path. Managed switches with broadcast storm control or port isolation can suppress discovery traffic while forwarding unicast ICMP.
- Power cycle and observe status LEDs. Confirm the runtime reaches RUN/STOP rather than an exception or boot state. A runtime that never starts leaves only the low-level stack answering.
Solution Paths
Network-layer fixes
- One active NIC, same subnet, same mask, firewall off for the test, then scan.
- If the address is unknown or suspect, use the firmware update tool to discover and rewrite the controller's IP configuration rather than editing it from the offline project.
- Confirm no duplicate IP on the segment before assigning anything.
P2CDS_NetConfig behavior
P2CDS_NetConfig are applied on download only when the settings have actually changed. Toggling the adjust-Ethernet-settings parameter back to TRUE with identical addresses produces no change on the controller and no observable effect. To force a rewrite, change an address field to a known-good value and download, or configure the address with the firmware update tool instead.Also note the ordering trap: if the project cannot download at all (see the CodeMeter issue below), no P2CDS_NetConfig change will ever reach the controller. Fix the download path first.
Security / certificate layer
If the failure began while inspecting the device certificate store, treat this as the prime suspect:
- Check the CODESYS Security Screen for enforced encrypted communication and enforced signed downloads. If encryption enforcement is enabled on the device but the client cannot validate or obtain the device certificate, the connection is refused and the node behaves as if absent.
- Delete stale device certificates cached on the PC so a fresh certificate exchange occurs on the next connect attempt.
- If a device certificate was deleted or replaced with an invalid one, regenerate the runtime's self-signed certificate from the security screen once communication is restored over USB or a factory-reset path.
- Device user management: if a user database was created or a password enabled on the controller, connection prompts for credentials. A failed/cancelled login can present as "no device".
Last resort
If nothing enumerates on Ethernet, USB, or the firmware tool after the above isolation, perform the controller's documented reset-to-factory-defaults procedure to clear network configuration, user management, and certificates, then re-establish communication on a point-to-point cable before restoring the application. Back up the project source first; a factory reset removes the boot application.
The CodeMeter Download Error
The original trigger — a CodeMeter error that blocks download only when a visualization is present in the project — is a licensing/runtime-license container problem, not a network problem. Separate the two issues:
| Symptom | Layer | Action |
|---|---|---|
| Download fails only with a visualization object in the project | Runtime licensing (CodeMeter) | Verify the visualization license is present and valid in the controller's license container; verify the CodeMeter runtime service is installed and running on the PC |
| Device does not appear in scan | Discovery / gateway / security | Follow the diagnostic sequence above |
Restore discovery first. Licensing cannot be inspected or repaired on a controller you cannot connect to.
Verification
- Scan in Communication Settings and confirm the P2CDS-622 appears with the expected node name and IP.
- Confirm the connection indicator turns green and the device information page reports the runtime version and serial number.
- Run the firmware update tool once more — it should now list the same device, confirming both discovery paths work.
- Re-enable the Windows firewall and any disabled adapters one at a time, rescanning after each, to identify exactly which component was blocking discovery. Document the required firewall rule.
- Download the application and confirm RUN state, then address the visualization/CodeMeter licensing item as a separate work order.
Why can I ping my P2CDS-622 but not see it in the CODESYS scan?
Ping uses ICMP, while CODESYS discovery relies on the gateway's UDP broadcast on the selected network interface. A firewall rule, a second active adapter (VPN, Wi-Fi, USB RNDIS, virtual switch), or a switch suppressing broadcasts will block discovery while leaving unicast ICMP working.
What does Extended Scan do differently from a normal scan?
Extended Scan lets you enter the controller's IP address or node name directly, sending a targeted request instead of relying on a broadcast reply. If Extended Scan works and the normal scan does not, the fault is broadcast filtering on the PC or the switch, not the controller.
Why does changing P2CDS_NetConfig settings have no effect?
Those settings are applied on project download only when the values have actually changed. Re-setting the adjust-Ethernet-settings parameter to TRUE with the same addresses writes nothing. Change an address field, or use the firmware update tool to set the network configuration directly.
Can editing device certificates break CODESYS communication?
Yes. If encrypted communication is enforced and the device certificate is deleted, replaced, expired, or untrusted by the client, the runtime refuses the connection and the controller appears absent from the scan. Clear stale cached certificates on the PC and regenerate the device certificate.
The firmware update tool shows no devices but the Ethernet LED flashes on refresh. What does that mean?
The LED activity confirms the link is up and discovery frames are being transmitted from the PC. An empty list therefore points to the reply being blocked (firewall, wrong adapter, wrong subnet) or to the controller's runtime/communication server not answering — not to a cable or link fault.