Resolving TIA Portal V20 0 Compatible Devices Error on 1517H3-PN

Problem Summary

When downloading a STEP 7 (TIA Portal) V20 project to a SIMATIC S7-1500H redundant station built around a CPU 1517H-3 PN (Firmware V3.1), a CP 1543-1 on the active backplane, and CP 1623 communication processors in the PC station, the "Select target device" dialog closes with the diagnostic line:

Scan completed - 0 compatible devices of 0 accessible devices found

The result is identical whether the dialog is launched for the PLC object or for the H-station. The companion Online > Accessible devices scan, however, does resolve the CPU and replies with its PROFINET device name, IP address, and MAC. A ping from the engineering station succeeds. A download to PLCSIM V20 also succeeds. The fault only reproduces against the physical H-station.

Affected Hardware and Software Versions

Verify the exact catalog number and firmware version of the CPU on the physical hardware by reading the rating plate and the online diagnostic buffer. The CPU 1517H-3 PN entered the H-system with firmware V3.0; V3.1 expanded the S7-1500H release to additional functions. Cross-check the firmware against the Siemens Industry Online Support entry "S7-1500H System Manual" before commissioning.

Root Cause Matrix

Items 1, 2, 3, 4, 5, 6 cover roughly 90 % of "0 of 0" reports in this exact symptom pattern. Items 7 and 8 are residual causes seen most often on integration tests rather than on first commissioning.

Network Architecture and PROFINET Behavior

The S7-1500H system uses two PROFINET interfaces per CPU: the dedicated H-Sync link over the X2 ports (R0 / R1 pair) and at least one X1 interface (or the optional CP 1543-1) for the plant network. With Firmware V3.1 the redundancy is established over the X2 PROFINET ports of the two R-CPUs; the plant network runs on the X1 ports. The ring typically uses MRP (Media Redundancy Protocol) with MRPD for PROFINET traffic. The PC station (PG/PC with CP 1623) connects to the same ring on a non-MRP port to remain reachable when one ring member fails.

Two discovery mechanisms are involved when TIA Portal scans the network:

1. Accessible devices — the PG sends a DCP (Discovery and Configuration Protocol) Identify broadcast (UDP/34964, multicast 01-0E-CF-00-00-00). Every PROFINET device replies with its name, IP, role, and MAC. The reply is over unicast back to the PG. The only requirement is UDP/34964 on the L2 segment.
2. Compatible devices — the PG first runs DCP Identify, then validates the relationship with each candidate by reading its GSD-based capabilities, then by attempting an Application Relationship (AR) and reading the LLDP neighbor table. The AR is the establishment of the PROFINET IO communication; it requires the device to be reachable, the LLDP frame (multicast 01-80-C2-00-0E-3F) to be forwarded, and the PROFINET device name configured in the project to match the one stored in the device.

Symmetric semantics: accessible = "I see you on the wire"; compatible = "I see you, I can talk to you, and I recognize the configuration we agreed on". A 0/0 result from the compatible scan with a positive accessible scan means the DCP layer passes for every visible device but the AR/LLDP layer fails — typically because the L2 forwarding breaks the AR/LLDP frame before it reaches the device, or because the device rejects the AR due to security or protection.

Step-by-Step Diagnostic Procedure

Run the procedure top-down. Stop at the first step that returns a result and apply the fix from the corresponding "Cause" section before continuing.

1. From the engineering station, open a command prompt and run arp -a. Confirm the MAC of the CPU (printed on the rating plate) is in the ARP cache. If it is not, the L2 path is broken or the wrong adapter is selected.
2. Run ping <CPU_IP> from the same adapter. Loss = 0, latency < 1 ms. Loss > 0 = L3 path is bad; fix the routing / subnet first.
3. Open TIA Portal > Online > Accessible devices. Confirm the CPU appears with the expected PROFINET name, role, and IP. The role column shows PN-IO-Device for the CPU.
4. In the same dialog, right-click the CPU > Flash LED. The CPU's two LED columns (the SF / BF and the dedicated PN LED) must blink. If they do, the L2 path to that specific CPU is healthy.
5. From the same dialog, read the PROFINET device name field. If it is blank or reads "noname", the physical CPU was never assigned a name. Assign the configured name (right-click > Assign PROFINET device name).
6. Open Online > Online & diagnostics on the configured CPU and check the diagnostic buffer for entries starting with "Communication" or "Security". Any TLS / certificate mismatch will be logged there.
7. Right-click the H-station > Download to device > Software (all). If the scan returns 0/0 with the IP of the CPU visible in Accessible devices, switch to the cause-by-cause resolution path below.

Cause 1 — LLDP / Multicast Blocking on Office Switches

This is the most common cause of the 0/0 result when the accessible scan works. Office / consumer-grade switches implement LLDP / IEEE 802.1AB-2009 filtering in one of three ways:

• The switch is an unmanaged switch with a small MAC/forwarding table and silently drops frames with reserved multicast destinations. LLDP uses destination 01-80-C2-00-0E-3F; some switches also drop the entire 01-80-C2 range.
• IGMP / MLD snooping is enabled on a managed switch but no querier is configured. The switch therefore never learns the multicast group state and floods only the first 2 – 3 minutes before pruning.
• The PROFINET multicast group is filtered by an ACL that was inherited from a copy-pasted template.

Diagnostics:

1. Connect the PG and the CPU with a direct PROFINET cable (bypassing any switch). Run the "compatible devices" scan again. If it now finds the CPU, the switch is the cause.
2. If a managed switch is mandatory, log into it and confirm the following: LLDP is enabled, IGMP snooping is disabled or the PROFINET MAC ranges are listed as static groups, no ACL denies the LLDP multicast destination.
3. Siemens PROFINET switches (SCALANCE XC-200 / XC-300 / XB-200 / XR-300) ship with a PROFINET preset that passes PROFINET traffic by default. Office switches (Cisco Small Business, HP OfficeConnect, Netgear, D-Link, TP-Link unmanaged) are the typical source of this defect.

Workaround: deploy a managed PROFINET switch (e.g. SCALANCE XC216-3) with the PROFINET preset. The preset disables IGMP snooping and forwards LLDP. After the swap, the "compatible devices" scan returns the CPU immediately.

Cause 2 — TIA Portal V20 Connection Security (TLS)

TIA Portal V17 introduced "connection mechanisms" for the PG/PC link to the PLC. V18 and later tightened the defaults. V20 ships with the "Modern" security level as the default for new projects. The security level controls which PG/PC connection types are accepted:

If a previous version of the project (V18 / V19) was created with the Classic level and the engineer is opening it in V20 for the first time, TIA V20 will use the project-defined level, not the V20 default. The PG sees the CPU in Accessible devices but the AR is rejected at TLS handshake. The result is 0/0 in the compatible scan.

Resolution path:

1. Open the CPU device properties > Protection & Security > Connection mechanisms.
2. Switch to Classic temporarily to confirm the TLS layer is the cause (do this only in a lab environment, never in production).
3. Re-run the compatible scan. If it now finds the CPU, the cause is confirmed.
4. Restore Modern (or Maximum) and complete the certificate exchange: in the CPU properties > Security > Certificate manager, export the CPU's certificate, install it on the PG's "Siemens TIA Engineer" certificate store, and re-build the project.

For the S7-1500H station, the connection security is configured on the H-station object, not on each R-CPU separately. Apply the same change on both R-CPUs in the H-station configuration if you are using TIA V19 or earlier; V20 propagates the setting automatically to both R-CPUs.

Cause 3 — PG/PC Interface and PC Station

The S7-1500H commissioning workflow expects the PC station to host a CP 1623 (PCIe) configured as a PROFINET IO device. The CP 1623 appears in the project under Devices & networks > PC station > CP 1623. The CP is then connected to the same PROFINET subnet as the H-station. The S7ONLINE access point of the engineering station must be tied to this CP and not to the standard Windows adapter.

Symptoms of a misconfigured PC station:

• The TIA Portal "Accessible devices" scan picks the PG's Intel / Realtek adapter, while the "compatible devices" scan uses the CP 1623 (because the project was compiled with the CP as the only PROFINET interface).
• The CP 1623 driver ("HARDNET IE") is installed but the CP is not associated with a PC station in TIA Portal.
• Two PROFINET adapters are active and TIA cannot disambiguate — the S7ONLINE access point dialog lets you choose one, but the download dialog uses a different default.

Resolution path:

1. Open Set PG/PC interface (Start > Siemens Automation > Set PG/PC interface). For the S7ONLINE access point, select the entry that points to the CP 1623 (e.g. CP1623.PROFINET.IO.1).
2. Confirm in the TIA project that the PC station contains a CP 1623 module and that the CP is on the same PROFINET subnet as the H-station. Drag the CP into the network view, connect it to the same subnet, recompile.
3. Close the project in TIA Portal, re-open it, then re-attempt the download.

If the engineer has used STEP 7 V5.5 and S7-400H, the "PC Internal" station is the historical equivalent of the CP 1623 in the PC station. In TIA Portal with S7-1500H, the explicit PC station with a CP 1623 module is the modern equivalent. A direct port-for-port translation from STEP 7 V5.5 to TIA V20 is one of the most common sources of this fault.

Cause 4 — PROFINET Device Name, IP, and CPU Protection

The PROFINET device name is the PROFINET equivalent of a station name in PROFIBUS. It is stored in the device (non-volatile) and must match the value in the TIA project. The matching happens at AR establishment, after the LLDP check. If the name does not match, the IO controller (TIA) will not see the device as "compatible" even if the DCP / LLDP frames flow correctly.

Two main failure modes for the device name:

• The CPU was never named (factory state: PROFINET name = ""). The accessible scan resolves the CPU but the compatible scan cannot match it to the project entry, which has a configured name like cpu-1517h-r0.
• The CPU was named with a different tool (PRONETA, the old STEP 7 V5.5 "Edit Ethernet Node", or another TIA project). The accessible scan shows the old name; the project expects a new name.

Resolution path:

1. Open Online > Accessible devices. Right-click the CPU > Assign PROFINET device name.
2. In the dialog, select the configured name from the drop-down (e.g. cpu-1517h-r0 for the first R-CPU, cpu-1517h-r1 for the second). The IP address field can be left untouched or set to the project value; do not change the subnet mask.
3. Click Assign name. Wait for the success message.
4. Re-run the compatible scan.

The IP address is a separate, secondary requirement. The PROFINET name is the primary identifier. If the IP on the device is in a different subnet from the PG, the AR establishment will fail. The accessible scan uses DCP / ICMP, which works across subnets only if a router is configured. Confirm the IP and subnet of the CP 1623 on the PG side match the CPU's PROFINET interface X1 or X2.

CPU protection is the last item in this category. With Firmware V3.1 the CPU supports an access level (Full access, Read-only, HMI access, No access). If a password is set and the level is "No access", the AR is rejected. For the first download to a fresh CPU, set:

• Protection & Security > Access level = "Full access (no protection)" or "Full access incl. fail-safe (no protection)" for the F-variant.
• Deactivate Know-how protection and Copy protection temporarily.
• Deactivate Secure communication temporarily if the F-CPU has an F-connection.

After the first successful download, restore the production protection level and re-enable TLS.

S7-1500H Download Procedure

The download to an S7-1500H station has additional steps compared to a standard S7-1500 station. Both R-CPUs must be in the same H-mode (RUN-Solo, RUN-Redundant, or STOP). The H-station must be online and acknowledged by the engineering station as a single object.

1. Compile the project fully (right-click the project > Compile > Software (rebuild all)). Resolve all warnings; the H-system warns on subtle configuration mismatches that the standard S7-1500 would silently accept.
2. Open the H-station in the project tree > right-click > Download to device > Software (all).
3. The "Select target device" dialog appears. The "compatible devices" list should now show the R-CPU currently in the role of primary. If the list is still 0/0, go back to the cause matrix above.
4. Select the primary R-CPU. The download proceeds to the H-station object, which then propagates the configuration to the backup R-CPU over the H-Sync link.
5. Confirm the request: "The system will be set to STOP. Continue?". Click Yes. The H-station stops, the new configuration is loaded to both R-CPUs, and the system is brought back to RUN-Solo or RUN-Redundant based on the project setting.
6. Watch the diagnostic buffer of both R-CPUs. The expected sequence is: STOP caused by PG, Configuration loaded, Restart, H-Sync up, Redundancy established. Any deviation is the actual cause of the "no compatible devices" symptom if the download appears to succeed but the H-system does not establish redundancy.

If the H-station was previously configured with a different topology (e.g. a 400H with CP 443-1), the new H-system configuration will fail to load because the hardware layout in the project does not match the physical rack. The accessible scan finds the CPU because the L2/L3 path is healthy; the compatible scan fails because the project entry for the H-station does not match the physical hardware. The fix is to add the CPU and CP 1543-1 to the H-station under Devices & networks explicitly, not to assume a copy of the 400H configuration will work.

Verification and Final Checks

After the first successful download, run the following checks before declaring the system ready:

1. Open Online > Accessible devices. The H-station must appear with role PN-IO-Device and IP equal to the project value.
2. Open Online & diagnostics on the H-station. The "Redundancy" tab must show Status: Redundant, Primary CPU: CPU 1517H-3 PN (R0), Backup CPU: CPU 1517H-3 PN (R1), and H-Sync: OK.
3. Read the diagnostic buffer of both R-CPUs. The last 10 entries must be free of "Communication error", "Security event", "PROFINET IO error".
4. Open the project, mark the H-station, right-click > Compile > Software (consistency check). The result must be "No errors, no warnings".
5. Run a forced switchover: in the H-station diagnostics, click Force switchover. The primary and backup must swap roles within 100 ms, the I/O must continue to update, and the diagnostic buffer must log Forced switchover executed.
6. Pull the PROFINET cable from the backup R-CPU. The H-station must remain in RUN-Redundant with the I/O update alive. Re-connect the cable; the backup must re-synchronize within 30 s for non-failover scenarios.

If any of these checks fails, go back to the corresponding "Cause" section. The "0/0" error does not always clear after a single round; in some H-station commissioning flows, the TLS layer needs to be re-armed after the first successful download because the CPU regenerates its certificate during the STOP-RUN cycle.

Migration Notes from STEP 7 V5.5 / S7-400H

Engineers who come from STEP 7 V5.5 with S7-400H often carry habits that cause this exact error pattern. The S7-1500H is not a 1-to-1 replacement of the 400H. The differences that matter most for this fault:

When converting a 400H project to a 1500H project, use the TIA Portal migration tool ("Migrate project") and then re-validate each item above. A migrated project that compiles cleanly will still fail at download if any of the items above were carried over unmodified. The Siemens Industry Online Support portal holds the official migration guide and the S7-1500H system manual — cross-check the project after migration against these documents before commissioning.

Frequently Asked Questions