A panel that still polls its PLC on port 2 has power and a running project; the fault is in the programming path. Check the software's COM selection and the panel's printer port assignment, verify the cable wiring against the documentation, then measure the signal-ground offset between laptop and panel, in that order, one change at a time.
An HMI panel that still polls its PLC on port 2 but ignores the programming PC has power, a running project and one working serial port. The fault is in the programming path, and it has four places to live: the COM selection in the PC, the panel's port configuration, the cable wiring, and the signal-ground reference between laptop and panel. Work them in that order. A deep momentary sag on a 220 V supply, with the panel on a UPS, looks like the obvious culprit; it is the last thing to blame, because the panel crossed that event with one port still talking. Change one thing at a time, and leave the PLC link wired while you test.
What the working PLC link tells you
Port 2 to the PLC and the programming port are separate circuits on the same board, each with its own line driver and its own configuration. A live PLC link tells you the panel has power, the project runs, and one serial path is healthy. The programming port is still an open question, so test it on its own.
Leave the PLC link connected while you diagnose. The process keeps its data, and you keep a known-good reference point. Save the project file before any recovery step: some panels drop their loaded project when you pull the backup battery, so a battery reset belongs at the end of the visit and only with the project file in hand.
What each symptom points to
Record the exact message the programming software gives you, then match it:
- The software cannot open the COM port. The number selected in the software and the number the PC assigned have parted company, or another program holds the port. Close every serial tool, including the PLC programming package, and read the number in the PC's device list.
- The port opens and the panel never answers. This is the case in question. The suspects, in order: panel port configuration, cable wiring against the documented cable, ground reference, port hardware.
- Timeouts and checksum errors instead of clean silence. Data is arriving damaged. That points at the ground reference or a marginal conductor, and timeout and invalid checksum errors works that pattern.
- The panel reports a communication fault on screen, or the project stops running. The problem is wider than the programming link. Check panel power and status before touching the programming port.
Clear the COM selection and the printer assignment first
Start on the PC. Read the COM number the operating system assigned to the port or the USB adapter, then select that same number in the programming software. Where the software only lists COM1 to COM4, fixing the COM port number is its own job. Retry once and write down the exact response. If the port opens and the panel answers, you are done.
Then read the panel's own setup, from its documentation. Operator panels with printer support expose settings such as printer language, printer port, paper size, orientation, color and print quality. A port assigned to a printer is unavailable to the programming software, and the symptom is plain silence, the same silence as a dead port. The port assignment lives in the panel's communication or setup menu; move the programming port back to PC programming and retry once.
Check the cable conductor by conductor, not by continuity
A continuity pass proves each conductor meets end to end. It says nothing about which pin each conductor lands on, about shorts between adjacent pins, or about the shield. A cable can pass a tester twice and still be a null-modem where the documented programming cable is straight-through, or carry a broken ground conductor.
Work the cable properly:
- Read the documented programming cable's conductor assignments and compare it conductor by conductor.
- Inspect both connectors for bent contacts, loose shells and damaged strain relief, with the panel powered down if its documentation says so.
- Connect direct: no extension lead, no gender changer, no unverified adapter.
- Swap in a known-good cable of the documented type and retry.
Keep the run short. The original RS-232 standard assumed about 15 m (50 ft) of cable, and a programming lead should be a fraction of that. Extending an RS-232 HMI cable covers what extra length costs a link.
Measure the reference before you touch grounding
RS-232 carries TxD and RxD as voltages measured against the signal-ground conductor. The standard puts a mark between -15 and -5 V and a space between +5 and +15 V at the driver, and requires a receiver to respond to anything past ±3 V. Any voltage between the two grounds subtracts from that margin, volt for volt.
A laptop running on battery is normal, and this one worked that way for six months. A floating serial interface takes its reference from the far end through the cable's ground conductor, which is why unearthed laptops program panels every day. Two things break that arrangement. An open ground conductor in the cable leaves the panel's receiver at its own idle level; receiver inputs include an internal 5 kΩ pull-down, so the port reads a silent, healthy line and never answers. Or a real potential difference exists between the two ends at the moment of connection, the classic source of both garbled serial data and damaged ports.
Safety note: never run a wire from the laptop chassis to the panel chassis as a trial fix, around equipment that just took a supply disturbance. A jumper like that can put the offset current straight through the signal ground. Plugging the laptop's charger into the 220 V socket beside the panel adds nothing on most laptops, because most adapters carry no earth pin. Measure instead: laptop connector shell to panel chassis, with the cable connected, first volts AC then volts DC, and decide from the number.
Example: laptop on battery, panel on a UPS, 3.8 V between grounds
Inputs, with sources:
- Driver minimum from the RS-232 standard: +5.0 V for a space, -5.0 V for a mark, at the laptop, measured against its own signal ground.
- Receiver threshold from the same standard: ±3.0 V at the panel.
- Ground offset, an example field reading taken with a meter: panel signal ground sits 3.8 V above laptop signal ground.
- The rest from the case: 220 V supply with a deep sag, panel fed through a UPS, six months of clean edits, cable continuity checked twice, PLC link on port 2 alive.
Rule in words: the panel sees the driver voltage minus the offset between the two grounds, and anything inside ±3.0 V counts as no signal at all.
Arithmetic:
- Space: +5.0 V - 3.8 V = +1.2 V at the panel. 1.2 V sits inside the ±3.0 V threshold, so every space is lost.
- Mark: -5.0 V - 3.8 V = -8.8 V at the panel. Past -3.0 V, so marks still arrive.
- Margin: 5.0 V - 3.0 V = 2.0 V per polarity at minimum drive.
Result: one polarity survives and the other collapses. The panel receives broken framing, and the programming software is designed to report timeouts or checksum rejects in that state, while the PLC link on port 2 keeps running because the PLC shares the panel's ground reference in the cabinet.
Decision: keep the offset under 2.0 V. At 3.8 V the reference is the fault. Fit an isolated USB-to-RS-232 adapter or an isolated serial converter, or give both ends a proper common reference following the panel documentation, and stop swapping cables and PCs.
Isolate the fault to the PC, the cable or the panel
Substitute one element at a time:
- Confirmed COM number, documented cable, verified port assignment: retry and record the exact message.
- Second known-good PC, same cable, this panel. If it connects, the fault is in the first PC: its port, its driver, or its software setup.
- First laptop and cable on a second panel of the same type. If it connects there, the fault is on the first panel.
- The failure follows the element it follows. Log every combination and its exact response.
The laptop's port has programmed other field devices, so a dead PC port is the less likely branch; a wrong COM selection on it is the common one. Burned port electronics stay last: the panel crossed the sag on a UPS with port 2 alive, so treat hardware damage as the conclusion after configuration, cable wiring, reference and a second PC all check out. If the panel's documentation allows a project download through its other port, that path uses hardware the live PLC link has already exercised, and it is a legitimate way in while the question settles.
The order that finds the fault in one visit
- Record the exact failure: the port will not open, or the panel gives no answer.
- Match the COM number between PC and software; close other serial programs.
- Read the panel's port configuration; clear any printer assignment on the programming port.
- Verify the cable's conductor assignments against the documented programming cable; swap in a known-good cable.
- Measure the ground offset. Under 2.0 V, move on. Over 2.0 V, fix the reference before anything else.
- Substitute a second PC, then a second panel, one at a time.
- Call the panel's programming port hardware the fault only after steps 2 to 6 pass and the port stays silent.
Recommendation: Clear the COM selection and the printer assignment, verify the cable wiring against the documented programming cable, then measure the ground offset, in that order. Above 2.0 V between laptop and panel, fix the reference with an isolated serial interface before swapping more hardware. At or under 2.0 V, with a verified cable and a second PC still getting silence, treat the panel's programming port as the fault and use the panel's second port for downloads where its documentation allows.
Questions
Does a working PLC link on port 2 clear the programming port?
No. The two ports are separate circuits with their own drivers and configurations, and port 2 also shares the panel's power and ground, so its health says the panel itself is alive. Test the programming port on its own, starting with its configuration.
Will plugging the laptop into mains power fix a ground problem?
Usually not. Most laptop power adapters carry no earth pin, so the 220 V socket beside the panel adds no reference. Measure instead, with the cable connected, in volts AC and then volts DC: an offset above 2 V is the fault and calls for an isolated serial interface.
Could the supply sag have destroyed the port electronics?
It could, but it is the last suspect. The panel crossed the sag on a UPS with port 2 still talking, and a disturbance that reached the panel hard enough to kill one driver normally disturbs more than one thing. Call it hardware only after configuration, cable wiring, reference and a second PC all check out.
Can I load the project through the panel's second port?
Where the panel documentation lists that port as accepting a download, yes, and the live PLC link already proves that hardware path. Plan the interruption: a download on that port means unplugging the PLC for the transfer, so pick a moment the line can lose its HMI data.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.