When the Kiosk Cannot Compute Pieces in EDGEBIC

When a routing step has no usable cycle time, the EDGEBIC by User Solutions kiosk computes an effective rate of zero and records piece fields as zero rather than inventing a number. The hours keep working perfectly, because they come from a clock rather than a calculation. The pieces stay honestly blank. That choice, refusing to fabricate, is worth understanding because the alternative would quietly corrupt every downstream number that touches output.

Here is where the rate comes from, what a zero costs you, and how to fix the routing that caused it.

Where the Rate Comes From

Hours and pieces are two views of the same work, and EDGEBIC converts between them with an effective rate expressed in pieces per hour:

effective rate (pieces/hour) = pieces per unit / hours per unit

Both inputs come from the routing step that runs at the machine, which is where piece-rate math lives rather than on the work center record. The rate is calculated and snapshotted onto each punch at the moment the punch opens. The conversion itself is covered in how hours and pieces convert on the shop floor.

If hours per unit is zero, the division has no answer. If pieces per unit is zero, the numerator is zero. Either way the rate is zero, and there is no rate to convert with.

What Zero Actually Costs

The honest answer is: less than people fear on most operations, and quite a lot on some. It depends on which measure your shop treats as the recorded truth, a convention covered in what is an actual entry mode.

Where hours are the recorded truth, the loss is cosmetic. Punch hours are measured, not calculated, so daily actual hours, the reschedule, plan versus actual variance, and job percent complete all behave exactly as they should. See how punches roll up into daily actual hours.

Where pieces are the recorded truth the loss is real. You count output because it is the meaningful unit on that operation, and without a rate the counts stand alone rather than feeding an hours figure. Operators can still record piece counts and those counts are kept, but you have a shop convention the routing cannot support. That is a routing to fix rather than a behavior to work around.

Why Not Just Estimate

It would be easy to fall back to some plausible number: the work center's nominal rate, an average from similar parts, last quarter's observed rate for this product. Every one of those options is worse than zero, and for the same reason.

A fabricated piece count is indistinguishable from a measured one once it is in the record. It flows into the day's output, into the observed rate for that date, into the quality factor of OEE, and into any quoting analysis built on historical output. Nobody looking at the number later can tell that it was a guess. A zero, by contrast, is obviously an absence, and an absence prompts somebody to go find out why.

This is the same principle behind the auto-filled actuals badge: EDGEBIC would rather show you that data is missing or assumed than smooth it over. A plan is only as trustworthy as the truth underneath it.

The Snapshot Rule

The rate is frozen onto each punch when the punch opens, and later routing edits do not reach back.

That matters for two reasons. First, historical reporting stays stable: last quarter's rates are whatever was actually in force last quarter, and correcting a standard today does not silently rewrite them. Second, a fix works immediately in the direction you want. Set the missing cycle time this morning and punches opened this afternoon carry a real rate, while nothing about yesterday's record changes.

The daily rollup follows the same spirit. For a date with both hours and pieces it uses the observed rate, pieces divided by hours, which is the truth about that day. Only when one of them is missing does it fall back to the snapshotted rate from the last closed punch.

Diagnosing and Fixing It

The symptom is easy to spot: an operation running normally, hours accumulating correctly, and piece fields stubbornly at zero.

Work through the inputs in this order.

Check hours per unit on the routing step. This is the usual culprit. A step created quickly, imported from a spreadsheet with a blank column, or copied from a template that never had a cycle time will carry zero here. See logging actuals from the planner if you need to correct the record for work already run.

Check pieces per unit on the routing step. Less common, but a zero here produces the same result.

Confirm the rate the day actually used. The daily actuals grid carries a rate column per day and an effective rate for the operation beneath it. A zero there is the symptom stated plainly, and it points back at the routing rather than at anything on the machine record.

Decide whether the step should be counted in pieces at all. Some operations genuinely have no meaningful piece count: a heat treat soak, a paint cure, an inspection hold. Those are hours-led by nature, and a zero derived piece count there is not a problem to solve.

A Worked Example

Two operations, same job, same shift.

Operation 30, CNC-1, hours-led. Routing carries 0.14 hours per piece and 1 piece per unit, so the rate is about 7.14 pieces per hour. The operator runs 7.53 hours and taps 42 good pieces. The daily row shows 7.53 hours, 42 pieces, and an observed rate of 5.58 pieces per hour, which is below standard and points at the quality hold recorded on its own punch.

Operation 40, Cure Oven, hours-led, no cycle time on the routing. The rate is zero. The operator punches 4.0 hours and the piece field stays at zero. The daily row shows 4.0 hours and no pieces.

The job's percent complete is computed from hours, so operation 40's blank piece count does not drag it down. The reschedule reads hours and plans the remainder correctly. Nothing about the plan is impaired, and the only thing you cannot say is how many pieces came out of a cure oven, which is not a question worth asking.

The Bottom Line

A missing cycle time produces a zero rate, and EDGEBIC records a zero rather than a guess. Hours keep working because they are measured; pieces stay blank because they would have to be invented. Fix the routing where output genuinely matters, especially where pieces are the number your shop records, and accept the blank where it does not. Rates are snapshotted per punch, so your fix applies forward without disturbing history. See the whole capture loop in the shop floor execution guide, or explore EDGEBIC.