A machine instance is one physical machine inside a work center: a work center named with three instances is three interchangeable machines sharing one name and one queue, and the instance count is the most direct multiplier in the whole capacity calculation. Three instances on an eight-hour shift offer twenty-four hours, not eight. That one number decides how much work exists, how fast a job can finish, and how many jobs can run at once.
EDGEBIC by User Solutions treats instances as interchangeable clones behind one work center. This article defines the term at a glance. For the full behavior, including load balancing, fractional instances, and cross-shift spillover, read machine instances in EDGEBIC.
How It Works
The instance count answers one question: how many identical machines stand behind this work center name? The engine multiplies the per-machine shift hours by the instance count to get the work center's capacity, so raising the count from one to three triples the available hours.
That multiplier has three direct consequences. Separate jobs can run at the same time, one per instance. A single large operation can be split across the instances and finish in a fraction of the time. And each allocation names the instance it ran on, so the Gantt shows which physical machine is committed rather than a bare work center name.
Instances assume the machines are identical: same speed, same shifts, same tooling. Machines that differ belong in their own work centers, pooled in a work center group so a routing can still target any of them. The dividing line is the word identical, because the engine books every instance at the same rate. Two new mills and two old mills in one four-instance pool would all be planned at an averaged speed neither pair can hold.
A Concrete Example
Take a bank of two identical stamping presses entered as one work center called Press-1, on a day shift of 08:00 to 16:00. The capacity is eight hours times two instances, which is sixteen hours a day. Two separate eight-hour jobs run at the same time, one per press, and both finish that day. A single sixteen-hour job can be split across both presses and finish in one day instead of two. And when a supervisor reads the board, the allocation names Instance 1 or Instance 2, so they know which press ran what.
That is the whole feature at the capacity level. The nuance is only in when it is the right model. If handing the job to any machine behind the name would take the same hours, they are instances. If not, they are separate work centers that belong in a group.
Instances Versus Groups Versus Departments
Three mechanisms pool machines, and they solve different problems. Instances are for machines that are truly identical, sharing one name and one queue, with the engine booking every one at the same rate. A work center group is for machines that are interchangeable but different: each keeps its own speed and calendar, and a routing step can target the pool so the engine picks the best member. A department is an organizational rollup the scheduler ignores.
Choosing wrong is the most consequential master data mistake in a scheduling setup. Put two fast mills and two slow mills into one four-instance pool and the plan runs all four at an averaged speed neither pair can hold: the old machines are chronically late, the new ones underused, and no report says why. The mechanisms also compose. A group member can itself be a multi-instance work center, so "three identical new mills plus two identical old mills, either family will do" is two work centers with instance counts of three and two, pooled in one group. Get the identical-versus-interchangeable distinction right at setup, and the plan holds.
How EDGEBIC Uses It
The instance count is a field on the work center. It multiplies capacity after downtime and holidays are subtracted, so an hour of maintenance on a three-instance work center removes three hours of capacity, because the interruption stopped every machine. Utilization percentages are computed against instance-multiplied capacity, which is why an under-counted instance count makes a normal week read as a severe overload.
Instances also interact with the one-per-day rule: with it on, each instance takes a single job per day, which is how you model furnaces and paint booths where a load owns the machine regardless of cycle time. The manufacturing glossary covers the related terms, and the full machine instances guide walks through load balancing, fractional instances, and taking one machine out of the plan.
Expert Q&A: Deep Dive
Q: We run two identical presses as two separate work centers, and every routing has to name one. Is there a reason to combine them?
A: If they are genuinely identical, combine them into one work center with two instances and you gain three things. The routing stops choosing a machine it has no information to choose, so the engine picks at run time based on actual load. A single long operation can be split across both presses and finish in half the wall-clock time. And capacity reporting reads as one resource, which is how the shop actually thinks about it. The one thing you give up is deliberately routing to a specific press, and if you need that regularly, it is a sign the two presses are not as interchangeable as they look.
Q: Our heat-treat bank has four chambers. If I set four instances, will the scheduler try to fit five loads on a busy day?
A: With the default pooled behavior, yes. Four chambers on an eight-hour shift offer thirty-two hours, and five loads of six hours each fit inside thirty-two on paper. That is wrong for a furnace, where a load occupies the chamber for the day regardless of cycle time. Turning on the one-per-day rule changes the arithmetic to one job per chamber per calendar day, so the fifth load slides to tomorrow and any leftover clock time goes unused deliberately. Four chambers then means exactly four loads a day, which is what the floor can actually do.
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
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.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.