TIA Portal V15.1 reports a failed connection while attempting to upload code to a PLC. The available evidence does not identify the PLC model, its IP address, the subnet mask, or whether the target is physical or simulated. Start by proving the selected PC adapter and local Ethernet path before changing project or PLC settings.
Align the PC Ethernet Interface
Configure a static IPv4 address on the PC Ethernet adapter so it belongs to the same subnet as the PLC. The reported example uses 192.168.0.150, but that address is valid only if it matches the PLC's subnet and does not duplicate another device. Select that configured adapter in TIA Portal; do not assume TIA selected the intended NIC when the PC has multiple adapters.
Run the TIA Portal Connection Search
- Connect the PC directly to the PLC to remove the switch from the initial test.
- In TIA Portal, select
PN/IEas the access path. - Select the Ethernet NIC carrying the configured static IPv4 address.
- Select the direct
X1interface where applicable, then start the device search. - If the search still fails after confirming the settings, restart the PC and repeat the search.
The evidence does not establish whether X1 applies to every possible target. Confirm the physical PLC port designation before selecting it.
Isolate Switch and Discovery Problems
| Observation | What it establishes | Next decision |
|---|---|---|
| Direct connection works | The PC adapter, TIA access path, and PLC can communicate without the switch. | Investigate the switch configuration and traffic handling. |
| Ping works but TIA discovery fails | IP unicast reachability exists, but discovery traffic may still be blocked. | Inspect discovery traffic and managed-switch filtering. |
| Direct connection also fails | The switch is not the sole cause. | Recheck the NIC, IPv4 subnet, cable, selected access path, and target type. |
A managed switch with IGMP snooping is a hypothesis when ordinary IP communication works but device detection does not. Test by bypassing the switch first. If bypassing restores discovery, review the switch's multicast handling; disable IGMP snooping only as a controlled diagnostic, then verify the result against the network design. A mirror port, passive tap, or equivalent capture point can confirm whether discovery probes and responses traverse the switch.
Check Host Filtering and Target Type
Temporarily test whether Windows firewall filtering affects discovery, using an approved maintenance window and restoring the firewall immediately after the test. Treat this as a diagnostic hypothesis, not a confirmed TIA Portal V15.1 defect. Also establish whether the target is a physical PLC or a simulated device: a simulated target has no physical cable or switch path, so troubleshoot its configured virtual network interface instead of applying physical-network conclusions.
FAQ
Why does TIA Portal V15.1 fail to connect even when ping works?
Ping proves IP unicast reachability only. TIA device discovery may use traffic handled differently by a managed switch or host firewall, so bypass the switch and repeat the PN/IE search through the selected NIC.
What PC IP address should I use to connect TIA Portal to the PLC?
Use an unused static IPv4 address in the PLC's subnet. 192.168.0.150 is the reported example, but it is appropriate only when the PLC address and subnet mask place it on that same subnet.
Can IGMP snooping prevent TIA Portal from finding a PLC?
It is a supported diagnostic hypothesis when discovery fails through a managed switch but succeeds over a direct cable. Bypass the switch first, then review or temporarily disable IGMP snooping under controlled conditions and repeat the search.