HMI popup shows frame but no text: fix the screen assignment

Why does my HMI popup show its frame but no text?

The static text is on the wrong screen: a popup window draws only the one screen assigned to it, and every object you placed on the main screen stays underneath, covered by the frame that just opened on top of it.

That is the whole model, and it is documented. The Pop-up Window Frame object in C-More is described in its help file as displaying a chosen screen on top of the screen the panel is already showing. The popup inherits nothing from the screen underneath. Objects belong to the screen they were drawn on.

Your two attempts fail for the same reason. The C0 bit you set under the text object's visibility option turned the text's drawing on and off, but the text never left the main screen, so it was never part of the popup's content. The text you drew over the popup's position had the same fault: right words, right pixels, wrong screen.

What do the symptoms tell you before you open the project?

Three symptoms separate cleanly: a frame with nothing inside means the assigned screen lacks the text, no frame at all means the request bit never changed, and stray text visible around the frame means the text sits on the main screen's surface.

• Frame opens, nothing inside it. The screen assigned to the popup is not the screen holding the text, or it holds no objects yet. This is the screen-assignment case, and the fix below clears it.
• Frame opens with text visible around its edges. The text is on the main screen, and the parts outside the popup's footprint stay visible while the frame covers the rest. The footprint sets how much hides: a 400 x 300 pixel popup on an 800 x 480 pixel panel covers 31% of the surface, and the arithmetic is in the worked example below.
• No frame at all. The request bit never changes, so the popup is never asked to open. That is a trigger problem, and the same request-bit pattern that drives an event triggered screen change on an HMI when a PLC alarm bit turns on applies here.
• The popup covers the whole screen. The window object's size property is at fault, and that repair is different: see HMI popup opens full screen: fix the frame and buttons.

What is the popup actually showing when it opens?

It is showing one preselected screen number: the Pop-up Window Frame object, in the documentation for C-More, is set up to display a chosen screen drawn on top of whatever screen the panel is showing.

The setting is a property of the popup object, and the object shows exactly the screen whose number it holds. Siemens' WinCC Unified popup examples build the content the same way, on screens configured in the project's screen list. Whatever your package calls the setting, screen assignment, window screen or content screen, it holds a screen number, and that number is the entire content of the popup. That is why a frame can be perfect while its content is absent: the assignment points at a screen with nothing on it, or at a screen that is not the one holding your text.

Can a visibility bit pull main-screen text into the popup?

No: the bit turns an object's drawing on its own screen on and off, and it has no way to move that object to another screen, so a C0 visibility condition cannot place main-screen text inside the popup.

A visibility condition is a drawing rule for the object it is attached to. While the bit is on, the object draws on the screen the object lives on; while the bit is off, the object skips. Nothing is relocated. Your C0 visibility condition therefore did this: while C0 was on, the text drew on the main screen, exactly where the popup was about to cover, and when C0 dropped, the text hid from a screen the popup never reads. The request side is healthy and stays: the C0 bit that brings the frame up is doing its job, because the frame comes up.

How do I put the static text on the popup's own screen?

Create one new screen in the project's screen list, place the static text object on it, and set the popup window object's screen assignment to that new screen number; the text then needs no visibility condition at all.

1. Create a new screen for the popup content, one screen per distinct popup message.
2. Place the static text on that screen with its final wording and position. The placement rules are the same as any static text job, and Put a full page of static text on an HMI screen covers the basics.
3. Open the popup object and set its screen assignment to the new screen's number.
4. Keep the request bit as it is. Here that is C0, and it keeps the one job it already does: opening the popup.
5. Delete the visibility condition from the text object.
6. Download the project to the panel with your install's normal transfer workflow, then trigger the fault and watch frame and text arrive together.

Anything else the popup should carry, numeric displays, indicator lamps, a close button, goes on that same assigned screen.

How big can a popup window be?

The popup's size is set in pixels on the window object, and one documented cap is 800 pixels wide by 600 pixels tall; the size changes how much of the screen the frame covers, never which screen fills it.

That cap comes from Vijeo Designer's own FAQ, and it leaves room for most alarm and message windows on small panels. Position and size live in the same object's properties in any package. The cap for your own software and panel is in its manual, and it does not matter for this fault: no pixel value repairs an assignment that points at the wrong screen.

What does a worked example look like?

A packing-line panel with an 800 x 480 pixel screen, a 400 x 300 pixel popup and 3 lines of static text carries the whole fault through with arithmetic you can repeat on your own project.

Scenario: bit C0 must open one fault popup, 400 x 300 pixels, centered, carrying 3 lines of static text. Before the fix, the 3 lines were drawn on the main screen at the popup's position, with C0 in the text object's visibility option.

Arithmetic first. The panel's area is 800 x 480 = 384,000 square pixels. The popup covers 400 x 300 = 120,000 square pixels, and 120,000 / 384,000 = 0.3125, so the frame hides 31% of the panel when it opens. All 3 lines sat inside that 400 x 300 footprint, so every line went under the frame. The remaining 264,000 square pixels of main screen (384,000 - 120,000) showed around it, empty of the message.

The fix: one new screen entered the screen list, the 3 lines moved onto it, the popup's assignment was set to that screen's number, C0 stayed untouched, and the text's visibility option was deleted. Result: the same C0 transition opens the frame, the 3 lines appear inside it, and the main screen never changes.

Why is the frame still empty after the fix?

Work the list in order, because each check splits the problem in two: screen first, assignment second, trigger third, and only then the visibility condition you were about to add back.

1. Open the text object and read the screen it sits on. If it reads the main screen, you have found the fault.
2. Open the popup object and read its assigned screen number. It must name the screen the text sits on.
3. Watch the request bit while you trigger the fault. If C0 never changes, the popup is never asked to open, and the fault is upstream in the logic, not in the screen assignment.
4. Make the text visibility unconditional and retest. If the text now shows on the main screen but still not in the popup, the object is on the wrong screen, and checks 1 and 2 settle it.
5. Right screen, right assignment, right trigger, frame still blank: download the project again and confirm the new screen reached the panel, because a panel that opens old screens fine but never shows the new one has taken an incomplete transfer.
6. A numeric display that opens empty inside an otherwise correct popup is a tag-address fault, not a popup fault, and HMI numeric display shows nothing: check the tag address first walks that one.

Do I still need the visibility bit on the text?

No: once the text lives on the popup's assigned screen, it shows every time that screen is displayed, so the old visibility condition comes off unless the message must appear only for some faults.

The assigned screen displays only while the popup is open, so unconditional text is safe; the operator never sees it on the main screen. Keep a visibility condition in one case: the popup screen carries two or more text objects and each must show for a different fault, each gated by its own bit. That is conditional content on a correctly assigned screen, and it works because the placement is finally right.

Recommendation: For any popup that shows the same message every time it opens, put the static text on the popup's assigned screen, delete the text's visibility condition, and keep the request bit as it is; apply the change to every popup in the project, because they all fail through the same missing assignment. Keep a visibility bit on popup text only when one popup screen must show different messages for different faults. If what the line needs beside the HMI is a standing status board, that is a separate screen: we build shop-floor signage displays that play their own message files offline, and they take no part in the HMI project.

Questions