Overlapping Cut, Form and Weld with Lot Streaming

Lot streaming is the difference between a fab shop's Gantt showing three long serial bars and the same job showing three overlapping ones. EDGEBIC by User Solutions lets a routing step declare how many finished pieces the next operation needs before it can start, then computes the handoff from that number and lets forming begin while cutting is still running. For a shop where the press brake waits for the whole nest, this is the shortest path to a shorter lead time without touching a single machine.

The mechanism is documented in lot streaming explained, and the concept in what a transfer batch is. This post is about the cut, form, and weld sequence.

The Cost of Waiting for the Whole Nest

A 500-piece bracket order goes to the laser, then to the press brake, then to the weld cell. In a plan without streaming, each operation waits for the one before it to finish completely. Three serial blocks, and the job's lead time is their sum.

Everyone on the floor knows this is wasteful. The first bracket off the laser is a finished bracket; there is no physical reason the brake cannot start on it. What is missing is not shop-floor sense, it is a way to tell the scheduler how many pieces the brake actually needs before it is worth starting, and how long the laser takes to make them.

Two numbers answer that: the transfer batch in pieces, and the per-piece time already in the routing.

The Formula, and a Worked Handoff

When a routing step carries a transfer batch, the scheduler computes when the downstream step may begin as:

setup + min(transfer batch, order quantity) × per-piece hours

Take a 100-piece turning job feeding a drill.

The upstream operation itself runs 52 hours end to end. Without streaming, the drill waits all 52. With it, the drill starts 12.5 hours in and the two operations overlap for the remaining 39.5 hours. That single handoff saves 15.5 hours, and the job's elapsed time compresses from roughly 52 hours to roughly 37.

Chain the same logic across cut, form, and weld and the compounding is where the real number comes from.

One-Piece Flow, Where the Cell Supports It

Set the transfer batch to 1 and you get the lean ideal: the downstream station starts as soon as the first good piece exists.

A 50-unit sub-assembly with 0.25 hours per unit and half an hour of setup makes its first piece at setup plus one cycle, which is 0.75 hours. The test station starts at 08:45 while soldering continues through piece 50. Serial, that job is 13 hours of soldering plus 5 hours of test, 18 hours total. Streamed, soldering finishes at 21:00 and test finishes at 13:45, roughly 13.75 hours, a 24 percent compression.

One-piece flow demands material handling that runs continuously, which is why it belongs in dedicated cells rather than across a whole shop. But the parameter is the same one; only the value changes.

The Physical Lag Between Stations

Streaming assumes pieces can move. Often they cannot move immediately, and the scheduler needs to know that too.

A transfer delay is a flat hour offset added on top of the streaming time, for the physical reality between stations: forklift travel, a cooling period before castings can be machined, incoming inspection. It is the right mechanism for a short handling lag.

Precision castings moving from foundry to machining show the shape: batch of 25, 0.8 hours per piece, one hour of setup, and two hours of cooling before the parts can be handled. The streaming time is 1 plus 20, which is 21 hours; the transfer delay pushes machining to 23 hours after the foundry starts. That two-hour cooling constraint is now in the plan rather than in somebody's head.

For multi-day transit, for instance parts going out to a coater and coming back, use transit days rather than transfer delay. Transit days are calendar or working-day aware and compose after the streaming calculation.

Continuous Processes Need a Different Model

Some fabrication operations have no meaningful piece count. A powder line, a wash and phosphate stage, a continuous coating booth: output is a stream, not a countable set.

Mark that work center as a continuous process and the scheduler ignores any transfer batch on steps routed there, using instead a start-to-start lag in hours. A lag of 1 on a spray operation running 08:00 to 12:00 lets the next operation start at 09:00, independent of quantity, per-piece time, or setup. Three hours of compression on a four-hour operation.

The two models are alternatives, not layers. When both are configured on the same step, the piece-count model wins on a discrete work center and the lag is ignored, which the anomaly report flags because the planner's intent is ambiguous. Clear one of the two.

What Composes With What

Order matters here, and getting it wrong is the most common surprise.

1. Queue time is applied to the upstream end first, as a shift-aware buffer.
2. Lot streaming replaces that result with the streaming time. This is the point of streaming: the downstream start can be earlier than the upstream end, so a value computed from the upstream end is exactly what has to be discarded.
3. Transit days are applied after, on top of whichever streaming model fired.

The middle step is the one that surprises planners. A queue time on the same step as a streaming parameter is discarded when streaming fires, because the streaming time is the successor's gate. If you want a handling lag on top of the streamed start, that is what the transfer delay is for. The anomaly report flags every routing step carrying both a lag and a queue time so you can confirm which behavior you meant.

Four Checks That Catch Misconfiguration

The anomaly report runs these automatically, and each corresponds to a real way this gets configured wrong.

That third one deserves a note. A routing carrying a batch of 100 because it was set for typical 200-piece runs, applied to a 30-piece rush order, would otherwise plan to wait for a piece that never exists. The cap prevents the deadlock; the check tells you it happened.

Streaming a Job That Is Already Running

Turning streaming on mid-job is handled rather than blocked. When the upstream step is in progress, the scheduler sums the actual piece counts logged day by day. If the accumulated pieces have already crossed the transfer batch, the downstream start is set from the crossing day rather than from a projection. If the threshold has not been crossed, the formula projects forward from the actual start.

The crossing time is taken conservatively as end of shift on the crossing day, because pieces trickling in through the day do not mean the batch was physically staged for movement at the moment the count ticked over. See shop floor tracking for how those piece counts arrive.

Turning It On Safely

Streaming is opt-in per routing step and defaults to off. Every step starts with a transfer batch of zero, the piece-count branch cannot fire on zero, and existing jobs schedule exactly as they did before. No global flag, no restart, no migration risk.

A sensible rollout: pick the one handoff where the wait is most visible, usually cut to form. Set a transfer batch that matches how your material handler actually moves parts, which is often a cart or a pallet quantity rather than a theoretical minimum. Add a transfer delay if there is a real physical lag. Reschedule and read the overlap on the Gantt. Then move to the next handoff.

The number to watch is not the operation's own duration, which does not change, but the downstream step's start date. That is where the lead time comes from.

For the category background, metal fabrication scheduling covers the fundamentals and the metal fabrication scheduling software page is the shorter evaluation read. If the real constraint is one machine setting the pace, scheduling a fab shop around its bottleneck is the companion, and if one operation genuinely needs two machines at once, running fabrication operations in parallel covers that. The industry fit guide maps the rest, and EDGEBIC is the product hub.

Ready to overlap your handoffs? Contact US for a demo and bring the job where the brake waits for the laser.