HMI white screen at startup: OFF-state visibility objects

What the white screen looks like

Five symptoms tell this story, and each points at one cause:

• White screen on the first boot of the day, no error. The panel may show its waiting-for-controller message while the controller powers up, then clear it, or come straight up white. Either way the link recovers and the screen stays white. The waiting message is normal startup behavior, typically gone within 10 to 30 seconds of the controller reaching run; the white screen after it clears is the fault.
• Always-visible objects draw, visibility objects do not. Static text and every object with no visibility condition appear. Every object using VisibilityOption to appear when its tag is OFF is missing. That split is the signature.
• One start-stop cycle restores everything. Turn the run bit ON, then OFF, and every missing object appears at once, within one scan of the transition. The draw needed a state change and the boot never supplied one.
• Swaps change nothing. The same project on a second identical panel and against a second controller family shows the same white screen. The fault follows the visibility logic, not the hardware.
• Power-up order decides it. Controller in run before the panel boots: objects draw. Panel first, or both powered together: white screen.

The deciding symptom is what happens after the waiting-for-controller message clears. Link up and live, OFF-state objects still missing: the fault is the panel's startup handling of visibility conditions. A screen that freezes mid-shift with an image already on it is a different problem, usually power, and HMI screen goes blank and freezes: check power first walks through that diagnosis.

Checks that confirm it in one shift

1. Read the tag while the screen is white. Monitor the run bit behind the missing objects from the controller side while the panel sits white: it reads OFF, exactly the state those objects are configured to show. The controller reports correctly and the panel is not drawing it.
2. Compare two objects on the same screen. Put an always-visible label beside a show-when-OFF message. Label draws, message missing: the visibility startup handling is the suspect.
3. Check the start screen setting. In this panel family the project setting is Start Screen Number in Panel Manager. Confirm a screen with that number exists. A start screen number with no matching screen is a different fault, and HMI panel shows no power up screen: set the startup screen covers it.
4. Run both power-up orders once each. Order A: controller powered first, in run before the panel boots. Order B: both powered together, with 10 seconds between switch-on and the controller reaching run. Objects draw in A and stay hidden in B: that is the fault.
5. Force one transition. With the machine clear to cycle, press start, then stop. Every missing object back after that single ON-to-OFF sequence: confirmed.

Do not chase the link after these checks. A link fault holds the waiting-for-controller message on screen; here the message clears and the objects stay hidden anyway.

Why the first draw misses OFF-state objects

Show-when-OFF is an intended configuration. Visibility gives an object a tag name plus the condition under which that tag makes the object visible, and the panel help documentation describes it in those terms; the documentation of another HMI family defines a Visible State of Off as the object hidden while its expression is true.

The fault sits in the first evaluation. At boot the panel draws its first screen before the controller is in run, so the tag has no live value yet. When communications establish, the tag arrives already OFF, the condition is already satisfied, and the objects never draw. The tests show a draw following a change of state, and an already-satisfied condition at boot produces no change; the first ON-to-OFF transition after startup is the first change the logic sees, which is why one start-stop cycle restores the whole screen. The panel maker confirmed the behavior as a firmware bug, and the workaround it issued is a different startup screen. The fault is confined to that first evaluation: once any transition arrives, the objects behave normally for the rest of the run.

The startup screen fix

The startup screen should be something the panel can draw from the project alone: static text and objects with no visibility condition. Machine or line name, a clock, a fixed line such as CONTROLLER STARTING. It can also carry an HMI splash screen shown for a set time on power up if you want the wait to do some work; 3 to 5 seconds covers a typical controller start.

1. Build or pick the screen. Nothing on it uses VisibilityOption or any other visibility condition.
2. Set it as the boot screen: Start Screen Number in Panel Manager, and confirm a screen with that number exists.
3. Download the project, then power panel and controller together, the exact condition that produced the white screen.
4. Check the boot: startup screen up at once, the waiting-for-controller message comes and goes, and the screen is complete.
5. Move to the operating screen once the controller is in run. If the project uses PLC-to-panel switching, the Switch to Screen Number function can make the move when the controller enters run; otherwise the operator navigates.
6. Repeat the whole test on the next cold start before releasing the project. Two clean cold boots, about 5 minutes of testing, is enough.

On the operating screen the OFF-state objects draw normally, because the panel is now past the first evaluation and behaves as it does in the controller-first order. Watch that step once on your machine; the workaround depends on it.

The inverted status bit fix

When the operating screen itself has to be correct at boot, change the logic instead. Add one rung per signal that writes the opposite of the machine state into a new status bit: the run bit drives a coil that is ON only while the machine is stopped. The reported project did it with a single rung that reversed input bit I:0.01 into O:0.1. Then set every object to appear when the status bit is ON, so the draw no longer depends on an OFF state.

Three rules keep the inversion safe:

• Write the bit every scan. A bit written unconditionally each scan carries a defined value from the first scan after the overnight power-down. The retention behavior behind that is covered in initialize PLC bits to a safe state after a long power outage.
• Keep the bit dedicated. Never flip the polarity of a bit that an interlock or a safety function reads. Leave those signals untouched, give the display bit its own name and address, and reuse nothing.
• Move every OFF-state condition to the new bit. Each object that appeared when the run bit was OFF now appears when the status bit is ON, and the same bit can drive two-state text so the wording stays consistent, as in show two text states on an HMI from one PLC bit.

Then run the two power-up orders and both machine states, running and stopped. If your panel and firmware miss the ON state at the first evaluation too, keep the startup screen fix in front; the both-together boot tells you in one start.

Example: one machine through the checks and the fix

Example project: a 4-inch panel on a machine that sits powered down overnight, 8 hours or more, panel firmware 3.20.10, project software 3.01. The boot screen carries a static title, a MOTOR STOPPED message and 6 buttons, and every conditional object is set to appear when the motor-run bit B3:0.0 is OFF. That is 7 visibility objects on one screen, all keyed to the OFF state.

First boot of the day, panel and controller powered together. The waiting-for-controller message appears, clears about 15 seconds later when the controller reaches run, and the screen draws white. The title draws; the MOTOR STOPPED message and the buttons do not. B3:0.0 monitors OFF while the screen sits white, so the controller reports the state the objects should show. One start-stop cycle, one ON-to-OFF transition, brings the message and all 6 buttons back together.

Four checks, four matching verdicts. Second identical panel: white. Second controller family: white. Panel firmware 3.20.10 and project software 3.01: white on both. Controller in run before the panel: objects draw. Verdict: startup visibility fault, not wiring, not the link, not the tag values.

Fix applied: a startup screen with the machine name and a fixed CONTROLLER STARTING line, no visibility conditions, set as the boot screen in Panel Manager and downloaded. Next cold start, both powered together: startup screen up immediately, controller reaches run about 15 seconds in, the PLC switches to the operating screen, and the MOTOR STOPPED message and buttons are all present with the machine still stopped. No transition needed. Decision: the startup screen stays in the project and the power-up order stays free.

Which fix to use

Recommendation: set a startup screen with no visibility objects as the panel's first screen and switch to the operating screen when the controller is in run. Apply it on every machine showing this fault: it needs no logic changes, and it is the workaround the panel maker issued. Use the inverted status bit instead on a screen that must show operating objects at boot: one rung per signal, a dedicated bit written every scan, objects shown on ON, both power-up orders tested before release.

Two things to leave alone. Do not delay panel power to dodge the fault; the order test is for diagnosis, and a production machine cannot hold a power-up schedule. Do not change panel software versions on an unconfirmed suggestion: the fault shows on 3.20.10 and on 3.01, and no version change on offer has a test behind it. For a firmware path for your exact model, send the project file to the panel maker's support and ask.

Questions