Fix CODESYS PROFINET ports not detected after a ping

Why does the device answer ping but the CODESYS scan finds no ports?

Because the two tests use different layers. Ping tests IP. The PROFINET scan uses DCP, a link-layer protocol whose identify request is a raw Ethernet frame of EtherType 0x8892 sent to the multicast address 01:0E:CF:00:00:00. Ping speaks ICMP over IP and never touches this path. DCP is the protocol that identifies every PROFINET device on the wire and assigns its station name and IP address; it is confined to the local network segment. The controller runtime sends the identify request as that raw frame, and every PROFINET device answers with its station name, its IP address and its vendor and device ID.

On a Windows-based runtime, those frames leave the PC through a packet-capture driver bound to one adapter. When that binding is missing or pointed at the wrong adapter, the frames never reach the cable. IP still works, so ping succeeds, and the scan returns nothing. The device is reachable and invisible at the same time, and both readings are correct.

How do I capture the discovery frames to see which side fails?

Run Wireshark on the adapter cabled to the device. Set the display filter to pn_dcp, start the capture, then trigger the device scan in CODESYS and read the frame counter. Two frames within 5 seconds mean discovery works. Zero frames means the request never left the PC. The whole test takes about a minute and it decides which fix you apply.

1. Open Wireshark and select the physical adapter the PC uses to reach the device.
2. Set the display filter to icmp and ping the device once. The replies must appear; this confirms you are capturing on the right adapter.
3. Switch the filter to pn_dcp and start the capture.
4. Trigger the device scan in CODESYS and watch the frame counter for the next 30 seconds.

A working exchange looks like one Identify Request to 01:0E:CF:00:00:00 from the PC and one Identify Response from the module, carrying the station name. Expect the counter to climb by at least two frames per scan: your request and the module's answer.

Which reading points to which fault?

Four readings cover this fault. No DCP frame on the wire points at the PC side. A request without a response points at the path between them. A device found without its port submodules points at the device description file. Sort your case into one of these before changing anything.

• Ping answers, scan silent, zero pn_dcp frames. The runtime is sending nothing on this adapter. The capture driver is missing, the PROFINET runtime components are not enabled, or the controller is bound to another adapter, often a VPN or virtual one. The fix is in the two sections below on the adapter and the configuration file.
• Identify request on the wire, no response. The frame dies between the PC and the device. Check the cable, check that the PC and the device sit in the same VLAN, and check whether the switch filters unknown multicast. PROFINET device ports run at 100 Mbit/s, so confirm the link negotiated 100 Mbit/s and not 10 Mbit/s. For the first test, put both on one plain unmanaged switch.
• Device found, interface or port submodules missing in the device tree. Discovery works. The imported GSDML revision does not match the installed module, so the tree is built without the ports. The fix is in the description section below.
• Device found with a name or IP mismatch message. The station name in the response differs from the configured name. Assign it through the device scan and compare again.

Recommendation: let the pn_dcp counter choose the branch before you touch the project. Zero frames on the wire means the fault is on the PC side, in the driver and the adapter binding, so work the two sections below in order. A request with a response and still no ports means the fault is in the device description, so work the GSDML section instead.

How do I bind the runtime to the right adapter?

Install the WinPcap driver the runtime configuration pages call for. Disable VPN and virtual adapters, then set the PROFINET controller to the one physical adapter cabled to the device, named exactly as the system names it. The binding, and nothing in the project, is what puts the frames on the wire.

1. Install the WinPcap driver named in the CODESYS runtime configuration instructions. Plain Npcap in its default mode is reported not to serve this runtime; if an Npcap install with its WinPcap-compatible option is already on the PC, test it once and fall back to WinPcap if the scan still sends nothing.
2. Open Wireshark and read the adapter list. The physical adapter must appear as a capturable interface; if it does not, fix the driver install first.
3. Note the exact system name of the physical adapter, for example Ethernet 2. Put VPN tunnels, virtual switches and Wi-Fi out of reach of the scan: a scan that has to cross a VPN tunnel or a USB-Ethernet adapter fails exactly this way, and device scans versus pings over VPN and USB-Ethernet adapters works through those cases.
4. In the runtime configuration, point the PROFINET controller at that adapter name, typed exactly as the system prints it.
5. Restart the runtime and repeat the capture: the Identify request must now appear on that adapter when you scan.

Where is the runtime configuration file and what changes in it?

It is the configuration file of the runtime itself, normally CODESYSControl.cfg, edited while the runtime is stopped. The Runtime Configuration pages in the CODESYS online help, under Fieldbus Support 3.5.17.0 and CODESYS PROFINET, print the exact component entries and adapter keys to add. It is a file of the runtime, so it is not inside the project tree.

1. Find the file. On a Windows runtime it sits in the runtime's installation or working directory. On a hardware controller it sits in the controller's file system, reached with the vendor's file-transfer tool or the CODESYS device file view.
2. Stop the runtime and keep a copy of the original file. Check if a CODESYS runtime is running or stopped shows how to read its state before you edit.
3. Enable the PROFINET runtime components the help pages name, including the network adapter entry, and set the adapter to the name from the previous section. Copy the entries from those pages themselves; the same pages state that the runtime components must be enabled. A component that fails to load shows up in the web UI first, as Controller runtime missing from the web UI after install describes.
4. Restart the runtime, log in, and download the application, then run the scan again.

Do this with the machine in a safe state: while the runtime is stopped it exchanges no IO data with the device, so schedule the restart for a stop in production, not mid-cycle.

Why does the device appear in the scan but without its ports?

Because the port submodules come from the device description file, the GSDML. When the imported revision does not match the installed interface module, CODESYS builds the device tree without the ports, and a working scan changes nothing about that tree. Discovery and description are two separate systems, and this reading means only the second one is broken.

1. Get the GSDML for the exact interface module and its revision, import it into the device repository, and add the device again from the repository.
2. Read the station name out of the DCP Identify Response in your capture and compare it with the name in the device configuration, character for character. If they differ, assign the name through the device scan and compare again.
3. If the runtime refuses the name assignment with a permission error, that is a separate fault with its own fix, in Fix a PROFINET IP change not enabled error.

What does the whole fix look like as one worked example?

Take an engineering PC at 192.168.0.50 with two adapters, a VPN tunnel named Ethernet 7 and the physical adapter Ethernet 2 cabled to an interface module at 192.168.0.10 with mask 255.255.255.0: the module answers ping, the scan stays empty, and the fix takes four steps. Both addresses sit in the same subnet, so IP was never the problem.

Capture first, with a ping running at one request per second: in 30 seconds the filter icmp counts 30 replies and pn_dcp counts 0. Thirty replies show the module hears the PC; zero DCP frames show the runtime never sent any, so the fault is on the PC side and the project file is innocent.

The adapter list shows why: the runtime configuration has the controller bound to the VPN adapter Ethernet 7, so every identify request went into the tunnel. Install WinPcap, stop the runtime, and in CODESYSControl.cfg enable the PROFINET components the help pages name with the adapter set to Ethernet 2. Restart and log in. Rescan with the capture running: the pn_dcp counter climbs by 2, one Identify Request to 01:0E:CF:00:00:00 and one response carrying station name remote-io-1 at 192.168.0.10. The configured name matches, and the device tree now shows the interface module with both port submodules, so the two ports the project needs are there to wire into the IO configuration.

How do I confirm the fix end to end?

Four checks in order: the runtime log loads the PROFINET component with no adapter error, the pn_dcp capture shows a request and a response on every scan, the scan lists the device with the name and IP you set, and the device tree shows the interface and port submodules with no mismatch markers. All four together, and only all four, close the fault.

• Runtime log: the PROFINET component loads after the restart with no adapter or driver error.
• Capture: pn_dcp shows one request and one response per scan, on the adapter you set.
• Scan: the device appears with the station name and IP you assigned.
• Online: log in to the application and open the device diagnostics; the module reports data exchange with its IO modules and no pending diagnosis.

When all four read clean, the ping told the truth the whole time: the IP side was never the fault, and the ports are now where the project expects them.

Questions