How a Step-Level One-Per-Day Rule Overrides the Machine

The one-job-per-day rule exists in two places in EDGEBIC by User Solutions: on the work center, where it governs everything the machine runs, and on the individual routing step, where it governs a single operation. When the flag is set on the step it enforces the one-job-per-instance-per-day constraint for that operation regardless of the machine's own setting. That is the difference between saying "this booth always gives a whole day to one job" and saying "this one coating needs a whole day, and the booth is otherwise normal."

The distinction is small in configuration and large in capacity, because the machine-level version applies the cost to every product that touches the machine.

Two ways to say the same thing, with different scope

The machine-level flag is the familiar one. Turn it on for a furnace or a booth and each instance of that work center serves one job per day. The engine finds a free instance, gives the entire job that instance for the day, and no other job shares it. The behavior is described in how one-per-day dedicates a machine for a full day.

The step-level flag says the same thing about one operation. When it is set on a routing step, that operation is placed under the dedicated-instance rule even if the work center it routes to is running ordinary load-balanced allocation for everything else.

The reason both exist is that the physical constraint sometimes belongs to the equipment and sometimes belongs to the product. A vacuum furnace whose cycle cannot be shared is an equipment constraint. A single high-purity alloy that cannot follow anything else through an otherwise flexible furnace is a product constraint. Modeling a product constraint on the equipment is what causes a plant to lose most of a machine's capacity for the sake of one part number.

What changes in the placement

Under normal allocation, the engine picks an instance by balancing load: the operation's hours are distributed across available instances, or filled sequentially, and several jobs can share a machine within the same day. The details of that choice are in load balancing versus dedicated instance scheduling.

Under the one-per-day rule, instance selection changes shape. The engine looks for an instance that carries no other job on the target date, assigns the whole operation to that instance, and blocks the rest of the day on it from other work. If no instance is free that day, the search moves to the next day and repeats.

Two consequences follow.

The operation cannot be spread across instances to shorten it. Whatever compression you would have gained from running on three machines at once is not available, because dedication and splitting are opposite instructions.

The date can move significantly. The engine is no longer asking whether there are free hours; it is asking whether there is a free instance-day. Those are very different questions on a busy machine, and the second one is much harder to satisfy.

A worked example: one booth, three products

A paint booth has two instances and runs an eight-hour day shift, giving 16 instance-hours a day. Three jobs are waiting.

• Job 1: standard gray, 4 hours
• Job 2: standard gray, 3 hours
• Job 3: a specialty coating, 3 hours, which cannot follow another product through the booth on the same day without a full purge

With no dedication anywhere, all three jobs land on the same day. The booth uses 10 of its 16 instance-hours and everything ships. On paper this is efficient. In reality Job 3 comes out contaminated, and the plan was fiction.

Now set the one-per-day flag on the booth itself. Every job gets a dedicated instance-day, so two jobs run today, one runs tomorrow, and the booth's effective throughput collapses from 16 instance-hours to two jobs a day regardless of size. Two three-hour jobs now consume a full day of a resource that could have done 16 hours of work. The specialty problem is solved by making every product expensive.

Now instead set the flag on Job 3's routing step and leave the booth alone. Jobs 1 and 2 share instance 1 normally, consuming seven of its eight hours. Job 3 takes instance 2 for the whole day. The booth uses 10 instance-hours of work, ships all three jobs on the same day, and the specialty coating still had the booth instance to itself.

That is the case for the step-level flag in one comparison: same protection, roughly a third of the capacity cost.

When to reach for it

Use the step-level flag when the reason for dedication is the product or the process rather than the machine. Contamination-sensitive coatings, cure cycles that must not be disturbed, high-purity or high-value loads, and validation runs that must be traceable to a single day of a single machine are the common cases.

Use the machine-level flag when the equipment itself cannot be shared within a day at any time, for any product. A batch oven whose door cannot be opened mid-cycle is a machine-level truth, and putting the flag on every routing step that touches it would be error-prone bookkeeping for the same outcome.

Do not use either one to express "this job is important." Priority and sequencing are separate mechanisms, covered in how a scheduler decides which job runs first. A dedication flag does not make a job run sooner. It usually makes it run later, because the constraint is harder to satisfy.

The capacity arithmetic to expect

On a single-instance machine, a step-level dedication is expensive: one operation takes the machine's entire day. If that operation is two hours long, six hours of the day are gone.

On a multi-instance machine, the cost is proportional. A work center with four instances gives up a quarter of its day per dedicated operation, and the other three instances continue serving normal work.

This is why shops that need product-level dedication often benefit more from adding an instance than from any scheduling change. The rule's cost is measured in instance-days, so the cheapest way to make it affordable is to have more instances to spend. The general trade-off between one large resource and several smaller ones is explored in one big machine versus several small machines, and it applies here with unusual force.

Reading the result

When an operation under the step-level rule is placed, the resulting schedule looks ordinary: one operation, one machine instance, a start and an end. What is not visible on the bar is that the rest of that instance's day is reserved. If you are reconciling why a machine shows idle time that nothing else could take, a step-level dedication on an operation earlier in the day is a common explanation, and it is a deliberate one rather than a gap.

The wider instance and capacity mechanics are described in the scheduling engine guide, and the underlying reason a dedicated day costs what it costs is the same reason finite capacity scheduling is worth doing at all: the hours are real, and spending them on exclusivity is a choice you should be able to see.

To model where product-level dedication would actually pay for itself in your plant, bring your routings to a demo.