HMI timer preset multiply breaks after 9: fix binary vs BCD

Why it works at 9 and breaks at 10

BCD packs one decimal digit into every four-bit group, so a 16-bit register holds four digits, 0 to 9999. Plain binary stores the whole value as one number. Both encodings write identical bits for 0 through 9, because a single digit fits in four bits either way. From 10 up they diverge and stay apart:

Picture the rung behind this fault: it loads the constant ten, stores it in V1425, multiplies the entered value in V1450, and stores the product in V1460. On this instruction set MUL works on BCD operands and MULB is its binary twin. A word that arrived in binary carries nibbles such as A, B and C once the value passes 9, and those are not decimal digits, so a BCD instruction has nothing valid to multiply. The timer reads its preset as BCD digits as well, which is why the result has to end up BCD even when the arithmetic runs in binary.

Symptoms and what each one points to

• Entries 1 through 9 scale correctly, 10 through 12 leave the result register unchanged. The HMI writes binary into a register the rung reads as BCD, and the two encodings agree only below 10.
• The result register sits at 10, the product of the last entry that computed cleanly. Runs below 10 produced a valid product, and the register has kept it since.
• A test with LD KA and MULB gives correct products. Hex A is binary ten, so this result confirms the HMI is delivering binary.
• The timer runs but finishes early or late with no fault showing. Some binary products, such as 0x0078, hold only valid BCD digits, so the timer accepts the word and reads preset 78.
• The screen shows the right number while the register holds something else. The entry object paints decimal digits on the display however the tag encodes the transfer, so the screen cannot tell you the encoding; the tag definition does.

Data-format mismatches between a panel and a PLC produce a family of signatures. When the nonsense turns up on an analog value instead of a timer preset, the same tag-format check applies, and the article on an HMI panel showing nonsense numbers from a PLC BCD analog register walks through that variant.

Record three values before you edit the rung

1. Enter a single-digit value such as 9 s. Note the raw word in V1450, the product in V1460, and the monitored timer preset.
2. Enter 12 s and note the same three values. In the failing case V1450 changes and V1460 does not.
3. Open the HMI configuration and open the tag addressed to V1450. Read its data format. The tag editor for this panel family lists a plain unsigned 16-bit integer and BCD Int 16 among its choices, alongside discrete and ASCII string types; your panel help file shows the complete set for your model.
4. If V1450 never holds the entered value in either test, stop there: the entry object or the tag address is wrong, and the math rung is not yet the suspect. Why HMI tag address formats change between PLC protocols explains how one register can be addressed differently under different drivers.

One note on the data window: most data windows render words in hex, and binary data shows hex letters there, so a hex rendering does not by itself prove a value wrong. What matters is which instruction consumes the word next.

Fix the tag data format to BCD Int 16

Change the data format on the V1450 tag to BCD Int 16. The HMI then transfers the entered value with every digit in its own nibble, and the rung stays exactly as written.

K10 in a BCD instruction is the BCD form of ten, so for a 12 s entry the multiply becomes BCD 10 × BCD 12 = BCD 120, and V1460 holds 0x0120, the correct preset at your ×10 scaling. The timer reads it correctly because the path is BCD end to end: tag, rung, preset, with no conversion instruction anywhere. Retest 10, 11 and 12; the register now tracks the entry one for one and the single-digit results do not move.

Keep binary math and convert before the timer

Keep the tag as a plain unsigned integer when other rungs already read the register as binary, and convert at the timer boundary instead. Ten loads as KA, the hexadecimal form of ten, and the binary multiply replaces the BCD one: LD KA, OUT V1425, MULB V1450, OUT V1460.

The product is now correct in binary: 12 × 10 = 120, stored as 0x0078. The timer still cannot use that word, because it reads BCD digits and 0x0078 reads as 78. Run the product through the BCD instruction and store the converted word where the timer picks up its preset; BCD rewrites binary 120 as the BCD word 0x0120. On this instruction set the conversions work through the accumulator, so the product passes through it on the way to the preset register. The number conversion instructions chapter of your model's user manual gives the exact load and convert order.

Worked example: 12 seconds through both fixes

Scenario: the operator wants a 12 s step, and the rung scales by 10 because the timer's time base is 0.1 s, so the correct preset is 120 and the step should run 12.0 s. If your time base differs, divide the seconds by the base to get the preset; the encoding fix below is unchanged.

Broken as found. The tag is a plain unsigned integer, so the entry lands in V1450 as binary 0x000C. MUL expects BCD, and nibble C is not a decimal digit, so no usable product comes out and V1460 keeps the 10 left by the earlier single-digit test. The timer holds preset 10 and the step runs 10 × 0.1 s = 1.0 s, an 11.0 s shortfall against the 12.0 s ordered.

Binary math, no conversion. LD KA with MULB gives 10 × 12 = 120, so V1460 holds 0x0078. The timer reads BCD digits 0, 0, 7, 8, accepts preset 78, and runs 78 × 0.1 s = 7.8 s. No fault appears anywhere; the step is simply 4.2 s short.

Fix 1. The tag becomes BCD Int 16, the entry lands as BCD 0x0012, and the BCD multiply produces BCD 120 in V1460 as 0x0120. The preset reads 120 and the step runs 120 × 0.1 s = 12.0 s.

Fix 2. V1450 stays binary at 0x000C, MULB gives 0x0078, and BCD converts it to 0x0120 before the timer reads the preset. The step again runs 12.0 s.

Both fixes land on the same word, 0x0120, and the same 12.0 s step. The broken paths fail in two different ways: one stalls at a stale value, the other times silently at the wrong length.

Verify before the line runs product

Run the entries that exposed the fault and confirm the preset against a stopwatch:

1. Enter 9 s and read preset 90 in the timer.
2. Enter 10 s and read preset 100.
3. Enter 12 s and read preset 120, then time one full cycle. A 12.0 s preset should match the stopwatch within the timer's resolution. If you want the running value visible on the HMI while you time it, show an HMI timer counting from a PLC current value sets up that display tag.

Change one boundary per edit, tag or rung, never both at once, so a wrong result points at the end that moved. If the preset reads correctly and the elapsed time is still off, the time base inside the timer instruction is the remaining suspect; read it in the programming reference before trusting any wall-clock math. A timing fix changes what the machine does, so check the corrected step time against the process specification and watch the first cycles before production.

Which fix to choose

Recommendation: set the V1450 tag to BCD Int 16 and keep the rung as written when the timer is the only consumer of the value. It is one setting, the original logic stays untouched, and the entries that failed at 10, 11 and 12 recover immediately. Keep the tag binary and add the BCD conversion between MULB and the preset when other rungs already treat the register as binary, so the conversion sits at the one boundary where the encoding changes. Apply one fix at one boundary; a second conversion anywhere else only moves the mismatch.

Questions