EDGEBIC How-To

How to Require a Tool on a Routing Step in EDGEBIC

User Solutions TeamUser Solutions Team
|
6 min read

To require a tool on a routing step in EDGEBIC by User Solutions, select the step in the BOR grid, open the Basic Information section of the details panel, and set Required tool: to the tool you want. The same setting appears on the node's properties panel in the BOR Designer, where it is labeled Required Tool. Choosing the entry labeled (none) means no tool constraint. From the next scheduling run, the step only lands in a window where a unit of that tool is free, no matter which machine runs it.

This is the step that turns a tool record into an actual constraint. Creating the tool comes first; nothing in the catalog affects any plan until a routing step asks for it.

Before You Start

PrerequisiteWhy
The tool exists and is activeThe picker lists active tools only
The tool's quantity reflects units you ownQuantity is the whole capacity model; an inflated number removes the contention you are trying to see
You know which steps physically hold the toolThe tool is held for the entire step that names it, setup and run alike

Step 1: Pick the Editor

Both routing editors set the same field. Use whichever you already work in.

The BOR grid is faster for setting the same requirement on several steps in a row. The BOR Designer is better when you want to see the routing shape while you decide which steps genuinely hold the fixture.

Step 2A: Set It in the BOR Grid

  1. Open the BOR tab and select the step in the grid.
  2. In the details panel, open the Basic Information section.
  3. Set Required tool: by picking the tool from the list. There is a hint icon beside the picker explaining the pool.

Step 2B: Set It in the BOR Designer

  1. Open the step's node in the Designer and use the properties panel.
  2. Set Required Tool. Same list, same effect.

Note the two labels differ slightly on screen. They are one setting.

The field appears on ordinary work-center nodes only. Material nodes, product nodes, and parallel or alternate child nodes do not show it.

Step 3: Repeat for Every Step That Holds the Tool

This is the judgment call. Name the tool on every step during which it is physically occupied, not only the one where it goes on.

If a part is fixtured for milling, stays fixtured through in-process inspection, and only comes off afterward, both steps require the fixture. Naming only the milling step tells the plan the fixture is free the moment milling ends, which understates contention and nothing on screen will flag it.

Step 4: Reschedule

Setting the requirement changes routing data and nothing else. Run a reschedule for the effect to appear. See how to reschedule safely if the job is already in flight.

What Changes When You Set It

SurfaceEffect
The routing stepCarries the requirement, and it is stored with the job's preserved routing so it survives reschedules
The next scheduling runThe step only lands in windows where the tool has free hours, regardless of which machine it runs on
The machine's own capacityUnchanged. The tool is an additional gate, not a replacement for one
A step bound to a machine poolMember selection accounts for the tool: a machine whose windows the tool can never cover is not chosen
Steps that do not name the toolEntirely unaffected

How to Check It Worked

Reopen the step and confirm the picker shows the tool rather than (none). Then reschedule and compare the operation's dates against the run before. If another step somewhere in the plant already books that tool's hours in the same window, this operation should have moved.

If the dates are identical, that is a legitimate outcome: the tool may simply not be contended in that window. To confirm the constraint is live rather than absent, look at the run's diagnostic log, which records the tooling lines for every booking made and every window skipped for an empty pool.

Common Mistakes

  • Setting it on one step of a multi-step fixturing. Every step that physically holds the tool must name it.
  • Expecting a change without a reschedule. Routing edits take effect on the next run.
  • Assuming the field belongs on the machine. It lives on the step. You never tell EDGEBIC which machines a tool fits.
  • Looking for the field on a material or product node. It appears on ordinary work-center nodes only.
  • Not finding the tool in the picker. The picker lists active tools only. Tick Active on the tool and save, then reopen the routing editor.
  • Assuming deactivating a tool clears the requirement. It does not. Steps keep the requirement and fail loudly on the next run until you re-point or reactivate.

Next Steps

If an operation genuinely needs two tools at once, see how to model a step that needs two tools. To record calibration or repair windows, see how to record tool downtime. The equivalent task for the human dimension is how to require a skill on a routing step.

Every task in this library is indexed on the EDGEBIC how-to hub. To see a single requirement change a plan that machines said was fine, book a walkthrough of EDGEBIC.

In the BOR grid, select the step, open the Basic Information section of the details panel, and set Required tool: to the tool. In the BOR Designer, select the step's node and set Required Tool in the properties panel. Both do the same thing in EDGEBIC by User Solutions, and choosing the entry labeled none clears the requirement. From the next scheduling run the step only lands in windows where the tool has free hours, on whichever machine it runs.

No. 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 independent dimensions and a step may need any combination of them, including a tool with no skill at all. A plain work-center step and a step bound to a machine pool can both carry a tool requirement.

Yes. The requirement is stored with the routing step and also with the job's preserved routing snapshot, so a reschedule that replays a job's frozen routing applies the same tool constraint it was originally scheduled under. That matters because the alternative failure is subtle: the constraint would work on fresh jobs and silently disappear on rescheduled ones.

Because Required Tool only appears on ordinary work-center nodes. Material nodes, product nodes, and parallel or alternate child nodes do not show it. If you are looking for the field on a node and it is absent, check what kind of node you have selected; a material step in particular has no machine to mount a fixture on.

Expert Q&A: Deep Dive

Q: Should every step in the routing that touches the fixture carry the requirement, or just the one where it goes on?

A: Every step during which the fixture is physically occupied. The tool is held for the whole of any step that names it, so if a part stays fixtured across three consecutive operations and the fixture cannot be released between them, all three steps require it. If the fixture goes on for milling and comes straight off, only the milling step names it. The common error is the first case handled as the second: naming only the first operation, so the plan thinks the fixture is free the moment milling ends when in reality it is still holding the part through inspection. That understates contention in a way nothing on screen will flag.

Q: We set the requirement and nothing changed in the schedule. What did we miss?

A: Almost always one of three things. You have not rescheduled: setting the requirement is a routing change and EDGEBIC does not replan by itself, so run a reschedule and look again. Or the tool is genuinely not contended, which is a real and good outcome: if only one step in the plant ever mounts it and there is plenty of pool, the constraint is satisfied everywhere and the dates are unchanged. Or you set it on one step and the contention is caused by a different step you have not touched yet. A tool only constrains work through the steps that name it, so a fixture used by four operations with the requirement on one of them will behave as if the other three do not exist.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together