Keep machine settings behind a PIN keypad that masks each digit as an asterisk, give each machine one status screen and one settings screen, and let 12 stored trends cover two machines from one small panel. Budget a typical 13 ms scan plus one rotation spike a day, and set the scan watchdog above that spike.
A small machine panel works best when it is designed like a control desk. One status screen the operator never has to leave, one settings screen per machine behind a PIN, and trend storage planned before the first power cut. Three numbers carry that layout on a panel as small as 3 inches. The screen count is about 30 for two machines, split into 8 settings screens and 12 trend windows. The PIN mask is one asterisk per digit. The scan budget is a typical 13 ms with a single spike when the day's trend data rotates. This page works through each number, what it assumes, and what it changes on the panel in front of you.
How many screens does one small touch panel need?
Budget one status screen and one settings screen per machine, and count on roughly 30 screens in total for a two-machine build on a 3-inch panel: 8 settings screens, 4 per machine, and 12 trend windows, 6 per machine. Every screen beyond that is a navigation decision someone has to learn, so the count is a design choice, not a leftover.
Group the screens by job. The status screen carries the values and alarms the operator acts on, and it is the screen the panel wakes up on. The settings screens carry setpoints and open only through the PIN gate. The trend windows read stored data and never hold a control. When a draft grows past this shape on a 3-inch panel, the hierarchy is usually duplicated somewhere, and merging two screens back into one beats adding a page of menus.
Pick the panel on startup and runtime behavior before you count screens: choosing an HMI panel by testing startup and runtime first lists what to measure before the layout is committed.
How do you keep settings screens behind a PIN?
Put one PIN entry screen between navigation and the settings group. Set the length and complexity of that PIN in the panel software's password policy settings, where the software documents that option; your panel's own manual prints the exact location. A wrong entry shows a plain access-denied message and returns the operator to the status screen, so the failed attempt leaves no trail of half-open screens.
The wider access-control layer, roles and the protected operator view, is covered in HMI screen access control for a protected operator view; this page stays on the keypad and the screen layout. One safety line belongs here: the PIN protects setpoints from casual change, and it is not a safety function. Keep each machine's independent stop path and interlocks wired outside the panel, so no password stands between an operator and a moving part.
How should the PIN keypad mask the digits as they are typed?
Show one asterisk and one space, * , in a row above the keypad for every digit typed, so a 4-digit PIN reads **** when complete and the digits themselves never appear on the screen. That is the whole mask: a text object, one cell per digit, refreshed on each key press.
What it changes on a real panel: reserve the top row of the entry screen for the mask and make each cell as wide as a keypad key, so the count reads at a glance from the side of the machine. Clear the row on a rejected PIN and on a timeout, so the next operator starts from zero and cannot inherit half a code. On a resistive single-touch panel, give every key its own full cell so a press lands on one digit, which is the same layout problem as designing a touch screen keyboard shift key on a single-touch panel. Shoulder-surfing a small panel is easy; the mask removes the payoff.
How much scan time does daily trend rotation take?
Budget a spike, not a steady load. A two-machine build with 12 stored trends ran a typical scan of about 13 ms and hit one rotation spike of about 80 ms once a day, when the day's trend data rotated. The arithmetic: 80 ms ÷ 13 ms ≈ 6, so the rotation scan runs about six times the typical scan.
Spread over a day of 86,400,000 ms, the spike is about one millionth of the day, which is why it hides in scan-time averages and then surprises someone watching a trend of scan times. Three decisions follow from that figure. Set any scan watchdog or communications timeout above the spike; a 100 ms threshold leaves 20 ms of headroom over it. Schedule the rotation at a fixed time of day when the machines are stopped, so the spike never lands inside a move. Write the spike into the handover notes, so the technician who sees one slow scan a day reads it as the rotation and not as a fault.
Where should the trend data live if power fails?
Treat panel memory as volatile until the documentation says otherwise. The archive you cannot afford to lose belongs outside the panel, because a build that kept its trends in panel memory alone lost them at the first power cut and moved to an external archive. Check your controller's own manual for what survives on its own: it documents load memory as the non-volatile storage for the user program, with the data areas separate.
So the program and the configuration ride through a power cut on their own, and the logged samples survive only where the logger writes them. Decide from the cost of a gap: if the trend only has to cover the current shift, panel storage is fine; if next week's process complaint needs a week of history, write the archive out. Archiving HMI trend data externally after a power cycle shows the archive pattern, and fitting a multi-hour temperature trend on an HMI without scrolling works out how the sample interval sets how many hours one window covers.
What does a worked example for two machines on one 3-inch panel look like?
Two machines share one 3-inch panel and one controller: just over 30 screens in total, of which 8 are settings screens behind the PIN gate and 12 are trend windows, with a typical scan of 13 ms and a single rotation spike once a day.
| Item | Value | Arithmetic or source |
|---|---|---|
| Screens in total | just over 30 | status, settings, trends, navigation |
| Settings screens | 8 | 2 machines × 4 per machine |
| Stored trends | 12 | 2 machines × 6 per machine |
| Status, trip and navigation screens | at least 10 | 30 − 8 − 12 |
| Typical scan | 13 ms | steady reading on the build |
| Rotation spike | once a day, about 6× the typical scan | daily trend data rotation |
| Watchdog setting | 100 ms | spike + 20 ms headroom |
| Program size | 236 rungs, 1,574 words | the whole two-machine control |
The decision this example supports: one 3-inch panel carries both machines, the operator works from a single status screen, and the only scan-time event worth writing into the handover notes is the rotation spike once a day. The whole two-machine control fit in 236 rungs and 1,574 words, which is the scale this hierarchy produces; a draft running at several times that usually means screens have been duplicated. The 12 trend windows behave exactly as configured once the extra sample in each chart is accounted for, which why an HMI trend chart plots one more sample than you configure works through.
When should the settings or trends move to a second screen?
Stay on one panel while one operator covers both machines from one spot; add a screen only when people who never touch the panel, such as maintenance or the office, need the status from across the room. Two machines and about 30 screens is the comfortable ceiling for a single 3-inch panel run by one person; past it, the fix is a panel at the second machine, not a deeper menu tree.
A wall board is a third job. It cannot mirror the machine panel, because on the signage displays we sell the HDMI port is an output and takes no signal from the controller. It plays its own copy: a small offline signage display from our wall and counter range plays slides straight from a memory card with no subscription, so the board shows the current counts and setpoint names as static slides, refreshed when someone changes the files on the card.
Recommendation: Keep the settings and the trends on the machine's own panel when one operator covers both machines from one spot: one status screen, one settings screen per machine behind a masked PIN, 12 stored trends, and any scan watchdog set above the rotation spike. Add a screen only for people who never touch the panel, and feed it from its own offline player, not from the controller's signal.
Questions
Does a PIN keypad protect the machine itself?
No. The PIN controls who can change setpoints on the screen, and nothing beyond that. It is not a safety function and does not replace a guarded stop, a lockable disconnect or the machine's own interlocks. Keep each machine's independent stop path wired outside the panel, so a forgotten password, a frozen screen or a dead panel can never leave an operator without a way to stop the machine.
How many digits should the PIN have?
Four digits give 10,000 combinations, because 10 × 10 × 10 × 10 = 10,000, and each extra digit multiplies the count by 10 again, so six digits give 1,000,000. The cost is one more key press per digit at entry, which matters when the operator wears gloves. Set the length in the panel software's password policy settings where the software documents that option, and pick the longest PIN the crew will still type on a cold morning.
Should a settings screen show the live value next to each setpoint?
Yes. A setpoint without its live value makes the operator leave the screen to check the effect of a change, and every navigation step is a chance to land on the wrong screen. Keep the live values read-only on the settings screens, keep the operator's control actions on the status screen, and the two jobs stay visibly separate.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.