Swap a faulty HMI panel using a flash card and its project IP

How do you make a spare HMI panel come up with the right IP address?

Save the address in the project's panel setup before you write the project to the flash card, and the address travels with the project: any replacement panel that loads that card comes up on the project's address, for example 192.168.1.50, with no setup screen touched.

That is a documented configuration. The setup-screen documentation for the panel lists the places an IP address can be set from, and the project is one of them, next to the panel's own screens and the programming software. Storing the address in the project is supported behaviour, so a spare prepared this way is not a workaround you have to defend to anyone.

Do the check while the working panel is still healthy. Open the station's project on the programming PC, open its panel setup, and read the stored address against the address plan for that station. A card written from a project with a stale address sends every future spare to the wrong number, and nobody notices until a failure.

What decides the address on a panel that boots from a flash card?

The last address written to the panel is the address it runs, and a project that carries its address in panel setup writes that value every time it loads, so the project's number wins over whatever the spare panel used on its previous job.

The three documented sources, the panel's screens, the programming software and the project, all write the same stored value, and whichever ran last is what the panel holds. A hardware swap therefore leaves the address where it was: the value is stored configuration, and the project re-applies it at every load. That is the whole reason a bare spare panel from the shelf takes the station's identity cleanly.

Keep the address plan with the card, on the label. Memory fails at 06:40 on a Saturday; a label does not.

What goes in the spare kit?

Four things: the project file with its address saved in panel setup, a CompactFlash card written from that project, the address plan on the card label, and a known-good Ethernet patch cable so a marginal cable never masquerades as a failed swap.

• The project: checked against the station's address plan, with the revision and the date written on the label.
• The card: written with the panel's documented save-to-card function. If the save runs with the card seated in the panel, expect the panel to want that card at the next power cycle and leave it installed; a panel that boots its project from the card needs the card at every start. A panel that comes up without its project around a power cycle has a boot-source or card problem, and the power-cycle checklist walks that fault in order.
• The label: panel address 192.168.1.50, controller 192.168.1.10, project revision, date.
• The cable: stored with the card, so the swap never ends in a cable hunt.

Store the kit at the machine, in the panel's cabinet or beside it, in a sealed bag away from magnetic fields.

How do you pick the address the project carries?

Keep the panel in the controller's subnet and change only the last number: with the common mask 255.255.255.0, a controller at 192.168.1.10 pairs with a panel at 192.168.1.50, while a second device at 192.168.1.10 would be a collision with the controller itself.

The arithmetic is plain IPv4 subnetting. A 255.255.255.0 mask fixes the first three numbers as the network, 192.168.1 here, and the fourth number names the device, from 1 through 254, each used once on that subnet. Panel at .50 and controller at .10 share the network and differ at the device number, so they talk directly with no router between them.

Reserve the panel's number outside any DHCP pool, or assign it statically in the project, so a visiting laptop never receives the panel's number while the spare depends on it. Give every panel on the line its own last number in the plan, so two stations never share one.

Why does the failed panel have to leave the network first?

Two devices answering on one IPv4 address break address resolution for both: switches and hosts flip between two hardware addresses for the same IP, connections drop at random on both panels, and the fault reads like bad cabling or a failing switch port rather than a duplicate address.

The mechanics are worth one paragraph. A panel claims its address on the network with ARP, the protocol that maps an IP address to a hardware address. When the spare announces 192.168.1.50 while the failed panel still holds it, the neighbours' tables map one IP to two hardware addresses and flip between them, so traffic to that address lands on one panel or the other at random, and other devices on the subnet feel it too. IPv4 address conflict detection, RFC 5227, gives a device a way to probe for and defend an address; it detects the clash, and two devices still cannot share one address.

So the disconnect is a hard step, not a preference. Power the failed panel down, or pull its Ethernet plug and tag the cable end. The state that causes the outage is powered and still plugged in.

What are the steps for the swap?

The swap is six actions at the machine: confirm the card's project, take the failed panel off the network, move the card, boot the spare, read the address the panel now shows, and verify one controller write before the line runs again.

1. On the programming PC, open the station's project and read the address stored in its panel setup against the label: 192.168.1.50 in this article's example. Correct it here if it has drifted, because the card inherits whatever the project stores.
2. Write the project to the card with the panel's documented save-to-card function, and leave the card seated if the save ran with the card in the panel; the panel then expects the card at its next power cycle.
3. Power the failed panel down, pull its Ethernet plug, and tag the cable end so nobody re-patches a live duplicate address.
4. Move the card into the spare panel, or seat the spare's own prepared card, and apply power. Give it one full boot: the panel loads the project, and the project applies its stored address in place of the spare's old number.
5. Open the panel's own setup or diagnostic screen and read the active address. It should read the project's 192.168.1.50. An address that still shows the spare's old number means the project never loaded, and the load is the thing to fix before anything else.
6. From a laptop on the same switch, ping the panel, then make one screen action write a value to the controller and watch the value land. Apply the same discipline as on a fresh panel-to-controller link: test writes before motion.

Scenario: the palletizer HMI fails at shift start, what does a prepared swap look like?

A palletizer panel at 192.168.1.50 dies at 06:40 with its controller at 192.168.1.10 and mask 255.255.255.0; the storeroom spare last ran at 192.168.1.75, and the prepared card in the panel's cabinet has the line back before the first pallet falls.

• 06:42. The failed panel is powered down, its plug pulled, the cable end tagged.
• 06:44. The cabinet card goes into the spare, power on, one full boot. The project loads and its panel setup writes 192.168.1.50 over the spare's stored 192.168.1.75.
• The subnet check, done on paper: 192.168.1.50 against 192.168.1.10. First three numbers match, 192.168.1; fourth numbers differ, 50 against 10. Same network, distinct device numbers, direct communication.
• 06:47. A laptop on the same switch pings 192.168.1.50 and gets a reply. One screen action writes a value to the controller and the value lands. The palletizer is released.

The counter-case shows why step 3 of the procedure is a hard step: leave the failed panel plugged in at 192.168.1.50 and both panels start dropping traffic, and the hunt moves to switches and cables while the pallets wait.

How do you check the spare took over cleanly?

Read the address where the panel displays it, reach the panel from a laptop on the same switch, and land one value in the controller: those three results, 192.168.1.50 shown, ping answered, write received, clear the swap for production.

Run them in order, because each one points at a different fault:

• Wrong project on the screen. The spare booted with its own stored project or an old card. Rewrite the card from the corrected project; if the download path misbehaves, the switch-side download fault is covered separately.
• Old spare address still shown. The project never loaded. Fix the boot and the card before touching anything on the network.
• Ping answers but the screen shows controller timeouts. The panel side is fine and the fault sits toward the controller; the first-setup Ethernet timeout checks apply here too.
• Write lands. Release the line, and update the label: which panel now runs, that the failed unit is retired, and the revision written.

Recommendation: Prepare one card for every panel whose failure stops a line, store it at the machine with the address plan on the label, and swap only after the failed panel is powered down and unplugged. Treat a spare with no prepared card as a half answer: without the project's stored address it cannot take the station's number correctly, and the swap turns back into a programming job at the worst possible hour.

Questions