A wrong software version error during HMI programming, with the versions matching on paper, is a failed transfer. When it appears only while the panel's PLC link is unplugged, the cause is the programming cable and its signal ground. Swap in the cable specified for the panel's programming port and prove a direct transfer before changing any software or firmware version.
A wrong software version error during HMI programming is rarely about versions when the numbers match on paper. It is the panel's way of reporting a failed transfer, and the usual culprit is the programming cable: a missing signal ground, an open conductor, or a cable built for a different port that happens to fit the connector. The tell is the pattern. The panel programs fine while its cable to the PLC stays connected, and it fails the moment that link is unplugged. That pattern points at the direct programming path, so meter the cable and its ground first and leave the software alone. This page gives the symptoms to sort, the numbers that explain why a small ground fault corrupts a serial transfer, the checks in order, and the fix.
What the error is actually reporting
In the field case behind this pattern, the programming software was version 2.20 Build 00.00, the panel showed firmware 2.20.00.00 with Mask ROM V1.37, and the project had loaded on that same panel before. Every version number matched, and the transfer still failed, five times in a row. Matching numbers with a repeatable transfer failure is a path fault.
A serial transfer that dies partway gets whatever message the panel keeps for failed transfers, and on this panel that message spoke about software versions. Misleading fault text is a habit of serial links in general. PLC hardware documents the same trap: the S:5/14 modem lost fault reports lost modem hardware for what is really a link problem (SLC 500 S:5/14 modem lost fault troubleshooting). Read the reproducible pattern first and the message text last.
Symptoms and what each points to
- Error appears only with the PLC link unplugged. The direct programming path is the fault, and in the field case the cause was the cable.
- Versions match on paper and the project loaded before. The transfer path is at fault; the software is not.
- The dialog or error code changes between attempts. A corrupted or unstable transfer, not a fixed incompatibility. The field case logged a different code on an earlier round.
- Removing one of two USB to serial adapters changes nothing. Adapter count is not the cause; test the panel's own cable.
- The software reports NAK or timeout errors instead of a version dialog. Same link, honest reporting. The DF1 NAK and PLC timeout fix covers that family.
Example: 5 V of drive, a 3 V receiver window and 2 V of margin
Inputs. Driver swing, at least 5 V into a load, from TIA/EIA-232, the RS-232 standard. Receiver decision window, -3 V to +3 V, also from TIA/EIA-232. Symptom, from the field case: software 2.20 Build 00.00 against firmware 2.20.00.00 and Mask ROM V1.37, all matching, transfer passing only while the PLC link is connected.
Rule. RS-232 sends every bit as a voltage the receiver measures against signal ground. If the programming cable omits or loses that conductor, the receiver measures against a floating reference, and any voltage difference between the two ends' grounds adds itself to every bit that arrives.
Arithmetic. Worst case margin = minimum drive - window edge = 5 V - 3 V = 2 V. A ground offset of 2 V, or 2 V dropped across one corroded contact and its return path, turns a legal 5 V level into a 3 V reading, right at the window's edge. With the ground open completely, the receiver has no fixed zero and bits read as they arrive.
Result. Bytes arrive wrong, the transfer aborts, and the panel reports the failure with the wrong-version dialog.
Decision. The threshold is 2 V, and that is the entire margin a minimum-spec driver carries. If pin 5 does not read through from end to end, or the transfer passes only while the PLC link is connected, replace the cable. Versions are the wrong thing to change.
Why connecting the PLC made the transfer pass
The PLC link cable gave the transfer a second path between the two grounds, so the reference existed again and the bytes arrived intact. That is why the fault dressed up as a programming requirement. It is a workaround, not a repair. The shop behind the field case was building seven of these machines for plants spread across the map and needed the same screen edit on every panel; dragging a PLC to the bench for each edit is a habit to break.
If a line is down and the transfer has to land now, use the PLC-connected route once, record that it passed only with the link in place, then do the cable work. The nearest write-up on the dependency itself is HMI works only while the programming cable stays in the PLC; this page stays on the misleading version message and the checks that close it.
What to check, in order
Put the panel and the PLC through your site's power-down or lockout procedure before pulling connectors or metering pins. Then work down the list, one change at a time:
- Reproduce the fault once, exactly. PLC link unplugged, same project, same PC, same ports. Save the dialog. In the field case it came back five times in a row, so repeatability is normal.
- Meter the ground. Both ends unplugged and power off: continuity from pin 5 to pin 5 across the two 9-pin connectors should read near 0 Ω. If the meter will not confirm a solid reading, stop there.
- Compare the wiring to the panel's documentation. Panel makers document the wiring for each serial port; confirm pins 2 and 3 land where the programming port's documentation says, and confirm the cable is the one specified for that port, not one that merely fits.
- Fit a known-good, specified cable. Same PC, same software version, same project, same adapters. One change.
- Retry with the PLC link still unplugged. If it passes, direct programming is confirmed and the fault is closed.
- If it still fails, change one variable at a time. Confirm the software is pointed at the COM port the panel's adapter took; two adapters usually create two ports. Then try another adapter. Every conductor counts, and the power pin check covers a conductor that fails the same quiet way.
- Restore and confirm. Reconnect the PLC link, confirm the machine's normal communications, and record the port map, PC to the panel's programming port and the panel's second port to the PLC's port 1, as the field case ran it.
The fix
Replace the faulty cable with the one the panel maker specifies and pull the old cable from service. Label it failed so it does not migrate back onto the spares shelf; a cable can pass a visual check and still fail a transfer, which is how this fault hides. If you run several panels, keep one labeled, known-good programming cable with the maintenance kit, so bench edits never depend on borrowing the machine's PLC.
If the error survives a known-good cable with pin 5 confirmed end to end, stop swapping parts. Save the exact dialog, note which port goes to the PC and which goes to the PLC, and record the software, firmware and Mask ROM versions the equipment shows. That package is what the panel maker's support desk works from, and it is the point at which a version problem finally becomes the live suspect.
Recommendation: When a panel reports a wrong software version error only while its PLC link is unplugged, treat it as a cable fault first: meter pin 5 end to end, fit the cable the panel maker specifies for the programming port, and prove a direct transfer before touching any software or firmware version. Change versions only if the same error returns on a known-good cable.
Questions
Why does the transfer work only while the panel is connected to the PLC?
The PLC link cable gives the transfer a second electrical path between the two ends' grounds, so the receiver has a reference again and the bytes arrive intact. It is a workaround, not a repair. Once the programming cable is replaced with the one specified for the panel's programming port, the same transfer should pass with the PLC link unplugged, and that direct pass is what closes the fault.
Can a cable that fits the connector still be the wrong cable?
Yes. Connectors are shared between ports that are wired differently, and a cable built for one panel's port can land the data and ground conductors where another port does not expect them. Panel makers document the wiring for each serial port, so read the documentation for the port you are actually cabling instead of copying a scheme that worked elsewhere on the same machine.
Can the wrong software version error be real?
Yes, but it is the last suspect, not the first. Versions that match on paper, a project that loaded before, and an error that comes and goes with a cable plugged in all point at the transfer path. A genuine mismatch fails on every transfer, with the PLC link connected or not, and the panel maker's support desk can compare the versions you record against its compatibility list.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.