Shop Floor Tracking That Feeds the Machine Shop Schedule

Shop floor tracking earns its place when the numbers it captures change the next schedule, not just the next report. EDGEBIC by User Solutions captures operator time and piece counts at a touchscreen terminal beside the machine, rolls them into a per-day hour breakdown, and feeds that straight into the next scheduling run, where completed work is preserved and only the remaining steps replan. For a machine shop running paper travelers, that is the difference between a schedule that describes yesterday and one that describes today.

The full mechanism, including the punch lifecycle and the audit model, is documented in actuals tracking explained. This post is about what a machine shop gets out of it.

Why the Paper Traveler Loses

The traveler is not wrong. It is late, and it is aggregated.

Late, because hours get keyed the next morning at the earliest, so every scheduling run is planning against a picture of the shop that is at least one shift old. Aggregated, because a traveler line that says "6.5 hours" cannot tell you that 0.9 of it was setup, 1.25 was a coolant failure, and the rest was cutting. Both problems are structural. No amount of discipline fixes them.

A terminal at the machine fixes both by construction. Each tap closes one state segment and opens the next, and every timestamp is taken on the server rather than the terminal's clock, so a kiosk whose time drifted last month does not corrupt the record.

One Shift, Captured

Here is a real CNC run: a turbine shaft job, 50 pieces, on a machine and instance the operator selects. The routing says 0.14 hours per piece with a pieces-per-unit of one, which gives an effective rate of 7.14 pieces per hour, snapshotted onto the punch the moment it opens.

The rollup that reaches the scheduler and the reports is one row: 7.00 planned hours, 7.53 actual hours, 42 actual pieces, and an observed rate of 5.58 pieces per hour against a standard of 7.14.

Read that last pair again, because it is the whole argument for piece counting. The hours look close to plan. The rate says the shift lost roughly an hour and a half somewhere, and the scrap event and its quality hold explain where. Neither number alone tells you that.

Two rules govern what lands in the rollup. Scrap is not counted in actual pieces, only good pieces are. And the 0.47 hours of setup does not appear in the daily production hours, because setup is tracked separately.

Where the Time Actually Went

Six punch states are available, and only two of them feed production hours.

Take a two-day paint booth job as the pattern. Day one: setup 07:50 to 08:45 (0.92 hours), run to 10:30 (1.75 hours), a machine-down pause for a coolant issue from 10:30 to 11:45 (1.25 hours), run again to 16:00 (4.25 hours), then idle overnight. Day two: resume at 07:55, complete at 11:00 (3.08 hours).

The daily breakdown reads 6.00 hours on day one and 3.08 on day two. The 0.92 hours of setup, the 1.25 hours of downtime, and the 15.92 hours of overnight idle are all captured and all excluded from production hours. The planner sees 9.08 actual hours against 7 planned, and can point at the coolant reason code as the 1.25-hour piece of the gap.

That is a supervisor conversation with evidence in it. Sixteen reason codes ship by default across four categories (machine, material, quality, waiting), and you can add work-center-specific codes that appear alongside the global ones.

Setup Variance a Machine Shop Can Use

Setup is where machine shops lose time they never see, so the kiosk lets an operator advance through sub-phases within a setup punch: teardown, fixture, tools, first article, QA hold, run-off.

A changeover recorded that way might read: teardown 0.33 hours, fixture 0.17, tools 0.50, first article 0.33. Total 1.33 hours against a 0.75-hour standard, which is a 0.58-hour variance. And the breakdown says the teardown alone consumed most of what the standard allowed for the whole changeover.

That is actionable in a way "setup ran long" never is. If your sequencing costs you setup hours, cutting CNC setup time by sequencing covers the scheduling side of the same problem, and the measured variance here is what tells you whether your matrix values match reality.

The Guardrails That Keep the Data Usable

Four rules protect the record, and each exists because the alternative caused a real problem.

End cannot precede start. A validator runs at every write path (grid edit, mark complete, actual start capture) and rejects an actual end at or before the actual start. Before it existed, a mistyped date persisted silently and then corrupted every downstream reschedule by looking like a completed step with an impossible range.

Same-day completion is safe. When a planner marks complete without typing an explicit end time, the end snaps to the last moment of the last day that carries actual activity. Without that, a job started at 08:00 and completed the same day would resolve an end of midnight, which is before the start, and trip the validator on the next run.

Corrections are appended, not overwritten. A supervisor fixing a punch (an operator tapped Complete an hour early, so 4.83 hours should read 5.83) writes an adjustment record carrying the field, the old value, the new value, who changed it, and a mandatory reason. The daily breakdown is then rebuilt. The same applies to an operator's own piece-count undo, which is recorded rather than silently absorbed.

System-filled days are visibly marked. When an operator starts a step whose prior steps have no actual dates, the kiosk asks before continuing. Accepting back-fills the missing steps from their planned dates and tags those days as system-filled, and the planner's log grid shows an "auto-filled" pill on exactly those rows. The pill clears the moment somebody edits the value. You always know which numbers a human typed.

What the Scheduler Does With It

This is the part that separates tracking from scheduling.

On the next run, the engine reads which steps have actual dates and classifies them. Completed steps are preserved with their real dates and are not rescheduled. In-progress steps keep their machine and their start. Remaining steps replan forward from where the job actually stands, not from where the original plan assumed it would be by now.

Completed work is never moved by a reschedule. That is a hard contract, and it is what makes daily rescheduling safe for a shop with work in process. Your operator does not arrive to find that last week's finished operations have been re-dated.

Two related behaviors are worth knowing. A step configured with a parallel work center produces two schedule rows, and the parallel row's actuals always follow the primary at log time rather than being entered twice, with hours scaled by the configured factor. And when the routing has drifted since the job was scheduled (a work center changed, a cycle time changed), the kiosk shows a non-blocking banner before the operator starts so they can flag it to the planner. See routing snapshots for why that drift is visible at all.

Starting Small

You do not need every machine wired on day one. Put a terminal at the constraint and one busy cell, run it for two weeks, and compare the daily breakdown against what the travelers said. The gap between those two numbers is your business case, and it is usually in the downtime reason codes rather than in the run hours.

For the category fundamentals, machine shop scheduling covers the ground and the machine shop scheduling software page is the shorter read. Once actuals flow, the quoting side gets sharper, because quoted hours can finally be compared against what jobs really took. The industry fit guide maps features to shop types, and EDGEBIC is the product hub.

Ready to see the terminal? Contact US for a demo and bring one job's travelers so we can compare.