Fix an HMI white screen lockup using the release note first

What the version 2.75 note gives you

A release note item hands you three facts: the symptom, the device pairing that triggers it, and the version that carries the correction. The 7/2/2012 list for EA7 version 2.75 carries the correction as item 9, the numbering used in the copy of the note that circulated in the field. The vendor's own C-more EA7 firmware history page lists the same correction under version 2.75 and numbers its entries in its own order, so search by the symptom line and the version, not by the item number.

The note names the P3000. One installation that matched the item ran a T12C panel against a CPU-550 over Ethernet, the PAC 3000 pairing in question. The pairing field is where the value sits: search the history for your controller model together with the words white screen and lockup, not only for your own part numbers. If the symptom line matches, the controller matches, and the installed version is older than the corrected one, you have your answer, and it is not in the cable cart.

What the symptom pattern points to

Match your symptom to one of these, and take the first move it names.

• White screen or freeze while the Ethernet link LEDs stay lit. The physical link held and the panel stopped drawing. That combination points at the panel's runtime or its firmware, so the release note check comes before any cable work.
• The fault shows up only while connected to one controller family. Pairing-specific behaviour is the signature of a firmware fault. Search the history for that controller model. It is the same shape as the case where one PLC model drops communications while the rest hold: the fault lives in the pairing, and the cabinet wiring stays innocent.
• One panel fails while identical panels on the same project and path hold. In the field case, several T12 and T15 panels shared one project and only one misbehaved. After the version check, a fault that stays with a single panel points at that panel.
• White screen immediately after an operating system or firmware update. Different fault, different first move: the update failed or does not match the panel, so follow the vendor's documented recovery. For a KTP1000 showing a white screen after an OS update, the documented path runs from the project's device list into Hmi Device Maintenance and a Reset to factory settings, as described in the vendor's own support documentation. Never re-flash from an unofficial image.
• Dark screen and no link LEDs. Power and cabling first. This is the one case where the multimeter comes before the release notes.

Checks, in this order

1. Record the versions. Panel model, controller model, connection type, installed firmware version, project software version. The panel's own setup screens and the project software on your PC both report them; the field procedure is in reading an HMI panel firmware version for field maintenance. Write the date next to the readings.
2. Search the history for the pairing. Controller model plus the symptom words. If the installed version predates the version that lists your symptom, stop diagnosing and schedule the update.
3. Verify the link once. Cable, both terminations, and the link LEDs observed during a lockup. A stable link through a frozen screen, with terminations that check out, ends the electrical work. Stacking ferrites after that is time spent on a fault the release note already covers.
4. Run the controlled swap. Put a known-good panel on the suspect connection, or the suspect panel on a known-good connection, and change one thing at a time. The swap procedure, including flash card and project IP handling, is in swapping a faulty HMI panel using a flash card and its project IP. Fault follows the panel: hardware. Fault stays with the port or the path: network or controller.

Example: a T12C locking up against a CPU-550 over Ethernet

Inputs, each with its source:

• Panel T12C, controller CPU-550, Ethernet connection: the PAC 3000 pairing. Symptom: white screen or lockup on this panel only, while the other T12 and T15 panels on the same project held. (the field case)
• Support answer on May 22, 2012: no reported lockups or white screens on that pairing. (dated)
• Correction: version 2.75, item 9, published 7/2/2012. (dated)

Rule in words: a support answer is current to the day it is given, and once a release note names your symptom and your pairing, the installed version decides the first corrective action.

Arithmetic: May 22 to July 2, 2012. May has 31 days, so 31 - 22 = 9 days left in May. June adds 30. July 2 adds 2. 9 + 30 + 2 = 41 days between the no-known-issues answer and the published fix.

Result: 41 days.

Decision: from July 2, 2012 onward the answer of record was stale. The first move the record supported was the version check, then the documented update for a pre-2.75 panel, and the swap only as the tiebreak: fault still present after the update means the panel, fault gone means the cabinet was never the problem. In the case as it played out, the panel was replaced before anyone re-read the history, and the ferrite and wiring days went to a fault the release note already owned.

The fix, in order

1. Back up the project with the vendor's documented backup procedure and record the installed version.
2. Apply the update to the corrected version, using the vendor's own instructions and firmware files. Power stays on for the entire write. A firmware write interrupted by a power cut is the fastest way to turn a lockup into a panel that never boots again, so pick a maintenance window and a supply you trust.
3. Read the version back off the panel when the write finishes.
4. Return the panel to the same controller and path used for the baseline, and verify the fix: clean boot, live controller data updating on screen, the operator actions the machine requires, and a run through whatever preceded the earlier lockups.
5. Replace the panel only when it already ran the corrected version before you started, or the fault returns after a correct update and the swap test made the fault follow the panel. Read the replacement's version before it goes on the wall; a panel carrying old firmware brings the same fault back.

The decision

Recommendation: Search the vendor's firmware history for your controller model together with the words white screen and lockup before any wiring work. If the installed version is older than the version that lists your symptom, schedule the documented update as the first fix and verify it with a live-data run. Fit ferrites and re-terminate only after that, and only once. Replace the panel only when it already runs the corrected version, or a controlled swap makes the fault follow it after a correct update.

Questions