Fixing ET200SP V90 PROFINET Connection Through Network Switch

Problem Description and Symptoms

A recurring commissioning problem in small PROFINET cells built around the SIMATIC ET 200SP, SINAMICS V90 PN, SIMATIC HMI KTP700, and an engineering PC is the partial-visibility fault: the HMI panel connects and exchanges data with the controller through the network switch and is fully operable, while the controller (ET 200SP CPU or interface module) and the drive (SINAMICS V90 PN) remain unreachable from the engineering PC on the same switch. Direct point-to-point cabling between the PC and the PLC works perfectly. The moment traffic is forced through an unmanaged consumer switch (TP-Link TL-SG series is the most commonly reported brand), the PC loses the ability to ping, browse, download to, or run PROFINET diagnostics against the PLC and the V90.

Observable symptoms in the field:

• PC pings succeed to the HMI (192.168.0.4) but time out to the PLC (192.168.0.6) and drive (192.168.0.20).
• PRONETA 3.3 (Siemens PROFINET commissioning tool) discovers the HMI but does not list the PLC or the V90 when the switch is in the path.
• TIA Portal "Online > Accessible devices" returns only the HMI; the PLC and V90 are missing.
• Direct PC-to-PLC cabling with a Cat5e patch cord works without any change to the TIA project.
• After a blank program download, the V90 surfaces alarm F7490 "No startup inhibit set", even when p8641 (STO/SS1 selection) is configured.
• The PROFINET device names appear empty in PRONETA, meaning the controllers have never completed DCP identification.
• Replacing the suspect switch with a Siemens SCALANCE XB005 immediately restores visibility of every device.

The defining clue is the asymmetry: the HMI connects, the PLC and drive do not, and direct cabling works. This is the signature of an Ethernet Layer-2 problem on the switch, not a TIA Portal project error or an IP addressing mistake. The HMI uses standard TCP/IP for its connection to the PLC; the PLC and V90 also use PROFINET DCP (Discovery and Configuration Protocol, EtherType 0x8892) for discovery and LLDP (IEEE 802.1AB, EtherType 0x88CC) for neighbour detection. A switch that mishandles these multicast frames causes the partial-visibility fault.

Reference Network Topology

The topology below is the canonical example reported in field service calls. All four devices use static IP addresses in the 192.168.0.0/24 subnet with a 255.255.255.0 mask, no default gateway, and the same IP assignment method on every device (S7-REGSVC or static PROFINET addressing via PRONETA).

The HMI runs as a PROFINET IO Device only for process-data exchange with the CPU; its IP stack is implemented in WinCC flexible / TIA WinCC. The V90 PN is a pure PROFINET drive that exchanges process data (telegram 1 or telegram 3) over the same network. All three IO stations must be reachable via DCP (multicast 01-0E-CF-00-00-00, EtherType 0x8892) for the IO Controller to assign names and parameters.

Root Cause Analysis

Six Layer-2 mechanisms are responsible for the partial-visibility fault in approximately 90% of field cases. They are listed below in order of likelihood for a TP-Link consumer switch in PROFINET service.

1. Energy Efficient Ethernet (IEEE 802.3az) breaking PROFINET RT

Many unmanaged switches, including multiple revisions of the TL-SG105, TL-SG108 and TL-SG116, advertise 802.3az Energy Efficient Ethernet (EEE) as a default-enabled feature. EEE puts the PHY into a Low Power Idle (LPI) state during inter-frame gaps. PROFINET RT Class 1 uses a 1 ms send clock and 31.25 µs bit time at 100 Mbit/s. The LPI wake-up latency on some PHYs exceeds 4 ms, which is longer than the PROFINET watchdog window, breaking the AR (Application Relationship) before it is fully established. The drive or CPU drops the AR, DCP responses are lost, and the device becomes invisible to PRONETA even though the link LED is solid green.

EEE is also enabled by default on many PC NICs (Intel I219-V, Realtek RTL8111) and on Windows 10/11 "Power Saver" profiles. Disable EEE on the PC NIC as well as the switch; one without the other leaves the problem in place.

2. Auto-negotiation collapsing to 10 Mbit/s or half-duplex

ET 200SP CPUs and V90 PN ports are factory-set to auto-negotiate, but they strongly prefer 100 Mbit/s / full-duplex. If the switch port is forced to 10 Mbit/s or half-duplex (often the default on legacy "green" switch settings, or on a switch whose auto-negotiation logic is buggy), the PLC link comes up but DCP multicast responses are dropped silently. Half-duplex on a 100 Mbit/s link is also the canonical trigger for late collisions, which PROFINET treats as a transport error.

3. IGMP / MLD snooping filtering PROFINET multicast

PROFINET uses the multicast group 01-0E-CF-00-00-00 for DCP identification, 01-0E-CF-00-00-10..1F for PROFINET RT frames, and LLDP multicast 01-80-C2-00-00-0E for neighbour detection. Unmanaged switches with IGMP snooping enabled (or "optimised for video streaming" presets on consumer switches) may treat unknown multicast as flooded, but during switch warm-up the snooping table is not yet populated, and DCP frames for 5-15 s after the first packet are dropped, during which PRONETA's first scan misses the device. MLD snooping for IPv6 multicast behaves the same way and is a common cause when Windows 10/11 IPv6 is left enabled on the PC.

4. MAC address table aging or reset on port events

Default MAC aging is 300 s on most consumer switches. This is normally fine. However, some switches (and the TL-SG108E in particular when set to "Flow Control Off" mode) reset the MAC table on any port-down event, which re-triggers a learning phase. During that phase, DCP responses from the PLC to the PC may arrive before the switch has learned the PC's MAC on that port, and the response is flooded but not necessarily returned to the originator. The visible symptom is that PRONETA discovers the device on some scans and misses it on others.

5. Auto-MDI/MDIX failure on damaged or shielded cables

Cat5e cables with a broken pair, a missing shield termination, or a poorly-crimped RJ45 plug can show full link on a direct connection (because both PHYs use the same MDI/MDIX logic) but fail on a switch that maps different pairs. The PLC link light comes on, but no frames are exchanged. Swap the patch cord first; this is the cheapest diagnostic step and resolves approximately 15% of field cases.

6. Loop or broadcast storm from a miswired daisy-chain

If the cell was previously wired in a ring or with two uplink ports back to the same switch, the unmanaged switch can spend 30-60 s in a learning/forwarding transition. Some low-end switches do not implement STP at all and flood broadcasts, masking the issue until PC traffic is heavy. A single Ethernet loop can also hold the switch's CPU at 100% and prevent it from forwarding PROFINET frames at all.

Diagnostic Procedure

Follow this sequence. Each step is independent; do not skip ahead to TIA Portal diagnostics until the Layer-2 health checks pass.

1. Verify the PC link state. Open "Network and Sharing Center > Ethernet > Status" and confirm 100 Mbit/s or 1 Gbit/s / full-duplex. If the link is 10 Mbit/s or half-duplex, the switch port is the problem and the rest of the cell will not work.
2. Substitute the switch. Use a different unmanaged switch known to handle PROFINET, e.g. a Siemens SCALANCE XB005 (article 6GK5 005-0BA00-1AB2). If the cell now works, the original switch is the defect and should be replaced.
3. Substitute the cables. Replace every Cat5e patch cord with a known-good one, even if the link LED is green on every port. Patch cords are the most common source of intermittent Layer-2 faults.
4. Disable 802.3az on the PC NIC. In Windows Device Manager > Network Adapter > Power Management, uncheck "Allow the computer to turn off this device to save power". In the adapter's Advanced properties, disable "Energy Efficient Ethernet" and "Green Ethernet". Realtek, Intel and Broadcom NICs all expose these properties.
5. Disable 802.3az on the switch. On a managed switch (TL-SG108E, TL-SG116E, SCALANCE XC208), log in and disable EEE per port. On a fixed-function unmanaged switch, EEE cannot be disabled, so the switch is unfit for PROFINET — replace it.
6. Force port speed/duplex on the PC. Set the PC NIC to 100 Mbit/s / full-duplex (no auto-negotiate) to remove one variable. PROFINET devices always run 100 Mbit/s full-duplex, so this is a safe configuration.
7. Run PRONETA in network analysis mode. PRONETA 3.3+ exposes a "Network analysis" tab that walks every subnet in parallel. It will display the missing PLC with a yellow "no DCP response" badge. This is the smoking gun that the Layer-2 path is broken.
8. Capture with Wireshark. Filter on eth.addr == <PLC MAC> and check whether DCP Identify requests (EtherType 0x8892, subfunction 0x01) ever leave the PC. If yes, but no Identify Response (subfunction 0x04) is seen, the PLC is not receiving them, or the response is filtered by the switch.
9. Check the PLC diagnostics buffer. In TIA Portal, "Online > Online & Diagnostics" on the CPU lists the most recent 100 entries. Look for "PROFINET IO system error" with details "DCP timeout" or "AR establishment failure". The exact error code (16#0001, 16#0002, 16#0010) maps to a specific cause; see Table 5 below.
10. Verify the V90 PN port directly. Use the V90's built-in web server (port 80) or STARTER / SINAMICS commissioning software to read r8970 (PROFINET state) and r8971 (PROFINET error). A value of 4 in r8970 means the AR is down. A value of 3 means the AR is established and the Layer-2 path is healthy.

Useful commands and capture filters

The following Windows and Wireshark commands are used throughout the diagnostic procedure.

ping 192.168.0.6 -t
ping 192.168.0.20 -t
arp -a
ipconfig /all
netsh interface show interface

Wireshark filter for DCP identify requests:
eth.type == 0x8892 && pn_dcp.subfunction == 0x01

Wireshark filter for DCP identify responses:
eth.type == 0x8892 && pn_dcp.subfunction == 0x04

Wireshark filter for PROFINET RT:
eth.type == 0x8892 && pn_rt

Wireshark filter for LLDP:
eth.type == 0x88cc

IP Address and Subnet Configuration

Although the partial-visibility fault is dominated by Layer-2 issues, IP misconfiguration is a fast-to-check co-conspirator. The reference addressing used in the failing cell is below; verify it on every device.

To make sure the PC is correctly addressed, run ipconfig /all from an elevated command prompt and confirm the IPv4 address, subnet mask, and that "DHCP Enabled" is "No" if static addressing is intended. If the PC is on a different /24 (for example, 192.168.1.10), the HMI would not work either. The fact that the HMI works confirms the PC's IP is in the same /24 as the cell.

To verify the PROFINET device name has been assigned correctly, run PRONETA, "Network analysis", click the device, and read the "Name of station" field. An empty field means the controller has never received a name from TIA Portal or PRONETA; the AR will not come up.

Switch Selection and Hardening for PROFINET

For cells with one IO Controller and up to ~8 IO Devices, a managed switch is strongly recommended. Siemens provides a PROFINET-conformant line; the most common field picks are listed in Table 3.

If the existing TP-Link must be kept, the following measures make it usable:

• Disable EEE per port via the switch's web UI (TL-SG108E, TL-SG116E). On a fixed-function TL-SG108 without a UI, EEE is hardware-enabled and cannot be disabled — replace the switch.
• Disable "Green Ethernet" / "Power Saving" mode if present in the switch's UI.
• Set every port to "Auto Negotiation" with "Flow Control Off" to remove any priority-pause interference with PROFINET RT.
• Keep cable lengths below 80 m even though Cat5e supports 100 m; headroom helps PROFINET timing on 100 Mbit/s full-duplex.
• Do not mix the PROFINET cell with general office traffic on the same switch; broadcast storms from Windows or DHCP will stall PROFINET AR bring-up.
• Do not connect the engineering PC and the cell through a Wi-Fi bridge or Powerline adapter; the latency and jitter will break PROFINET RT Class 1.

PROFINET Device Discovery with PRONETA

PRONETA is the standard tool for verifying Layer-2 reachability before opening TIA Portal. Download PRONETA 3.3 or later from the Siemens support portal. The verification procedure is:

1. Connect the PC, HMI, PLC, and V90 through the suspect switch.
2. Launch PRONETA and click Network analysis.
3. Set the IP range to 192.168.0.0/24 and start the scan.
4. After 5-15 s the tool lists every PROFINET-capable device, including the HMI if it answers DCP.
5. Devices that respond to DCP but whose IP is in a different subnet are flagged yellow. Devices that do not respond are flagged red.

For every red device:

• Check the link LED on the switch port — solid green means PHY is up.
• From the PC, run arp -a and verify whether the MAC of the missing device is in the ARP cache. If yes, the switch forwarded the DCP response; the upper layers are at fault. If no, the switch is filtering.
• Use PRONETA's "Set IP address" function to force an IP from the PC. If the device accepts the IP but the project still fails, the Layer-2 path is repaired; if it refuses, the device is unreachable.
• Use PRONETA's "I/O Test" function to test the PLC's PROFINET ports directly. With the PLC connected directly to the PC, run "I/O Test" and verify that all configured slots are reported. This isolates the PLC's PROFINET stack from any switch issue.

PRONETA can also read the ET 200SP station's neighbour list (LLDP), which shows every PROFINET device visible to the CPU through the switch. If the CPU's neighbour list is empty, the Layer-2 path is broken; if it lists the HMI but not the V90, the V90's PROFINET port is the suspect.

TIA Portal Project and Download

Once the switch is verified and every device pings, configure TIA Portal to use the same PROFINET topology as the physical cell. The mandatory settings in the project are:

• PC interface: "PN/IE" with the active NIC, "TCP/IP (Auto)" mode.
• PLC PROFINET interface: same subnet (192.168.0.x / 255.255.255.0).
• V90 PN: same subnet, PROFINET name "v90-drive", IP 192.168.0.20.
• HMI: same subnet, name "ktp700-hmi", IP 192.168.0.4.
• Use the device-name assignment function in TIA Portal (Online > PROFINET device name assignment) to push the name to the V90 and the HMI; DCP cannot complete the AR without a name.
• For the ET 200SP CPU 1510SP-1 PN, ensure firmware V2.9 or later is installed. Earlier firmware has a known PROFINET AR timeout bug fixed in V2.9 SP1.

If the HMI was connecting through the switch in the failing cell, the TIA Portal project for the HMI is almost certainly correct. The remaining work is to align the PLC and V90 with the same PROFINET configuration and assign the names. Once the names are assigned, restart the PLC; the AR with the V90 should come up within 5 s.

The PROFINET diagnostics in TIA Portal can be used to confirm the AR state. Open "Online > Online & Diagnostics > PROFINET diagnostics" on the CPU. The "I/O systems" tab should show the V90 with a green check and the cycle time 1 ms.

V90 Drive Startup Inhibit Handling

The "NO STARTUP INHIBIT SET" alarm is fault F7490 on the V90 PN and is independent of the Layer-2 fault, but it is reported in the same context. The alarm is raised when the drive has been powered up but the safety startup inhibit has not been acknowledged.

The alarm is cleared by acknowledging the inhibit through the safety configuration or, in non-safety applications, by setting p9601 to 0. The fact that a blank TIA Portal program download clears the alarm suggests that the previous configuration was generating the alarm; the network fault and the alarm are coincident, not causal.

To verify the drive's PROFINET state without using STARTER, browse to the V90's web server (http://192.168.0.20) and open "Diagnostics > PROFINET". The web server is enabled by default on V90 PN drives with firmware V1.04 or later.

PROFINET AR Error Code Matrix

The following table maps the most common PROFINET AR error codes reported in the ET 200SP CPU's diagnostic buffer to their root cause and corrective action. The codes are reported in hex.

Verification Checklist

Use this matrix to confirm the cell is fully operational after the switch replacement or hardening.

Frequently Asked Questions