Lot Streaming Did Not Overlap My Operations: Causes and Fixes

When lot streaming does not produce the overlap you configured, it is one of four documented conditions: neither streaming field is set, the transfer batch is too large, the flow step ran on an alternative machine, or the work center is continuous-process. EDGEBIC by User Solutions supports two overlap models, and each has a specific reason it can quietly do nothing, so the fix is to find which condition applies.

The controls you use to diagnose this are the anomaly report and the routing step fields. This post is the detailed version of the lot-streaming symptom in the EDGEBIC troubleshooting guide. For the mechanism, lot streaming explained covers both models, and how to overlap operations shows the setup.

The Two Overlap Models, Briefly

EDGEBIC compresses a routing by letting a downstream step begin before the upstream step finishes the whole lot. It does this two ways. The piece-count model uses a transfer batch size: once that many pieces accumulate upstream, the downstream step may start. The flow-step model uses a start-to-start lag in hours: the downstream step may begin a set number of hours after the upstream step starts. Piece-count versus time-lag overlap compares the two. If neither field carries a value, there is no streaming and the downstream step correctly waits for full completion.

Cause 1: Neither Streaming Field Is Set

The first thing to rule out is that streaming was never actually enabled. Both the transfer batch size and the flow step default to zero on every routing step, so a step where both are still zero produces no overlap by design.

How to tell: open the routing step and read the transfer batch size and flow step fields. Two zeros means nothing triggers streaming.

Fix: set one of them. Use a transfer batch size for discrete pieces, or a flow step in hours for a fixed head start or a continuous process. Do not set both on the same step; that ambiguity is its own flagged condition, and setting two lot-streaming methods on one step covers which of the two the engine uses.

Cause 2: The Transfer Batch Is as Large as the Order

The engine caps the transfer batch at the order quantity, because it cannot wait for a piece that will never exist. When the batch size is set as large as or larger than the order, the cap makes the first sublot equal to the whole lot, and the downstream step waits for every piece exactly as it would with no streaming.

How to tell: the anomaly report flags a transfer batch that meets or exceeds the maximum order quantity for that step as a warning that streaming has become serial. Compare the batch size to your typical order size.

Fix: lower the transfer batch to a fraction of the smallest order that routes through the step, commonly 10 to 25 percent of a typical order. A 200-piece order with a batch of 50 moves the first sublot downstream after a quarter of the run, giving real compression.

Cause 3: The Flow Step Ran on an Alternative Machine

A flow step is keyed to the routing's primary machine. When a job runs the step on an alternative work center instead, the engine cannot match the flow setting to the alternate-routed schedule, so it silently skips the flow step and the downstream step starts at the full upstream end.

How to tell: the anomaly report flags this as critical, naming the flow step, the alternate machine the step ran on, and the primary machine the flow was configured for. The tell is that streaming works on runs that use the primary machine and fails on runs that use a backup.

Fix: the reliable workaround is to use a transfer batch size instead of a flow step, because the piece-count model does not depend on the primary-machine match. Alternatively, route the step to the machine it actually runs on so the primary matches. The schedule ignored my alternate work center covers alternate routing more broadly.

Cause 4: The Work Center Is Continuous-Process

A work center flagged as continuous-process, such as a paint line, chemical reactor, or extruder, does not use the piece-count model, because a discrete piece count is meaningless there. The engine ignores the transfer batch size on steps routed to such a center and falls back to the flow step. If no flow step is set, no overlap happens.

How to tell: the anomaly report flags a transfer batch size on a continuous-process center, noting that piece-count is ignored and the flow-step value in effect. Check the continuous-process flag on the machine.

Fix: if the center truly is continuous-process, clear the transfer batch and set a flow step in hours instead. If the machine is actually discrete and the flag is wrong, turn the continuous-process flag off and the piece-count model takes effect. Continuous-process work centers explains the flag.

A Note on Flow-Step Values

If you set a flow step but see no overlap, check the value. The flow step is a start-to-start lag in hours, so a value larger than the upstream run pushes the successor past the upstream end and acts as a delay rather than an overlap. A flow step of 1 on an operation running two hours creates overlap; a flow step of 3 on the same operation does not. The value is hours, not a fraction of the run.

How to Diagnose Missing Overlap, in Order

1. Read the two streaming fields on the step. Both zero means streaming was never enabled.
2. Compare the transfer batch to the order quantity. A batch as large as the order caps to serial; lower it.
3. Check whether the run used an alternative machine. A flow step on an alternate-routed step is skipped; switch to a transfer batch or fix the routing.
4. Check the continuous-process flag on the machine. It disables piece-count; use a flow step or correct the flag.
5. Confirm the flow-step value is smaller than the upstream run if you want overlap rather than a delay.

Prevention

• Pick one model per step. A transfer batch for discrete pieces, a flow step in hours for continuous processes, never both on the same step.
• Size the transfer batch below your smallest order. A batch that can equal the order quantity silently becomes serial on small runs.
• Prefer a transfer batch when a step uses alternate machines. The piece-count model survives alternate routing where a flow step does not.
• Run the anomaly report after enabling streaming. The flow, batch, and continuous-process checks fire immediately on a save, so you catch a dead configuration before a job runs. The lot streaming overlap walkthrough shows a working example end to end, and if steps appear out of order rather than not overlapping, read steps scheduled out of sequence.