Ping fails to the HMI panel: one Panel Manager device per com link

One device per communication link, defined in the project

The programming software treats every communication path as its own link, and each link a project uses needs a device entry: one for the link you program the panel over, one for each link the panel talks to a controller on. A project set up over USB that runs its controller link on serial can be missing the Ethernet entry entirely, and nothing about cables, addresses or switches creates it.

That was the whole fault on this bench. Under Panel Manager the project had no device for the Ethernet link; once one was set up, the Ethernet transfer worked. The entries carry identifiers in the DEVxxx style, the software's own numbering, so set up the entries your project needs and give every link exactly one.

Keep USB as the recovery path until the Ethernet transfer has worked once.

Symptoms and what each one points to

• The PC pings the PLC but not the panel. The PC-to-PLC path is good; the panel is the device that stays silent. Check the panel's IP screens, the link lights, the PC's interfaces, then Panel Manager.
• The panel appears in Ethernet Browse and the indicator goes red when you select it. Something on the wire answers, but the programming session does not open. Check the address match, one active PC interface, then the project's device list.
• USB programming works. The panel runs; stay on USB and treat it as the recovery path while you test Ethernet.
• The panel-to-PLC serial link works. That link has its device entry and its cable. The Ethernet link needs its own entry.
• A direct crossover cable to the PLC fails. That clears little: modern Ethernet ports cross the transmit and receive pairs internally. Move all 3 devices onto an unmanaged switch.

USB is your lifeline for this whole procedure, so sort it out first if it wobbles. When the PC detects the panel but the software cannot connect over USB, the fault usually ends at the cable, and the cable's power pin is the first part to check. A USB device the software refuses has its own write-up too: USB device detected but HMI software cannot connect.

The wider pattern, a dead programming link while the controller link runs, has other entry points as well; HMI programming link dead while the PLC link still works covers the ones that start at the cable and the port settings.

Read the addresses off the panel before editing anything

Nothing on this bench hands out addresses: no DHCP server and no DNS, so there is no lease to expire and no name to resolve. The address typed into each device is the address it holds. Read the panel's own screens instead of trusting your notes; it takes under 1 minute per device. From the run screen, touch and hold the upper-left corner to open the setup menu, then hold the same corner again to reach the IP setup; the values live in the panel's built-in System Setup screens, described in the panel's user manual.

All three are private 192.168.x.x addresses, the range reserved for local networks that do not route to the internet, so this bench is closed to everything beyond the switch. When the panel's screens match the table, stop editing. The example next shows why those values are already correct.

Example: three static addresses on one 192.168.2.0/24 bench

Inputs: PC at 192.168.2.104, PLC at 192.168.2.3, panel at 192.168.2.2, each with subnet mask 255.255.255.0, so 3 devices on one flat network. The values come off the PC's adapter settings and the panel's IP setup screens on the bench, and reading them all takes about 2 minutes.

Rule in words: a mask of 255.255.255.0 is a /24. The first three octets name the network; the last octet numbers the devices, with .0 as the network address and .255 as broadcast, which leaves 192.168.2.1 to 192.168.2.254, 254 usable addresses. Two addresses sit in the same IP network when masking each with 255.255.255.0 leaves the same first three octets.

Arithmetic:

• PC: 192.168.2.104 AND 255.255.255.0 = 192.168.2.0
• PLC: 192.168.2.3 AND 255.255.255.0 = 192.168.2.0
• Panel: 192.168.2.2 AND 255.255.255.0 = 192.168.2.0

Result: all three AND out to 192.168.2.0, a single /24 network holding 254 usable addresses. The PC at .104 and the panel at .2 are neighbors on one /24 network; 104 against 2 is fourth-octet detail the mask throws away.

Decision, with its threshold: when your three addresses AND out to the same network, the addresses are cleared and the fault is in the wire, the PC's interfaces or the project's device list. When two of them AND out differently, fix the address or the mask before touching anything else, because a flat bench with no router carries no traffic between different networks. Re-reading the three addresses after any change takes 1 minute and is cheaper than a second hour of cable swapping.

One note on the wire itself: a direct panel-to-PLC run on a crossover cable failed here, and moving all three devices onto an unmanaged switch brought the PLC path back and took managed-switch configuration out of the suspect list. Keep that switch in place for every test below.

Physical path and the PC's network cards

1. Look at link lights on the panel port, the PC port and both switch ports. A dark port ends the network questions and starts the cable questions. Give each link 10 seconds to come up after a plug-in before judging it.
2. Keep the unmanaged switch in the path for every test.
3. Give the software one active interface. If the PC has a second network card or a Wi-Fi adapter, disable the one that is not connected to this network and run Ethernet Browse again; the software's own guidance asks for exactly this, because two live interfaces can push the discovery traffic out the wrong one.
4. Read what ping says. Run at least 4 pings so you see a pattern and not one lost packet; a request that times out went out and nothing answered, while destination unreachable means the PC has no route, which points at a mask or a missing network entry. The two messages clear different halves of the bench.

The panel's manual gives one USB sign worth knowing before you lean on the recovery path: a USB light that sits red signals a communication problem to the panel, and that is your cue to fix USB before continuing. The manual's troubleshooting chapter covers it.

Browse lists the panel and the indicator stays red

Run Send Project to Panel > Ethernet > Browse. The list picks up whatever answers on the wire, and here the panel appeared. Selecting it and pressing OK is where a session opens, and the indicator next to Ethernet is the verdict: green means open, red means it failed. The software's guidance ties a red indicator to three causes: the PC and the panel are on different networks, network delay, or a hardware problem. The AND check above cleared the first, lit link lights and an unmanaged switch mostly cleared the third, and a bench with one switch has no delay path. That is exactly the pattern that moves your attention from the wire to the project.

Browse also earns its keep as a setup tool: when the panel appears in the list, selecting Change IP writes the address for you, which beats typing it into the touch screens.

A red indicator while a TCP port test to the same address passes is its own puzzle; red offline link indicator when the TCP port test passes works that combination.

Firewall: the last check on the PC

If the link lights are lit, the addresses AND out to one network, one interface is active and the session still fails, look at the PC's firewall. A firewall can block ping as well as the ports the programming software uses, and a wired, correctly addressed bench failing its ping test for exactly that reason is a documented cause in network troubleshooting guides. Make a rule for the programming application on the bench interface, allow it about 30 seconds to take effect, and retest. Keep the firewall enabled; a rule for one application is the fix, and an open firewall follows that PC onto the next job.

The fix: one device per com link in Panel Manager

1. Connect over USB and open the project in the programming software. USB works here, and it stays the recovery path until Ethernet works.
2. Open Panel Manager in the project.
3. List the communication links the project really uses: the link you program the panel over, and the link the panel uses to reach the controller. On this bench that is Ethernet for programming and serial to the PLC.
4. Create a device entry for every link that has none. The software names entries in the DEVxxx style; what matters is one entry per link, with that link's own settings filled in.
5. Save the project and transfer it to the panel over USB. A transfer of a small project over USB takes about 1 minute.
6. Return to Send Project to Panel > Ethernet > Browse, select the panel, press OK and wait for the indicator to go green before any transfer.

The pass is a green indicator and a completed Ethernet transfer. If ping now answers but the protocol test still fails, that pair of symptoms has its own walk-through: HMI protocol test fails while ping passes: recover firmware.

Recommendation: When USB programs the panel and the controller serial link runs but Ethernet fails, work the order used here: read the addresses off the panel's setup screens, prove them with the AND check, keep an unmanaged switch in the path, disable the PC's unused network interfaces, then open Panel Manager and create one device for each communication link. On a bench addressed PC 192.168.2.104, PLC 192.168.2.3, panel 192.168.2.2, all 255.255.255.0, the addresses are already correct and the device list is where the fix lives. Keep USB as the recovery path until the Ethernet transfer finishes with a green indicator.

Questions