When to Use a Machine Pool vs an Alternate Work Center

A machine pool, called a work center group, is a reusable set of interchangeable machines you define once and bind to any routing step, while an alternate work center is a fallback machine listed by hand on a single step. Both give the engine more than one place to run an operation, so both cut queue time on a busy machine. The difference is maintenance and reuse. A pool is central and shared; an alternate list is local and manual. EDGEBIC by User Solutions supports both, and choosing the right one keeps your routings from drifting the first time a machine is added or retired.

Two ways to say "run this anywhere in the group"

Most shops have clusters of machines that are different but interchangeable for a class of work: three mills of different vintages, two nearly identical welding cells, a fast laser and a slow backup. The scheduler needs to know it may run a step on any of them. There are two ways to tell it.

The first is a per-step alternate list. On one routing step you name the primary machine and add fallback machines by hand. The engine picks the candidate that finishes soonest. This is fine for a one-off fallback, but the same three-machine list copied onto dozens of routings drifts the moment someone adds a fourth machine and forgets a routing.

The second is a work center group. You define the pool once, give it a name like MILLING, add members, and bind routing steps to the group instead of to a single machine. At schedule time the engine explodes the group into candidate machines and shops the pool. Add a member to the group and every bound step considers it immediately, with no routing edits.

The maintenance trade-off

The pool wins whenever the same cluster serves more than a couple of routings, which describes most machining, welding, and finishing cells. The alternate list earns its place for a genuine one-off: this single routing may spill to that one machine, and nothing else does.

How each picks the machine

Both mechanisms run the same underlying resolver: build the candidate list, evaluate each against live capacity, pick the winner. A group adds a per-group selection strategy on top.

The efficiency factor is what makes a pool honest about a mixed cluster. A member factor of 0.5 means the machine runs the work in half the base hours; 1.5 means it takes 50 percent longer. Setup is a separate per-member override and is never scaled by the factor, because a machine can run fast and still set up slow. A factor only penalizes a member in the comparison, though; it never removes one, so keeping a slow machine out of a pool comes down to the member list, the Active flag, and the selection strategy instead.

A worked example

A MILLING group has three members, all on the same day shift, one machine each:

All mills free Monday, earliest completion strategy. The engine projects finishes: Mill-1 at 12:30, Mill-2 at 10:30, Mill-3 at 14:15. Mill-2 wins and the job books 08:00 to 10:30. The Job View shows Mill-2, and the step still stores its group binding so a later reschedule can re-shop the pool.

Mill-2 booked solid until Wednesday. Now the projected finishes are Mill-1 at 12:30 Monday, Mill-2 not until Wednesday, Mill-3 at 14:15 Monday. Mill-1 wins. The fastest machine loses to the available one, which is the entire point of capacity-aware pooling.

That second case is what a hand-maintained alternate list gives you too, but only if you remembered to put all three machines on this exact routing. The group gives it to every bound routing at once.

The rule that keeps it clean

A group binding and manual alternates cannot coexist on one step. When you bind a step to a group, any manual alternates are stripped, because the group is the alternate list. This is deliberate: two competing sources of candidate machines would have undefined selection. One step, one source.

Groups are also not the same as instances. Instances model identical units inside a single work center, sharing one calendar and one speed. A pool models different-but-interchangeable machines, each keeping its own calendar and its own relative speed. If your machines are truly identical, instances plus load balancing is simpler; if they differ, a group is the right tool. And a pool is a machine question only, never a skill question: model qualified operators separately, not as group members.

Which to reach for

Bind steps to a work center group when the cluster is shared across routings and you want one place to add or retire a machine. Keep a per-step alternate for a genuine one-off fallback. For the definition and the full member model, see what a work center group is; to configure one, see how to bind a routing step to a machine pool; and for the broader picture of how the engine resolves candidate machines, the scheduling engine guide traces the whole path. When the machines must run at the same time rather than as alternatives, that is dependent vs independent parallel scheduling, a different mechanism entirely. See how the pool behaves live in EDGEBIC.