Objects stay on the HMI editor screen while their text vanishes, and the properties box still shows every label. Check Windows display scaling first: the editor is built for the 96 DPI of 100% scaling, and 125% or 150% hands it 120 or 144 DPI. Read the installed version's Readme.txt, set the scaling it names, reopen the project and verify two screens before editing anything.
An HMI project opens, every object sits where it belongs, and the text on the objects is missing from the PC screen. Open one object's properties box and all the labels are still there. That combination points at the PC, not at the project: the Windows display scaling no longer matches the value the installed programming software documents in its Readme.txt. The check takes about 5 minutes, needs no download and no reinstall, and almost never requires re-typed text. This page sorts the symptoms, gives the DPI numbers behind the setting, walks the fix in order, and works one laptop example through the arithmetic.
What each symptom points to
Match what you see against these four patterns before you change anything:
- Objects render, text missing, properties still correct. That is the display-scale mismatch this page fixes, and the project data is still intact.
- The project opens on the old PC but throws a seek or open error on the new one. That is a software-version mismatch between the two PCs, covered in HMI project seek failed after moving PCs.
- The editor will not start or dies part way through a session. That is an install or environment fault; start from HMI editor crash diagnosis before software repair before reinstalling anything.
- The PC preview looks right but the panel shows nothing after a download. The fault is on the panel side; see a text panel that takes a download but shows no messages. Faults that live on the panel or its install are collected under shop-floor screens.
Check Windows scaling against the Readme.txt
The installed programming software prints its display requirement in the Readme.txt that ships with that version. Read it; it names the Windows DPI setting the editor expects. Windows keeps the current value under Settings, System, Display: on a Windows 10 PC, under Scale and layout, the drop-down named “Change the size of text, apps, and other items” shows and sets the scaling percentage.
The numbers behind that percentage are fixed. Windows defines 100% scaling as 96 DPI. One step up, 125% reports 96 × 1.25 = 120 DPI; 150% reports 96 × 1.5 = 144 DPI. Legacy HMI editors were drawn against the 96 DPI of 100%, which is why their documentation pins the setting there. New laptops often ship at 125% or 150%, so a project that looked right on the old shop PC can break on a newer one with no edit from anyone. One major HMI software vendor documents the workaround for this exact preview fault as 100% scaling together with a 1920 × 1080 resolution.
Before you change anything, write down the software version, the current scaling value, and whether the PC or its display settings changed since the project last looked right.
Why the text layer drops while the objects survive is inside the editor's drawing code. The useful fact sits in the properties box: the text is still stored, so the job is to fix the preview, not the project.
The fix in order
- Back the project up. Copy the project file to a second folder or a USB drive and leave that copy untouched.
- Keep the panel out of it. Do not download a test copy to a working panel to preview it there; if a transfer does become necessary, first check the HMI firmware revision before a project transfer.
- Read the Readme.txt that ships with the installed software and note its Windows DPI requirement.
- Set Windows to that value. On Windows 10: Settings, System, Display, then the drop-down “Change the size of text, apps, and other items” under Scale and layout; choose 100%. When the documentation pairs a resolution with the scaling, set that too; one vendor documents 100% with 1920 × 1080 for this fault.
- Close the editor completely and reopen the project.
- Verify two things: the text shows on at least two of the affected screens, and the object properties still match your backup.
- If the preview is still wrong at the documented value, open a second project on the same PC. Two projects wrong points at the PC or the software install; only this project wrong means the backup stays alone and the case goes to the software vendor.
Example: a 150% laptop hiding 24 labels
Scenario. A maintenance laptop with a 1920 × 1080 panel runs Windows display scaling at 150%, the value new laptops often ship with. A line's HMI project has one screen with 24 text objects. After a software update, all 24 objects render and none of the 24 labels shows; every properties box still lists its label.
The arithmetic. Windows defines 100% scaling as 96 DPI, so 150% reports 96 × 1.5 = 144 DPI. The editor is built against the 96 DPI of 100%, and 144 DPI is 1.5 times the value it expects. The Readme.txt names 100%.
The fix. Set “Change the size of text, apps, and other items” to 100%, keep the 1920 × 1080 resolution, close the editor, reopen the project. All 24 labels render again. The properties were correct throughout, so nothing was re-entered and nothing was downloaded. Total time: about 5 minutes.
Recommendation
Recommendation: Before you re-enter a single label, read the installed editor's Readme.txt and set Windows scaling to the value it names; when the readme prints none, set 100%, which is 96 DPI and the value legacy editors of this kind are built against, and add a 1920 × 1080 resolution, the pairing one vendor documents for this fault. Then reopen the project, confirm the text on two screens and the properties against your backup. Keep the programming PC at the documented setting for project work; if the text still fails there, test a second project and take the software version, the DPI value and both results to the vendor.
Questions
Is the text gone from the project file?
Open several affected objects on different screens and read the properties boxes. If the label, size and color fields still hold the intended values, the text is stored in the project and only the PC-side preview is wrong. If the properties are genuinely empty for every object on every screen, the project data itself is the problem, and no scaling change will bring the labels back.
Can other programs keep their larger scaling?
Yes. Windows sizes each program that declares itself DPI-aware to its own value, so browsers and office software keep their larger text while the editor PC sits at 100% for project work. Programs that declare no awareness are stretched as one bitmap; a legacy HMI editor drawn at fixed pixel sizes is the kind that breaks under that treatment, which is why its documentation pins the setting.
What if the Readme.txt prints no DPI value at all?
Work from the baseline. Windows defines 100% as 96 DPI, 125% as 120 and 150% as 144, and legacy editors of this kind are built against the 96 DPI value. Set 100% with a 1920 × 1080 resolution, the pairing one HMI software vendor documents for this exact fault, and retest. If your version's documentation names a different value anywhere, that value wins.
When do I stop troubleshooting myself?
After the documented scaling value is set and a second project still shows the same fault, the cause sits in the PC or the software installation, and more project edits only risk damage. Send the software version, the Windows scaling value, the second project's result and a copy of the affected project to the vendor's support channel, and keep your backup copy until the cause is confirmed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.