How to Keep a Slow Machine Out of a Machine Pool

There is no automatic efficiency screen on a machine pool: nothing filters candidates by a performance rating, so a machine is in a pool because somebody put it there. In EDGEBIC by User Solutions you keep a slow machine out, or make it a last resort, through four explicit controls: the member list, each member's Active flag, the factor that describes relative speed, and the group's selection strategy. The explicitness is the design, not a gap.

Why explicit rather than automatic

It is tempting to want a threshold: set a minimum performance level and let the engine drop anything below it. Consider what that does on a busy week. A pool that quietly excludes a machine has removed real capacity from your plant, and the symptom surfaces later as jobs that will not fit, with no visible cause. You would be debugging a plan against a candidate list you cannot see.

Explicit membership inverts that. The candidate list is exactly what you configured, so when a machine is not being used, the reason is one of a handful of settings you can read in a few seconds.

The four controls

Removing a machine, temporarily or permanently

Temporarily: untick Active. The machine drops out of every group-bound step's candidate list on the next scheduling run, and operations already started on it stay exactly where they are. That pairing is what makes this safe mid-week: future work stops landing there without disturbing work in progress.

Permanently: remove the member. The right move when a machine has left the pool for good.

One guard worth knowing: a group needs at least one active member to be schedulable at all. A fully deactivated pool fails visibly rather than quietly picking something else, which is what you want from a safety mechanism.

Making a slow machine a last resort instead

Exclusion is often the wrong tool. If the machine can do the work, just not as fast, you usually want it available for overflow and ignored otherwise. Two settings achieve that.

The factor. Each member carries a factor multiplying the step's base run hours for that machine: 1.0 is baseline, 0.5 is twice as fast, 2.0 is twice as slow. It is never applied to setup time, which is carried separately as an optional setup override, so a machine can run fast and still set up slowly.

Use the factor for work-class differences, meaning this machine takes twenty five percent longer for this kind of work. If a machine is simply slower at everything, that belongs in its own work center configuration rather than in a pool factor, or the same slowness gets described twice. The distinction is covered in how efficiency scales run time but not setup.

The strategy. With the default earliest-completion strategy the engine computes real per-machine hours using each member's factor before choosing, so an honestly-described slow machine loses whenever a faster one finishes sooner, and wins only when it genuinely would finish first because the others are busy. That is usually the behavior people were reaching for when they asked about a threshold.

Choosing the strategy

Primary first is the direct answer to "use the new machine unless it is full". Flag that machine as Primary, and note only one member can hold the flag: ticking a second unticks the first. Priority then breaks ties among the rest, lower numbers first, and also decides the fallback primary when no member carries the flag.

Diagnosing a machine that never gets work

1. The Active flag. Unticked means the machine left every candidate list on the last run, which is exactly this symptom.
2. The strategy. Under primary first, a free third machine sitting idle while the primary works is correct.
3. The factor. A number well above one keeps earliest completion preferring others. Check it against reality.
4. A manual pin. A planner's machine pin always wins and survives rescheduling, so a pinned step will not shop the pool.

Only then look at shifts and calendars.

Pools, parallel machines and alternates are different things

Worth separating, because the words get used interchangeably on a shop floor.

A pool is "any of these machines may run this step, pick one". That is a work center group, and everything above applies to it.

Parallel machines run together: an independent parallel machine takes its own capacity-checked share of the work to shorten the operation, while a dependent parallel mirror runs in lockstep with the primary. To keep a slow machine out of a parallel step you simply do not add it as a parallel machine, since the candidate list there is whatever you configured on the step. The two modes are compared in dependent and independent parallel and the lockstep behavior in how dependent parallel mirroring locks machines together.

A true alternative is instead of: one machine ends up doing the step. It carries its own setup and its own hours, entered directly, with no factor involved. If you want a slow machine available as an emergency route but never as a routine partner, a true alternative is the right shape.

One last note on maintenance: interchangeable machines are better modeled as a group than as an alternate list hand-configured on every routing step, which drifts the first time somebody edits one copy. Binding a step to a group supersedes any manual alternate list on that step, because from then on the group is the alternate list. How a work center group shops a pool of machines covers the shopping behavior.

All of this only produces a real decision because capacity is treated as genuinely finite. If capacity were infinite, adding a slow machine would be free. It is not, which is why membership is a decision you make rather than one the engine makes quietly for you.

The takeaway

Nothing screens machines out of a pool automatically, because a silent exclusion would remove capacity you thought you had. Keep a machine out by unticking its Active flag, which takes effect on the next run while leaving started work alone, or remove the member outright when the change is permanent. More often the better answer is to make it a last resort: describe its speed with an honest factor, which never touches setup, and let earliest completion prefer faster members, or flag a Primary and use primary first. When a pooled machine never gets work, check Active, then the strategy, then the factor, then a manual pin. See the platform on the EDGEBIC overview, the upgrade path on the RMDB to EDGEBIC guide, and pair this with the complete scheduling engine guide.