Set an HMI internal tag value or use static text for a fixed label

Should a fixed version label be static text or an internal tag?

Use static text whenever the label never changes while the project runs. A display-only text object with no text-entry control gives the operator no way to change it, so a fixed 4-character label such as "V2.4" needs no internal tag at all. Static text carries the string inside the project file. There is no tag to declare, no write path to document and no persistency setting to remember.

Your worry about someone changing the formatting is answered by the object type. Formatting such as font, size and color is a property of the project, set in the editor. A display-only object offers the operator nothing to select or type into. What remains is project control, which is a separate door. Anyone holding the programming software can reword the label, so treat the editor and the deployed project the way you treat any engineering tool: saved copies and a known good download.

Recommendation: use static text for a version label that is fixed for the life of the project. Reserve an internal tag for values that change while the project runs, and set the non-volatile or persistency option when such a value must survive a restart.

What decides the choice between an internal tag and static text?

One question decides it: does the value change while the project runs? If it never changes, static text wins on every count. If it must change by product, recipe, shift or operator action, the value needs a tag and a documented way to write it.

Apply the test to the version label. The string is constant for every minute a given project runs. It changes only when engineering loads a different project, and the new project brings its own text. That makes it static by definition.

The test flips when the panel must show something the process sets: a batch code arriving from the PLC, a product name that follows a recipe, or a message an operator selects from a list. Those values live in tags. The screen needs a display object bound to the tag plus a documented write path, the same pattern as a dynamic text label beside static pushbuttons.

What does each option cost you to set up and maintain?

Static text costs one object per screen and nothing else. For a 4-character version label that is 1 item to draw and 0 tags to declare. A tag-based label costs at least 3 items: the tag, the display object and a documented write path.

The last row is the only one that invites an edit, and a version label should never sit in it. The middle rows earn their extra maintenance only when something at runtime writes the tag. If nothing does, the tag adds two ways the screen can go wrong: a value that was never set, and a value that no longer matches the loaded project.

How do you stop an operator from changing the label?

Leave the text object display-only. With no text-entry control paired to it, the screen offers zero ways to type or select a new value. The panel documentation describes text entry as a separate object that writes to a register.

The editor's own help draws this line between the two objects. The text display shows a value. The text entry object writes typed characters to a register, in the entry styles your editor documents. Leave the entry object off the screen and the label has no on-panel edit path. Since formatting lives in the project too, the operator cannot reflow the text either.

If the panel also carries engineering screens, gate them with screen access control for a protected operator view so a curious operator cannot reach an editable page at all. Then test with the operator's normal access, on the running panel, not in the editor preview.

When does the value need an internal tag after all?

Add a tag only when the displayed value must change while the project runs, for example a label that switches among 6 program variants by product. The tag then needs a display object that reads it and a documented write path, such as a value set by the PLC.

Any of these counts as a runtime change. The PLC writes the string over its link when a batch starts. A recipe copy loads a product name. A script updates a message on a schedule. Build it as tag plus display object plus write path, and close the design with retention. Internal tag values are lost when the project restarts unless the runtime's non-volatile or persistency option is set. Where HMI internal tag retention survives power-off and download covers where each method holds.

Example: static text or a tag for 6 program variants on 12 panels?

A plant runs 12 identical filling machines on 6 program variants, each panel a 10.1-inch model showing a 4-character label such as "V2.4". Static text keeps 6 objects and 0 tags. A tag-based label keeps 18 items to configure and keep aligned.

The fleet breaks down as 2 machines on V1.9, 4 on V2.0 and 6 on V2.4, which is 12 panels across 6 projects.

Option A, one internal tag per variant: 6 tags, 6 display objects and 6 write paths. That is 6 × 3 = 18 items to configure. Each download must keep the tag's value in step with the project it travels with, and a persistency decision rides on every tag.

Option B, static text: one text object per project, so 6 objects across the fleet, 0 tags and 0 persistency settings. Each label is edited once, at the download that installs its variant.

The count decides it: 6 items against 18. Option B also removes the mismatch case where the tag reads V2.0 while the loaded project is V2.4. Because the string never changes while its project runs, static text is the right build for all 12 panels. If a future variant must also show a batch code set by the PLC, that new value gets its own tag under the test in the section above, while the version string stays static.

What do you check before you call the job done?

Run two checks before you sign off. Operate the running panel exactly as an operator would and confirm the label cannot be edited. Then confirm the project version on the screen matches the project you just saved.

Then work the list:

1. Touch the label and open every page an operator can reach. Confirm no keypad or selector offers a new value anywhere.
2. Read the string on the panel and match it to the project you saved. The version label doubles as your proof of which project is loaded.
3. For a tag-based label, force the write path once and watch the value arrive. Power-cycle the panel if the value must survive a restart.
4. Record the version string and the download date in the change log, so the next engineer knows what is on each panel.

If you are choosing a panel for new work, ask the maker's documentation two things before you buy. First, the exact name of the non-volatile or persistency setting for internal tags in your editor version. Second, the entry object styles that decide when a field can be typed into. Both are printed in the tag and object help pages, and neither is a detail you want to discover on site.

Which other labels deserve the same treatment?

Any string that is fixed for the life of the project gets static text: the station name, the units caption beside a numeric field, a safety instruction line, a full page of process text. All of it is carried in the project with 0 tags behind it.

Apply the same test to every string on the screen and the boundaries fall out on their own. Static text also scales past one short line. A full page of static text on an HMI screen covers the layout side for larger text blocks.

Keep one more distinction in view as you plan the cabinet. The HMI shows machine state and belongs to the controls project. A separate notice or andon-style status board is a different screen with a different job. If a cell needs one, our shop-floor signage screens play their own content from a memory card with no subscription. They are not HMIs and take no video input, so the machine project stays untouched.

Questions