How a Job Sticks to the Same Machine Instance

When a work center has several identical machines, EDGEBIC by User Solutions prefers to keep a single job on the same machine instance across every shift and day it runs there, rather than scattering its hours across different machines. The engine remembers where a job first landed and tries to reuse that instance, relaxing the preference only when the machine cannot take the work. Continuity keeps changeover cost honest and the job's trail on the floor coherent, which is why it is the default instinct on a multi-machine center.

A work center is often not one machine but several interchangeable ones, called instances. When a job needs more hours than a single shift holds, or spans several days, the engine has a choice each time it places another chunk of that job: put it back on the machine the job is already on, or send it to a different one. The default answer is to keep it together.

Why continuity is the default

Moving a job between identical machines is not free on the floor. It can mean re-fixturing on the new machine, re-dialing a setup, and, just as costly in practice, a confused physical trail: an operator who expects the job on Mill-1 finds half of it on Mill-2. Keeping a job on one instance avoids all of that. The setup is paid once, the job stays in one place, and the record matches reality.

So EDGEBIC treats instance selection with a memory. The first time a job's operation lands on an instance at a center, that assignment is remembered, and subsequent portions of the same job at the same center prefer that instance. A job that runs three hours today and five tomorrow runs both on the same machine when it can, rather than being split across two for no benefit.

This is a genuinely different question from which shift a job's hours land on, covered in how multi-shift allocation fills capacity. The allocator decides when; instance continuity decides on which of the identical machines.

A preference, not a lock

Continuity is a strong default, but it is a preference, not a hard constraint. If the remembered instance is not available for the shift and hours the next portion of the job needs, because it is fully booked or down for maintenance, the engine does not stall the job waiting for it. It falls back to selecting another available instance, usually the least loaded one that can take the work.

That fallback is the right trade. Holding a job idle on a busy machine just to preserve continuity would cost more than the second setup it avoids. So the rule is: keep the job together while the preferred machine can serve it, and move it rather than delay it when the machine cannot.

Two explicit policies also override the continuity instinct, because they serve different goals:

• One-per-day dedication deliberately assigns each machine a single job for the whole day, a stronger form of continuity used where changeover owns the day, as in how one-per-day dedicates a machine for a full day.
• Load balancing deliberately splits a job across instances to finish it faster in parallel, the opposite instinct, chosen when speed on one job matters more than continuity. The two are contrasted in load balancing versus dedicated instance scheduling.

Continuity is the default when neither of those policies is in force.

A worked example: a job across two days

Take a milling center with two instances, Mill-1 and Mill-2, on an 8-hour day shift. A job needs 12 hours at this center and can start Monday.

Monday. The engine places the first 8 hours. It selects Mill-1 (say Mill-2 already has other work), and remembers that this job is on Mill-1.

Tuesday. Four hours remain. The continuity preference points back to Mill-1. Mill-1 has room Tuesday, so the remaining 4 hours go on Mill-1 too. The job ran entirely on one machine across two days, one setup, one coherent trail.

Now change Tuesday. Suppose Mill-1 is down for maintenance Tuesday. The continuity preference cannot be satisfied, so rather than delay the job to Wednesday when Mill-1 returns, the engine places Tuesday's 4 hours on Mill-2, the available instance. The job moved, but only because staying would have meant waiting. The replaced assignment is visible, so a planner can see the job used two machines and why.

The same job, and whether it stays on one machine or moves depends entirely on whether the preferred instance could serve it, exactly as a preference-with-fallback should behave.

When to lean on it, and when to override

Rely on the default continuity when setup and re-fixturing between identical machines are real costs and you want jobs to stay put. Reach for load balancing when finishing one large job quickly, by running it on several machines at once, is worth splitting it up. Reach for one-per-day when a machine should own a single job for the day regardless of hours, typically where changeover dominates.

The reason EDGEBIC exposes all three, rather than hard-coding one, is that shops genuinely differ. A fixture-heavy machining center wants continuity. A bank of identical CNC mills clearing a backlog wants load balancing. A heat-treat furnace wants one-per-day. The engine's default is continuity because it is the safest general instinct, and the other two are there for the cases that need them.

For the wider picture, the complete scheduling engine guide shows how instance selection sits inside the allocator, and finite versus infinite capacity scheduling explains why respecting each instance's real capacity is what keeps these choices honest. To see how your own multi-machine centers keep jobs together, explore the EDGEBIC engine or bring your data to a demo.