Pass whole numbers from an HMI recipe float to 16-bit integers

Why can't the recipe object move a float into a 16-bit register?

A recipe object copies values between tags of the same type and performs no arithmetic. A 32-bit float and an unsigned 16-bit word share no bit-level relationship. Your PLC logic must supply the round, range-check and write.

A recipe field binds to one tag and copies that tag's value out and back. The two formats store numbers differently. An unsigned 16-bit word is a plain binary magnitude from 0 to 65535. A single-precision float packs a sign bit, an 8-bit exponent and a 23-bit fraction into 32 bits. No bit in one pattern stands for a digit in the other, so a transfer needs real arithmetic: round or truncate, range-check, then write.

Two limits shape that arithmetic. Range: the word holds nothing negative and nothing above 65535, so the PLC must clamp or flag those cases. Precision: a float32 holds every whole number exactly up to 16,777,216, because its 23 stored fraction bits carry 24 bits of precision, so whole-number process values inside that span lose nothing as float.

Build the PLC-side cast now and check the release notes of your installed panel software later for a built-in type conversion. A feature request does not put a line back in production.

What happens if I map a float tag onto a single 16-bit register?

You get half of the two-word IEEE 754 bit pattern, never the number. 100.0 is stored as 0x42C80000, so a single-word read returns 17096 from the high word or 0 from the low word while the float changes underneath.

A single-precision float occupies two adjacent 16-bit registers. A panel that reads one of them gets a slice of the encoding, and the slice shifts with the mantissa bits as the process value drifts. Overlaying an integer tag on the float's address reinterprets the same bits, so the displayed number swings across the word range while the float moves by a fraction of a unit.

Use a known value to confirm any two-register link before trusting it. 1.0 encodes as 0x3F800000, so the high word reads 16256 and the low word reads 0. If your panel or gateway shows that pair, you are looking at raw halves of the float. The layout is covered step by step in how to display a PLC float stored in two word registers on an HMI.

Which symptom points to which data-type fault?

Each failure mode names its own cause. 17096 for a value near 100 means a half-word read. A value that goes negative above 32767 means signed interpretation of an unsigned word. Values that swing as the float moves mean two tags overlaying one address.

• 17096 for a value near 100, or 16256 for 1.0. The panel is reading one word of the float's two-register encoding. Repair the mapping; the whole number was never in the word.
• Correct up to 32767, negative above it. The tag is being read as signed. A word holding 40000 displays as 40000 - 65536 = -25536; set the number format to unsigned or convert in the PLC.
• A large positive number that matches no scaling. The tag's number format does not match the data behind it; set the signed decimal data format covers that case in detail.
• A value that swings wildly while the float drifts slightly. An integer tag overlays the float's address and reinterprets its bits.
• A register that stays untouched after a conversion run. The convert instruction never executed; check the enable condition first, the same first check used when a real-to-BCD conversion writes nothing.

How do I convert a recipe float to a 16-bit word in PLC logic?

Round the float first, clamp it to the unsigned 16-bit range of 0 to 65535, latch a fault outside that range, hold the last valid word, and write only the clamped result to the word the recipe object binds to.

You need a float working tag in the PLC, a 16-bit unsigned recipe word, a fault bit, and the panel recipe bound to that word alone.

1. Download, word to float. Convert the unsigned word to a real with the PLC's integer-to-real instruction, treating the word as unsigned. A signed conversion turns any value above 32767 negative.
2. Upload, float to word. Add 0.5 before converting if a fractional part can appear, convert to integer, then range-check: below 0 or above 65535 sets the fault and leaves the last valid word in place.
3. Latch and show the fault. Wire the fault bit to a panel alarm or indicator so a rejected recipe value is visible and the operator reloads. A wrapped or truncated value must never reach the machine as a setpoint; holding the last valid word and raising the alarm is the safe behavior.
4. Check the rounding. Confirm in the PLC manual whether the real-to-integer instruction rounds or truncates. Adding 0.5 before a truncating convert gives round-to-nearest; skip the add when the instruction already rounds.
5. Bound the typed values too. The same clamp-in-ladder pattern for panel numeric entry is set out in clamping numeric entry limits in PLC ladder logic.

Worked example: what does 100.0 become on each data path?

Mapped raw, 100.0 sits in two words as 0x42C80000 and its high word alone reads 17096, which is 16384 + 512 + 192 + 8. Converted in the PLC, 100.0 + 0.5 = 100.5 truncates to 100, and the word reads exactly 100.

A baking line stores a mix time of 100 seconds as a float tag, and the panel recipe field is one unsigned 16-bit word.

The same run at the edges: 0 converts to word 0; 65535 stays 65535; 65536 fails the range check, so the fault latches and the word holds its last valid value; -1.0 seconds fails below zero the same way. A field typed as 12.5 becomes 12.5 + 0.5 = 13.0, truncate = 13.

Which tests check the conversion before the line runs?

Write each edge value from the panel and read the PLC tag, the recipe word and the fault bit back: 0 returns 0, 100 returns 100, 65535 returns 65535, while 65536 and -1 latch the fault and hold the last valid word.

Then round-trip a full recipe: load it to the PLC, upload it back, and compare every field with the source. A field that returns shifted by a fixed offset points to word order in a two-register type. A large odd number points to signedness. Both are mapping faults, and both are caught here, before production.

When is a 32-bit integer or a fixed-point scale the better path?

Move the whole path to 32-bit integers when values exceed 65535 and the tag list offers the type; a float32 holds every whole number up to 16,777,216 exactly. Scale by 10 when one decimal matters, resolution 0.1 units, and a span of 0 to 6553.5 covers your largest value.

Pick the data path before editing the panel:

Verify any two-register link with the known value 1.0, which encodes as 0x3F800000. A high word of 16256 confirms the order you assumed, and a low word of 16256 means the registers are swapped. Converting a CODESYS REAL into two Modbus WORD registers walks that word-order check step by step. For the screen side of these panels, the shop-floor screens category collects the other register and display fixes.

Recommendation: Keep the recipe on the 16-bit unsigned word with the conversion in PLC logic when your values are whole numbers that fit 0 to 65535. Move the whole path to 32-bit integers when any value exceeds 65535 and the tag list offers the type. Use a scale factor of 10 when a field needs one decimal place, resolution 0.1 units, and 6553.5 covers its largest value.

Questions