Splitting a Large Order Across Parallel Work Centers in EDGEBIC

To finish a large order faster in EDGEBIC by User Solutions, you set the routing step to independent parallel and add a second machine, and the engine finds a window where both are free, splits the hours across them with load balancing, and completes the step in roughly half the wall-clock time. This walkthrough runs one big milling job across two mills and verifies the split. It is part of our worked examples series, and it is the opposite case to the synchronized multi-spindle walkthrough: there the machines are locked together, here they work the same job independently to go faster. The numbers are illustrative; the parallel behavior is documented.

The Setup: One Big Job, Two Identical Mills

Cascade Components has a 60-hour milling operation on a job due in three days. On one mill, at 8 working hours a day, that step alone is roughly a week and a half, and the date is impossible. The shop has two identical mills, MILL-1 and MILL-2, both on the same day shift. The plan is to run the milling step on both at once. This is independent parallel: two machines, the same job, working side by side to halve the elapsed time.

Independent parallel differs from a true alternative. A true alternative runs the job on one machine or the other, whichever is free; independent parallel runs it on both simultaneously and splits the work. For a lead-time crunch on a big job, splitting is what you want.

Step 1: Configure the Step as Independent Parallel

Dana, the planner, opens the product's bill of routing and selects the milling step. She sets the step's Work Center Type to independent parallel. Then, in the step's Alternative Work Centers sub-grid, she clicks Add and chooses MILL-2. She sets:

• Factor to 1.0, because MILL-2 runs at the same rate as MILL-1. (A slower machine would take a factor above 1.0 so its hours are costed honestly.)
• Type to Independent and Category to Parallel, meaning "run alongside the primary," not "replace it."
• Active on, finite capacity on (so MILL-2's real capacity is respected), and Priority 1.

She saves the routing.

Step 2: Set the Split Behavior

Whether the hours split evenly or by available capacity is controlled on the step's parallel-processing configuration. Dana leaves load balancing on, the default, which gives more hours to whichever mill has more free capacity in the shared window and so minimizes completion time. She also sets the maximum simultaneous machines to two, because parallelism only takes effect when more than one machine is allowed to run at once. (Left at one, the split would never happen.)

If she wanted a strict 50/50 regardless of load, she would turn load balancing off, and the engine would allocate to the first machine up to its share before the second. For a straight speed-up on twin machines, load balancing is the right choice.

Step 3: Reschedule and Split the Hours

Dana reschedules the job. When the engine reaches the milling step, it does not just pick a machine; it looks for a shift window where both MILL-1 and MILL-2 have capacity at the same time. Finding one, it splits the roughly 60 hours across the two mills using load balancing and emits two schedule lines for the step, one per machine, with the same logical start.

The two lines overlap in time. Instead of 60 hours of elapsed milling on one machine, the job runs about 30 hours of elapsed time across two, and the step's end date is set by whichever mill finishes last. The job now fits the three-day window.

Where the Hours Land

The total work is the same; the elapsed time roughly halves because two machines share it. That is the entire value of independent parallel for a lead-time crunch.

Step 4: Verify the Split Actually Happened

Dana confirms it two ways. In the Job View, she filters to the job and expands the milling step: two schedule lines, one naming MILL-1 and one naming MILL-2, each with about half the step's hours, overlapping in time. That is the proof that the engine split the work rather than running it twice on one machine.

She also glances at the Work Center Utilization report, where both mills now carry milling hours from this job. If only one schedule line had appeared, the usual cause is that the two mills had no common shift on the target day, so the engine could not find a simultaneous window, or MILL-2 was fully booked. The fix is to ensure both share a working shift and that the second has room, then reschedule.

What This Run Proves

1. Independent parallel splits one job across two machines. Both run the same operation at once, and the elapsed time roughly halves.
2. Load balancing packs the split against real capacity. The busier-with-headroom machine takes more hours; even split is available by turning it off.
3. Both machines need a common shift and real capacity. The engine requires a simultaneous free window, or it searches forward for one.
4. The step ends when the slower machine finishes. Completion is driven by the last-finishing line, not the average.
5. Two schedule lines are the proof. One line per machine in the Job View confirms a genuine split.

Variations Worth Trying

Add a third mill. Install a third parallel machine on the same step and raise the maximum simultaneous machines to three. The 60 hours split three ways, and the elapsed time drops toward a third, capacity permitting.

Handle a slower second machine. If MILL-2 is older and slower, set its factor above 1.0 so its share is costed and timed honestly. The split then reflects the real speed difference instead of assuming twins.

Choose overflow instead of split. If you would rather keep MILL-1 as the primary and only spill to MILL-2 when MILL-1 is full, use a true alternative instead of parallel. That fallback behavior has its own backup-machine walkthrough.

The Bigger Point: Parallelism Is a Routing Decision, Not a Manual Split

Splitting a big job across machines by hand means computing each machine's share, checking both calendars for a common window, and keeping the two halves in sync, which is exactly the kind of arithmetic a finite capacity engine exists to do. You make the decision once in the routing (this step may run parallel on these machines), and the engine finds the window, splits the hours, and proves the split on the Gantt every time the job runs.

User Solutions has built that discipline into scheduling tools since 1991, for operations that fight lead time daily: the US Navy, GE, BAE Systems, and Cummins among them. GE Railcar's climb from 30% to 90% on-time delivery came from squeezing exactly this kind of elapsed time out of the plan. EDGEBIC carries that lineage forward.

Bring your worst lead-time crunch and your twin machines. Contact us and we will model the parallel split against your routing data, or read the work-center rebalancing walkthrough to see the same parallel mechanism used to relieve a bottleneck.