How EDGEBIC Switches Between Finite and Infinite Capacity

EDGEBIC by User Solutions schedules at finite capacity by default and runs infinite only where you ask it to. The material planning pass nets quantities at infinite capacity, the scheduling engine places every operation at finite capacity, and three settings decide how strictly a given job is held to real machine hours: the finite capacity flag on each routing step, the dependent or independent mode of a parallel machine, and the schedule-at-utilization percentage. This post shows where each one lives, what it changes, and what the two models do to the same three jobs, with numbers.

The general method comparison, with a 12-row table and a load vs sequence diagram, is in finite vs infinite capacity planning and scheduling. This post is the EDGEBIC product view.

Where EDGEBIC runs infinite and where it runs finite

The two passes are explained in why material planning and finite scheduling are two passes in EDGEBIC. The rest of this post covers the scheduling side.

Switch 1: the finite capacity flag on a routing step

Each routing step carries a finite capacity flag, found with the other step-level controls in the grid view. It is on by default. With it on, the engine will not place the step's hours until the work center has room after everything already booked. With it off, the engine books the hours where the routing wants them and nothing checks the machine, which is infinite capacity for that one operation.

Turn it off only for a step that does not occupy a machine: an administrative marker, or a material step that consumes a component rather than machine time. If a step on a busy machine has the flag off, the utilization report will show that machine climbing past what its shifts define. That symptom is the first thing to check when a full machine keeps accepting work.

Switch 2: independent or dependent parallel machines

On a secondary work center attached to a step, the same flag picks the parallel model. Flag on means independent: the secondary machine's own capacity is checked and consumed, so both machines must have room at the same moment. Flag off means dependent parallel processing: the secondary machine mirrors the parent's start, end and instance without its own check. Dependent is right for heads on one frame that physically run together. It is wrong for two lines you want to share a job, because neither line gets tested for existing bookings.

What the infinite pass produces

An infinite capacity model treats each work center as if it had unlimited parallel lanes. Release ten jobs to a single mill and the model happily starts all ten at once, because it never asks whether the mill can be in ten places at the same time. The output is a load profile: total hours demanded per period versus total hours available. That profile is genuinely useful for one thing, spotting an overloaded week before you accept the order that causes it.

What infinite capacity cannot do is give you an executable schedule. Its completion dates assume zero queue time, so they are always the earliest arithmetic possible, never the earliest achievable. On a busy floor the gap between those two is where every missed delivery lives.

What the finite engine does instead

Finite capacity scheduling places one operation, consumes that machine time, then places the next operation against whatever time is left. Two jobs that both want the same mill on Monday do not both get Monday; the higher-priority job claims it and the second job queues behind it. The result is a set of dates that already account for the wait every job experiences in a real queue.

This is why finite dates are later than infinite dates and also why they are trustworthy. The finite engine is not being pessimistic. It is showing you the queue that already exists on your floor, the one infinite planning hides. Once that queue is visible you can act on it, which is why finite scheduling shrinks lead times rather than stretching them.

A worked example: three jobs, one work center

One work center, one instance, one 8-hour day shift. To keep planning realistic you define the shift as the 6.4 hours the machine really delivers rather than a fictional 8, since that is where headroom belongs. Three jobs arrive Monday morning, each needing 10 run hours:

Infinite capacity starts all three Monday 08:00. Each is 10 hours of work, so at face value each "finishes" partway through Tuesday. The report shows all three on time. Nobody on the floor believes it, because there is one machine.

Finite capacity sequences by priority and start date, then queues:

Thirty run hours divided by 6.4 planning hours per day is about 4.7 days of elapsed time. MO-A hits its Tuesday due date; MO-B misses Wednesday by less than an hour of Thursday work; MO-C misses Thursday by most of a day. The finite model just told you, on Monday, that two of three orders are already late. That is a decision you can act on: add a shift, offload MO-C to an alternate work center, or renegotiate a date. The infinite model gave you nothing to act on because it reported success.

Switch 3: the schedule-at-utilization dial

Even a finite schedule has to decide how many of a shift's clock hours are truly plannable. Nobody runs a machine 100 percent of every shift; there are micro-stops, tool changes, and breaks. EDGEBIC exposes this as a per-job schedule-at-utilization percentage. At 80 percent on an 8-hour shift, each instance offers 6.4 hours a day to the finite engine. Set it to 100 percent and you have quietly recreated the infinite model's optimism inside a finite run, and your dates will drift. This dial is covered in depth alongside how multi-shift allocation fills capacity.

When infinite still earns its place

Infinite capacity is not wrong, it is just a different question. Reach for it when you want a fast, months-out sanity check: is October broadly overloaded, or is there room to take on the new contract? You do not need a sequenced schedule to answer that, and running the full finite engine over a rough forecast would be slower than the answer deserves. The discipline is to never confuse the rough-cut load profile with a promise. The moment you quote a date to a customer, that date should come from the finite run, not the infinite one.

Why the finite model is the honest one

A finite schedule respects the same reality your operators live in: one job at a time, per instance, inside real shifts, minus holidays and downtime. When it says a job finishes Friday, that date already includes the queue behind it. This is the foundation the rest of the platform builds on, from searching forward in time for the next open capacity to keeping a shared bottleneck fed. It is also why finite scheduling was the model behind the schedules User Solutions built for operations from GE Railcar, which moved from 30 percent to 90 percent on-time delivery, to the US Navy carrier Nimitz with its 26,000-plus scheduled tasks. Those results came from planning against real capacity, not wished-for capacity.

The full pipeline, from the finite placement rules to the optimizer that sits on top of them, is laid out in the scheduling engine guide. To watch the finite model queue your own jobs and surface the dates you can actually promise, see EDGEBIC on your data.