Set cycle times and downtime filters

The three numbers that decide whether your counts and your goals match the floor.

Every goal, pace and gauge in Production is derived from figures you type onto an operation in the Parts List, at /production?select=parts_list. Three of them carry the weight: the ideal cycle time, the quantity per cycle, and the continuous downtime filter. Counts still arrive when these are wrong, measured against the wrong target, which is much harder to notice.

Before you start

• A part with at least one operation. See Create parts and operations.
• The operation's detection algorithm set, because it decides which of these fields appear and whether the count itself reads the cycle time. See Choose a production tracking algorithm.

Set the ideal cycle time

Ideal cycle time is how long one good cycle of this operation takes when the machine is running well. You enter it. Nothing measures it for you.

Three figures in the product are called a cycle time, and only one of them is yours to type:

To set the ideal:

1. Open Production, then the Parts List tab at /production?select=parts_list.
2. Click into the operation's Ideal Operation Cycle Time cell.
3. Type the cycle across the four boxes: hr, min, sec, and after the decimal point, hundredths of a second. A 20-second molding cycle is 0 : 0 : 20 . 0. A half-second press stroke is 0 : 0 : 0 . 50.
4. On a Discrete Analysis or Discrete w/o Merge operation, set the tolerance percentage in the box beside it. Hover it to read the Cycle Time Range it produces, for example (00:01:48 - 00:02:12) for a 2-minute cycle at 10%.
5. Click elsewhere. The cell saves on its own, with no Save button.

The hour box takes a single digit, minutes and seconds stop at 59, and the tolerance runs 1 to 99% and falls back to 10% if you clear it. Continuous Analysis and Counter operations carry no tolerance box and save with the tolerance at zero.

Set the ideal cycle time to the best sustainable cycle, not the fastest one ever recorded. Every pace figure on the site is measured against it, so a heroic number makes a normal shift look like a failure and trains people to ignore a red gauge. Time 10 to 20 consecutive cycles on a good day and use that.

Ideal cycle time and production rate are the same number stated two ways.

Production rate is the same number

Production rate is the ideal cycle time turned over: parts per minute instead of seconds per part.

production rate = 60 ÷ cycle time in seconds

A 20-second cycle is 3.0 ops/min and a half-second stroke is 120.0 ops/min. The unit is the operation's own OP UNIT label, which defaults to ops. See Unit and quantity per cycle.

On a Counter operation, and only there, the Parts List cell carries a swap control beside the boxes. Click it to switch the cell between H:M:S and the rate, type the rate, and the cycle time is written back from it. The two figures can never disagree, because only the cycle time is stored.

Everywhere else the rate is a reading rather than an input. Shift Production and the machine page show Ideal, Goal and Actual together, with one arrow that flips all three between a cycle time and a rate.

Enter whichever number your plant already quotes. A press rated at 120 strokes a minute is easier to type as a rate than as 0.50 seconds, and a molder quoted at a 22-second cycle is easier to type as a cycle. On a Counter operation you have the choice; on the other three, convert once and type the cycle.

Set quantity per cycle

Quantity per cycle is how many parts one detected cycle of this operation yields. It is the QTY/OP cell on the row, with its own unit label beside it, which defaults to made. The field reference is on Unit and quantity per cycle.

It belongs on this page because the cycle time is per cycle, never per part. A two-cavity mold with a 22-second shot makes two parts every 22 seconds: the cycle time stays 22.0 and QTY/OP goes to 2. Halving the cycle time instead gets the part count right and every rate, goal and gauge wrong.

The number reaches three places:

• Part counts are the cycle count multiplied by it. A four-cavity mold left at 1 reports a quarter of its real output.
• Gauges reported in ops divide it back out, which is the second gauge Shift Production draws beside Progress on any operation whose cycle yields more than one part. See Read the board.
• A work order's time estimate divides the pieces ordered by it. 500 pieces at a 45-second cycle, 2 per cycle, estimates 3 hrs 8 mins and shows its working as Estimated from 45s cycle x 500 pcs at 2/cycle.

Leave QTY/OP at 1 unless the machine really yields more or fewer parts per cycle. It is the only field on the row that scales the answer, so it is the first cell to check when a count comes out doubled or halved, and the last one to change when a count looks close.

Quantity per cycle. A two-cavity mold produces two parts per cycle.

Set the continuous downtime filter

A downtime filter is a share of the ideal cycle time under which a stop is counted as running time instead of as downtime. It exists so that brief in-cycle pauses on a machine that never fully stops do not fill the downtime record.

Only Continuous Analysis operations have one. That algorithm produces its count by dividing running time by the cycle time, so a pause counted as downtime is also a pause that costs parts. See Continuous Analysis.

The Downtime Filter column appears on a part only when at least one of its operations runs that algorithm, and inside that part only the Continuous rows carry an editable cell. On a part whose operations are all discrete, the column is not on the table at all.

1. Click the Downtime Filter cell on the Continuous Analysis row.
2. Type a percentage. The field accepts 0 to 200 and clamps anything higher as you type.
3. Click elsewhere to save. Hovering the cell reads back what the current number does.

Read the percentage as a length of time, because that is what it becomes: 150% of a 20-second cycle is a 30-second window, and every stop shorter than 30 seconds is converted to uptime.

Ideal cycle time against actual, with the continuous downtime filter window marked. Pauses inside the window are not counted as stops.Two horizontal bars covering the same three minutes. The upper bar, labeled ideal, one cycle every 20 seconds, is divided into nine equal cells and annotated nine cycles in three minutes. The lower bar, labeled actual, what the sensor saw, is mostly running and is broken by three pauses: an 8 second pause and a 26 second pause, both drawn in violet and marked becomes uptime, and a 48 second pause drawn in gray and marked stays downtime. A dashed violet line inside the 48 second pause marks where the filter window ends, 30 seconds in. The actual bar is annotated under 5 cycles in the same 3 minutes. A key below reads: filter window, 150 percent of a 20 second cycle, equals 30 seconds. A closing line reads: a stop shorter than the window is counted as running time. The 48 second stop runs past it, so it stays downtime.

Because the window is a multiple of the cycle time, changing the cycle time moves the filter with it. An operation re-timed from 20 to 40 seconds at 150% goes from hiding 30-second stops to hiding minute-long ones without anybody touching the filter.

You do not need a downtime filter on a machine that runs continuously. The filter exists to stop short in-cycle pauses reading as stops, and a truly continuous process has none to hide, so all the filter does there is hide real ones. Start at 0, watch the Downtimes report for a week, and raise it only if that list fills with pauses nobody on the floor would call a stop.

Short stops on the other three algorithms are handled on the machine instead, by Downtime Threshold with Treat short downtimes as uptime. See Handle short stops.

Where the shift goal comes from

The Calculated Goal on Shift Production is derived from the ideal cycle time you set here. That page reads the number and cannot set it. There is no per-operation goal override anywhere in the product.

Goal = (Shift Duration - Expected Downtime) / Cycle Time

Expected downtime is the historical average for that operation and machine. See Where the goals come from.

Two more numbers follow the same cycle time. The parts gauge, performance, measures actual output against what the ideal cycle time implies over the window, so it moves the moment you change the ideal. The hourly bars carry a per-hour goal derived from the same figure and the machine's uptime goal.

See Performance and Production metrics.

The downtime filter feeds a different pair. Converting a stop to running time raises uptime and lowers downtime for that machine, so a filter set too high flatters the board.

Cycle settings reference

Check your numbers against the floor

Check the numbers you typed against what the machine reports, once it has run the operation for an hour or more.

1. Open the machine's row on the Assets page and read the Cycle time it reports beside the operation. That figure is measured from detection events, not from anything you entered. See Review the detected cycle time.
2. Compare it with your ideal. A figure within a few percent means the ideal is a fair target; a figure half or double the ideal is an algorithm problem rather than a cycle-time one.
3. Open Shift Production at /production?select=part and read Ideal, Goal and Actual together on the operation's row.
4. Check the parts gauge. A gauge above 100% means the machine beat an ideal cycle time that is set too slow, not that it outran physics.
5. Open the Downtimes report and confirm that real stops are in the list and short in-cycle pauses are not. That is the filter's verdict.

Validate the count itself against a hand count rather than against a total that looks about right. The procedure and its accuracy bands are on Validate your choice.

When a change does not save, the cell puts the old value back and the dashboard raises the server's message as a toast. Retype the value once; a message that returns is a number being rejected, not a number being lost.

Counts that stay wrong after all three of these numbers check out are on Troubleshoot inaccurate part counts.

See also

• Troubleshoot inaccurate part counts
• How each metric is calculated
• Set OEE and utilization goals
• Track production against shift goals
• Choose a production tracking algorithm