A download the panel accepts and a pushbutton test that toggles a PLC bit show the link is good; the message path is separate. Check the programming software generation against the panel's firmware letter first: version 1 pairs with letter 'a', version 2 with letter 'B'. Then force the message's own trigger bit ON for 5 seconds and watch it; where the bit goes true and the text stays blank, the message assignment in the project is the fix.
A text panel that accepts a download and then shows nothing in RUN has already passed the checks most people repeat: the display draws its setup screens, the processor stores the project, and the cable reaches the PC. The blank screen is the runtime message path, and two faults stop it. Either the programming software generation does not match the panel's firmware generation, or the message's configured trigger never goes true. Check them in that order. The pushbutton test has done its job; run it once to confirm the link, then stop touching the cable. Read the firmware letter, compare it with the software generation on your PC, then watch the exact bit the project's message is conditioned on while you force it ON.
What each symptom points to
- Setup screens draw and the panel accepts a download. The display, the processor and the link to the PC all work. The fault sits in the runtime layer above them: the pairing or the message trigger.
- RUN stays blank after a clean download. Two candidates: the software generation and firmware letter are mismatched, or no configured message condition is true.
- Pressing F1 toggles C0 with the pushbuttons mapped at V40600. The panel-to-PLC link passes traffic. That test exercises the comm path and the pushbutton map; it exercises nothing about which condition the runtime messages watch.
- No comm indication, yet the bit toggles anyway. Trust the action over the lamp: cause a change you can see in a register and watch that register. That result outranks any status lamp or comm line on the panel.
- The download stalls or errors part way through. Different layer, the PC link; a USB serial adapter timeout when programming a text panel is the common cause there.
Match the software generation to the firmware letter
On the panel family this article follows, the maker ships two generations and documents the pairing: version 1 programming software goes with panel firmware letter 'a', and version 2 software goes with letter 'B'. A mismatched pair is a documented cause of exactly this fault: the panel accepts the transfer either way, and RUN never draws a message.
Read the letter from the panel itself. Most text panels print the firmware revision on a setup or version screen in their own menus; the manual names the path for the model. Read the generation from the software: the about screen or the installer names it. Then compare the pair. Version 1 with 'a' passes. Version 2 with 'B' passes. Anything else is a mismatch, and re-downloading the same file cannot fix it.
When the pair is wrong, move the project to the matching software generation, using the maker's documented transfer or rebuild procedure. Keep the firmware as it is: re-flashing a panel in service is a factory-level job, and the software move does the same work and can be undone.
Watch the trigger bit the message actually uses
The pushbutton test used C0 only because the pushbuttons were mapped at V40600 and F1 was set up to toggle it. A runtime message almost never shares a test coil. Open the saved project, find the message definition, and read the address and condition configured to select it: a bit, a register value or a comparison. That address is the only one worth watching.
Save a copy of the project, then reproduce the operator action while you watch the configured address in the PLC software. Two outcomes split the fault:
- The value stays false while you operate the control. The fault is upstream, in the PLC logic or in the address the project watches. The panel is doing what it was told.
- The value goes true and the text stays blank. The fault is panel-side: the pairing or the message assignment.
When the plant condition is hard to reproduce, force the bit from the PLC software instead: switch it ON and hold it for 5 seconds. The worked example below shows why 5 seconds is long enough. If the project's trigger is a momentary bit, hold the operator control down through the whole test, because a quick press can be shorter than one message refresh; how many PLC scans an HMI momentary button bit stays on gives the numbers behind that. Check the idle state too: a project that defines a default message shows that idle text whenever every condition is false, which reads like a dead panel.
Worked example
A packaging line panel comes out of storage. It enters setup mode, draws its menus, accepts a download, and RUN stays blank. Pushbuttons are mapped at V40600, and pressing F1 toggles C0 in the ladder, so the panel-to-PLC link passes traffic.
The project defines three messages on screen 1, conditioned on C10, C11 and C12. The ladder sets C10 while the infeed guard is open. The guard is closed, so the test forces the bit instead of waiting for someone to open a guard.
Force C10 ON and hold it for 5 seconds with the bit monitor open. At a typical small-PLC scan time of 10 ms, 5 seconds is 500 scans (5,000 ms / 10 ms = 500), so a correctly configured message has hundreds of chances to draw. The monitor reads C10 = 1 for the whole 5 seconds. The panel stays blank.
Now the pair check. The panel's setup screen reports firmware letter 'B'. The project was written and downloaded with version 1 software, and version 1 pairs with 'a'. The pair is wrong, and the successful download never tested it.
Decision: move the project to the version 2 software that pairs with letter 'B', confirm the C10 assignment there, download once through the documented procedure, and repeat the same 5-second force. C10 ON draws the guard message; C10 OFF returns the idle text. The cable, the PLC and the guard logic were never at fault.
Fix the project and prove it in RUN
- Back up the project file and write the firmware letter and software generation on the panel's service record.
- Open the project in the software generation that matches the firmware letter.
- Confirm the message text exists and is assigned to the screen the panel opens in RUN. A message parked on screen 3 never draws on screen 1.
- Confirm the trigger address and condition match the PLC logic that should drive them, and correct one item at a time so each test has one cause.
- Download through the maker's documented transfer procedure.
- Run the acceptance test in RUN: force the trigger ON and watch the text draw, then drop it out and watch the idle message return. Both ends matter, because a message that appears and never clears reads as a new fault on the next shift.
- Record the passing pair on the panel's service record: firmware letter, software generation, project file name.
If the panel fails the hardware signs instead (no setup screens, no download accepted, no response at any address), the fault is the panel itself, and replacement means matching the panel family and its protocol before you order. For planning the screen that serves the rest of the line, see our shop-floor display category.
Recommendation: Before the third re-download, read the firmware letter off the panel's setup screen and check it against the software generation on your PC. A wrong pair means moving the project to the matching generation and retiring the old file. A right pair means leaving the cable alone and running the force test on the message's own trigger while you watch the bit: bit goes true and text stays blank, correct the message assignment in the project; bit never goes true, fix the PLC logic that drives it.
Questions
How do I find the panel's firmware letter if its menus hide it?
Most text panels print the revision on a setup or version screen, and the manual names the exact menu path for the model. If the panel exposes no such screen, the panel maker's support desk can identify the firmware from the model and serial number. Read the panel first and ask the maker second, and keep the firmware as it is: moving the project to the matching software generation does the job and can be undone.
How do I tell a dead panel from a wrong project?
Setup screens that draw cleanly and a download the panel stores clear the display, the processor and the link to the PC, so the hardware is alive and the fault is in the runtime layer. True hardware failure looks different: no setup screens, no download accepted and no response at any address. That split sends project faults through the checks in this article and hardware faults to a like-for-like replacement.
The pair matches and the forced trigger goes true, but the text is still blank. What is left?
The message assignment is the remaining suspect, checked from inside the project: the text exists, it is assigned to the screen the panel opens in RUN, and its message group is enabled on that screen. Rerun the full 5-second force while watching both the bit monitor and the panel. If every item checks out and the screen stays dark, gather the firmware letter, the software generation, a project backup and the forced-bit test result, and take all four to the panel maker's support.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.