When the same HMI transfer error appears with the panel connected and with it unplugged, the cable and the panel are out of the causal path and the PC is the variable. The matching fix is to run the HMI configuration software in Windows XP (Service Pack 2) compatibility mode, set on the program that starts the send, then repeat the transfer. Keep the Windows XP workstation as the fallback sender until the new PC completes two sends in a row.
An HMI project that sends fine from the old Windows XP workstation keeps failing on the new PC, and the error is the same with the panel connected and with it unplugged. That pattern puts the fault on the PC side: the send dies inside the HMI configuration software before any panel link is opened. The fix that matches this pattern is to run the software in Windows XP (Service Pack 2) compatibility mode, set on the program that starts the transfer. This article gives you the two-attempt test that isolates the PC as the variable, the steps to set the mode on the right executable, and the checks to run in order if the mode changes nothing.
What each symptom points to
Match your case to one of these four before you replace any hardware.
- The identical error appears with the panel connected and with the cable unplugged. The send is failing inside the PC software, before a panel link is opened. Work the PC side.
- The same project and the same cable send fine from a Windows XP computer. The computer is the one variable that has not been tested. Compare the two PCs before buying a new cable.
- The software installs and the project edits normally, and only the send step fails. The failure sits in the transfer program's startup, which is where an operating-system compatibility problem shows up.
- The error text or the failure point changes when you connect the panel. The send has reached a connection-dependent stage. Check the cable, the port and the panel's transfer readiness, in that order, with the panel's own manual in hand.
Run the two-attempt test first
Two sends, with one condition changed between them, tell you which branch to work.
- Send the project once with the panel connected. Write down the exact error text and the step where it appears.
- Send once more with the programming cable unplugged from the panel. Write the error text down again.
- Compare the two records. Identical text at the same step in both runs points at the PC software, because the connection state changed and the outcome stayed fixed. A different error or a different failure point means the connection matters, so move to cable, port and panel checks.
- Send the same project from the Windows XP computer, same cable, panel connected. A clean send there completes the comparison: one variable changed, one outcome changed.
Set Windows XP (Service Pack 2) compatibility mode
Compatibility mode is a documented Windows feature. It tells Windows to present selected behavior of an older Windows version to one program, which is what HMI software written for Windows XP usually needs on a newer PC.
- Close the HMI configuration software.
- In Windows Explorer, locate the shortcut or the EXE that starts the send. If your suite keeps the transfer in a separate upload utility, that program is the one to set.
- Right-click the file, open Properties, and open the Compatibility tab.
- Tick
Run this program in compatibility mode for:and choose Windows XP (Service Pack 2). - Click OK, reopen the software, and repeat the same send with the panel connected.
Windows stores compatibility settings per program. A setting on the editor shortcut stays with that one EXE, so set the mode on every program that takes part in the send. The setting lives in the program's properties, never in the project file, and the same tab clears it when you no longer want it.
Example: one project, one cable, two PCs, one stopwatch
The scenario: an HMI suite released around 2009 for Windows XP, running on a Windows Vista workstation. Every send stalls at the transfer step and fails about 12 seconds in. The same project file and programming cable send cleanly from the old Windows XP computer, completing in about 40 seconds. The test matrix looks like this:
| Attempt | PC | Programming cable | Time to fail or finish | Result |
|---|---|---|---|---|
| 1 | Windows Vista | connected | 12 s | error at the send step |
| 2 | Windows Vista | unplugged | 12 s | identical error at the same step |
| 3 | Windows XP | connected | 40 s | send completes |
Read the numbers. Attempts 1 and 2 differ only in the connection state, and the error appears at the same step at the same 12 s mark in 2 of 2 runs, so the panel link is not what triggers the failure. Attempts 1 and 3 hold the project, the cable and the panel constant and change one thing, the PC, and the outcome flips: 1 changed variable, 1 changed outcome. That places the fault on the Vista host. Set Windows XP (Service Pack 2) compatibility mode on the transfer program there and repeat the send; a working transfer should then run to the 40 s class of completion time instead of stopping at 12 s. The fourth attempt, with the panel connected, completes the project to the panel. Log four values: the Windows version, the compatibility setting, the original error text and the result.
The times in this example are illustrative. Your own sends take what they take; the useful number is the point at which the send stops, and whether that point is identical across connection states.
If the error is unchanged
Work this list in order and stop when a send completes.
- Check which program you set. The Compatibility tab setting belongs to one EXE. If the editor hands the send to a separate transfer utility, set the same mode on that utility as well and retry.
- Match the software versions between the two PCs. A version gap between the editing PC and the tools on it produces its own transfer errors, so read the version from the program's about box on both computers. The version-mismatch branch has its own article: HMI project seek failed after moving PCs: check the software version.
- Check the panel's firmware revision before the next send, as set out in check the HMI firmware revision before a project transfer, so the send is judged against the panel's documented requirements.
- Capture the evidence and escalate with it. Keep the exact error text, the failure point in both connection states, and the software identity from the about box, and take those to the HMI maker's documented support channel.
In the meantime, keep the Windows XP workstation as the fallback sender. One caution on that fallback: Windows XP stopped receiving security updates on April 8, 2014, so keep such a machine off the plant network.
The decision
Recommendation: When the send fails with identical error text in both connection states, and the same project and cable send cleanly from the Windows XP PC, set Windows XP (Service Pack 2) compatibility mode on the program that starts the transfer on the new PC and repeat the send. Keep the Windows XP workstation as the fallback sender until the new PC completes two sends in a row, keep it off the plant network while it is in service, and log the compatibility setting in the workstation's maintenance note so the next engineer can reproduce or clear it.
If the cell also needs a standalone notice or status screen for andon counts and shift messages, our shop-floor signage covers that job.
Questions
Does compatibility mode change the project file or the panel?
No. Windows keeps the setting per program, in the registry, and it only changes how Windows presents operating-system behavior to that one program. The project file, the cable and the panel stay exactly as they were. Clear the setting later from the same Compatibility tab, which makes the change safe to trial: if it does not help, one click returns the workstation to its previous state.
Which Windows version should the dropdown be set to?
Set Windows XP (Service Pack 2) first, because that is the value that matches XP-era HMI tooling. Newer Windows versions also list Windows XP (Service Pack 3); try it second, after a Service Pack 2 run changes nothing. Log whichever value works so the next workstation setup can copy it.
Can the old Windows XP computer stay as the permanent transfer station?
Treat it as a fallback, not a plan. Windows XP stopped receiving security updates on April 8, 2014, so a machine running it belongs off the plant network, with project files moved by USB and opened only from trusted sources. The goal is a supported PC that sends projects on its own, with the compatibility setting written into the maintenance note.
The send works in compatibility mode. What should I record?
Four values: the Windows version, the compatibility setting and the program it is set on, the original error text, and the result. The setting belongs to one program on one PC, so a new workstation needs it set again, and the note turns a repeat of the failure into a two-minute check. When the software is later upgraded to a version built for the current Windows, clear the mode from the same Compatibility tab.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.