The Tool Constraint: The Third Thing an Operation Needs

A tool constraint models the fixture, mold, jig, die, or gauge an operation must physically mount, as a plant-wide pool shared across every machine rather than capacity belonging to one. That single modeling choice is the entire point. The expensive five-axis fixture that fits three mills is one object, and it can be bolted to exactly one of them at a time. EDGEBIC by User Solutions treats it that way, so a plan can never put two fixture jobs on two machines in the same window and print clean.

An operation can need three different things before it can start. The machine has always been scheduled. The person arrived with operator skills and rosters. The tool is the third, and it behaves unlike either of the other two.

What a tool is, and what it deliberately is not

A tool is a scarce shared physical asset with two properties and nothing else: how many identical units you own, and when it is away. That is the whole model.

It is not attached to a work center. You never tell EDGEBIC which machines a fixture fits. The fit is expressed entirely by which routing steps require it, so if only the two mill steps name the fixture, the scheduler will never plan it anywhere else. Recording the physical fit in the tool's notes field is for your planners, not for the engine.

That absence is not an omission. It is the model. Because a tool belongs to no machine, its scarcity cannot be expressed in any machine's capacity bucket, and putting it in one would defeat the purpose.

The clash a machine-by-machine view cannot show

Consider two mills, one 8-hour day shift each, and two five-hour jobs, one on each mill. Sixteen machine-hours are available Monday and ten hours of work needs doing. Both jobs schedule Monday 08:00 to 13:00 and both machines look comfortably free all afternoon.

Every number in that plan is correct, and the plan is fiction. Both steps mount the same fixture, and there is one of it. One of those jobs is going to be a machine, an operator, a work order, and no fixture.

This is the defining property of the tool dimension. Capacity questions are normally answered per machine: how much can this work center do. A fixture's scarcity is invisible from any single machine's ledger precisely because the whole point of it is that it moves between them. Mill-1 sees eight free hours. Mill-2 sees eight free hours. Both statements are true and the plan is still impossible.

How the constraint changes the answer

When the fixture is modeled as a tool, the two mills stop being independent. The fixture has a pool of hours for each day and shift, and every allocated machine-hour books exactly one tool-hour from it. When the pool runs out, the next operation is simply not offered that window, even though its machine is standing empty.

With one fixture and an eight-hour day shift, the pool is eight fixture-hours on Monday. The first job takes five. The second job gets the remaining three on Monday and its last two hours the next morning. Its total work is unchanged at five hours. Only when it happens moved.

That is the rule worth memorizing: a tool constraint changes when, never how much. No hours appear, none vanish. Work relocates to windows where the fixture is genuinely available. The whole discipline of finite capacity applied to an object that is not a machine.

Three dimensions on one step, independently keyed

A routing step can name a work center or a machine pool, a required skill, and a required tool. They compose without interfering, because each is exhausted separately and all three are checked in the same window.

• The work center or pool answers which machine.
• The required skill answers which human.
• The required tool answers which fixture.

The scheduler needs room in all three before it will place the operation. A step may need any combination of them, including none. The tool picker is not gated on the skill field, unlike the operator pin, which unlocks only once a skill is chosen. Machines, people, and tools are three genuinely independent questions.

When a step targets a machine pool, the pool's member selection already accounts for the tool. A machine whose windows the fixture can never cover loses at selection time rather than being chosen and then failing.

Where a tool requirement is visible today

Worth being precise about, because the answer is narrower than you might assume.

Tool-required operations do not carry a marker on the Schedule View Gantt or a column in the Job View, the way skill-required operations do. There is no tool equivalent of a dispatch list or a resource calendar lens. To see where a fixture's hours went, read the routing steps that require it and the jobs scheduled against those steps, or read the tooling lines in the run's diagnostic log.

That gap is worth planning around rather than being surprised by. It also makes the next post in this series useful: an operation sliding for no visible reason is a normal symptom of a healthy tool constraint, and knowing to look at tooling saves the hour you would otherwise spend on the machine's calendar.

When a tool record earns its keep

Reach for one only when the asset genuinely travels between machines. If a jig lives permanently on one machine, it is not a scheduling constraint: that machine's own capacity already models it, and a tool record adds maintenance for nothing. Tools pay for themselves when they are shared, and the clearest signal is a floor memory of someone waiting on a fixture while their machine stood idle.

Over 35-plus years, User Solutions has watched shops discover that their real bottleneck was never a machine. The full placement pipeline is in the scheduling engine guide, and you can model your own shared fixture and read the contention in the dates in EDGEBIC.