HMI simulator lockup after project edits: isolate the cause

Why does the HMI simulator hang right after I edit the project?

Windows flags a window as hung when its interface thread has processed no messages for more than 5 seconds. The Not Responding label means the simulator stopped drawing and listening; the edit history is then your strongest clue, and a long editing session puts the newest project objects first.

Simulation is the first time the software has to interpret everything you added since the last good run: screens, tags, animations, fonts. A lockup that appears after many successful runs and many changes points at the newest objects before anything else. Environment changes land on the same schedule, though: a security tool update, a Windows patch or a new startup program can arrive in the same week as your edits. That is why the two-project test below makes the call instead of your edit history.

What does Not Responding in Task Manager actually tell you?

It tells you the program stopped processing interface messages, nothing more. Microsoft's troubleshooting guidance for application hangs notes that a process can miss the Not Responding label while still working, so pair the flag with a fixed 60-second wait before you judge the program dead.

The 60-second line is your own rule: give the process that long before you close anything. Then read the pattern against this list:

• Not Responding within seconds on every project, every time: the installation or the Windows environment.
• Simulation never starts and the editor returns quietly after a busy cursor: the launch of the runtime window is being blocked; record whether the cursor appears before or after the return.
• Hangs on the edited project only, while a fresh project simulates cleanly: project data.
• Hangs on both projects: a background software conflict or a broken installation.
• Simulates fine under a different Windows account on the same PC: account policy or a profile-level restriction.
• Graphics arrive seconds late but the program never gets the Not Responding flag: that is the response-delay fault, covered in why an HMI button response delay runs several seconds.

A hard exit with a program-fault message in ea1-run.exe is a different fault with its own fix; the simulator program faults article covers that case.

What should I check before I run any test?

Save a second copy of the project to a new file name, record four facts about the PC, and run one open-and-save pass with no simulation. This pass keeps the only good copy safe and makes every later result repeatable.

The four facts to write down:

• Windows edition and build number.
• The simulator software version, from its about box.
• Where the project file lives: a local drive or a network share. A stalled network path stalls a project load, so test from a local copy either way.
• Whether the account is managed by an IT department.

Then open the project and save it once. If the open or the save throws a warning, write the exact text down; those warnings are evidence for a support case, and a project that cannot save cleanly is an earlier, different fault.

Which test separates a project fault from a PC fault?

Run one minimal project and the edited project in the simulator on the same PC, three attempts each with a 60-second wait per attempt. If only the edited project locks, the fault is in the project data, and if both lock, it is the Windows environment.

1. Copy the edited project to a new file name and leave the original untouched.
2. Build a minimal project from scratch: one screen, one numeric tag, one pushbutton. Nothing else.
3. Run the minimal project three times. Wait a full 60 seconds each time and record pass or lock.
4. Run the copied edited project the same way, three times.
5. Read the result off this table.

Project data is a real suspect: oversized bitmaps that exhaust bitmap memory are a documented project-side failure, and the HMI bitmap image memory article shows that family of fault. The same isolate-the-cause logic applies on the hardware side. When a panel blanks and locks after a download, the panel-side isolate-the-cause sequence runs the same comparison.

The reinstall already failed, so why not just reinstall again?

Stop reinstalling: a reinstall replaces the program files. A lockup that survived one already lives in the project data, the Windows profile, or a background conflict, none of which a reinstall touches.

Reinstalls do earn their keep in one case, when the fault lives in the installed components; OPC errors that clear after reinstalling core components document that pattern. Your test result tells the two apart: if the minimal project locks too, clean boot first and only then consider a repair install; if the minimal project runs, leave the installation alone and go after the project. Hold the software version constant through the whole isolation. A downgrade to an older release changes two variables at once, and a result that improves under it cannot tell you whether the version or the environment changed.

How long does the isolation test take in a worked example?

In a worked example with a 40-screen project and 8 edits from the last session, the full isolation and bisection takes about 15 minutes of bench time: 9 minutes for the two-project test and about 5 minutes to walk the edits down to one.

Situation: a 40-screen machine project, three weeks of edits, 8 changes made in the last session, and a lockup on every simulation attempt since.

• One attempt: 10 s to launch the software + 20 s to open the project + 60 s judgment wait = 90 s per attempt.
• Two-project test: 3 attempts × 2 projects = 6 attempts; 6 × 90 s = 540 s = 9 minutes.
• Bisection: revert half of the 8 edits into a fresh save-as copy and simulate once. It runs, the fault sits among the 4 reverted edits; it locks, it sits among the 4 kept. Each round halves the suspect set, so 8 → 4 → 2 → 1 takes 3 rounds; 3 × 90 s = 270 s, about 5 minutes.
• Total: 9 + 5 = 14 minutes, call it 15 with note-taking, and the final round names the single edit that breaks the simulator.

Two rules hold the example together: every test runs on a fresh save-as copy so the backup never changes, and any round that would put the only recoverable copy at risk ends the session and hands the case to the vendor's support.

When is it the Windows environment, and what do I change?

The environment is the fault when the minimal project locks too. The documented way to expose it is a clean boot: Windows starts with only essential drivers and startup programs, which removes background software conflicts in one move.

Windows' own support documentation gives the exact clean-boot steps for your edition. Run them, retest the minimal project three times, and if it now runs, re-enable the disabled items in halves until the lock returns; that names the conflicting program. If the clean boot changes nothing, try a second Windows account on the same PC, then a second PC, recording each result as a variable. On an IT-managed machine, ask the administrator what changed on this PC before you alter anything; policy and security software are legitimate suspects, and they are also theirs to move. Panel hardware gets the same one-variable treatment: the hardware manuals handle a panel that will not power up with power off, remove the SD memory card, power back on, and that strip-one-variable discipline is exactly what a clean boot does for the PC.

How do I confirm the fix before the project goes back on the panel?

A fixed project re-enters simulation, holds for the full 60 seconds and repeats that result after you close and reopen it. Treat one quiet return to the editor as a failed attempt, because a pass has to reproduce.

Run the repaired project three times clean, then walk every screen once inside the simulation and exercise the objects you changed. Save, reopen and repeat the three attempts; a fix that only holds while the editor stays open is no fix. Only then move the project toward the panel, and when a PLC link is involved, test writes before motion, as the operator panel PLC link setup article insists. One line belongs here as safety: never download a project you have not validated in simulation to a panel that drives a running machine.

When do I stop and send the case to the software vendor's support?

Stop and escalate when a clean boot, a second account and a second PC all fail the minimal project, because you have then shown the fault sits in the software installation or the Windows build and no bench test you can run will move it.

That combination has eliminated the two causes you can fix on the bench, so the remaining suspect is the installation or the Windows build itself. Send the vendor:

• Windows edition and build.
• The simulator version from its about box.
• The minimal project and its 3-attempt result.
• The edited project copy and its 3-attempt result, with the timing of each attempt.
• The exact point where the busy cursor appears: before the runtime window, or after.
• Whether the account and PC are IT-managed.

A reproducible case with a preserved project copy is the strongest ticket you can file, and it is what gets the defect in front of the people who can patch it.

Recommendation: run the two-project, three-attempt test on the same PC before any further reinstall, with a 60-second wait per attempt. If the minimal project simulates and the edited project locks, repair the project by bisection from a fresh save-as copy, about 15 minutes for the worked case. If the minimal project locks too, clean boot the PC, then try a second account and a second PC, and escalate to the vendor's support with the recorded results. Hold the software version constant the whole time.

If the cell also needs a notice or andon board that runs without a PC, our shop-floor screens play images and video offline from microSD or USB, and the category page lists what they take to mount and power.

Questions