8 Parallel Work Center Configuration Mistakes in EDGEBIC

Multi-machine scheduling fails in a small number of very specific ways, and the two most common are so consistent that they are worth checking before anything else: duplicate shift records, and the wrong category on the entry. Each mistake below is paired with its symptom and its fix, for EDGEBIC by User Solutions.

For the three categories and when to use each, read parallel and alternate work centers explained. For the fields themselves, read how to configure parallel and alternate work centers.

1. Two Identical Shift Records Instead of One Shared Row

Symptom: A parallel group never schedules, or scheduling reports that no simultaneous window could be found, on machines that visibly run the same hours.

Cause: Common shifts across a group are found by matching the shift record itself, not the hours printed on it. Two rows created separately that both read 08:00 to 16:00 are two different shifts, so the intersection across the group is empty on every date and the capacity gates are never reached.

Fix: Open each machine's associated shifts list and confirm the same row appears on all of them. Delete the duplicate and assign the shared row. Check the use-global-shifts flag too, since it bypasses per-machine assignments and is a common way duplicates get created in the first place.

This is the single most frequent cause of a group that will not schedule, and it costs two minutes to rule out.

2. Leaving the Category as Parallel When You Wanted a Fallback

Symptom: You added a backup machine expecting it to take over when the primary is booked, and instead both machines appear on the job.

Cause: The parallel category is the default on existing data. A parallel entry runs alongside the primary; a true alternative replaces it.

Fix: Set the category to true alternative on the entry. The resolver then projects a completion time on the primary and every active candidate before scheduling begins and switches the operation to whichever finishes soonest.

3. The Finite Capacity Setting Turning an Independent Machine into a Mirror

Symptom: A second machine appears on the operation with the same timestamps as the primary, does not consume any capacity, and shows load above 100 percent.

Cause: The finite capacity setting on the entry is what separates independent from dependent. Checked means the machine's capacity is genuinely checked and consumed. Unchecked means the machine is mirrored: it receives a copy of the primary's schedule with no capacity gate at all.

Fix: Check the setting for machines that should be independent. Leave it unchecked only for machines that are physically joined to the lead, where the bypass is a promise about hardware rather than an accident.

4. Using the Dependent Category for Machines That Are Not Joined

Symptom: Machines are over-booked. A load view shows a mirror-configured machine well over 100 percent while other jobs are also planned on it.

Cause: Mirrored machines bypass the capacity check on purpose, because a machine bolted to the same motion as the lead is committed regardless of what its own calendar says. Apply that to machines that merely tend to run together and their capacity stops being respected.

Fix: Reserve the dependent category for genuine synchronized hardware: ganged drill heads, twin robots on one frame, slaved stations on one line. The synchronized multi-spindle walkthrough shows what a correct dependent setup produces. Everything else that runs at the same time and can be placed separately belongs in the independent category.

5. Max Parallel Work Centers Left at One

Symptom: You added a second and third machine to a group and the schedule looks exactly as it did before.

Cause: The max parallel work centers setting on the step's parallel processing options caps how many machines run together, and it defaults to one.

Fix: Raise it to the number of machines you actually want running at once. While you are on that screen, note that load balancing also lives there rather than on the individual machine entries, and defaults are used when the parallel processing record does not exist for the step.

6. Setting a Factor on a True Alternate

Symptom: A backup machine's projected times ignore the factor you carefully entered, and the next person reading the routing draws the wrong conclusion about how fast the machine is.

Cause: The factor is not used for true alternates. A true alternate carries its own run hours and its own setup time, and those are what the resolver uses when it projects completion.

Fix: Leave the factor alone on true alternate entries and enter the real per-alternative setup and runtime instead. This matters for the same reason in reverse: a true alternate with blank setup and runtime inherits the primary's numbers, so a slower backup can look artificially attractive and a machine with a long setup can be chosen when it should not be. Enter real values on every alternate you rely on.

7. Adding Hand-Built Alternates to a Pool-Bound Step

Symptom: Alternate entries you added to a routing step disappear on the next scheduling run.

Cause: A step is bound to a machine pool or carries a hand-built alternate list, never both, because the pool is the alternate list. When the pool expands into candidates at schedule time, hand-added alternate entries on that step are removed so two competing sources cannot fight over the same decision.

Fix: Add the machine to the pool rather than to the step. If you find yourself maintaining the same alternate list across many routing steps, that is the signal to switch to a pool anyway: members carry their own efficiency and setup, and one binding replaces dozens of hand-built lists. What a work center group is covers the trade-off.

8. Deleting an Entry to Take a Machine Out Temporarily

Symptom: A machine comes back from maintenance and its parallel configuration has to be rebuilt from scratch, often with a different factor than it had before.

Cause: Deleting the entry removes the configuration along with the machine.

Fix: Set the entry inactive instead. Inactive entries are skipped when the candidate list is built, scheduling proceeds with the remaining active machines, and re-enabling restores the original settings exactly. Note the difference from marking downtime on the work center itself: downtime blocks the machine for every routing, while an inactive entry removes it from this one operation.

The Five-Minute Audit

Run this on every routing step that names more than one machine. It catches all eight mistakes above.

1. Shift records. Does the same shift row appear on every machine in the group? Match the record, not the hours.
2. Category. Is each entry parallel or true alternative, and is that what you meant? Parallel is the default, so check the fallback machines specifically.
3. Finite capacity. Checked on machines that should consume their own capacity, unchecked only on machines physically joined to the lead.
4. Max parallel work centers. Raised above the default of one wherever a group has more than one secondary machine.
5. Per-alternative numbers. Real setup time and runtime entered on every true alternate you rely on, rather than left blank.
6. Factor. Set on parallel mirrors, left alone on true alternates.
7. Pool bindings. No hand-built alternate entries on steps that are bound to a machine pool.

Two of these deserve to be checked more often than the rest. Shift records because they are the most common failure and the least visible, and category because it is the field most likely to be left at its default while the person setting it up believes they configured something else.

If you would rather check the output, two signatures are diagnostic. A group that never schedules almost always means no shared shift record. A machine reading above 100 percent load that is not deliberately configured as a synchronized mirror almost always means the finite capacity setting is unchecked where it should be checked.

Three Results That Are Not Mistakes

A group is delayed rather than starting partially. Independent parallel machines are placed all together or not at all. If one member is down Monday and Tuesday, the group starts Wednesday rather than running the healthy machines alone. A schedule showing two of three machines running would be a plan nobody can execute.

Adding a fourth machine made things worse. Every additional member adds another calendar that has to agree at the same instant, so simultaneous windows get rarer as groups grow. When the goal is more capacity rather than more machines on one operation, a pool or a higher instance count on one work center is the right structure.

An in-progress job stays on a slower machine. On a reschedule, machines carrying actual dates for that job are locked, and the resolver will not move the work even if another machine now looks faster. That is correct: the part is physically on that machine. Completed work is never moved by a reschedule.

Where to Go Next

For the gate-by-gate logic behind every accepted or rejected window, including what rollback does when a placement fails partway through, read how EDGEBIC validates simultaneous capacity. For the shift setup that most of these mistakes depend on, read how to schedule jobs across shifts. The complete guide to EDGEBIC maps the rest of the platform.