A parts counter that rolls over at 9,999 is a 16-bit BCD value: packed BCD stores one decimal digit per 4-bit group, so a 16-bit word holds four digits and stops there. Size the count to the largest total between resets, widen lifetime totals to 32-bit in the PLC, and set the HMI tag and display digits to match.
A parts counter that rolls over at 9,999 has hit the limit of a 16-bit BCD number, not a broken panel. Packed BCD stores one decimal digit in each group of 4 bits, so a 16-bit word carries exactly four digits, and the increment past 9,999 has nowhere to go. The same wall stands at 65,535 for an unsigned 16-bit count and at 99,999,999 for a 32-bit BCD count. Fixing it means matching three things: the width the PLC counts in, the encoding the HMI tag reads, and the number of digits the display object shows. Below are the range for each width, the symptoms that separate a width limit from a tag mismatch, a worked example at 600 parts per hour, and the steps that move a lifetime total to a 32-bit count.
Why does an HMI parts counter roll over at 9,999?
A count that stops at 9,999 is stored as 16-bit packed BCD somewhere in the chain, because packed BCD holds one decimal digit per 4-bit group, so a 16-bit word has four digit groups and cannot represent 10,000 or anything above it.
Most PLC counter instructions store their accumulated value in BCD, which is why the four-digit wall keeps appearing. On the step past 9,999, a BCD add wraps the digits to 0000; a plain binary add leaves a nibble outside 0 through 9, and a BCD-formatted display turns that pattern into junk instead of a number. The unsigned path has its wall one place higher: a 16-bit binary word holds 65,536 distinct values numbered 0 through 65,535, so 65,535 increments to 0. Neither the PLC nor the panel is broken; the width is too small for the total you asked it to hold.
What do the symptoms tell you before you open the program?
Match the symptom to the width and the tag type before you change anything: a wrap to 0 or 0000 is a real width limit reached, while junk digits, a negative number or a clipped value point to a tag or display setting.
- The count returns to 0 or 0000 mid-run. The register reached its width limit and wrapped: 9,999 on a 16-bit BCD count, 65,535 on an unsigned 16-bit count. Widening the count is the fix; another panel would wrap the same way.
- The digits turn to junk just past 9,999. A BCD-formatted tag is reading a value that no longer holds four decimal digits, usually a binary count interpreted as BCD. The same mismatch lies behind nonsense numbers from a PLC BCD analog register.
- A large total reads as a wrong big number or a negative. The tag type does not match the stored value: a signed 16-bit tag shows 65,535 as -1, and a tag left on the low word of a 32-bit pair shows only that word. Setting the signed decimal data format fixes the signed case.
- Only the last digits of a large total appear. The numeric display object has too few digits enabled; widen it to the range in the table below.
- The count climbs faster than parts pass the sensor. The increment rung is true on every PLC scan while the part sits on the sensor; count the signal's rising edge so each part adds exactly 1.
How far can each tag width actually count?
Pick the width from the largest total the register must hold between resets: 16-bit BCD stops at 9,999, unsigned 16-bit at 65,535, BCD 32 at 99,999,999 and unsigned 32-bit at 4,294,967,295.
The ranges follow from the encoding. Packed BCD carries one decimal digit per 4 bits, so 16 bits give four digits and 32 bits give eight, topping out at 99,999,999. Binary words hold 65,536 and 4,294,967,296 distinct values numbered from 0, so the largest stored counts are one less: 65,535 and 4,294,967,295.
| Tag data type | Digits | Largest value | Right for |
|---|---|---|---|
| 16-bit BCD | 4 | 9,999 | batch and shift counts reset before 10,000 |
| Unsigned 16-bit | 5 | 65,535 | daily and weekly totals |
| 32-bit BCD | 8 | 99,999,999 | lifetime totals on a line running for years |
| Unsigned 32-bit | 10 | 4,294,967,295 | any total a machine will ever reach |
Some built-in counter instructions sit below all of these. A byte-wide count wraps past 255; walkthrough for a counter instruction that rolls over beyond 255 applies the same widening fix. In some PLC families the counter instruction is three-digit BCD and stops at 999; counting beyond a BCD counter's 999 limit moves that total to a wider format too. The tag database in the HMI software prints a range beside each data type, so read the printed range against the largest total you need before you commit.
Worked example: how long does each width last at 600 cartons per hour?
A line completing one carton every 6 seconds counts 600 per hour and 4,800 per 8-hour shift, and that rate alone decides the width: 16-bit BCD rolls about 40 minutes into the third shift, unsigned 16-bit in the third week, and a 32-bit type outlasts the machine.
- Rate: 3,600 seconds ÷ 6 seconds per carton = 600 cartons per hour; 600 × 8 hours = 4,800 cartons per shift.
- 16-bit BCD, limit 9,999: two shifts hold 2 × 4,800 = 9,600 cartons. The count reaches 9,999 another 9,999 − 9,600 = 399 cartons into the third shift, at 399 × 6 = 2,394 seconds, about 40 minutes, and wraps on the next carton.
- Unsigned 16-bit, limit 65,535: 65,535 ÷ 4,800 = 13.7 shifts. Thirteen shifts hold 62,400 cartons, leaving 65,535 − 62,400 = 3,135, which lands 3,135 × 6 = 18,810 seconds, about 5.2 hours, into shift 14 in the third week.
- Week total, 5 shifts: 4,800 × 5 = 24,000 cartons, past the 9,999 BCD limit and inside the 65,535 unsigned range.
- Lifetime total, 250 shifts a year for 15 years: 4,800 × 250 × 15 = 18,000,000 cartons, which needs 32 bits. BCD 32 holds it below its 99,999,999 ceiling with room to spare.
Decision: a count reset every shift fits 16-bit BCD at this rate; a week total needs unsigned 16-bit; a lifetime total needs 32 bits, and BCD 32 carries 18,000,000 with headroom.
How do you widen the count in the PLC?
Move the total to a double-word register pair, add 1 with the double-word add instruction once per part event, and keep the encoding you chose: BCD math for a BCD tag, binary math for an unsigned tag, never a mix.
One-word increment instructions come in a BCD form and a binary form, and both stop at one word, which is the limit you just measured. For a larger total, load the two-word block, add the constant 1, and store it back to the same starting register. When a small batch count also has to fold into the running total, adding a 16-bit BCD value to a 32-bit BCD total in a PLC shows the add and the register layout. Count the rising edge of the part-present signal: a rung that stays true while a carton blocks the sensor adds 1 on every scan and the total runs away from reality. Keep the total as an integer; a parts count is a whole number and floating point buys nothing here.
What do you set on the HMI so the wide total reads right?
Set the tag's data type field to the same encoding and width the PLC stores, point it at the first register of the pair, and raise the numeric display object's digit count to hold the new range: 8 digits for BCD 32, 10 for unsigned 32.
Open the tag database in the HMI software and pick the type that matches the register pair. Widen the numeric display object's digit setting to the same range; a four-digit object clips the total it can no longer show. If the data type field is greyed out, the fix for a greyed-out HMI tag data type lists the causes in order. If the tag already feeds other screens, changing an HMI tag data type without rebuilding every object keeps the edit contained.
How do you prove the fix before production?
Preset the register to a test value just under each boundary, pulse the part input past 9,999 and past 65,535 with the machine in a safe state, and confirm the panel and the PLC agree at every step before you release the line.
- Trigger the part input once. The PLC register and the panel must both step by exactly 1.
- Preset the register pair to 9,995 and pulse the input past 10,000. The display must show five or more digits and keep counting, with no wrap to 0000 and no junk.
- Preset to 65,530 and pulse past 65,535, the old unsigned wall. On a BCD 32 tag, a preset near 99,999,999 shows how the logic behaves at that ceiling; a lifetime total should never reach it.
- Operate the reset once and confirm both words clear to zero, not just the low word. If the total is a lifetime figure, decide who may reset before you add a reset button to the panel, and save the previous count before a PLC counter reset when the history matters.
- Run one full production cycle with the panel beside a known count before you call the job done.
Which width should the tag use?
Choose 16-bit BCD only when the panel resets the count every shift and the total stays under 9,999; choose unsigned 16-bit for weekly totals; choose a 32-bit type for anything the machine must remember for its working life.
Recommendation: size the count from the longest total the panel must show between resets. Keep 16-bit BCD for batch and shift totals that stay four digits, move to unsigned 16-bit when the total must survive a week, and count lifetime totals in a 32-bit register with double-word adds, the HMI tag set to the matching type, and the display widened to match. Test the old boundaries with preset values before the line runs. If the count also has to read from across the floor, put it on a separate shop-floor screen driven from the PLC network; displaying a PLC counter value where operators can see it covers the distances and layouts.
Questions
Why do some references list the unsigned 32-bit maximum as 4,294,967,296?
4,294,967,296 is the number of distinct values in 32 bits, 2 to the 32nd power. Because the values start at 0, the largest value a 32-bit unsigned count can hold is one less: 4,294,967,295. Use the smaller figure when you check a count against the range.
Can the HMI fix the rollover without touching the PLC program?
No. A wider tag or more display digits changes how an existing value is read; if the PLC still counts in one word, the register itself wraps at 9,999 or 65,535. Widen the count in the PLC first, then match the tag and the digits to it.
Do run-hour meters hit the same 16-bit limits?
Yes, but much later. An unsigned 16-bit hour meter holds 65,535 hours, about 31 years at 2,080 hours a year, which is one 8-hour shift five days a week. A parts counter at production rates rolls in days or weeks, so hour meters rarely need 32 bits while parts totals often do.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.