Count each accepted cycle once into a 32-bit retentive counter set, compare a stored calendar key with the PLC clock every scan, and on a change copy the finished period into a dated history table before clearing. That closes daily, weekly, monthly and yearly totals exactly once and keeps them through a power cut.
A production count is easy to total and easy to lose: the day total clears at midnight and takes last Tuesday's number with it. The fix costs a dozen retentive registers. Count each accepted cycle once into a 32-bit counter set. Keep a stored copy of the last closed calendar key and compare it with the PLC clock every scan. When the key changes, close the finished period into a dated history table first, clear the counter second, write the new key last. Because the rung writes the key back inside the same scan, the rollover fires once, at the boundary, and never on the scans after it. The same pattern closes the day, the week, the month and the year. This article sizes the counters and the history table, walks the rungs in order, and ends with the clock tests that clear the design before Monday's shift.
What do you need before you write the first rung?
You need four things: one clean accepted-cycle signal, a 32-bit counter set in retentive registers, the PLC's real-time clock registers, and a dated history table with room for a full year of daily records.
Agree the counting event with production first: one increment per unit that ships, with rejects, rework and test cycles left out. If two bottles can pass the sensor inside one scan, count on a high-speed counter input. An ordinary counter instruction samples once per scan and misses the second pulse.
Retentive means the PLC restores the range at power-up. Your manual prints which data range is retentive; put the counters, the stored keys and the history table there. It is the same memory trick that keeps PLC run-hour totals alive through a power loss.
The clock comes from the PLC itself. The panel needs two features: numeric fields that read the live registers, and a data log that writes CSV rows to a USB stick.
How wide must the counter register be?
A 16-bit register rolls over at 65,535 and a 32-bit register at 4,294,967,295, so divide the limit by your cycle rate: at 7,200 cycles an hour the 16-bit count overflows after 9.1 hours of running.
The limits are arithmetic, not settings. An unsigned 16-bit register holds 0 to 2^16 minus 1, which is 65,535, and an unsigned 32-bit register holds 0 to 2^32 minus 1, which is 4,294,967,295. Divide the limit by your hourly rate to get the running hours the counter survives. A wrapped counter is the same failure as an HMI parts counter rolling over at 9,999: the register passes its width, jumps to zero, and every total built on it loses the wrapped part.
The decision is quick. Any counter that can reach 65,535 between its resets goes 32-bit; at bottling rates that is every counter in the design, including the day total. Size the panel's numeric field to the register, not the other way round: a field too narrow hides the true count even when the register is fine.
Where does the PLC get the date for the boundaries?
The PLC's own real-time clock supplies the date: it keeps year, month, day, hour and minute in system registers your manual lists by address, and you set it once from the programming software.
Build a live calendar key from those registers every scan: the current year, the day-of-year from 1 to 366, the week-numbering year and week number, and the month from 1 to 12. Day-of-year is worth the conversion because February, 30-day months and leap years stop being special cases; the day key simply changes at midnight, whichever month it is.
If the production day begins at 06:00 instead of midnight, apply the offset when you build the day key: before 06:00, use the previous calendar date, so the bottles filled at 05:30 close into yesterday's record. Month and year keys stay on the calendar month and calendar year, because the office report follows accounting months, not 30-day blocks.
Set the clock from the programming software at commissioning. After long storage or a battery swap, check the date before the first shift.
How do you build the rollover logic step by step?
Store the last closed calendar key in retentive registers and compare it with the live key each scan: the mismatch is true for exactly one scan, because the same rung writes the new key back before the next scan ends.
Build it in this order:
- Count accepted cycles into a 32-bit lifetime counter placed in retentive registers, on a high-speed counter input if the sensor can pulse twice inside one scan.
- Reserve four 32-bit period counters, for day, week, month and year, and five stored key registers: year, day-of-year, week year, week number and month.
- Each scan, compute the live keys from the clock registers, applying your production-day offset to the day key.
- Day rung: when the stored year and day-of-year differ from the live pair, copy the day counter into the next free history slot with its date stamp, clear the day counter, then write the live pair into the stored registers. Copy, clear, key, in that order, inside one rung. That is the same rule as saving the previous count before a PLC counter reset, applied once per period.
- Week, month and year rungs: the same pattern on their own key pairs, so each boundary closes exactly once, even when day, week and year end together at New Year.
- Decide the write-failure path before it happens: if the history table is full or a write fails, hold the counter, raise a status bit and leave the period open until the operator makes room. The total stays on screen and the shift knows why.
- Plan the restart: counts accrue only while the PLC is powered, so after an outage across a boundary the key mismatch closes the old period once, and the skipped period simply has no record. The report shows the gap by its dates.
Steps 4 and 5 can share one subroutine that takes the period's key pair and counter as inputs.
Which week is week 1 when the year turns?
The common week-numbering convention runs a week Monday through Sunday and calls week 1 the week that contains the year's first Thursday. That makes a year 52 or 53 weeks and hands a few days at the year's edge to the neighbouring year's week numbering.
In practice that means three things. The week boundary is Monday 00:00, so the weekly rung fires on Sunday midnight, not Saturday. Week 1 is the first week with four or more days in the new year; December 30, 2024 belongs to week 1 of 2025 even though the calendar year still says 2024. And one year in five or six runs 53 weeks, so store the week-numbering year beside the week number and let the report show it: week 53 looks weak against week 52 until the reader sees why.
Use that convention as the default unless accounting runs a different calendar, such as a 4-4-5 retail week; in that case build the week key from that calendar's own week table and write the convention into the report header.
How much retentive memory does a year of history need?
One daily record of date stamp plus 32-bit count takes 5 registers, so a leap year of 366 records takes 1,830, and with keys and live counters the whole design fits in about 1,850 retentive words.
The arithmetic: 3 registers for the date stamp (year, month, day) plus 2 registers for the 32-bit count makes 5 per record, and 366 x 5 = 1,830. The live side adds a 32-bit lifetime counter (2 registers), four 32-bit period counters (8) and five stored keys (5), for 15 more. If the model's retentive range is smaller than that, keep a 90-day rolling window in the PLC: 90 x 5 = 450 registers plus the 15 live ones, and let the panel's CSV log carry the long-term history. This is the same sizing exercise as fitting an HMI trend's Total Stored Samples to the panel's memory: count the records, multiply by the registers each one takes, compare the result with the range the manual prints.
Recommendation: keep one 32-bit lifetime counter and day, week, month and year counters in retentive registers with their five stored keys, close a dated record at each boundary in copy-clear-key order, and size the daily table to the retentive range you actually have: a full year of records when it fits, a 90-day rolling window when it does not, with the CSV log carrying anything older.
Example: what does a line at 120 bottles a minute store at each boundary?
A line running 120 bottles a minute produces 7,200 bottles an hour and 115,200 in a 16-hour day, so its 16-bit counter dies 9.1 hours into the first shift and every total from the day up must live in a 32-bit register.
Run the divisions:
- Rate: 120 x 60 = 7,200 bottles an hour.
- Day: 16 running hours x 7,200 = 115,200 bottles.
- 16-bit check: 65,535 / 7,200 = 9.1 hours, so the 16-bit register wraps mid-shift; 32-bit everywhere.
- Week: 6 run days x 115,200 = 691,200 bottles.
- Month: 26 run days x 115,200 = 2,995,200 bottles.
- Year: 300 run days x 115,200 = 34,560,000 bottles.
- Lifetime headroom: 4,294,967,295 / 115,200 = 37,283 run days, about 124 years at 300 run days a year, so one 32-bit lifetime counter never needs a rollover in service.
| Period | Assumption behind it | Count at close | Width |
|---|---|---|---|
| Day | 16 running hours | 115,200 | 32-bit |
| Week | 6 run days | 691,200 | 32-bit |
| Month | 26 run days | 2,995,200 | 32-bit |
| Year | 300 run days | 34,560,000 | 32-bit |
| Lifetime | never resets | up to 4,294,967,295 | 32-bit |
The assumptions are the illustrative ones: 16 running hours a day, 6 run days a week, 26 run days a month, 300 run days a year. Put your own rate and calendar into the same divisions and the table rebuilds itself.
How do the counts reach the panel and the printed report?
Point the panel's numeric fields at the live registers, and have the panel's data log write one CSV row per closed period record to a USB stick. Period-completion rows give the spreadsheet everything a printed report needs without logging the same total thousands of times a day.
Log from the PLC's history table, not from a live value: each new history record is complete and timestamped, so a panel that reconnects after a communication loss can back-fill the rows it missed. Open the CSV in the spreadsheet, total by date for the week, month and year views, and print the layout the office already uses. If the rows arrive as separate daily files, combining daily HMI log files into one CSV is the last step before the report.
One distinction that changes a purchase: a live operator panel and a floor notice board are different jobs. The panel reads the PLC over its driver link; a large board showing today's goal and month-to-date takes a refreshed show instead. Our factory and plant floor screens play a show offline from a memory card or USB stick, or from your own Android app, so the board changes when the show changes and the live numbers stay on the panel.
How do you test the rollover before the shift starts?
Force the clock instead of waiting for midnight: set it to 23:58 on a Sunday, run 3 minutes of production into Monday, and you should see one daily record, one weekly record and two counters reset to zero.
Stop the line or pick a gap between batches before you force the clock, because recipes and time-based sequences see the jump too. Then run the checks:
- Midnight and week test: clock to Sunday 23:58, 3 minutes of running. Exactly one daily record and one weekly record, day and week counters at zero, stored keys updated.
- Month test: repeat on the last day of a month. The month rung fires once and the new month starts at zero.
- Power test: cut power mid-shift and restart. Lifetime and day counters come back, the clock holds its time, and no record appeared because of the outage.
- Sample test: run a counted batch of 100 units. Lifetime and day both add 100 and every panel field agrees.
- Gap test: with the line stopped, push the clock forward two days. The old day closes with its own date stamp, the skipped day produces no row, and the year total is untouched.
- Log test: take the USB stick to the office, open the CSV, compare its rows against the history table, and print the report.
Pass those six and the totals survive midnight, the weekend, a power cut and the printer.
Questions
What happens if I correct a bad day after its record closed?
Post the correction into that day's record in the history table, then re-total the week, month and year from the records in the spreadsheet before printing. This is why the design keeps dated daily rows: a stored closing total is hard to correct, while an edited record lets every roll-up be recomputed from the data that is actually right.
Should the counts live in the panel instead of the PLC?
Keep them in the PLC. A panel project gets replaced or re-downloaded, a communication loss can blank its displayed values, and its log files are a copy made after the fact. The retentive registers in the PLC are the source of the numbers; the panel displays them, writes one row per closed record and prints.
What happens when the machine sits idle for a month?
The idle month produces no records, because counts accrue only while the line runs. The year total stays the sum of the records that exist, and the skipped period shows up in the report as a date gap. If accounting wants an explicit zero row for a no-production period, add it in the spreadsheet from the date list.
What if the PLC clock resets after a battery failure?
The counts in retentive registers survive, but the key comparison closes the current period into one record stamped with the wrong date. Set the clock first, then make the stored keys match the new date before production starts, and correct the stamp on that one record so the report stays in date order.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.