Why the PLC and MES Shift Counts Never Match, and Which One to Trust
The shift report says 1,738 good parts and the HMI says 1,742. Where to look first: counter style, historian deltas, S6F11 event time, or the spool.
The night shift report printed 1,738 good parts. The equipment HMI showed 1,742. Four parts.
Those four cost two days. The PLC counter was fine, the historian had not dropped a sample, every MES transaction was present. The problem was that four systems each understood "06:00" as a slightly different moment.
Counters are wrong less often than people assume. Reconciliation is a boundary problem: where the count starts, where it ends, and whose clock decides.
Nail down the source of truth per count first
Starting the meeting with "MES is correct" versus "the PLC is correct" turns it into a two-hour meeting. Decide one source per kind of count and move on.
| Count | Source to use | Why |
|---|---|---|
| Machine cycle | PLC | Closest to the equipment |
| Good count | The station that decides pass/fail | The test station, not the packer |
| Reject count | Test system + operator reason entry | Reason code mapping is separate work |
| Rework | MES or operator station | Usually invisible to PLC logic |
| Shift total | Reporting layer | Depends on boundaries and order context |
On a line that counts good parts at the packer and rejects at the test station, good + reject will never equal cycle count. Parts disappear in between. That is a design decision, not a defect — but if it is not written down it gets reported as a defect every quarter.
Decide at the same time what happens when an operator edits a count in MES: correction, override, or a separate adjustment record. Deciding later means deciding after the data is already mixed.
Know the counter style before writing the report
Two tags both named "good count" can behave completely differently.
A counter that resets at shift start or power cycle. A lifetime totalizer that only wraps at its numeric limit. A one-shot pulse per part. A batch counter that resets at order change. Good and reject counters with entirely different reset timing — common enough that you should check rather than assume.
For reporting, the lifetime totalizer wins. Subtract shift start from shift end and you are done; nobody has to know who reset what. A resettable counter can work, but only if reset timing is controlled and logged as an event. If that condition looks unlikely to hold on this project, asking the controls vendor for a totalizer up front is the cheaper fight.
A 16-bit counter on a 60 ppm line wraps roughly every 18 hours — at least once inside a three-shift day. Document the rollover value and delta handling, and if the line can actually reach it, push it over the edge once in simulation.
Time boundaries: this is where the days go
The line does not stop because the shift did. The report window closes at 06:00 and the equipment keeps finishing the parts already in it. At least four clocks are involved:
- The PLC or equipment internal clock.
- The moment the SCADA collector read the value.
- The historian's storage timestamp, usually UTC.
- The moment MES committed the transaction.
Equipment connected over SECS/GEM adds one more. The clock SV carried in an S6F11 event report is the equipment's time, not the time the host received it. Split shifts on host arrival time and a tool running three seconds slow moves a handful of boundary parts into the wrong shift. GEM has S2F31 Date and Time Set Request precisely for this: sync on every host connect and log the delta you corrected. A tool drifting four seconds a day is telling you its RTC battery is dying, and you would rather hear that from the sync log than from a reconciliation dispute.
The spool drain is worse. After a link drops and comes back, the equipment pushes out everything it queued as spooled S6F11s. Those messages carry past event times and present arrival times. A report that assigns shifts by arrival order fails silently here: an event generated at 05:50 arrives at 06:10 and lands on the day shift instead of the night shift. Confirm in the code — not the design document — whether your report keys on event time or arrival time.
Write these down:
- Shift start/end timestamps, timezone, and which clock measures them.
- Grace period for late operator login or order close.
- Whether a count exactly at the boundary belongs to the previous or next shift (
>=or>, one line, settled). - DST handling if the site observes it: once a year the night shift is nine hours long and once it is seven. Any per-hour KPI spikes on those two days.
- Which shift owns planned downtime during handover.
On a high-speed line, avoid report logic that trusts a single sampled value at the boundary. Test what your historian's compression and interpolation rules actually produce at that one point and the reason becomes obvious.
Keep order context attached to the count
A raw count without context cannot be reconciled afterwards. The count event should carry shift ID, work order, lot or carrier ID, product code and recipe version, equipment state at the time of the count, and quality state — good, reject, hold, rework, sample.
If the shift starts at 06:00 and the product changes at 06:02, those two minutes have to be visible. That gap is exactly how you get a report whose total is right and whose per-product split is wrong.
Log resets and rollovers instead of hiding them
A silent counter reset destroys delta arithmetic. Log at minimum: shift reset command, order or batch reset, PLC download and cold restart, counter rollover, manual adjustment, and communication gaps between SCADA and PLC.
When computing deltas, refuse unexplained negative changes. A reset or rollover event has to be there to justify one; without it the record goes to review. I have seen delta code that quietly took the absolute value instead. Nobody noticed for three months.
Reconcile by exception, never by overwrite
Overwriting one value with another makes the report match and deletes the reason. A shift summary should hold both the measurement and the adjustment:
- PLC measured good / reject count
- MES accepted good count
- Manual adjustment, with reason and operator
- Reconciled final count
- Reconciliation status: matched, adjusted, late data, missing data, under review
Production reads the final count; engineering traces the difference. Those two requirements do not conflict. They only conflict if you insist on one column.
A 30-minute check before go-live
Run a short controlled trial before anyone trusts the production report.
- Take a short reporting window.
- Produce a known number of good parts and rejects.
- Change product or order once inside the window.
- Force one operator correction if procedure allows it.
- Restart the collector or pull the network cable to create a communication gap. On SECS/GEM this is where the spool fills and then drains after reconnect.
- Compare PLC, SCADA, historian, MES, and final report values.
Skip step 5 and the trial proves almost nothing. Reports rarely disagree during clean running.
Matching totals is not the goal on its own. The test is whether a mismatch leaves a reason a human can read. A report that prints one final number is not necessarily correct — it is just quiet.
If you want to watch the equipment side of this on the wire, drop and restore the link against the SECS/GEM simulator and see how far event time and arrival time separate before you go arguing about the counter.