Troubleshooting Primary Setup Tool and Accessible Nodes on S7-300

1. Problem Statement

A field engineer commissioning a new SIMATIC S7-300 CPU 317-2 PN/DP with a CP 343-1 communications processor cannot find the station using either of the two standard discovery mechanisms in the legacy Siemens toolchain:

• Siemens Primary Setup Tool (PST) V4.2 / V4.1 — Browse network dialog returns zero devices after the progress bar completes.
• SIMATIC Manager Step 7 V5.5 — PLC → Edit Ethernet Node or View → Accessible Nodes returns an empty node list.

The same hardware, the same unmanaged switch, and the same known-good Cat5e patch lead let the engineer's laptop ping the PLC as soon as the correct IP was supplied out-of-band. Yet Browse and Accessible Nodes still returned no entries. The fault is reproducible on the host operating system but disappears when the engineer switches to a virtual machine (VM) using bridged networking.

This is a recurring, well-documented failure mode when commissioning a brand-new S7-300 PN/DP station from a Windows engineering host. The root cause is almost never a defective CPU, CP, cable, or switch — it is a mismatch between how the discovery protocols (DCP, LLDP, and ISO-on-TCP / TCP broadcasts) interact with the host's network stack, the active PG/PC interface, and the local firewall posture.

2. Affected Systems, Firmware, and Catalog Numbers

3. Network Discovery Protocols — What the Tools Actually Send

Step 7 Accessible Nodes and PST Browse rely on the same low-level mechanisms. Understanding them is the only way to reason about why a healthy segment can return no devices.

3.1 DCP — Discovery and Configuration Protocol (PROFINET)

DCP is a Layer-2 multicast protocol (EtherType 0x8892) used by PROFINET devices to identify themselves. It is the protocol used by Accessible Nodes:

• Identify Request — multicast 01:0E:CF:00:00:00 with a IdentifyAll filter.
• Identify Response — every reachable PROFINET node replies with its Name of Station, Type, and MAC address.

For DCP to work, the host NIC must:

1. Be in promiscuous (or at least multicast-listening) mode.
2. Have the PG/PC interface in Step 7 set to a PROFINET/ISO Ethernet adapter — not TCP/IP.Auto.1 unless the CPU is on the same IP subnet.
3. Have no switch filter blocking multicast 01:0E:CF:00:00:00 (unmanaged switches pass multicast; some managed switches require IGMP snooping disabled for the commissioning VLAN).

3.2 S7 Broadcast (MAC FF:FF:FF:FF:FF:FF)

Older Accessible Nodes scans also send an S7 broadcast to the configured ISO Ethernet MAC. The expected response is the device's MAC plus station name, even when the device has no IP address assigned. If the laptop's local MAC table is empty (for example, a freshly booted VM with no prior ARP traffic to that segment), the broadcast will still be transmitted by the NIC — but the response will be unicast back to the source MAC. If the source MAC the host advertises is not the one Step 7 expects, the response is dropped at the application layer.

3.3 TCP/IP Probe (PST Browse)

PST Browse uses a TCP/UDP probe against the configured subnet range and a S7RPC ping. A device with 0.0.0.0 IP will not respond to a TCP probe addressed to a specific IP — that is why a factory-fresh CPU 317-2 PN/DP will not appear in PST Browse until it has been assigned an IP via the S7 mechanism.

4. Root Cause Analysis — Why the Engineer Saw "Nothing"

Working backwards from the symptoms, four interacting root causes are common. They are listed in the order they should be eliminated.

4.1 Wrong PG/PC Interface Selected

Step 7's discovery routines bind to whichever adapter the active PG/PC interface names. If the active entry is TCPIP.AUTO.1 and the host has multiple virtual NICs (Hyper-V, VMware, WSL, VPN, USB-Ethernet), the broadcast may egress the wrong adapter or may not egress at all because TCPIP.AUTO prefers the adapter with a route to the configured default gateway.

4.2 Host Firewall or EDR Filtering ISO/DCP Frames

Even with the Windows Firewall service stopped, third-party endpoint detection agents, VPN split-tunnel drivers, and Intel/Realtek advanced driver features (e.g., Teaming, Virtual Machine Queues) can drop DCP multicast. A VM with bridged networking bypasses these filters because the hypervisor presents a synthetic NIC whose driver stack is minimal.

4.3 VM Bridged MAC Mismatch

This is the cause that bit the field engineer. In a bridged VM, the guest's virtual NIC presents its own MAC address to the segment. The host's real NIC presents another. When the host's Step 7 sends a DCP multicast, the response is unicast back to the host's MAC — but Step 7's discovery thread may be listening on the wrong socket because the PG/PC interface is bound to a virtual adapter. Switching to the VM made the listener bind to the bridged MAC, and the responses flowed correctly.

4.4 Out-of-Band IP Already Set by Another Engineer

If a colleague has already loaded the project and assigned an IP, the CPU will not respond to DCP from a host that is on a different subnet. The ping succeeding was diagnostic: it confirmed L3 reachability to the assigned IP, but it told you nothing about whether DCP was working from the same host.

5. Diagnostic Procedure — Start at the Bottom of the Stack

1. Verify physical layer. Link LED on the CPU/CP and the switch port. Use a known-good patch lead. Confirm auto-negotiation settled (look for "1 Gbps / Full" in the NIC status).
2. Set a static IP on the host NIC in the same subnet as the PLC (for example, PLC 192.168.0.1/24, host 192.168.0.100/24). Disable every other NIC (Wi-Fi, VPN, virtual adapters) before opening Step 7.
3. Issue an out-of-band ARP request:

   arp -d *
   ping 192.168.0.1
   arp -a | findstr 192.168.0.1

   If arp -a returns the MAC of the CPU 317 (printed on the front panel as MAC: xx-xx-xx-xx-xx-xx), L2/L3 is healthy. The CPU is alive; discovery is a software issue.
4. Capture multicast. Run Wireshark on the host NIC with the filter eth.addr == 01:0e:cf:00:00:00 || lldp while triggering Accessible Nodes. You should see DCP Identify.Request from the host. If you do not, Step 7 is bound to the wrong adapter.
5. Confirm the PG/PC interface. In Start → SIMATIC → PG/PC Interface, the active access point must be S7ONLINE (STEP7) → <your NIC>.ISO or <your NIC>.TCPIP, not TCPIP.AUTO.1.
6. Temporarily disable security software — Windows Firewall, third-party EDR, VPN, and any NDIS filter driver (e.g., WfpProv in Wireshark, npcap bindings). Reboot, retry.

6. Resolution Path A — Make the Host Discovery Work

Apply these in order. Stop and re-test Accessible Nodes after each step.

6.1 Set a Static, Same-Subnet Address on the Host

The single highest-impact change. With a static IP in the same /24 as the CPU, the host's ARP table builds, the DCP response arrives, and Step 7's listener thread registers the node.

# Windows (PowerShell)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.0.100 -PrefixLength 24
Set-NetDnsServer -InterfaceAlias "Ethernet" -ResetServerAddresses

6.2 Fix the PG/PC Interface Assignment

1. Open Start → SIMATIC → PG/PC Interface.
2. Set the Access point of the application to S7ONLINE (STEP7).
3. Set the Interface parameterization used to your physical NIC with ISO Ind. Ethernet or TCP/IP (Auto) bound directly to that NIC's MAC — not a virtual adapter.
4. Click Diagnostics; the status should read OK and the MAC printed must match the host NIC's real MAC (visible in ipconfig /all).

6.3 Disable Everything That Sits Between the NIC and Step 7

6.4 Reinstall the SIMATIC NET / Step 7 PG/PC Interface Driver

If the host's Step 7 was upgraded over a previous version (typical when moving from V5.4 to V5.5 SP2), the ISO transport can be left pointing to a now-deleted virtual adapter. Reinstalling the SIMATIC NET PC software, or at minimum running Set PG/PC Interface → Install/Remove Interfaces → Reinstall, rebuilds the binding table.

7. Resolution Path B — Recover the IP When the CPU Has None

If the CPU is truly factory-fresh (no IP, no project), discovery must be done before L3 exists. Use one of the following in priority order.

7.1 MAC-Address Assignment on the Host

Read the MAC from the front-panel label of the CPU 317-2 PN/DP (the PROFINET port X2 MAC, not the MPI/DP MAC). Configure a static IP on the host that is on the same subnet you intend to assign to the CPU, then:

1. Open Step 7 → PLC → Edit Ethernet Node.
2. Click Browse. Because the CPU is factory-fresh, this will not find it — proceed to step 3.
3. Click Add. Enter the CPU's MAC address (with hyphens, e.g. 00-0E-8C-XX-XX-XX) and the target IP, e.g. 192.168.0.1, subnet 255.255.255.0, router 192.168.0.250.
4. Click Assign IP Configuration. The CPU will write the IP via DCP and reboot its PROFINET stack.
5. Re-open Accessible Nodes — the CPU should now appear with its station name.

7.2 Use the "Flash LEDs" Confirmation

After entering the MAC in Edit Ethernet Node, the Flash LED button toggles the CPU's BF (bus fault) and MAINT LEDs at 1 Hz for 5 s. This is the safety check the field engineer should use to confirm they are talking to the right physical CPU before writing an IP — particularly important on a panel with multiple CPUs.

7.3 MPI/DP Path as a Fallback

For mixed-era plants where a USB-MPI adapter is available, the IP can be assigned via the CPU's PN-IO interface properties inside HW Config (Step 7 V5.5) after going online over MPI. The MPI path is slower and tied to a serial port, but it is immune to every L2 multicast pitfall above. Reserve this for stations that have the CPU's MPI port accessible.

7.4 Port Scan with Nmap as Last Resort

If the CPU already has an IP from a previous engineer, scan the subnet:

nmap -sP 192.168.0.0/24
nmap -sS -p 102,161,34962,34963,34964 192.168.0.1

8. Resolution Path C — Make the VM Work Reliably

The VM fix is straightforward but easy to misconfigure.

1. In the VM settings, change the network adapter to Bridged (VMware) or Bridged Adapter (VirtualBox) bound to the physical NIC that connects to the PLC.
2. Replicate the MAC used by the bridged VM to the host. In VirtualBox this is exposed in File → Host Network Manager → Adapter → MAC; in VMware it is in Edit → Virtual Network Editor → VMnet0.
3. Set a static IP inside the VM in the same subnet as the PLC. Disable the host's own PROFINET connection while commissioning from the VM to avoid route ambiguity.
4. Install the SIMATIC NET PC software inside the VM (it will detect the bridged NIC and offer an Intel PRO/1000 MT — ISO Ind. Ethernet entry). Select that entry in Set PG/PC Interface.
5. Run Accessible Nodes from inside the VM. It should find the CPU within 3 s of the scan completing.

9. Verification and Commissioning Checklist

10. Field-Proven Caveats

• Two PROFINET ports, one IP. The CPU 317-2 PN/DP has an integrated 2-port switch. The IP and MAC live on the switch's logical interface, not on a single port. If you swap the patch lead from X2 P1 to X2 P2 without rebooting, the CPU keeps the same MAC and IP — no surprise. However, if you daisy-chain through the CPU to a downstream ET200, a DCP scan from the commissioning host may briefly return the ET200 as well. Filter by station name to avoid confusion.
• PROFINET name is independent of IP. Accessible Nodes will list a CPU with a valid IP but no PROFINET name, and Step 7 will refuse to bring it online as an IO device. Always assign the device name from HW Config (or TIA Portal) before pulling the project to the controller.
• Switch port fast-aging. Some managed switches (e.g., SCALANCE XC/XB) have a 5-second MAC aging timer that is too aggressive for DCP. During commissioning, set the port to No Aging or increase the timer to 60 s.
• Windows 11 24H2 NDIS 6.85 regression. A number of field reports indicate that the Windows 11 24H2 release can lose ISO multicast responses on Intel I219-V adapters. Downgrading the driver to the 2023 vendor revision, or switching to a USB-Ethernet adapter, restores discovery. The 25H1 update improves this; test on a non-critical workstation before rolling it out fleet-wide.
• Don't conflate PST with SIMATIC commissioning. PST is the right tool only for SCALANCE switches, WLAN controllers, and the SINEC NMS ecosystem. For an S7-300/S7-400 CPU, the correct path is Edit Ethernet Node or TIA Portal. See the SiePortal thread on PST versioning for the official scoping guidance.

11. Modern Alternative: TIA Portal Accessible Devices

For any greenfield project after 2018, prefer TIA Portal V17/V18/V19 over Step 7 V5.5:

• Online → Accessible Devices performs the same DCP scan but with better diagnostics (per-device PROFINET diagnostics buffer).
• Direct IP assignment without MAC entry is possible if the host and the CPU are on the same subnet.
• Cross-discovery works for S7-300, S7-1500, ET200, and SCALANCE in a single scan.

For migrating a Step 7 V5.5 project, you can still use Step 7 for IP setup, then convert the project with TIA Portal's Migrate Project wizard without losing the assigned IP.

12. References Within the Article

Inline links to official Siemens resources used in this guide:

• Siemens SiePortal — PST discovery thread (CPU 317-2 PN/DP)
• Siemens SiePortal — Most recent version of Primary Setup Tool (PST)

Frequently Asked Questions