What an HMI background screen is for and how to use it

What a background screen is

Most HMI project editors let each screen use a background screen: a second sheet of objects that sits behind the screen's own objects. Anything placed on the background appears on every screen assigned to it. Anything placed on the screen itself appears only there. The screen's own objects sit in front, so the shared parts read as the fixed frame and the screen's parts read as the content.

Two uses cover most projects:

• A row of standard buttons and the base color, shared by every screen in a slot-storage application.
• A company logo that must appear on every screen, placed once instead of once per screen.

What belongs on the background and what stays on the screen

Put on the background only what every assigned screen shares exactly: the base color, the logo, the navigation row, a header whose wording is identical on each screen. Put on each screen everything that differs: the slot label, the recipe button, live values, alarms tied to that screen.

The test for one element is simple. If two screens would ever show it differently, it belongs on the screens. If no screen would ever show it differently, it belongs on the background.

A caution banner with identical wording can go on the background. The warning that qualifies one action, such as the text telling the operator which slot a transfer will overwrite, belongs on the same screen as the button that starts it. An operator about to press a transfer button reads what sits next to that button, so that is where the warning lives. Elements that must stay in place while the operator moves between screens follow the same thinking; the wider pattern is a persistent HMI layout.

A worked example: 20 slot screens, 2 objects each

The scenario: a machine on a panel of 1920 x 1080 pixels stores parameter sets in 20 slots. Choosing a slot opens its own screen with caution information and the recipe button that transfers the data. The 20 screens are identical except for the slot label and that button.

Inputs:

• 20 screens, one per storage slot.
• 2 objects per screen that differ: the label and the recipe button.
• 1 background screen holding the standard button row and the base color.

The rule in words: shared elements are placed once, on the background. Differing elements are placed once per screen, on the screen.

The arithmetic:

• Screen-specific placements: 20 screens × 2 objects = 40 placements.
• Shared button row: 1 placement on the background. Copied onto each screen instead, the same row takes 20 placements.
• Moving one standard button later in the job: 1 edit on the background. Copied onto each screen, the same move takes 20 edits and leaves 19 chances to miss one.

The result: the background places the shared row once and holds every later change to it at one edit. The screens carry 40 placements of genuinely different content, which is work no layer removes. Before committing to 20 slots, plan the row count against the recipe table row limit so the layout never outruns the recipe table. If typing 20 labels by hand is the worry, drive the label from the stored slot name instead of fixed text; showing a saved name on an HMI screen covers that route.

Decision: 20 screens sharing one fixed layout with only 2 objects differing is exactly the case a background is built for.

Recommendation: build one background screen whenever three or more screens share the same fixed elements; with two screens, copy the objects, and with one screen there is nothing to share. Keep the label, the recipe button and any warning tied to one slot on the individual screens, whatever the count.

What the background never holds

The background is a layout layer. It stores no parameter values, it remembers no selected slot and it runs no transfer. Recipe transfer on an HMI panel is a documented runtime action: the panel loads values from the recipe store into the controller. That action belongs to the recipe system and to the button configured on the slot screen.

So the division of labor is fixed:

• The background: what the screens look like.
• The screen: which slot is named and which button starts the transfer.
• The recipe system: where the values sit and how they move.

Writing the operator's entries into a recipe store is its own job with its own button set; saving HMI screen input to recipe storage walks that path. And before any shared button is trusted, open its action and its destination in the project editor. A copied button with the wrong destination is a functional error on one screen. A background button with the wrong destination is the same error on all 20 screens at once.

Checking a screen that lost its shared elements

Shared content that disappears has three causes, and each points somewhere different:

• Missing on every screen: the element was never placed on the background, or the screens are not assigned to that background.
• Missing on one screen: that screen's background assignment differs from its neighbors, or one of its own objects covers the element's position.
• Present but wrong: the label or the button action, which are screen-specific objects and are meant to differ per slot.

Open a working screen and the failing one side by side in the editor and compare the background assignment first. The controls that assign a background to a screen live in the project editor's screen and panel setup pages; their exact names vary with the panel software version, so take them from that version's help.

Verifying the layout at runtime

Preview the project and walk all 20 screens, not just the first. On each one, confirm the shared row, the base color and the label. Press each shared button where it is safe to do so and confirm it lands on the same destination from every screen. For the slot screens, run one test transfer on a slot you can afford to overwrite, then read the values back from the controller before you call the job done.

Questions