Fixing S7-1500 Missing from TIA Portal Accessible Devices

Problem Overview

When commissioning or maintaining a SIMATIC S7-1500 / ET 200 CPU (e.g. CPU 1517, CPU 1515, CPU 1513, or ET 200SP) from a programming PC running TIA Portal, engineers frequently need to use the "Accessible devices" function (German: "Erreichbare Teilnehmer") to discover a target station whose IP address is partially or fully unknown. This discovery function performs a Layer 2 DCP (Discovery and Configuration Protocol) broadcast that every PROFINET device must answer, and the TIA Portal then populates the result list with every reachable CPU/HMI/Switch/PC station in the broadcast domain.

The failure mode this article addresses is:

• The CPU replies to ping from the engineering station (Layer 3 reachability is OK).
• The project still goes "Online" successfully when the IP is typed manually into the project tree.
• However, the same CPU does not appear in the "Accessible devices" / "Update accessible devices" list, while other devices on the same physical network do appear.

This symptom is independent of TIA Portal version (observed on V14, V15, V15.1, V16, V17, and V20) and is not caused by a defective CPU. It is almost always a network-layer problem that prevents the DCP/MAC multicast from reaching the controller, or a host-stack problem that blocks the reply on the engineering PC.

Technical Background: How "Accessible Devices" Works

TIA Portal's "Update accessible devices" function does not send an ICMP echo request and does not rely on the configured IP address. Instead it sends a Layer 2 Ethernet frame to the PROFINET multicast destination address 01:0E:CF:00:00:00 (DCP Identify request). Every PROFINET device that supports DCP must answer with a DCP Identify response that contains, among other fields:

• Device MAC address (PROFINET port MAC, not the chassis MAC on modular CPUs)
• Configured IP address (or 0.0.0.0 if the device is in DHCP/zeros)
• Subnet mask
• Default gateway
• Device name (NameOfStation, e.g. plc1517-1)
• Vendor ID and Device ID (Siemens vendor ID = 0x002A)

Because DCP is a non-routable multicast, it is blocked by every routed hop (router, Layer 3 switch with VLAN interfaces, firewall, etc.). It is also filtered by some managed switches that drop frames whose payload is too large for the default MTU, or whose port-security policy drops unknown multicast MACs. The official Siemens procedure for displaying accessible devices is documented in the TIA Portal Online & Diagnostics help:

Displaying accessible devices - TIA Portal V20 Online Help

The procedure is identical for V14-V20:

1. Open the project navigation "Online & diagnostics" of any device.
2. Select the PROFINET interface of the PC/PG (the network adapter that is physically connected to the controller subnet).
3. Click "Update accessible devices" (the circular-arrow icon). TIA Portal will issue the DCP Identify broadcast on that adapter only.
4. After a few seconds, every responding station is listed with its IP, MAC, type, and rack/slot.

Root Cause Matrix

The five root causes observed in the field account for >95 % of "Accessible devices" failures on S7-1500 CPUs:

Detailed Root-Cause 1: Subnet / Routing Issue

In the case that triggered this article, the engineering workstation was on subnet 10.60.0.0/24 and the CPU was on 10.61.0.0/24 (the second-to-last octet differed by 1). Both subnets were carried by the same physical switch infrastructure, but the Layer 3 boundary - normally invisible at L2 - was the reason that the DCP broadcast from the PG never crossed the inter-VLAN / inter-subnet hop.

Why does ping work? Because the administrator (or the network itself) had a static route or inter-VLAN routing enabled for ICMP, but the Layer 2 multicast path was either filtered or simply not present on the PG's VLAN. ping is a routed unicast; DCP is a non-routed multicast. Two different things.

Fix variants:

1. Re-IP the PG into a static address inside the CPU's subnet (e.g. move PG from 10.60.x.x to 10.61.x.x) so that the DCP broadcast is natively accepted by the local NIC.
2. Add a route on the PG that keeps the broadcast in scope (limited use - DCP is multicast, not unicast, so a static unicast route will not help; the broadcast must physically be present on the local L2 segment).
3. Configure a Layer 2 tunnel (VLAN trunk, "switchport mode trunk" on Cisco) between the two subnets so they share one L2 domain.
4. Add a supernet mask that covers both subnets, e.g. 255.255.254.0 (/23). A /23 covers 10.60.0.0 - 10.61.255.255 with one network address and the broadcast still inside the PG's broadcast domain. Both PG and CPU must use this new mask; otherwise the DCP broadcast of the PG stops at the first L3 boundary.

Detailed Root-Cause 2: Managed Switch Drops DCP Multicast

Symptoms:

• Wireshark on the engineering PC's adapter shows the outgoing DCP Identify-Request (EtherType 0x8892, dst MAC 01:0E:CF:00:00:00), but no DCP Identify-Response.
• The same PC connected directly to the CPU with a patch cable does see the response.
• Other TCP/UDP traffic (HTTP, ISO-on-TCP, SNMP) flows normally.

Common switch-side causes:

• MTU too small: PROFINET uses the standard Ethernet MTU of 1500 bytes. If the switch has been configured for jumbo frames or a smaller MTU on that port, the frame is dropped silently.
• IGMP/MLD snooping: When snooping is on, the switch expects IGMP joins. PROFINET multicasts are not IGMP, so they are dropped.
• Port security / MAC lock-down: The switch limits the number of MACs per port. The DCP response from the CPU carries a MAC that has not yet been learned and is dropped.
• Storm control / broadcast suppression: Some switches count PROFINET multicasts as broadcasts and drop them above a low threshold.
• Cisco trunk mode required: On certain Cisco Catalyst models (2960-S, 3560, 9300), the PROFINET multicast is only forwarded when the port is in switchport mode trunk with the appropriate native VLAN. Access ports filter the LLDP/DCP combination that Siemens uses.

Verification on Cisco IOS:

! Show whether DCP multicasts are being received on the uplink
monitor session 1 source interface Gi0/1 both
monitor session 1 destination interface Gi0/24

! Show MAC-address-table entries for the PROFINET multicast MAC
show mac address-table address 010E.CF00.0000

! Show whether any drops are happening due to multicast
show platform software fed switch active mls cef summary

Fix on Cisco IOS:

interface GigabitEthernet0/1
 description PROFINET-port-to-CPU
 switchport mode trunk
 switchport trunk native vlan 60
 switchport trunk allowed vlan 60,61
 spanning-tree portfast trunk
 mls qos trust cos
 no igmp snooping

Detailed Root-Cause 3: Windows Defender / Third-Party AV

A surprisingly common root cause is corrupted Microsoft Defender settings on the engineering PC, where the registry keys that store Windows Security policies are hijacked by malware. The visible symptom in Windows Security is the message "Virus & threat protection - this setting is managed by your administrator" together with greyed-out toggles.

What happens behind the scenes:

1. Defender's service WinDefend injects the Windows Filtering Platform (WFP) callout driver WdNisDrv to inspect every packet on every interface.
2. If the WFP filters are corrupted, the driver can drop Ethernet frames whose EtherType is not on its allow-list.
3. EtherType 0x8892 (PROFINET DCP) is not whitelisted by default - it is filtered out at WFP level even though the IP/TCP stack has no rule against it.

Quick verification (does not require re-installing anything):

1. Temporarily disable "Real-time protection" in Windows Security (only possible if Defender is not centrally managed; if the toggle is grey, jump to step 2).
2. Repeat "Update accessible devices" in TIA Portal. If the CPU now appears, Defender is the cause.

Repair procedure (corporate PCs only with admin rights):

1. Open regedit as Administrator.
2. Export and delete the keys:
   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Policies
3. Reboot. Re-enable Tamper Protection. Re-check Windows Security - the "managed by your administrator" message should be gone.
4. If the issue persists, fully reset Defender via PowerShell:
   Get-AppxPackage Microsoft.SecHealthUI -AllUsers | Reset-AppxPackage

For hardened environments where Defender is centrally administered by Intune/SCCM and cannot be reset locally, push the following firewall exceptions to the engineering image:

New-NetFirewallRule -DisplayName "PROFINET DCP" -Direction Inbound -Protocol UDP -LocalPort 34964 -Action Allow
New-NetFirewallRule -DisplayName "PROFINET DCP" -Direction Outbound -Protocol UDP -LocalPort 34964 -Action Allow
New-NetFirewallRule -DisplayName "PROFINET RT" -Direction Inbound -Protocol UDP -LocalPort 34962 -Action Allow
New-NetFirewallRule -DisplayName "PROFINET RT" -Direction Outbound -Protocol UDP -LocalPort 34962 -Action Allow

Detailed Root-Cause 4: Cisco Switch Trunk-Mode

This is the resolution that finally fixed the original case: the lab Cisco switch was operating in access mode on the PROFINET port, which silently dropped the LLDP frames embedded in the DCP Discovery-Request from the TIA Portal. PROFINET relies on LLDP for neighbourhood detection, and LLDP frames are VLAN-tagged by Siemens. Cisco access ports discard tagged frames whose VLAN tag is not the native VLAN.

Reference behaviour, confirmed by the support thread, is that Catalyst 2960-S and 3560-X require switchport mode trunk on ports that forward PROFINET. The same applies to most modern Cisco IOS-XE platforms (Catalyst 9300, 9500, IE3x00 industrial switches).

Step-by-step resolution procedure:

1. Identify the affected port on the lab switch (e.g. GigabitEthernet0/5).
2. Enter config mode: configure terminal.
3. Apply: interface GigabitEthernet0/5 → switchport mode trunk → switchport trunk native vlan <id> → switchport trunk allowed vlan <id>,<id2>.
4. For PROFINET conformance, also enable: ptp enable (if the controller is acting as PTP master) and lldp transmit / lldp receive.
5. Save the configuration: end → write memory.
6. From the engineering PC, repeat "Update accessible devices" in TIA Portal.

Detailed Root-Cause 5: TIA Portal Cache Behaviour

A TIA Portal behaviour that surprises many engineers is that "Update accessible devices" does not always re-broadcast on the network. After the first successful scan, the result list is stored in a per-project cache. The next time the user clicks "Update accessible devices" without first invalidating the cache (e.g. by closing the project, opening a different PG/PC interface, or by triggering "Download to device → scan"), TIA Portal may simply repaint the cached list, omitting devices that have since appeared on the wire.

Observed behaviour in the original case:

1. PG was on the desk, CPU was in the lab. Accessible devices did not show the CPU.
2. Engineer went to the lab, connected the PG directly, changed the CPU IP, returned to the desk.
3. Accessible devices still did not show the CPU under its new IP.
4. Engineer triggered "Download to device" (right-click on the CPU → "Download to device → PG/PC and devices in the target subnet"). The download wizard issued a fresh DCP scan and the CPU appeared in the scan window.

Best practice:

• Always trigger "Download to device" (the wizard does a forced re-scan) when an emergency IP change is required.
• Switch the PG/PC interface (Online & diagnostics → "PG/PC interface") to a different adapter, then back, to force TIA Portal to invalidate the cache.
• Close the project and reopen it; this clears the per-project cache.

Step-by-Step Diagnostic Procedure

1. Confirm the IP stack on the engineering PC with ipconfig /all. Note the IP, mask, default gateway, and which physical adapter is bound to the PROFINET subnet.
2. Ping the CPU by its current IP: ping -t <ip>. If ping fails, the issue is plain L3 reachability and Accessible devices will also fail.
3. Capture the wire with Wireshark on the engineering PC's PROFINET adapter. Apply the filter pn_dcp || eth.addr == 01:0e:cf:00:00:00 and click "Update accessible devices" in TIA Portal. You should see a DCP Identify-Request; if you do not see a reply from the CPU's MAC, the network path is the culprit.
4. Test direct connection: connect the PG directly to the CPU with a patch cable or via a small unmanaged switch. If the CPU now appears in Accessible devices, the active infrastructure is the cause.
5. Test with SIMATIC Automation Tool or PRONETA from Siemens - both perform a PROFINET scan that bypasses the TIA Portal cache. If the CPU appears in PRONETA but not in TIA Portal, the cache is the cause.
6. Check the antivirus: disable real-time protection temporarily; if the CPU appears, follow the Defender repair procedure above.
7. Check the active switch: identify the port in the lab patch panel, log in to the switch, verify the port is in trunk mode and is not filtering multicast.

Emergency Workaround: Programmatic IP Change

If the engineering PC still cannot discover the CPU via Accessible devices but can ping it and reach it on TCP port 102 (ISO-TSAP), the IP of the CPU can still be reset without TIA Portal. This procedure works on S7-1200/S7-1500/ET 200SP CPUs whose firmware supports the "Reset to factory settings" or the "Assign IP address via the MAC address" function:

1. Read the MAC address from the label on the front of the CPU (PROFINET port X1 or X2 - the second-from-bottom line of the label).
2. Open SIMATIC Automation Tool (free download from Siemens) → "Network → "Accessible devices" → right-click the CPU → "Assign IP address".
3. Alternatively, use the primary setup tool PRONETA (free) → "Network analysis" → select the CPU → "Assign PROFINET name and IP".
4. Alternatively, use the legacy SIMATIC Manager / STEP 7 V5.x "Accessible Nodes" - this older tool performs the DCP broadcast differently and is sometimes able to reach CPUs that TIA Portal cannot (it is a useful triage step but is not a long-term solution because STEP 7 V5.x is no longer developed for the S7-1500).

Verification Checklist

After applying any of the fixes above, verify with this checklist:

• Click "Update accessible devices" in TIA Portal. The CPU appears within 5 seconds with its IP, MAC, type "S7-1500 / ET 200SP", and rack/slot information.
• Right-click the CPU → "Online & diagnostics" → "Connect to target device" succeeds without timeout.
• Right-click the CPU → "Download to device" succeeds; the CPU goes through STOP → RUN transition and the RUN LED is solid green.
• Wireshark capture during the next "Update accessible devices" shows a DCP Identify-Request followed by a DCP Identify-Response from the CPU's MAC.

Field-Proven Caveats

• CPU 1517-3 PN/DP has three PROFINET interfaces (X1, X2, X3). DCP discovery is per-interface - if the engineering PC is on the wrong subnet for the chosen interface, Accessible devices will not show the CPU on that interface.
• DHCP-mode S7-1500 with no DHCP server available will assign itself an APIPA address (169.254.x.x). It still answers DCP - TIA Portal will list it with IP 0.0.0.0 until an address is assigned.
• Firmware < V1.8 on S7-1500 has DCP multicast filter active by default. Either upgrade firmware or uncheck "Filter multicast" in the interface properties (TIA Portal → Device properties → Interface → PROFINET interface options).
• Windows 11 22H2 onwards enables "Multicast Listener Discovery version 2" by default. Some older PROFINET devices do not answer MLDv2 queries; disable MLD on the PC's adapter if the controller disappears after a Windows update.
• VPN/Remote: TIA Portal "Accessible devices" does not traverse any VPN tunnel because the tunnel terminates at the L3 boundary. Use a router-based remote-maintenance solution such as the SCALANCE MUM-800 or TeamViewer Tensor with PROFINET-passthrough - both are designed for this and are documented in the SCALANCE MUM manual.

Official Siemens Documentation

For deeper background, refer to:

• Displaying accessible devices - TIA Portal V20 Online Help
• Function manual "PROFINET with TIA Portal" (Siemens Support entry ID 109751348, free after registration)
• SIMATIC Automation Tool - Operating Instructions (Siemens Support entry ID 49960656)

FAQ