Conditional HMI downtime prompt when no sensor cause exists

The gate condition, in one line

Three inputs decide the prompt:

• RUNNING, a BOOL from machine feedback: an auxiliary contact on the filler contactor or a current-sensing relay on the power feed. This reads what the machine actually does, not what the PLC commanded.
• CAUSE, one BOOL per known automatic cause. The no-bottle proximity input is the example here; latch it into the open event.
• IN_RUN, an optional BOOL for the production window, so a planned stop between shifts does not look unexplained.

PROMPT, the BOOL that triggers the reason screen, is STOPPED AND NOT CAUSE_ANY AND IN_RUN, where STOPPED is RUNNING held false through a short debounce. That single line separates a cause list that works from one that trains operators to click past it: the screen appears exactly when the PLC cannot explain the stop itself, and never otherwise.

What you need

• Run feedback into the PLC. An auxiliary contact on the contactor is simplest; a current-sensing relay works where no spare contact exists. Set its pickup below the machine's running draw and above zero, and read the running current off the feeder label first.
• One PLC input per automatic cause you can already detect: the no-bottle proximity, the overload trip contact, and any other input whose state alone names the cause.
• Timestamped event logging on the panel. Panels of this class log alarms and events with date and time stamps, and a 6-inch monochrome unit handles this application, because a reason list and a few numeric fields are not demanding.
• Retentive run and downtime timers in the PLC.
• The reason list as preprogrammed messages, one per standard cause.
• A supply for the PLC, panel and added sensors that the filler disconnect does not switch.

Have a qualified electrician make the connection to the power feed and rate the current sensor for the conductor it monitors.

Power the logging hardware separately

The stop that most needs a reason is the one where an operator opens the filler's power feed. If the PLC and panel sit on that same feed, they die with the machine: no stop stamp, no restart stamp, no screen, no record. Trace what the operator's switch actually kills before you design any logic. Feed the controller, panel and added sensors from their own supply, and the logger watches the feed drop while staying alive to stamp it. If a retrofit leaves the PLC powered but the panel dark, the controller keeps timing and the operator answers after restart; decide in advance that a late selection attaches to the event that was open, not to whichever record is newest.

Logging every stop fills a panel's event buffer eventually, so check how your log behaves when it is full; the fix for one panel's log buffer memory full errors shows what to look at. For the wider picture of turning stop events into per-shift figures, the article on PLC downtime tracking with automatic stop detection and shift totals covers accumulation and reporting, which this page does not repeat.

Set it up step by step

The bit names below are mine; use whatever your software calls them.

1. Wire the feedback. Auxiliary contact or current-relay output into a PLC input. RUNNING is a BOOL in the input image, true only while the machine actually turns.
2. Debounce. An off-delay of 1 s on RUNNING gives STOPPED. A rotary filler cannot restart, and no real stop recovers, inside a second; raise the delay if glitches still create false events.
3. Open the event at the stop edge. On the rising edge of STOPPED, store the stop time. Panels of this class follow the same pattern: activate PLC alarms, then create an alarm log for them. Using an alarm history to timestamp machine events keeps stamps and causes in one place.
4. Latch the cause at the same edge. If NO_BOTTLE, the BOOL from the proximity input, is true when STOPPED rises, the event is automatic: write the cause to the log and leave PROMPT false.
5. Gate the causes from the PLC side. A cause already active when the panel connects must still reach the event; gate the bit so a cause active at startup still logs, instead of trusting the alarm list to catch it on its own.
6. Compute the prompt. PROMPT = STOPPED AND NOT CAUSE_ANY, ANDed with IN_RUN if you use one. Wire it to the screen change trigger.
7. Record the selection. Give the operator preprogrammed messages. The chosen message writes to the log with its own stamp and PROMPT clears, while the event stays open; a timestamped event log driven by a bit is the object for this on many panels.
8. Close at restart. On the falling edge of STOPPED, stamp the restart and close the event. Duration is the restart stamp minus the stop stamp.
9. Accumulate retentively. A plain timer enabled by STOPPED resets the instant the machine runs again, which is why downtime totals keep vanishing; the enabling condition is the whole trap. Use retentive timers for downtime and run time, and clear totals only from a PIN protected HMI settings screen.
10. Handle overlap. If a second stop edge arrives while an event is open, close the first one marked incomplete and open the next. A late reason attaches to the event that was open when the prompt showed.

Example: one 8-hour shift on the filler

Inputs. Scheduled production 06:00 to 14:00, 480 min, from the shift schedule, with IN_RUN true through that window. RUNNING from an auxiliary contact on the filler feed contactor; NO_BOTTLE from the bottle-path proximity. Run timer reading at 14:00: 436 min, from the retentive run timer. The day's events, illustrative times for this case: stop 09:14:32, restart 09:19:32, no bottle active; stop 11:40:00, restart 11:52:00, no bottle active; stop 13:02:00, restart 13:29:00, no cause, the operator opened the feed.

Rule. Scheduled time minus run time is total downtime. Total downtime minus the automatic causes is unexplained time. The number of prompts equals the number of stops with no cause attached.

Arithmetic. 480 min - 436 min = 44 min of downtime. The no-bottle stops: 09:19:32 - 09:14:32 = 5 min, and 11:52:00 - 11:40:00 = 12 min, so automatic causes cover 5 + 12 = 17 min. Unexplained: 44 - 17 = 27 min, which matches the one unexplained stop: 13:29:00 - 13:02:00 = 27 min. PROMPT went true once, at 13:02:00. The operator picked a reason at 13:04:10, so the event kept the 13:02:00 stamp and all 27 min, including the 2 min 10 s before anyone touched the screen, charged to that one cause.

Result. 44 min of downtime split into 17 min automatic and 27 min operator-entered, which is 27 of the 480 min scheduled, about 6%. One prompt all shift, and two sensor stops the operator never saw.

Decision. This is the shape you want: one question per shift, one record with one cause. If the same unexplained cause starts repeating more than about once per shift, add the input that sees it, a door switch, the overload trip contact or a current sensor on the feed, instead of lengthening the operator's list.

Check it worked

1. With the line running, cover the no-bottle sensor. The log gains an entry with date and time, and the reason screen must stay hidden.
2. Open the filler disconnect with no cause active. PROMPT goes true within about a second, the reason list appears, pick a message. Then open the log: a reason visible on screen is not proof it saved, so confirm the selected message and the operator-stop event carry the same event.
3. Restart and confirm the record closed with a stop and a restart stamp, and that the retentive totals kept counting through the stop.
4. Open only the filler feed and watch the panel stay up through it. If panel and PLC go dark together, the supply boundary is wrong, and no amount of screen logic fixes that.

Recommendation: take the stop signal from machine feedback, latch one cause bit per sensor at the stop edge, and trigger the reason screen from PROMPT = STOPPED with no cause latched. Keep the PLC, panel and sensor supply outside the operator's disconnect, accumulate in retentive timers, and clear totals only from a protected screen. When the same unexplained cause repeats more than about once per shift, add the input that detects it instead of adding reasons to the operator's list.

Questions