One Label checkbox drives both the text beside the value and the text on the entry keypad, so an unlabeled field opens an unlabeled keypad. Copy the default keypad into a user-defined keypad, add a static text header naming the field, and assign that keypad to the entry object. Count unique headers first: one large project ended at about 50 keypads for more than 300 numeric entries.
Dense operator screens often show a column of bare numbers with no labels: the values sit close together, and each one is identified by position alone. Touch one of those numbers and the entry keypad opens with nothing on it to say which field is being edited. The entry object has no separate control for the two places a label can appear, so an unlabeled field carries no text onto its keypad. The fix is to give the keypad its own text: copy the default keypad into a user-defined keypad, add a static text header that names the field, and assign that keypad to the entry object. The panel help documents user-defined keypads as the way to change the layout of a Password, Numeric Entry, or Text Entry keypad. Below: the build, the count that sizes the job, the panel test, and the upkeep on a large project.
Why does an unlabeled numeric entry open an unlabeled keypad?
In the entry object, one Label checkbox controls both the text beside the value and the text the keypad shows, and switching it off grays out the label text field, so an unlabeled field has no text to carry onto the keypad. What the job needs is independent control: label off beside the value on the normal screen, identifying text on the keypad at entry time. Do not read the Label checkbox as a keypad-only setting; it is one display control for both places.
The supported route is the User Defined Keypad feature. The panel help documents it as the way to change the layout or size of a Password, Numeric Entry, or Text Entry keypad, with the keys built from the Key Button object. A keypad you define carries its own layout, so a static text header drawn across its top shows every time that keypad opens, and the normal screen keeps its bare value.
What do you need before you start?
You need the project open in the HMI programming software, the list of numeric entry fields that must stay unlabeled, the header text for each group, and a panel or simulator to test on: one keypad per unique header is the rule that sizes the job.
- The project file in the HMI programming software. If the panel runs a project you do not have on your PC, read the project from the panel before editing so the keypad work starts from the version that is actually running.
- The numeric entry fields that must stay unlabeled, listed in screen order with their neighbors noted, because grouping decisions come from the neighbors.
- Header text for every field or group, written before any keypad is built. The header is what the operator reads mid-entry, so it carries purpose and unit: Batch weight, kg.
- A simulator or the panel, for the test after the build.
How do you add a static text header to a user-defined keypad?
Copy the default keypad into a user-defined keypad, draw a static text header across its top, and assign that keypad to the entry object through the Keypad selector under Numeric Entrys in the lower-right of the object settings; the header then shows every time the keypad opens.
- Open the keypad database in the programming software: Menu > Database > Define Keypad.
- Copy and paste the default keypad. The copy becomes a user-defined keypad. Name it after the header text immediately, for example Batch weight kg, so the keypad database reads like the screen it serves.
- Leave the keys alone. The keypad's keys are Key Button objects, and the header changes none of what they send.
- Draw a static text object across the top strip of the layout and type the header: Batch weight, kg. Leave a margin so the text clears the top row of keys.
- Save the keypad.
- Open the numeric entry object and find the Keypad selector in the lower-right area, under Numeric Entrys. Change it to your user-defined keypad. Linking a user-defined keypad to an HMI numeric entry object covers that assignment in detail.
- Leave the object's Label display off, so the normal screen keeps its bare value.
- Repeat from step 2 for the next unique header.
Menu wording moves between software releases; the two places to find stay the same: the keypad database and the entry object's keypad selector.
How many user-defined keypads will your project need?
Count unique headers, not numeric entry objects: fields can share one keypad when a single header identifies each of them clearly, and a screen with 14 entries can need as few as 6 keypads.
- Fields share one keypad when one header names every field in the group accurately: same purpose, same unit, no ambiguity in context.
- Do not merge fields whose shared header would misname any of them. A header that reads Delay, s across two unlike timers tells the operator nothing at the moment of entry.
- Write each group's header, add the fields that need their own wording, and the total is the keypad count.
Example
A packaging line screen carries 14 numeric entry fields, tightly grouped: 6 oven zone temperature setpoints in °C, 4 conveyor time delays in s, and 4 values that each need their own wording: batch target weight in kg, mixer speed in %, a batch counter preset, and a target fill level in %. Two group headers cover the temperature setpoints and the conveyor delays, so the screen needs 6 keypads: 2 group keypads + 4 individual keypads. At 15 minutes per keypad to build, name, assign and panel-test, the job is 90 minutes (6 × 15). One keypad per field would be 14 keypads and 210 minutes (14 × 15), more than twice the work, with no extra information on the keypad.
How do you check the header shows on the panel?
Judge the result on the panel, in both display states: the normal screen must still show the bare value, and the keypad that opens on the field must carry that field's header, with a typed test value telling you the number landed in the right field.
Work down one list; each line passes or sends you to a fix.
- Normal screen: the value sits alone, with no label beside it.
- Touch the field: the keypad opens with that field's header, and the number keys behave as before.
- Type a known test value and commit it. The value changes on screen and in the controller, and the closest neighbor keeps its old value. Run this on the simulator, or on the panel with the line in a state where a changed value is harmless; a wrong setpoint on live equipment can stop or damage it.
- Repeat the selection test on the two fields spaced closest together. A wrong keypad assignment hides best where fields sit closest.
- If the label shows up on the normal screen, correct the object's Label setting. If the header is missing or wrong, recheck the Keypad assignment and the header text on the assigned keypad.
Do not duplicate the pattern across the project until both display states and the target-field test pass.
What does this cost on a project with hundreds of entries?
Budget roughly 15 minutes per keypad for build, naming, assignment and panel test, and expect grouping to land near one keypad per six entries: one large project finished at about 50 keypads for more than 300 numeric entries, about 12.5 hours at that rate.
Three things move that figure: how much the headers group, how much panel testing each keypad gets, and how often you recheck copied objects. On a project of a few hundred entries, the maintenance is where the cost hides.
- Name each keypad after its header text, so the keypad database reads like the screen.
- A copied numeric entry object carries its keypad assignment with it. A pasted field can open another field's keypad until you reassign it, and the error shows only at entry time, so retest every object you copy or move.
- Keep the field-to-keypad mapping in the project notes. At 50 keypads, the mapping is the documentation.
- Take a master copy of the project before a batch of keypad work; HMI project upload protection: keep a master copy covers the habit.
When should you label the field on the screen instead?
Put the label on the normal screen when operators need field identification outside entry too, or when the build time for the keypads outweighs the screen space a visible label needs.
A keypad header identifies the field at the moment of entry. An on-screen label also helps while the operator browses, compares values, or hunts for the right number after a fault. That visibility costs screen space, which is what dense screens lack, so take the middle path when both matter: a group caption reading Oven temperatures, °C plus per-field keypad headers reading Zone 3, °C labels the screen lightly and still names the field at entry. If the real problem is that the screen has no room, moving notice-style values onto a separate display frees space; shop-floor signage displays built for plants play offline content or run your own Android app.
Recommendation: Give every unlabeled numeric entry a user-defined keypad header on dense screens where operators pick fields by position: copy the default keypad, add the static text header, assign it under Numeric Entrys, and pass the panel test in both display states before duplicating. Group fields that one header names accurately so the count stays well under one keypad per entry; if nearly every field needs its own wording, label the screen and skip the keypad fleet.
Questions
Does the same user-defined keypad trick work on password and text entry fields?
The panel help documents the User Defined Keypad for Password, Numeric Entry, and Text Entry keypads, so the same method identifies any entry field that must stay unlabeled on the normal screen. Copy the default keypad for that entry type, draw the header, and assign it as you would for a numeric entry, wording the header for the field or group it serves.
Is there a character limit for the keypad header text?
There is no separate character count to stay under. The header is static text you draw into the keypad layout, so its length is limited by the width you give it at the font size you chose. Keep it short enough to clear the top row of keys, and check the fit on the panel at the operator's working distance.
Can one keypad show a different header for each field it serves?
No. A keypad layout is drawn once and opens the same for every entry object assigned to it, so each wording needs a keypad of its own. That is why the header count drives the build time: grouping fields under one accurate header is what keeps the count down on a large project.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.