Build a small backup HMI panel project that limps along

What should a backup HMI panel actually do?

A backup HMI panel should keep the machine in a controlled state with six to ten operator controls and the messages tied to them. It is a temporary reduced interface that holds production until the programmed replacement panel arrives, not a small copy of the 15-inch main screen.

Write the reduced set down before you open the design software. For each control, record four things: the operator action, the PLC tag it writes, the state change it should cause, and the indication that tells the operator the machine accepted the command. Six to ten is a working limit, not a taste. Past that, an operator under pressure stops distinguishing a requested action from a completed machine response, which is exactly the confusion a backup exists to prevent.

The cut also decides feasibility. If safe recovery depends on features the small panel cannot run, above all the main project's event pop-up system, the reduced project is not the recovery path for that machine. The plan then changes to a programmed spare, as the last section sets out.

Which message methods does a small panel support?

Three documented methods cover it: stacked static text shown by a visibility condition, lookup text where an integer tag picks a line from a text list, and dynamic text received as a string from the PLC. The main project's event pop-up system transfers to none of them.

• Stacked static text is the simplest to check. Put each message in its own text object, drive each object's visibility from its own tag, and confirm the conditions are mutually exclusive; the show-and-hide static text technique covers the mechanics.
• Lookup text is the best fit for a fixed alarm set: one integer drives the whole list, and a wording change happens in one place. How it relates to multi-state text is in lookup text versus multi-state text.
• Dynamic text takes its wording straight from the PLC, so it suits text that changes often or carries live values; embed a PLC variable in the message string for the value part. If the string arrives blank or scrambled, check the byte swap setting before rebuilding anything.

Prototype the chosen method with live PLC data before entering the full list. A method whose triggers and wording do not track the controller state is worse than no messages, because the operator acts on the wrong line.

How do you cut a 50-event alarm list down before you build?

Sort the full list once and keep only the alarms an operator must see to run the machine in reduced mode, dropping everything else to one catch-all line. Then record code, trigger tag, text and keep-or-drop for each event and store that inventory with the backup project.

The keep test is one question per event: does the operator have to see this to keep the machine in a controlled state? Alarms that stop an axis, stop material flow, or demand a clear-and-confirm stay. Advisories, trends, counts and maintenance-due notes drop to the catch-all. Record four columns for every event: its integer code, the tag or condition that raises it, the exact text, and keep or drop. Store the finished inventory next to the backup project file, because the next rebuild starts from it, and re-check every kept trigger against the PLC logic before it is entered.

Worked example: which of 50 alarms stay on the backup panel?

A packaging machine's 15-inch main panel shows 50 alarm pop-ups. Reduced running needs seven controls and a readout, and 14 of the 50 alarms make the operator act, so the backup carries seven controls, 14 numbered messages and one catch-all for the other 36.

The machine is a packer. Reduced mode must let an operator start, stop, jog, purge, enable feed, reset faults and acknowledge: seven controls, plus a cycle-count readout. Walk the 50 events with the keep test: 14 leave an axis faulted, stop flow, or require clear-and-confirm, so they stay; the other 36 are advisories and counts, so they drop. The arithmetic: 50 total - 14 kept = 36 undefined codes.

Map the codes for lookup text: 0 shows nothing, because reduced mode is running normally; codes 1 to 14 show the kept alarms; every code from 15 to 50 resolves to one catch-all line, Fault active: call maintenance. Any value the fault word can hold outside 1 to 14 lands on that catch-all, and forcing 37 from the PLC once proves the mapping.

Time to build, at a planning rate of 2 minutes to enter and first-check each message, longer on wording changes: 14 x 2 = 28 minutes of entry, then about an hour to check seven controls and 15 lines against the PLC. Call the first build a half-day with the load and the operator walkthrough; the next identical machine starts from the finished project file, so its build is a load and a retest.

What do you need before you build the backup project?

The backup panel with touch, the design software and cable, the archived main project, the PLC communication settings from it, the alarm inventory, and the printed reduced procedure; build from the archive, because the failed panel gives its project back to nobody.

• The backup panel, with touch.
• A PC with the panel design software and the programming cable.
• The archived copy of the main panel project, current with the machine's released revision; keep archives current with the safe backup-and-restore routine.
• The PLC communication settings: driver, port and station address, copied from the archived main project, not guessed off the hardware.
• The alarm inventory from the cut.
• The printed reduced-mode procedure that gets packed in the box.

How do you build and load the backup project?

Start a new project for the backup panel, copy only the communication settings from the archived main project, build the controls and the kept messages with their catch-all, load it from the PC, and label the panel. The first build fits in a half-day, and later copies load in minutes.

1. Create a new project for the backup panel's model. Do not open the main project file and delete your way down; a cloned project carries object types and features the small panel cannot run.
2. Copy the communication settings from the archived main project: driver, port, station address.
3. Build the controls, six to ten of them. For each, record the operator action, the tag it writes, the PLC change it should cause, and the indication that shows the machine accepted it.
4. Enter the kept messages as lookup text: code 0 blank, codes 1 to 14 for the kept alarms, and one catch-all line assigned to every other code, following the worked example's numbering.
5. Where a message uses stacked static text, set each visibility condition and confirm no two conditions can be true at once.
6. Load the project from the PC to the panel.
7. Label the panel with its machine, and print the reduced procedure: what the panel shows in each state, what each control does, and what to expect until the replacement arrives. Pack it in the panel's box with the inventory.

How do you prove the backup works before it ships?

Connect the backup panel to the machine's PLC and check each piece: every control moves the PLC value and the machine, every kept code shows its line, and an undefined code lands on the catch-all. A panel that only lights its own buttons has never been checked against the machine.

• With the PLC online, press each control and watch two things: the PLC value change, and the machine respond. A button that highlights on the panel has checked the screen and nothing about the machine.
• Force each kept code by writing 1 through 14 by hand, and read the exact line on the panel.
• Write an undefined code, 37 in the example, and confirm the catch-all appears.
• For dynamic text, send a known string and read it back character by character; garbled or blank means byte swap, then re-test.
• Run the printed procedure start to finish with an operator who knows the machine.
• Sign the check sheet and pack it with the panel, the project file and the inventory.

When is a reduced backup panel the wrong plan?

When recovery needs more than six to ten controls, when operators depend on pop-up event features a small panel cannot show, or when the site will hold a programmed spare of the main panel, keep the programmed spare instead; the reduced panel is not the recovery path in those cases.

Three cases take that road. If the cut leaves more controls than an operator can manage, if the kept list still holds most of the 50, or if reduced running risks product or tooling, the recovery plan is a programmed spare of the main panel. A machine that cannot run safely in reduced mode gets no reduced panel at all, only the spare arrangement. And where a customer site will hold a programmed spare of its own, that beats a reduced backup, because it restores the full interface in minutes.

Recommendation: ship the reduced backup panel with a machine when the cut leaves six to ten controls and a kept list on the worked example's scale, about a dozen lines, and the panel has passed every PLC check before it goes in the box. Keep the programmed spare of the main panel, with software, archive and cable, at the factory for machines whose cut fails that scale, and make the factory the spare's home wherever a site will not hold one.

One line stands above the arithmetic: if reduced mode hides an interlock state or a confirmation the machine needs before it moves, that machine gets no reduced backup. Buttons that light on an incomplete interface are the failure this plan exists to prevent.

Where the real need is a line-side notice board that repeats status to everyone on a shift, that is a separate screen with its own job; see shop-floor screens and andon-style boards.

Questions