Every 20-second jam creates a downtime record that operators must explain

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • PlantInsight
    Junior Member
    • 21.10.2026
    • 7

    #1

    Every 20-second jam creates a downtime record that operators must explain

    On our labeling machine the product sometimes jams for 10 to 30 seconds and the operator clears it by hand. Each of these short stops shows up as a separate downtime, and on a bad day there are more than 60 of them waiting for a reason on the kiosk. The operators have started picking a random reason just to get rid of them, which makes our downtime analysis useless.
    Longer stops, from about two minutes, are the ones we really want explained. Is there a setting that decides when a stop becomes a downtime record? I'd prefer not to change anything in the PLC program.
  • Technical Support
    Senior Member
    • 11.08.2025
    • 105

    #2
    Yes. Each machine has a Working Timeout (min) setting for exactly this situation, and no PLC change is needed.
    What it does
    A downtime starts when the machine's running signal stays 0 for this many minutes. The default is 0, which means a downtime starts immediately when the signal drops. That is why every short jam creates a record on your labeling machine.
    How to change it
    1. Open MACHINES and open the Machine Settings of the labeling machine.
    2. Set Working Timeout (min) to the threshold you want, for example 2.
    3. Save.
    From then on, stops shorter than the threshold no longer open a downtime record, so operators are only asked for reasons for the longer stops you care about.
    Things to keep in mind
    - Choose the value together with production and maintenance. A threshold that is too high can hide real problems.
    - The setting is per machine, so you can keep 0 on machines where every stop matters.
    - Short stops still exist physically. Keep an eye on the Working Status chart on the dashboard and on Performance to see whether frequent jams are costing you output.
    - The records that already exist are not removed. For the current backlog, review them under DOWNTIMES > No Reason Assigned and assign a suitable reason, for example a dedicated "short jam" cause, instead of random ones.
    Also make sure the running signal itself is clean: if it flickers between 0 and 1, fix the signal first, otherwise any threshold will be hard to tune.
    Documentation: https://greensoft.ai/documentation/p...ser-interface/

    Comment

    Working...