When the laptop reaches the PLC but every panel project download times out on the same /24, the addresses are already right. Work through the laptop firewall, the switch's port filters or VLANs, and the address stored in each panel, then prove the switch with one direct-cable download per panel.
When the programming laptop reaches the PLC through the switch but every panel project download times out, the addressing is already correct and needs no further changes. The fault sits in one of three places: the laptop firewall, the managed switch's port filters or VLAN settings, or the address stored inside each panel. Work through them in that order, because the firewall costs nothing to test and the panel setup takes the longest. Then settle the question with one direct-cable download per panel: if the direct cable works and the switched path fails, the switch configuration is the repair target. This article covers the download path from PC to panel. If the panels also fail to read live PLC data, the cause is on the PLC link; connecting two operator panels to one PLC with no plant network covers that case.
What a working PLC link already proves
The laptop's session with the PLC travels through the laptop NIC, its patch cable, one switch port, the switch fabric and the PLC port. A working session clears all of those, so the laptop side of the network is healthy. All four devices sit on the same subnet under the 255.255.255.0 mask, so each one treats the others as on-link and no gateway is ever consulted; adding a gateway entry changes nothing. Re-addressing the devices adds a duplicate-address risk and fixes nothing. Power-cycling the switch clears a stale MAC table entry at most; it cannot undo a port filter, an access list or a VLAN assignment.
Symptoms and what each points to
- Both panels refuse downloads while the laptop works with the PLC: a shared cause, in practice the laptop firewall, the switch configuration, or the same setup mistake made on both panels.
- Ping to a panel replies but the transfer times out, typically after 30 to 60 seconds: the IP path is open and the transfer service is blocked at the firewall or the switch.
- Ping to a panel fails: the cable, the switch port, or the address stored in that panel.
- One panel downloads and the other refuses: a per-panel cause, so test that panel's cable, port and stored address on their own.
- Downloads succeed on one attempt and fail on the next: a duplicate IP address somewhere on the subnet.
- Direct-cable downloads work and switched downloads fail: the switch configuration.
Check the laptop firewall first
The Windows firewall can block the programming software's traffic while pings keep answering, which produces the most misleading signature in this fault. Turn the firewall off for one download test, or add an allow rule for the programming software, and retest before touching anything else. If the laptop downloaded projects without trouble last year and fails after an operating-system update, the firewall is the first suspect; HMI project transfer fails on a newer Windows PC covers that situation in detail. One safety note: a programming laptop usually also holds remote access to the plant network, so switch the firewall back on, or leave only the specific allow rule in place, before the laptop leaves the bench.
Compare the switch configuration with the panel's port list
A managed switch can pass PLC traffic and drop panel traffic on the same fabric. Runtime protocols and download services listen on different ports: a PLC that speaks Modbus TCP answers on TCP port 502, while the panel's download service uses whatever TCP and UDP ports its maker documents, normally in the programming software's help file. The standard ranges are well-known ports 0 to 1023 and registered ports 1024 to 49151; a filter that opens only well-known ports still blocks a download service whose ports sit in the registered range.
Check three settings on the ports serving the panels and the laptop. Port filters or access lists: remove them or add allow rules for the documented ports. VLAN membership: ports in different VLANs are separate networks, and two hosts with addresses in the same subnet that sit in different VLANs never reach each other, because each treats the other as on-link and sends nothing to the gateway. Move the panel and laptop ports into the PLC's VLAN. 802.1X port authentication holds a port closed until the attached device authenticates, so a panel with no supplicant stays blocked even next to a PLC port that authenticates fine. An unmanaged switch has none of these features, so on one of those the cause lies elsewhere.
Check the address the panel actually holds
Each panel stores its own IP address and subnet mask in its setup menus, entered at the panel itself. Confirm panel one shows 192.168.100.101 and panel two shows 192.168.100.102, both with 255.255.255.0, then leave the values alone. In the programming software's transfer dialog, select the Ethernet transfer method and enter the target panel's own address. Entering the PLC's 192.168.100.99 points the transfer at a device that offers no download service, and the attempt fails at once. Ping each panel address from the laptop before opening the software; a reply confirms the address is reachable. A duplicate address behaves differently, with the intermittent signature listed above; the FAQ below gives the test for it.
Example: one direct cable settles it
The network: laptop 192.168.100.103, panels 192.168.100.101 and 192.168.100.102, PLC 192.168.100.99, mask 255.255.255.0 on every device, one 24-port managed switch with 1000 Mbit/s (gigabit) ports. The subnet arithmetic: 192.168.100.101 AND 255.255.255.0 = 192.168.100.0, and the same operation on .99, .102 and .103 gives 192.168.100.0 every time, so all four devices are on-link and the addressing needs no change.
The test:
- Turn the laptop firewall off.
- Ping 192.168.100.99 from the laptop. Replies confirm the laptop, its cable, its switch port and the fabric are good.
- Ping 192.168.100.101. A reply confirms the panel is up, on-link and answering.
- Start a project download to 192.168.100.101 over Ethernet. It times out after about 30 to 60 seconds.
- Disconnect the laptop from the switch and cable it directly to the panel's Ethernet port. A patch cable of 2 m or less works fine at a bench, and copper Ethernet runs up to 100 m. Nearly every current NIC and panel port swaps the wire pairs itself; if either port is an older 10/100 port without that feature, use a crossover cable.
- Leave the addresses alone: the laptop stays on 192.168.100.103, the panel on 192.168.100.101.
- Ping 192.168.100.101 again. It replies.
- Run the same download. It completes and the panel restarts into the new project.
Result: the panel, its stored address, the cable and the software all work, so the switched path is the fault. Repeat steps 5 to 8 on the second panel at 192.168.100.102. If both panels download on the direct cable, fix the switch as the next section describes. The direct cable gets tonight's project onto the panel; it is a stopgap, not the plant's wiring.
Put the download back on the switch
- Open the switch's running configuration and find the entries for the two panel ports and the laptop port: port filters, access lists, VLAN membership, 802.1X.
- Move the panel and laptop ports into the PLC's VLAN, or add allow rules for the TCP and UDP ports the help file prints. On an 802.1X port, exempt the panels or attach a supplicant the way the switch documentation describes.
- Save the configuration so the fix survives a power cut, and copy it off the switch.
- Reconnect everything, then ping 192.168.100.99, 192.168.100.101 and 192.168.100.102 from the laptop. All three must reply.
- Download to each panel by its own address, and confirm each panel restarts into the new project.
- With both panels running, confirm each still displays live PLC values. A download that lands while the values freeze means the panel's PLC driver or PLC address setup was disturbed along the way; HMI pings the PLC but reads fail: check the protocol driver walks through that fault.
Keep it from coming back
- Record every address on one network sheet: panel one 192.168.100.101, panel two 192.168.100.102, PLC 192.168.100.99, laptop 192.168.100.103, mask 255.255.255.0. A duplicate address produces the intermittent failure that gets misread as a flaky switch.
- Set the address at the panel, ping it, then open the software, in that order.
- Give each panel a direct-cable download test at commissioning, so a single-panel fault is never confused with a shared one. Two panels failing identically on Ethernet point at a shared cause; on a serial link the shared port itself is often the problem, which two HMI panels fail on one PLC serial port covers.
- Keep the printed port list with the switch configuration file, so whoever edits the switch next keeps the panels' TCP and UDP ports open.
Recommendation: When the laptop reaches the PLC but every panel download times out on one /24, turn the laptop firewall off for one test, then run one direct-cable download per panel. If those transfers succeed, change the switch and nothing else: move the panel and laptop ports into the PLC's VLAN or allow the documented TCP and UDP ports on them, save the configuration, and re-verify with pings to all three devices plus one download to each panel. Leave the addresses alone unless a ping proves a duplicate.
Questions
Why does ping reach the panel but the project download still times out?
Ping tests the IP path with ICMP. A project download is a session the programming software opens against the panel's transfer service, and that service listens on its own TCP and UDP ports. A firewall or switch rule can pass ICMP and PLC traffic while blocking those ports, which produces exactly this signature. Compare the rules on the laptop and panel ports with the port list the panel maker prints in the programming software's help file.
One panel downloads and the other refuses. Is the switch still the cause?
A shared cause rarely explains one good panel beside one bad one. Move the failing panel onto the working panel's switch port and cable, and try again. If the fault follows the port or cable, the switch port is the problem. If the fault follows the panel, check the address stored in that panel's setup menus, its link light, and finally a direct-cable download to separate the panel from the network.
How do I find a duplicate IP address on this network?
Unplug the panel you suspect, then ping its address from the laptop. A reply means another device is holding 192.168.100.101. Duplicate addresses show up as downloads that succeed on one attempt and fail on the next, which reads like a flaky switch. Give every device a unique address, write the list down, and ping each address once more with every panel powered.
The direct cable works. What exactly do I change on the switch?
Open the switch's running configuration and look at the two panel ports and the laptop port. Change one of three things: remove the port filter or access list on those ports, move them into the same VLAN as the PLC port, or add rules that allow the TCP and UDP ports the panel maker documents. Save the configuration afterward so the fix survives a power cut.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.