Choosing an HMI panel: test startup and runtime first

What the operating system changes

A proprietary-platform panel loads its own firmware and little else. A Windows-CE-based panel boots an entire operating system first, and Windows CE initializes its drivers one after another during that boot, so a single slow driver holds up the whole sequence. Vendor boot-trim guidance for Windows Embedded Compact puts the recoverable time in exactly those places: serial startup work and startup self-tests that can be disabled. Proprietary firmware skips most of that by design, loading only what the runtime needs, which is where the difference in the table below comes from.

The operating system choice stays invisible once the runtime is up. The same project run on both panel classes updated data and accepted operator entries with no reported difference. Windows CE is a real-time operating system by design, with deterministic interrupt latency, which is why panel builders put it inside operator terminals at all.

The two classes side by side

The acceptance test before you buy

1. Set the finish line: the first screen that accepts operator input. If the candidate parks on a splash page or an empty start screen after boot, set the startup screen first, then time it.
2. Time three cold starts. Off at the disconnect, wait for full shutdown, apply power, stopwatch running to the touch-ready screen. Write down all three runs and judge on the slowest. Time the incumbent panel the same way.
3. Run your project, not a demo. Load the finished project, run the machine at production speed, and watch the fastest-changing values while an operator makes the entries the cycle demands. If updates lag, check the poll cycle and the panel-to-device communication delay in the system settings before blaming the operating system.
4. Cut power once, with the machine idle, and confirm the project comes back on its own. A panel that boots and then sits at the operating system because the visualization never started has a failed project transfer: reload and retime. If the project vanishes after a power cycle, that is a separate fault, and why an HMI panel loses its project after a power cycle names the checks.
5. Record the installed firmware revision before and after any project transfer; the firmware revision check takes a minute and prevents a mismatched package.

Cut power only when the machine is idle or at a safe state; a power-cycle test in a running cycle is an unplanned stop you did not script.

Check: the candidate passes when its slowest cold start fits the restart schedule priced in the example below, and when data updates and operator entries match the incumbent panel entry for entry under load.

Example: pricing the boot on your restart schedule

Scenario: a packaging line starts twice per working day over 250 working days, so 2 x 250 = 500 starts a year. The incumbent proprietary panel times 5 s to its first screen, the top of its reported 2-5 s range. The candidate Windows-CE panel times 20 s, the top of its 15-20 s range.

• Proprietary: 500 starts x 5 s = 2,500 s = 42 min of boot wait a year.
• Windows CE: 500 starts x 20 s = 10,000 s = 167 min, about 2.8 h a year.
• Gap: 125 min a year, on a line that runs 4,000 h (16 h x 250 days).

Two hours of accumulated operator waiting across a year is noise; if the CE panel's data logging earns its keep, accept the boot. Now move the schedule. A line with hourly changeovers starts 16 times a day: 16 x 250 = 4,000 starts a year. The same 15 s gap becomes 4,000 x 15 s = 60,000 s = 16.7 h of boot screen a year, close to two operator shifts of pure waiting. On that schedule the boot decides the purchase, and the proprietary panel stays unless a timed test shows the CE panel's trimmed boot fits the changeover.

When each class wins

Stay proprietary when the restarts land on an operator: hourly changeovers, a panel that is the first screen up after every stop, no logging requirement, and project changes rare enough that the PC trip costs nothing. Choose the Windows-CE-based panel when the added function pays: data logging for quality records, higher resolution on the same diagonal, or updates loaded on the floor from a USB stick. Resolution only pays on the right diagonal, and viewing distance sets that; the screen-size guide carries the arithmetic.

Whichever class you buy, a failed-panel replacement is its own exercise: match the protocol to the PLC before the swap so the new panel talks to the controller on day one.

What to ask for before the purchase order

• A measured cold-start time, power on to first operator screen, for the exact model number and firmware you will receive, not a family brochure figure.
• What startup work the shipping image already trims: serial driver loads and startup self-tests are where a Windows-CE panel's boot seconds hide, and the vendor's boot documentation lists what can be disabled.
• Whether your model loads a project package from a USB stick through its own screens, and which firmware revision the procedure needs.
• Where the poll interval and the panel-to-device communication delay live in the settings, so a slow-update complaint later is a two-minute check.
• The startup screen setting, so the panel lands on the operator's screen and your timed start measures real boot, not a splash delay.

Recommendation: Shortlist both classes, then buy the panel whose exact model and finished project pass the timed test: price the boot gap against your starts per year using the example above, and require the candidate to match the incumbent panel's data updates and operator entries under production load. Take the Windows-CE-based panel when logging, resolution or USB project loading earns its keep on a line that starts a few times a day; stay proprietary when the line restarts hourly and the boot screen would sit in front of an operator all year.

Questions