Fix blank PV and SV values on an HMI panel over RS-485

Why do PV and SV read blank on an HMI panel over RS-485?

Check the controller's communication settings before you touch a wire: protocol, station address, baud rate, data bits, parity and stop bits have to match the panel's device configuration. In the repair this article follows, every read came back once those parameters were corrected.

The panel and the controller each hold their own copy of the serial rules. The panel's copy sits in its device configuration; the controller's copy sits in a communication parameter group reached from the controller's keypad. When the two copies disagree, the controller either never recognizes a request or answers in a framing the panel throws away, and the two displays you built the screen for stay empty.

That is what the repair behind this article came down to. The two signal conductors were landed correctly at the adapter and at the controller's terminals, and a swap test during the search changed nothing. Correcting the parameters inside the controller brought PV and SV up on the panel with the wiring exactly as it was.

What does each blank-read symptom point to?

The panel's own read status splits the problem in two: a timeout on every read points at settings, address or wiring, while a valid response with blank or wrong values points at the register address or data format inside the panel project.

• Timeout on every read, PV and SV together. The controller is not answering at all. Suspects in order: the protocol set to RTU on one end and ASCII on the other, a station address that does not match, a baud rate, data bit, parity or stop bit value that disagrees, and only then the copper.
• A valid response, but a value that is blank, frozen or unreadable. The loop works. The panel is reading the wrong holding register for that item, or the raw value needs a scaling setting.
• PV reads and SV does not, or the reverse. Treat them as two separate reads. The working one shows the conductors, the settings and the station address are all good, so the fault sits in the failing item's register reference alone.
• The panel's number disagrees with the number on the controller's own display. Typically a scaled value arriving without its decimal point, for example 1234 where the controller shows 123.4 °C. That item's data format in the panel project needs its scaling set.

When the second symptom appears only after a particular screen opens, compare the tags that screen polls; the same screen-by-screen logic separates a reference fault from a loop fault.

How do you read the panel's read status before rewiring?

Open the panel's diagnostics or communication monitor and write down the result of one PV read and one SV read before you change anything: timeout, protocol error, or a valid transaction.

Most HMI configuration packages carry a diagnostics or communication monitor screen that lists each device read with its result. Keep those two results in front of you, because they split the job: settings and wiring produce timeouts, register references produce valid reads of the wrong thing. Run the same two reads again after every change, one change at a time. A loop that goes from timeouts on both reads to a valid PV read with a still-blank SV has told you the settings are now right and the SV reference is what remains, and it told you without a meter or a screwdriver.

Which communication parameters must match on both ends?

Six settings have to agree on both ends of the link: the same protocol, the same station address and the same serial format, with each value read from the device actually installed instead of trusted from a project template.

The controller's manual carries a Modbus communication chapter documenting the 2-wire RS-485 port, the two protocols it accepts, Modbus RTU and Modbus ASCII, and the parameter group that holds the station address and serial format. The panel side carries the same list in its device configuration. Before tuning anything, confirm the device type selected in the panel actually matches the controller model; check the panel driver list before tuning serial settings explains why that comes first.

One row out of step is enough to blank every display, and every row out of step looks identical from the panel's side. RTU and ASCII deserve their own warning because they are different framings entirely, so a protocol mismatch behaves like a severed pair. When the controller's port is fixed or already agreed with other equipment on the loop, set the panel to match it, the same way you would connect an HMI to a PLC port with fixed serial settings. The same six values decide a Modbus RTU link between an HMI and a VFD, so the comparison habit carries over to every serial device behind a panel.

What does the wiring still have to satisfy?

A 2-wire RS-485 loop needs the twisted pair landed on the two signal terminals at each end, a termination resistor across the pair at each end of the trunk, and polarity matched by the documented signal names, because conductor labels vary between manufacturers.

The RS-485 standard names the two conductors A and B, with A negative relative to B in the idle mark state. Equipment labels rarely cooperate: some devices print + and −, some print D+ and D−, and manufacturers do not map their labels to A and B the same way. Match polarity by the signal names in the two manuals, with the pair traced terminal to terminal.

The termination resistor is typically 120 Ω, the value that matches a twisted-pair trunk cable's characteristic impedance. Fit one across the pair at each end of the trunk and nowhere else; a termination at every drop loads the pair and distorts the signal. Ground the cable shield at one end. Keep the serial pair away from the relay-output terminals on a temperature controller's terminal block, and power the loop down before moving conductors, because those blocks often carry mains-voltage output wiring.

Then the decision rule that saves the most time on this job. A loop that answers even one read has already settled its polarity, its termination and its settings, so leave the conductors alone. Only a loop that never answers, with settings matched on both ends, earns the polarity swap test, and on a 2-wire link that test costs half a minute with the power off.

Worked example: how long does one PV and SV read take at 9600 baud?

At 9600 bit/s with 8 data bits and 1 stop bit, a Modbus RTU transaction that reads PV and SV as 2 holding registers moves 170 bits and finishes in about 25 ms, roughly one tenth of a 250 ms poll interval.

Take a loop where the panel polls the controller every 250 ms and reads PV and SV together, at 9600 bit/s with 8 data bits, no parity, 1 stop bit and station address 1 on both ends.

A Modbus RTU request for 2 registers is 8 bytes: 1 address byte, 1 function byte, 2 start-register bytes, 2 register-count bytes and 2 CRC bytes. The answer is 9 bytes: address, function, a byte count, 4 data bytes for the two 16-bit registers, and the CRC. With 1 start bit, 8 data bits and 1 stop bit, every byte travels as 10 bits, so the transaction moves 17 × 10 = 170 bits. At 9600 bit/s that is 170 ÷ 9600 = 17.7 ms of wire time. Modbus RTU adds a silent gap of 3.5 character times in front of and behind every frame; one character is 10 ÷ 9600 = 1.04 ms, so the two gaps add 2 × 3.65 = 7.3 ms. Total: about 25 ms per transaction.

That is one tenth of the 250 ms poll interval, so a correctly configured loop carries this traffic with room to spare. Raise the port to 19200 bit/s and the same transaction drops to about 12.5 ms. Add a parity bit and it climbs to about 27.5 ms, because every byte now carries 11 bits instead of 10.

The decision comes from the same arithmetic. If the panel polls every 250 ms and every single poll times out, bandwidth has nothing to do with it: the loop sits idle because the controller never recognizes a frame. One mismatched value in the table above, a panel at 19200 bit/s talking to a controller at 9600 bit/s, produces the same silence as a cut wire.

How do you apply the correction and keep it?

Write down the settings you found, change one side to match the other, retest one PV read and one SV read against the values on the controller's own display, and save the corrected configuration on both devices so the fix survives a restart or a project reload.

1. Record both parameter lists before touching anything: the controller's communication group from its keypad and the panel's device settings from its configuration screen.
2. Change one side to match the other. On a loop with nothing else hanging on it, pick whichever side is easier to reach; in the repair this article follows, the controller's parameters were the ones that were wrong.
3. Save on both ends. Store the corrected values in the controller and download the corrected project to the panel, because a parameter set held only in working memory is gone at the next power cycle.
4. Retest one PV read and one SV read and compare each with the number on the controller's own display.
5. If a value arrives but reads wrong, the item needs its decimal scaling set; set the correct HMI data format for the value is that job's own walkthrough.
6. Power both devices down and up once as part of normal maintenance and confirm both reads return.
7. If matched settings still return nothing, run the wiring checks from the section above, and stop there if the loop stays silent, because at that point the fault needs the two manuals and the model numbers on the bench.

Recommendation: Put the controller's communication parameters beside the panel's device configuration before you move a single conductor, and make the controller's list and the panel's list identical. Let the panel's read status split the fault: a timeout on every read points at settings or copper, a valid response with a blank or wrong number points at that item's register reference or data format. Rewire only when matched settings still return no answer at all.

Questions