How a Scheduler Handles a Shared Tool or Fixture

A finite capacity scheduler handles a shared tool or fixture by modeling it as a plant-wide pool with a quantity of its own, required by the routing steps that mount it, so every machine in the plant draws on the same pool. EDGEBIC by User Solutions ships that as a first-class constraint: a tool carries how many units you own and when it is away, and a routing step names it in a Required tool: field. If two jobs on two different machines both need the one five-axis fixture, the second one waits. The contention becomes a visible start-time shift instead of a floor collision.

Why a shared tool needs modeling at all

A shared fixture, die, or mold is a resource just like a machine, but shops rarely track it as one. The machine schedule looks fine, the mills sit at 60 percent, and yet dates slip. The reason is that two jobs on two different machines both need the same fixture, and only one fixture exists. On paper both jobs are feasible; on the floor one of them waits.

That wait never appears in a machine utilization report, because no machine is overloaded. It shows up only as unexplained work in process and missed dates. This is the one clash a machine-by-machine Gantt structurally cannot draw: the fixture belongs to no lane, so both lanes are honestly free and the plan is still impossible. The generic problem, and how to spot it, is covered in when tooling is your bottleneck.

What a tool is, and what it deliberately is not

A tool in EDGEBIC is a scarce shared physical asset: the fixture, mold, jig, die, or gauge that must be mounted before the operation can run at all. It carries two things and nothing else.

Quantity is how many identical units you own plant-wide. One fixture means strictly one operation at a time anywhere in the plant; three identical gauges mean up to three operations can each hold one, across any mix of machines. Downtime is a date range when the tool is away for calibration, repair, or a loan. Both dates are inclusive, so the tool is back the day after the end date, and inside the range it contributes nothing whatever its quantity says.

What a tool deliberately does not have is a work center. You never tell EDGEBIC which machines a fixture fits: that 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. Record the physical fit in the tool's notes for your planners; the engine does not need it. Nor does a tool have the dials a machine has, the shifts and instances and utilization behind how a scheduler picks an instance. It has a count and its absences, because that is all a physical object actually has.

One data-entry mistake follows directly. Quantity is units you own, never machines the tool fits. A fixture that bolts to three mills but exists as one object is quantity 1; entering 3 tells the scheduler you can run three jobs at once, and the plan goes straight back to being fiction.

Requiring the tool on the step

Tools live under the Daily Hours tab on the Tools inner tab: a catalog with a name, an asset code, a quantity, an active flag, and a grid of downtime ranges.

The requirement itself lives on the routing step, not on the machine. In the BOR grid it is the Required tool: picker in the step's Basic Information section; in the BOR Designer it is the Required Tool property on the selected node. Leaving it at (none) means no constraint, which is what makes the feature safe to adopt one operation at a time.

The picker is not gated on the step's required skill, unlike the operator fields: machines, people, and tools are three independent questions and a step may need any combination. And the tool is held for setup and run alike at the full rate, because a fixture cannot be half mounted the way one operator can tend two machines. Every allocated machine-hour books exactly one tool-hour.

A worked example

Three mills, each free most of the week and each running one eight-hour day shift. The shop owns one copy of Fixture Set A. Three jobs this week all need it, four hours each, all releasable Monday.

Before the tool exists the jobs are independent: twenty-four machine-hours against twelve hours of work, so all three run Monday 08:00 to 12:00 and every mill looks free all afternoon. On the floor, two of those three never start.

Now create Fixture Set A with a quantity of 1, set Required tool: on all three steps, and reschedule. Monday's fixture pool is eight hours, one unit times the eight-hour window. Job 1 takes the first four, 08:00 to 12:00. Job 2 takes the remaining four, 12:00 to 16:00, and the pool is spent. Job 3 is not offered a Monday window at all, no matter that its mill has eight untouched hours, and lands Tuesday 08:00 to 12:00.

The total work is unchanged at twelve hours. Only when it happens moved, and that is the rule worth memorizing: a tool constraint changes when, never how much. Buy a second fixture, set the quantity to 2, and Monday's pool doubles to sixteen hours; all three jobs fit Monday again, which is the honest version of the first plan rather than the wishful one.

Downtime, and the failure that is deliberate

Record a calibration window as a downtime range and the pool is zero on every date inside it, so operations requiring the tool skip those days and resume the first day after the range ends. A calibration you know about but never entered protects nothing.

The third way a tool moves a job is louder. If a step requires a tool that is inactive, unknown, or has a quantity of zero, the run stops that job and records a message naming the tool. Other jobs are unaffected. That refusal is a feature: the alternative is quietly planning an operation onto a machine that physically cannot run it, which produces a schedule that looks perfect and collapses at the machine.

If you already model a fixture as a work center

Turning a fixture into a pseudo work center that routings pass through was a reasonable way to get a capacity ceiling, and any routing built that way still schedules. Moving it onto a tool record is an upgrade rather than a repair, and it is worth making.

The pattern is easy to spot: a work center with no machine behind it, named after a fixture or a mold, that operations route through in addition to their real machine, whose instance count is the number of tool copies rather than machines, and whose shifts are a hand-kept copy of another work center's calendar. Every routing that uses it carries an extra step that was never a real operation.

Moving over is three moves, in order:

1. Create the tool under Daily Hours then Tools, quantity set to the number of physical units you own, and carry the maintenance you were keeping on the pseudo work center's calendar across as downtime ranges.
2. Set Required tool: on the steps that actually mount it, which are the real operations, not the detour step.
3. Remove the stand-in work center from those routings, then reschedule.

The gain is accuracy where the workaround quietly cost you it. Step counts, routing diagrams, and lead-time reporting stop carrying an operation that does not exist. The pseudo machine's calendar stops needing to be kept in step with the real machines, which was what let the fixture look available on days the mills were closed. And the requirement rides the job's preserved routing, so it survives a reschedule without you maintaining anything.

Where a tool requirement is visible

Be precise here, because the answer is narrower than you might assume. The Tools tab shows the catalog, each tool with its quantity and downtime ranges. The routing step shows its Required tool: setting in both BOR editors. The scheduling run reports failures by name and records every booking and every skipped window in its diagnostic log.

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, and 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. 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.

The broader idea is the same one behind every finite constraint: name the scarce resource, give it real capacity, and let the engine refuse to over-book it. Model your own shared fixture and read the contention in the dates in EDGEBIC, and see how the engine allocates finite capacity in the scheduling engine guide. For the constraint mindset in general, production bottleneck identification is a useful companion.