What Is a Dead-Field Check in Scheduling?

A dead-field check is an anomaly check that flags routing steps carrying a value in a field the scheduler never reads. It exists to close the gap between what a planner believes a number does and what it actually does. In EDGEBIC by User Solutions it reports move hours and teardown hours set above zero, as a warning rather than an error, because the data is not wrong so much as inert.

How it works

A routing step carries a set of timing fields, and the engine composes a step's placement from a specific subset of them. Setup and run hours give the step its duration. Queue time adds a shift-aware buffer after it. Transit days add a calendar or working-day delay for physical movement. The overlap models, the flow lag and the transfer batch, govern how early a successor may begin.

Two fields sit outside that composition. Move hours and teardown hours are declared on the step and surface in duration estimates and on displays, but the engine does not consume them when it decides when the successor may start. Set them to any value and the produced schedule is identical.

The check walks the routing data and reports any step where either field is above zero. The severity is a warning, and the scope is the plant rather than one job, because the condition is a configuration observation rather than a plan defect.

What makes this worth a check rather than a footnote is how plausible the fields look. They sit in the same editor as the fields that do drive timing, they take the same units, and nothing about entering a value suggests the number will be ignored. A planner who fills them in expecting a buffer gets a plan with no buffer and no error message, and may not notice for weeks.

A concrete example

Imagine a form where most boxes route your request somewhere and two of them do not. They look identical. They accept the same kind of answer. Fill in one of the live boxes and something happens; fill in one of the dead boxes and the form is accepted, no complaint is raised, and nothing happens at all.

The dead-field check is the note that arrives afterwards saying which boxes those were.

Put that on a routing. A planner adds thirty minutes of teardown to every finishing step, reasoning that the fixture has to come off before the next job can load. The plan looks fine. Jobs still run back to back with no gap, and the finishing cell quietly falls half an hour behind on every changeover, because the buffer the planner entered never existed in the schedule.

Run the check and the flagged steps name themselves. The fix is a field change rather than a value change: the same thirty minutes entered as queue time is a shift-aware buffer the engine honors, and the gap appears where the planner meant it to be all along.

How EDGEBIC uses it

The check runs alongside the other scheduling anomaly checks and appears in the anomaly report, described in scheduling anomaly check. Running the report and reading its output is walked through in how to run the scheduler anomalies report in EDGEBIC.

The two fields it names have their own glossary entries: move time in a routing and teardown time in a routing. The symptom that usually brings someone here first is documented in I set move or teardown hours but nothing changed.

The usual remedy is to express the intent in a field the engine reads, most often queue time for a buffer that must elapse before the successor, or transit time when parts genuinely leave the area. Both compose into placement in a defined order, which is why they change the plan and the dead fields do not. For the wider vocabulary, see the manufacturing glossary, and to see routing timing inside a live plan, explore EDGEBIC.