Advance, grip, match, release — a four-step dance where one wrong beat drops the part or crashes the spindles
On any Swiss-type or multi-channel turning machine with a sub-spindle, the part transfer is the moment the whole cycle pivots on. The sub-spindle advances to meet the main, grips the part, matches speed and orientation, and the cut-off releases it — all in the right order, all timed against each other. Done right, it’s invisible: the part passes from front-side work to back-side work without a hiccup. Done wrong, it’s one of the most expensive crashes on the machine, because two spindles and a nearly-finished part are all in motion at once.
And it’s the failure mode almost nobody actually simulates — because it isn’t a toolpath. It’s a sequence of machine actions and spindle states, timed against each other, and that’s exactly what a toolpath-only check leaves out.
The ways the handoff goes wrong
Every one of these runs as valid code and lands the part correctly *most* of the time — which is what makes the transfer so easy to get subtly wrong:
- Cut-off before the grip is complete. The cut-off fires while the sub-spindle collet hasn’t fully closed. The part is released with nothing holding it — dropped into the machine, or flung.
- The sub advances into the main’s zone too early. The sub-spindle moves in to take the part while a main-side tool, or the main spindle face, is still where the sub is going. Spindle-to-tool or spindle-to-spindle collision.
- Speed or orientation mismatch at pickup. The two spindles aren’t synchronized in rpm (or C-axis orientation) at the instant of grip, so the part is wrenched — marked, bent, or torn out of the collet.
- A synchronization point missing between the sides. On a multi-channel machine, the transfer depends on the two channels reaching the handoff together. Miss the wait and one side proceeds while the other isn’t ready.
- Back-working starts before the transfer settles. A sub-side tool begins its operation before the part is fully seated and the main has cleared, meeting a surface — or the main — that should have been gone.
- A copied transfer block from another job. The proven handoff sequence lifted from a part with different lengths, different grip position, or different timing brings assumptions that no longer hold.
Why a listing and a toolpath sim both miss it
The transfer is resistant to both everyday checks for the same reason: **it lives in time and in machine state, not in geometry.
Reading the code doesn’t reveal it. The transfer is a sequence of M-codes and moves spread across one or two channels, each individually valid. Whether the grip completes *before* the cut-off, whether the sub arrives *after* the main-side tool has cleared — that ordering isn’t visible by reading lines in sequence, especially across two channels.
A toolpath simulation doesn’t run it. A toolpath render is about where cutting edges go. The transfer is mostly *non-cutting* machine action — spindle advance, collet open/close, speed match, cut-off — synchronized between two spindles. If the simulation doesn’t execute those machine actions with their real timing and the real spindle states, there’s nothing there to collide, and the drop or the crash simply doesn’t appear.
Catching it reliably needs the real program executed the way the control sequences it, with both spindles, the shared motors, and the handling actions modeled on a twin of the actual machine.
Where Eureka G-Code fits
Eureka G-Code reads the true ISO of the machine and executes it on a digital twin that includes multiple spindles and shared motors, running the synchronization commands the way the control will. Crucially, it simulates the handling sequence — bar feed, reposition, cut-off, transfer, eject, re-chuck — synchronized with the cutting cycles, not just the toolpaths. So the handoff runs on the twin in its real order and its real timing: the sub advancing, the grip closing, the speed matching, the cut-off releasing.
That’s what makes the transfer crash visible before it happens. The cut-off that fires before the grip completes, the sub that advances into an occupied zone, the missing sync between channels, the back-working tool that starts too early — all of them surface on the twin, along with the near-miss clearances between the spindles and tooling that are fine today and a crash the day something is set a millimeter closer. It applies equally to a single sliding-headstock Swiss and to a multi-channel turn-mill, because in both the transfer is the same timed dance.
> Take the job with your tightest transfer — the short part, the fast pickup, the back-working operation that starts the instant the sub has it — and run the real ISO on a twin of your machine in Eureka G-Code. Watching the handoff sequence the way the control runs it, before the spindles do it for real, is how the drop gets caught at a desk.
FAQ
Why does my part get dropped or marked during the sub-spindle transfer?
Almost always a timing problem in the handoff: the cut-off firing before the sub-spindle grip completes (dropped part), or the two spindles not matched in speed/orientation at pickup (marked, bent, or torn part). Every hole and diameter can be correct — the fault is in the sequence, not the geometry.
Why doesn't my CAM or toolpath simulation catch a transfer crash?
Because the transfer is mostly non-cutting machine action — spindle advance, collet open/close, speed match, cut-off — synchronized between two spindles. A toolpath simulation checks where cutting edges go, so it doesn’t execute those actions or their timing, and the crash or drop doesn’t appear.
Does Eureka G-Code simulate the cut-off and part handoff?
Yes. It executes multiple spindles and shared motors and simulates the handling sequence — bar feed, reposition, cut-off, transfer, eject, re-chuck — synchronized with the cutting cycles, so a mistimed handoff shows up on the twin before the machine runs.
Does this apply to both Swiss and multi-channel machines?
Yes. Any machine with a sub-spindle relies on the same timed handoff — a sliding-headstock Swiss or a multi-turret, multi-spindle turn-mill — and Eureka G-Code simulates the transfer on a twin of either.
Can it catch a transfer sequence copied from another job?
Yes. Because it runs the actual ISO on a twin of the specific machine and part, a copied handoff that carries the wrong grip position or timing shows up as a collision, drop, or near-miss when executed over the real geometry.
Next step
Request a demonstration on a digital twin of your own machine and controller.
Step through the real ISO on a digital twin — find the bug at a desk, not one near-miss at a time on the spindle.