Have the PLC detect each stop from the machine's run feedback and accumulate the seconds for each cause with a retentive timer at a 1-second time base. Copy every total into a dated shift record when the real-time clock crosses the boundary, then reset. The operator menu labels causes; the signals supply the minutes.
Track downtime with the PLC, not with operator diligence. The controller detects each stop from the machine's run feedback, a retentive timer accumulates the stopped seconds for each cause, and when the real-time clock crosses the shift boundary the program copies every total into a shift record and then resets the timers. The operator's reason menu still has a job: it names the causes the signals miss. The report stays complete when nobody touches the panel, the totals survive a power cut, and each shift starts its timers from zero.
What counts as stopped
Downtime is an availability loss in OEE, the standard plant metric that multiplies availability, performance and quality, so the definition of producing decides every number in the report. Define producing from feedback: the machine makes parts while the drive reports running or the discharge photoeye sees parts passing. The run command is only an order to run, so time this condition:
run command ON AND run feedback OPEN
A stop while the command is on gets timed. A planned changeover with the command off stays out of the report. Stack lights already carry this state, so the amber or red signal can drive the timing rung when it is wired from the same feedback chain; keep the raw feedback bit as the timer input, and a burned-out lamp then never hides a stop.
What you need
- A PLC with a real-time clock and a retentive accumulating timer. That is the RTO instruction in the set that uses the name; most other sets have an equivalent, and where there is none, a TON that runs every scan and adds its increment to a retained register reproduces the behavior.
- One feedback signal for the stopped state, plus one signal per tracked cause: a chute level switch for no material, a guard switch for an open door, a fault bit from the drive.
- Four to six cause categories that a signal can back, plus an unknown bucket for stopped time nothing explains.
- A touch panel or HMI for the live elapsed seconds and the operator reason entries, or an LED marquee off a PLC output for a glance from across the aisle. Live registers need a display wired to the controller; a player that loops files from a memory card has no path to one, which is why our shop-floor displays fit the static board beside the machine, shift targets and safety topics, and not this job.
- One shift-record area per shift: a date tag, a shift number, one register per cause and one for total stopped time. Size the seconds registers for the longest shift; a signed 16-bit counter overflows at 32767 s, which is 9 h 6 min, so an 8-hour shift fits and a longer one wants 32 bits.
Program the timers and the shift copy
-
Define the stopped state from feedback with the condition above, and watch the bit change while an operator stops and restarts the machine.
-
Name four to six causes the machine can detect with a signal it already has, and reserve the unknown bucket for everything else.
| Cause | Signal that backs it | Timer rung |
|---|---|---|
| No material | Chute level switch low | Stopped AND level low |
| Door open | Guard switch tripped | Stopped AND guard tripped |
| Drive fault | Drive fault bit | Stopped AND fault active |
| Unknown | No cause above | Stopped AND none of the above |
-
Make the buckets exclusive. Evaluate the causes in a fixed priority, first match wins, so every stopped second lands in one bucket and the cause totals sum to total stopped time.
-
Program one retentive timer per bucket plus one for total stopped time, all at a 1-second time base, each on its rung from the table. An RTO accumulates while its rung is true and pauses when the rung goes false, so a stop in three pieces reads as one total, and the value holds through a power cut or a processor mode change until a separate reset instruction. If the feedback chatters, measure the longest false dropout with one of these timers and set a filter just above it; a filter set blind can swallow a real short stop. The same accumulation pattern that drives a motor run-hours display drives these buckets.
-
Show the active cause and the live elapsed seconds on the panel, and keep restart a single button. A forced reason entry before restart adds delay at the worst moment, and the timers run with no entry at all.
-
Fire a one-shot when the real-time clock reaches the boundary, 14:00 for a 06:00 day shift. The one-shot copies every accumulator and the total-stopped value into that shift's record with the date and shift number, then resets the timers. Copy first and reset second, so a hiccup mid-sequence leaves the old totals readable. Copying before clearing is the same order that protects a count saved before a reset, and the clock half of this step is the job covered by setting the HMI clock from the PLC.
-
Guard the reset. Only the boundary one-shot and a maintenance-level screen reset the accumulators, and no operator page carries a reset button.
Give the operator menu a smaller job
The menu labels causes; the signals supply the minutes. When the PLC matches a cause, the panel shows that label and the operator corrects it if it is wrong. When nothing matches, the stop keeps counting in the unknown bucket, and the report says unknown. A missing entry costs a label, never minutes. Keep the menu on screen through fault messages too; PLC messages overwriting the operator menu is the usual way a panel ends up hiding it.
Example: 37 minutes of no material on a filler
A bottling filler runs a 06:00 to 14:00 shift and reports at 14:00. The tracked causes are no material from the chute level switch, door open from the guard switch and drive fault, all timed at a 1-second time base. The operator never opens the reason menu all shift.
- 10:42:00. The upstream tank runs dry. The level switch drops low, the feed starves, and the drive feedback opens while the run command stays on. The no-material timer starts.
- 10:51:00. Material returns, the rung goes false, and the timer pauses holding 9 min × 60 = 540 s.
- 13:07:00. The tank runs dry again and the timer resumes on top of 540 s.
- 13:35:00. Material returns. The timer now holds 540 s + (28 min × 60) = 540 + 1680 = 2220 s.
- 14:00:00. The clock crosses the boundary, the one-shot fires, and the shift record receives 2220 s written as 37 min 0 s under no material, with the total-stopped timer reading 2220 s as well. Both accumulators reset and the next shift starts from zero.
2220 s sits well inside a 16-bit register, which overflows at 32767 s (9 h 6 min). The report shows 37 minutes of no material at 1-second resolution, and every second of it came from the level switch and the feedback contact, with zero operator entries.
How to check it worked
- Drive each cause one at a time with the run command on: its timer counts, the other buckets hold, and total stopped equals the sum.
- Cut controller power mid-stop with 12 min on the clock: 12 × 60 = 720 s must be in the accumulator at power-up, because a retentive timer holds its value through a power cut.
- Set the PLC clock to 13:58 and let it cross 14:00. The copy runs once, the record carries every category with the date, and the accumulators read 0. Cross a second boundary after a manual reset to check that the one-shot waits for the next match.
- Stopwatch one real stop and match the record to the second.
- Watch the feedback contact during a real stop. A jumpered or welded auxiliary that stays closed through a stopped machine hides every stop downstream.
The decision
Recommendation: Time every unplanned stop from the machine's run feedback with one retentive timer per cause at a 1-second time base, keep four to six signal-backed causes plus an unknown bucket, and copy the totals into a dated shift record at the clock boundary before any reset. Use the operator menu to label causes the signals miss, and keep restart free of reason entry. Size the seconds registers for the longest shift: 16 bits holds 9 h 6 min, so take 32 bits for anything longer.
Questions
What happens to the downtime totals when the PLC loses power?
A retentive timer keeps its accumulated value through a power cut, a change of processor mode and a rung that drops out, until a reset instruction clears it. A plain on-delay timer loses its value at those same events, so the accumulator has to be the retentive type or a retained register. Keep the accumulators and the shift records in the memory ranges your controller documents as retentive, and test one power cut before trusting a report.
Can one PLC track three shifts a day?
Give each shift its own record set and compare the clock against every boundary, for example 06:00, 14:00 and 22:00. The one-shot fires at whichever boundary the clock crosses, writes the date and shift number with the totals, and resets the accumulators for the next shift. At a midnight boundary, take the date from the clock's calendar together with the boundary comparison, so each record carries the day it belongs to.
Why do the reason totals add up to more than the stop time?
Two timers counted the same seconds. Either the causes overlap with no priority order, or the totals are deliberately overlapping. Fix it one of two ways: evaluate the causes in a fixed priority so each stopped second lands in a single bucket, or keep the overlap and print a note on the report that these totals must be summed separately. Reconcile either version against a total-stopped timer measured straight from the run feedback.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.