Display a PLC float stored in two word registers on an HMI

6 min read · Published November 6, 2026

A PLC real is a 32-bit IEEE 754 float spread over two 16-bit word registers. Set one HMI numeric field to the 32-bit float format and point it at the first register of the pair. If the decoded value is still wrong, check the start address, then the word order.

A real number needs more than one 16-bit register. A small PLC stores it as a 32-bit IEEE 754 float split across two consecutive word registers, and an HMI field set for a plain integer shows only a fragment of that encoding: an unrelated number that tracks the process value. The fix is one numeric field set to the 32-bit float format and pointed at the first register of the pair. Decimal-place and scaling settings change how a number looks; they never change how the pair is decoded. Get the format and the start address right first, tune the presentation second, and check word order last, because word order only matters once everything else is right.

How a real sits in two registers

Most HMI tools name this format something like 32-bit float, real or binary32. It is the IEEE 754 single-precision layout: 32 bits in total, made up of 1 sign bit, 8 exponent bits and 23 fraction bits. IEEE 754 stores the exponent with a bias of 127, so an exponent field of 130 means 2^3.

The PLC splits those 32 bits across two 16-bit registers. The first register holds the sign, the exponent and the top fraction bits. The second holds the rest of the fraction. Decoded as a 16-bit integer, the first register gives a plausible-looking but wrong number, and the second gives another unrelated one. That is why two integer fields bound to the two addresses show the storage and never the engineering value.

Writing the value out again as two registers is the mirror job. That direction is covered step by step in converting a CODESYS REAL into two Modbus WORD registers.

Set the field up

  1. Back up the HMI project, then open the numeric display object that is meant to show the value.
  2. Set its data format to the 32-bit float option, IEEE 754 single precision. A 16-bit signed, 16-bit unsigned or 32-bit integer setting decodes a different layout and shows the wrong number even with a correct address.
  3. Point the object at the first register of the pair. Take the address from the PLC tag list, not from a neighboring object on the screen.
  4. Set decimal places and any display limits after the format is right. Those settings shape presentation only.
  5. Transfer the project and watch the field while the process value changes.

If the software offers no 32-bit float option at all, do not substitute another data type; the practical fallback is a scaled integer in the PLC, described in the last FAQ below.

What the wrong number tells you

The shape of the wrong value narrows the fault to one item. Work down the list in order; each row assumes the rows above are already clear.

  • A steady, plausible integer, wrong by orders of magnitude. The object decodes one 16-bit word as an integer. Set the 32-bit float format (steps above).
  • A huge value, often with junk digits after the decimal point. The start register is off, usually by one. Check the start address against the PLC tag list.
  • A tiny value such as 0.00 or -0.00 for a process value nowhere near zero, while the registers visibly change in the PLC software. The two words are assembled in the wrong order. Swap the word order in the field's data-format settings and compare again.
  • The right value that never updates. The object points at a copied or stale address. Bind it to the live registers.
  • Zero for every value, with the registers also reading zero or frozen in the PLC software. The fault sits upstream in the write or transfer path. Fix the transfer first.

When that last case runs over Modbus, it has its own fix, written up as fixing CODESYS showing 0 for Modbus TCP analog values.

Example: decode 12.5 from two registers

Say a tank temperature of 12.5 sits in two consecutive 16-bit registers, 100 and 101, high word first. The register numbers are illustrative; yours come from the PLC tag list.

Encoding: 12.5 in binary is 1100.1. Normalized, that is 1.1001 × 2^3. The sign bit is 0. The exponent field is 3 + 127 = 130, written 10000010 in binary. The fraction is 1001 followed by nineteen zeros. Assembled, the 32 bits read 0 10000010 10010000000000000000000, which is 0x41480000 in hex. Split across the pair: register 100 holds the high word 0x4148 = 16712, and register 101 holds the low word 0x8000 = 32768.

A field set to 32-bit float at register 100 reassembles 0x41480000, reads the exponent 130 - 127 = 3 and the fraction 0.1001 in binary = 9/16 = 0.5625, and shows (1 + 0.5625) × 2^3 = 12.5. Correct.

Two wrong settings produce the two classic symptoms. A field set to 16-bit signed integer at register 100 shows 16712: steady, plausible, wrong by a factor of about 1337. That is the reading that fools people, because it looks like a scaling problem. A field with the word order swapped assembles 0x80004148 instead: sign 1, exponent field 0, fraction 16712. The value decodes as -(16712 / 2^23) × 2^-126; 16712 / 2^23 is 0.00199 and 2^-126 is 1.175 × 10^-38, so the field gets about -2.34 × 10^-41, which a two-decimal field shows as -0.00.

Word order, checked last

Word order is which register holds the high word. A PLC that stores the high word first and a field that assembles low word first turn the same pair into two different numbers, and the example shows the shape of each result.

Check word order after the format and the start address are confirmed. Read both registers in the PLC programming software. If the first register carries the sign and a magnitude in the range of the process value, and the second reads as an arbitrary number, the pair is high word first and the field should be set to match. The word order choice sits in the same data-format settings as the type selection on most HMI tools. Change it there, transfer, and compare the field against the live value. Leave the PLC storing the value in its native order and let the field follow. If the value arrives over Modbus, the device documentation states the register order it uses for 32-bit floats, so the field can be set correctly before the first transfer.

Verify, then record

Compare the field against the PLC's live value at two operating points, one near 10 percent of the process span and one near 90 percent. Sign and magnitude must match at both, and the digits must update as the value moves. If you force a test value into the registers, put the machine in a safe state first: a forced real feeds the same logic that runs the line.

Record four items in the project notes: the start register, the data format, the word order and the decimal places. Whoever edits the screen next then reads the decode off the notes instead of reverse-engineering it. More fixes for operator panels and shop-floor boards sit in the factory screens section.

The decision

Recommendation: Set one numeric field to the 32-bit IEEE 754 float format and point it at the first register of the pair. In most cases that single setting fixes the display. If the decoded value is still wrong, check the start address, then swap the word order in the field's data-format settings. Hand the screen back only after the field matches the PLC's live value at two operating points, with the start register, format, word order and decimal places recorded in the project notes.

Questions

How do I find which register holds the high word before touching the screen?

Read both registers with the PLC programming software and look at the first byte of each. For a normal positive process value between about 0.01 and 65000, the high word starts with a byte between 0x3C and 0x47 in hex, because that byte carries the sign bit and the top of the 8-bit exponent. The low word carries only fraction bits, so it reads as an arbitrary number with no usable pattern.

Does the same fix apply to a numeric input field?

Yes, with one extra switch. The input object needs the same 32-bit float format pointed at the first register, plus floating-point entry, so the on-screen keypad produces a real value with a decimal point instead of a whole number the PLC reads as units. Set both on the same object, then test by typing a value with decimals and reading the registers back in the PLC software.

What if the HMI software has no 32-bit float option?

Scale in the PLC. Move the real into a 16-bit integer with a fixed multiplier before it reaches the display registers; multiply by 10, for instance, to keep one decimal place, then show that integer with the decimal position implied by the label. The field then uses a 16-bit integer format. Write the multiplier next to the field or in the project notes so nobody reads the raw number as engineering units.

Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.

Keep reading

Build your signAsk for a quote