Build a custom HMI keypad and overlay key graphics

What you need

• Editor access to the project, and a saved copy of it. All edits below go into the copy.
• The Key Button object, in the Buttons section of the Object List. It is the active input; a static bitmap is a picture and never an input.
• A bitmap source for the key faces: the editor's STATIC BITMAP > SYMBOL path, which includes a "computer key" group, plus per-key background colours.
• A throwaway test target: a numeric entry object on a test screen, standing in for the real setpoint during first runs.
• Two numbers from the panel datasheet, active screen width in millimetres and horizontal pixel count, for converting key sizes to pixels.
• The operating distance: how far the operator stands from the panel when entering values.

Size the keys before you draw anything

Three limits decide the layout, and graphics come after all of them.

Key size. MIL-STD-1472, the military human-factors standard, puts the minimum touch-activated key at 19 mm (0.75 in) across in at least one dimension. That assumes a bare fingertip; keys for gloved hands should match the gloved fingertip, which is wider. Convert the limit to pixels with the panel's pitch: divide the active width in millimetres by the horizontal pixel count, then divide the key size by that pitch.

Key gaps. Leave about 3 mm between active areas. An adult fingertip pad is 10 to 12 mm wide, and the contact patch spreads wider under a press, so the gap is what keeps an off-center press on one key instead of two.

Key labels. At a 2 ft (0.6 m) operating distance, the FHWA legibility planning figure of 20 ft of viewing distance per inch of capital height calls for 0.1 in (2.5 mm) capitals. On a panel with a 0.19 mm pitch that is about 13 px, so a 20 px digit label is comfortable on a 19 mm key.

Scenario: does a 12-key grid fit the panel?

The keypad is digits 0 through 9 plus Clear and Enter: 12 keys in 4 rows of 3, square keys, 15 px gaps, about 3 mm on both example panels.

Panel 1: 4.3-inch, 480 x 272 px, active area about 95 mm wide.

• Pitch: 95 mm / 480 px = 0.198 mm/px.
• 19 mm key in pixels: 19 / 0.198 = 96 px.
• Grid width: 3 x 96 + 2 x 15 = 318 px, inside the 480 px width.
• Grid height: 4 x 96 + 3 x 15 = 429 px against a 272 px screen height. It misses by 157 px.
• Squeezed into 272 px, each row gets (272 - 3 x 15 - 20 px of margins) / 4 = 51 px, and 51 x 0.198 = 10.1 mm per key, roughly half the minimum.

Panel 2: 7-inch, 800 x 480 px, active area about 152 mm wide.

• Pitch: 152 mm / 800 px = 0.190 mm/px.
• 19 mm key: 19 / 0.190 = 100 px.
• Grid: 3 x 100 + 2 x 15 = 330 px wide, 4 x 100 + 3 x 15 = 445 px tall. That leaves 35 px of height, about 6 mm for top and bottom margins, and 470 px of width for the entry display beside the keys.

Decision: on the 4.3-inch panel, keep the built-in keypad or replace the 12-key design with one row of three 19 mm trim keys (SET, -, +), which fits the height easily. On the 7-inch panel, build the full grid with 100 px keys and a 300 px entry display next to it.

Open a keypad definition and make a working copy

The editor keeps keypad designs apart from operating screens, under Database > Define Keypad. The defined keypads show up in the screen field, and the documentation calls a replacement design a user-defined keypad: a definition that can change the layout or size of a Numeric Entry, Text Entry or Password keypad.

1. Open Database > Define Keypad.
2. Right-click in the screen field and copy one of the built-in keypads as a starting point, or create a new screen. The built-in designs are short and worth opening first; each shows how the editor assembles keys into a working keypad.
3. Name the copy so the list tells the two apart.
4. Save the project, reopen the definition, and confirm the copy is listed while the original is untouched.

Work in the copy from here on.

Build the keys from Key Button objects

The active object is the Key Button in the Buttons section of the Object List. Its documented job is to input numbers or text into objects that require data entry, which is exactly what a keypad key does.

1. Place the numeric entry object on the keypad screen where the operator can watch the value fill in. How the two connect is covered in our article on linking a user-defined keypad to an HMI numeric entry object.
2. Add one Key Button per key: ten digits, Clear, Enter, and a decimal point if the target value needs one.
3. Configure each button for its function: the digit it sends, Clear, Enter.
4. Snap keys to the sizes from the scenario, 100 px squares with 15 px gaps on the 7-inch example.
5. If the entry must reach a specific register or a run of registers, wire that side now; one pattern is saving each entry to an indexed PLC table word, covered in our article on saving each HMI numeric entry to the next PLC table word.

Give the keypad a soft target for its first runs: the throwaway numeric entry object, never a live setpoint. A stray press during testing must not be able to move a value that a running batch or machine depends on.

Test the value before any graphics

Test what the target object receives, not what the screen looks like.

1. Press 1, 2, 5, 0 in order and watch the entry object: it should read 1250, with each press appending, not overwriting.
2. Enter 0 first and verify what the field does with a leading zero: accepted, stripped or rejected, and that the stored value matches what you decided.
3. Enter more digits than the field holds, press Clear, then enter again and confirm no leftover digits survive into the new entry.
4. Check both ends: the entry object showing 1250 and the register the process reads holding 1250 are two separate checks, and both must pass.

If a value arrives wrong, malformed or truncated, fix the entry logic here. Every problem fixed after the bitmaps go on costs a second pass over the graphics.

Overlay static bitmaps one key at a time

Once every key delivers the right value, restyle the faces. Static bitmaps placed over Key Button objects leave the buttons underneath working, so the graphic is a faceplate and the Key Button stays the input. The STATIC BITMAP > SYMBOL path includes a "computer key" group for realistic key faces, and background colours can be set per key.

1. Add one bitmap over one key, sized to cover that key's active area, never the neighbour's.
2. Run the project on the panel and press that key at its visible center. The editor preview shows placement only; the press on the panel is the test that counts.
3. If the key stops responding, remove or move the most recent bitmap and press again. One step separates a graphic covering the active area from a disturbed button.
4. Repeat key by key, testing each before adding the next.

Keep the printed character inside each graphic readable at the operating distance, and give the operator confirmation that a press registered; our article on showing touch feedback on a transparent bitmap button covers that side. The same layering approach scales up: station select screens built from bitmap pushbutton overlays use it for a whole bank of buttons.

Keep password entry on its own path

The keypad that opens when an operator calls a password-protected object is its own case. Whether your definition restyles it depends on the software release, and your editor's help file says which way yours goes. Settling it takes one test: invoke a protected object, look at the keypad that appears, and make a test entry. Keep this as a separate test case from ordinary entry, and see our article on password entry on an HMI panel with no touch screen for how the entry itself works on panels without touch. If your release keeps the password keypad built-in, leave it there. A keypad operators already know is fine to keep.

How to check it worked

Work down this list before the keypad goes into normal use:

• Every key fires when pressed at its visible center, and no neighbour fires with it.
• 1250 reaches the entry object and the register behind it as the same value.
• Leading zeros, overlength entries and Clear behave the way the test section decided.
• Every bitmap sits inside its own key, and the labels read from where the operator stands.
• The protected object opens with its own keypad and accepts the test password.
• After a shift of real use, no key shows missed or doubled presses. If response drags as the graphics went on, our article on fixing a slow HMI panel's touch and screen updates is the next stop.

When the keypad has passed every check in the list above, the rest of the cell is a different job. If the line also needs a screen that shows status or notices to everyone at once, that is a separate display doing a separate job, and our shop-floor signage covers it.

Recommendation: Build the custom keypad on a panel that gives each key at least 19 mm of active area, which on a pitch near 0.19 mm means 100 px squares with 15 px gaps, and verify the entry value on a throwaway object before the first bitmap goes on. On a panel too small for the grid, keep the built-in keypad and cut entry down to a few large trim keys. Test the password path separately before designing any screen around a restyled password keypad.

Questions