HMI panels invisible after power up: test the managed switch

What the symptom pattern points to

• The PLC replies, both panels time out. The path treats the panel ports differently from the PLC port. On a managed switch that means storm control, port security, VLAN membership or spanning-tree startup on exactly those ports.
• It worked last week and died after a power cycle. A state that forms at power up: ports held in spanning-tree startup states, a port-security lock that trips on a rebooting device's first frames, or a storm-control trip. Addresses do not change over a weekend.
• All three addresses reply, the software still lists no panels. Discovery is blocked above the path: a laptop firewall, a second active adapter, or the wrong link type picked in the software.
• Nothing replies at all. The laptop adapter, the cable or the switch port. Swap the cable and the port before anything else.
• Replies come and go. Duplex or speed negotiation trouble, or a switch state changing under you. Move to a known-good port and set speed the same on both ends.

Set the laptop straight first

The laptop is the fastest thing to rule out, so rule it out before the switch.

1. Turn off every firewall on the laptop for this test, including any security suite, and re-enable it with the panel software's exceptions afterward.
2. Disable the wireless adapter. A second active adapter sends discovery traffic out the wrong interface.
3. Run ipconfig /all and note every adapter's address and mask. No second adapter may hold an address on the cell's subnet.

Check: only the wired adapter is active, it holds the cell subnet's address, and the firewall is off for the test.

Ping all three addresses before you open the software

Ping is the baseline. Software discovery fails wherever ping fails, and the pattern of answers tells you where to go next.

• ping 192.168.100.99 (PLC Ethernet module)
• ping 192.168.100.101 (panel 1)
• ping 192.168.100.102 (panel 2)

After a cold start, wait a full minute before you call a ping failed. A managed port can sit deaf through its spanning-tree startup states, and the arithmetic in the example below sets that minute. Record all three answers before moving on. If every device answers and the software still lists nothing, the cause sits one layer above the path; the same split between a passing ping and a failing connection is worked through in HMI pings the PLC but reads fail: check the protocol driver.

Take the managed switch out of the path

1. Get a plain unmanaged switch or hub with at least four ports. One with no configuration passes broadcast, multicast and unknown unicast frames exactly as they arrive.
2. Make the re-patch with the cell's power off at its disconnect. Move the laptop, both panels and the PLC Ethernet module onto the unmanaged switch.
3. Power the whole cell up once, together, and wait for link lights plus a full minute.
4. Repeat the three pings.
5. Open the panel software's network device search, with the link type set to the Ethernet option instead of a serial or USB choice. Use the identify command that flashes a panel's screen to confirm you are looking at the panel you think you are.

The verdict rule:

• Panels ping and appear in the software on the plain switch. The managed switch configuration is the fault. The permanent fix below gives the administrator the list to work through.
• Panels stay silent on the plain switch too. The switch is cleared. The fault is on the panel or laptop side: repeat the laptop checks, then patch the laptop directly to one panel with a standard cable as the last split.

Example: two 8-inch panels and a PLC module behind a 24-port managed switch

Inputs. The cell's address plan, read off each panel's setup screen and the laptop's ipconfig /all: panel 1 at 192.168.100.101, panel 2 at 192.168.100.102, PLC Ethernet module at 192.168.100.99, laptop at 192.168.100.103, all four with mask 255.255.255.0. The hardware: two 8-inch operator panels and one 24-port managed switch. The timing inputs: one spanning-tree forward delay of 15 s, and a test budget of about 15 minutes.

The rule in words. A managed port forwards ordinary unicast once it is up, but panel discovery travels on broadcast frames, and the port can drop those under storm control or hold them through its spanning-tree startup states.

The arithmetic. One forward delay interval is 15 s. A port passes through listening and then learning before it forwards, so 2 × 15 s = 30 s of silence after every link-up. On a cold start the wait runs close to a full minute, about twice that 30 s figure, so 60 s is the wait to allow before a ping counts as failed.

The result. All four addresses sit on one /24 with no repeats, so the plan itself is sound. After a 60 s wait on the managed switch, 192.168.100.99 replies and both panels time out. After the same cold power cycle on the unmanaged switch, 192.168.100.101 and 192.168.100.102 both reply, both appear in the software's device list, and the identify command flashes the correct panel each time.

The decision. PLC answers, panels silent past 60 s on the managed switch, panels alive on the unmanaged switch: the switch configuration is the fault, and the whole test fit the 15-minute budget. If the panels had stayed silent on the plain switch too, the switch would be cleared and the next suspects would be the laptop setup and the panels themselves.

Why a managed switch hides panels

Two documented switch behaviours produce this exact symptom.

Storm control. A managed switch can cap the broadcast, multicast and unknown unicast traffic a port may pass. A port that reaches its cap enters a storm-control state and stops traffic, and the device behind the port sees nothing but delays. Panel discovery is broadcast traffic, so it is the first casualty; the PLC's point-to-point session is unicast and goes straight through.

Spanning-tree startup states. Spanning tree holds a port in listening, then learning, before it forwards anything. One forward delay interval is 15 s, so the two states take 2 × 15 s = 30 s, and full cold starts run close to a minute. A panel that boots and announces itself inside that window is invisible even though its cable, address and project are all fine.

Port security and VLANs close the remaining gaps: a port that locks after a rebooting device's first frames, or ports placed in different VLANs, pass the PLC and drop the panels just as cleanly. For the rack-level choice between the two switch types, a comparison of managed and unmanaged Ethernet switches for PLC communications covers what each passes and what each filters.

Make the managed switch pass the traffic

If the test convicted the switch, hand the switch administrator this list for the ports used by the panels, the PLC module and the laptop:

• Broadcast storm control: the caps on broadcast and multicast, and whether a trip latches the port.
• Port security or MAC limiting: what happens to a port when a device reboots and its first frames arrive.
• VLAN membership: all four ports in one VLAN.
• Spanning tree: whether the ports run the full listening and learning wait on every link-up, and whether the switch documents a host-port setting that skips it.
• Speed and duplex: forced settings on one end only produce the comes-and-goes symptom; set both ends to negotiate or both to the same fixed speed.

Exact menu names and defaults differ by model and firmware, so read them from the switch's own manual. After any change, power-cycle the switch and the panels cold and repeat the three pings; the answer must match what you saw before the power cycle.

Keep the cell on its own switch and segment either way, so plant IT routing and filtering never reach the panels; the wiring plan for connecting two operator panels to one PLC with no plant network is the pattern to follow. Adding more panels later changes the update load on that link too; connecting many operator panels to one PLC without slow updates covers the sizing.

Prove it cold before you call it fixed

A network that passes only the first time will fail again on Monday.

1. Power everything off, then on together, switch included.
2. Wait for link lights plus a full minute, then ping the PLC module and both panels.
3. Download a screen project to panel 1 over Ethernet, then to panel 2.
4. Confirm both panels still talk to the PLC after each download.
5. Power-cycle once more and repeat step 2.

Recommendation: run the 15-minute unmanaged-switch test before you change any address, reinstall any software or swap any panel. If the panels answer on the plain switch, have the switch administrator review storm control, port security, VLAN membership, spanning-tree startup and speed or duplex on exactly the ports the panels, the PLC module and the laptop use, then prove the fix with one cold power cycle. If the switch cannot be made to pass discovery reliably, leave the cell on its own unmanaged switch and its own segment.

Questions