Paper cup machine downtime coding converts interrupted production into analyzable events. The data becomes misleading when start and end rules vary, planned and unplanned stops are mixed, or reason codes describe assumptions instead of observed conditions.
This guide supports operational data quality. It does not prescribe an OEE formula, target availability or universal loss taxonomy. Define metrics and decisions within the site management system. Publish the current code definitions and revision history so trend changes can be separated from classification changes. Retain raw events.
Diagnostic decision table
| Coding issue | Control | Distortion |
|---|---|---|
| Event boundary varies | Common start and end rules | Duration cannot compare |
| Reason guessed | Symptom first, cause later | False root-cause ranking |
| Microstops omitted | Automated or sampled capture | Chronic loss disappears |
| Planned stops mixed | Separate categories | Reliability looks worse |
Define event start, end and state
State when downtime begins: loss of intended cycle, blocked output or operator stop, according to the metric purpose. Define the end as stable production, first acceptable cup or another controlled state. Treat warm-up and quality hold explicitly.
Synchronize machine, HMI and production clocks. Avoid ending an event when motion resumes if rejected cups continue. Preserve raw timestamps so revised business rules can be applied without rewriting history.
Create a usable coding hierarchy
Use a small first level such as planned, external, process, equipment and quality, then more specific symptom and component levels. Provide definitions and examples. Keep an unknown or investigation-pending code so operators are not forced to guess.
Separate observed symptom from confirmed failure mode and root cause. A low-air-pressure alarm may result from supply, leak, valve or sensor behavior. Update the diagnosis field after investigation without replacing the original event code.
Capture production and configuration context
Link SKU, cup size, material, machine mode, forming position, shift, recipe revision and preceding changeover where relevant. Record whether the stop was automatic or manual and whether product required containment.
Context enables fair comparison but should not burden operators with fields that systems already know. Automate reliable fields and validate interfaces. Missing context must remain visible rather than filled with a convenient default.
Reconcile overlapping and short events
Define how a primary event owns time when several alarms occur. Preserve secondary signals for diagnosis. Decide how microstops are collected and whether they aggregate by mechanism. Ensure total scheduled time reconciles with running, planned and unplanned categories.
Do not delete short stops simply because they are hard to classify. Repeated brief interruptions can cause large output loss and quality instability. Review unclassified duration as a data-quality metric.
Analyze losses and verify actions
Rank duration, frequency and production impact separately. A rare long failure and frequent short stop need different action. Stratify by configuration and validate top codes against work orders and operator evidence.
After correction, use the same event rules to confirm change and watch for shifted codes. Send HANNAI time-linked alarms, context and repair evidence for technical diagnosis. Downtime ranking identifies where to investigate, not the cause by itself.
Related equipment and next checks
Review the paper cup production line and the related guide to paper cup machine recurring alarm analysis. The Engineering Notes archive connects these checks with wider machine planning.
Frequently asked questions
Should operators enter a root cause immediately?
Record the observed reason first and update diagnosis after evidence review.
When does an event end?
Use one defined state such as stable acceptable production.
Are microstops important?
Yes. Repeated short events can create substantial loss.
Should frequency and duration be combined?
Review them separately before choosing priorities.
Review the evidence with HANNAI
Send your machine model, component identification and the observations described in this guide. Include the drawing or material reference and any before-and-after measurements so the required next check can be identified.