Two turrets can cut the same part at once — so the failure is coordination, not the toolpath
Nakamura-Tome built its reputation on twin-spindle, twin-turret machines: two opposed spindles (left and right) and two turrets (upper and lower), usually both with a Y-axis, coordinated across multiple channels. That architecture is what makes them fast — and it’s what makes them hard to program. On these machines, two turrets can cut the same part at the same time (pinch turning and pinch milling), motion can be superimposed across both spindles, the part transfers directly from the left spindle to the right under precise L/R synchronization, and the whole thing is choreographed with waiting M-codes. The geometry of any one cut is usually simple. What bites is the coordination — between turrets, between spindles, and across the channels that run them.
So the mistakes here aren’t “G-code errors” in the usual sense. They’re synchronization, pinch coordination, superimpose state, transfer phase, and channel/turret assignment — and on a machine where two turrets share a work zone around one part, any of them is a collision.
Main pain points
- Multi-channel synchronization and waiting M-codes. The turrets and spindles run as separate channels coordinated by waiting M-codes — used, for example, in the part-transfer cycles. Miss a wait in one channel and the channels desync: one turret advances while the other isn’t ready, deadlocking or driving into the shared zone.
- Pinch turn/mill coordination. When both turrets cut the same part simultaneously — one balancing the other’s cutting force — their positions and timing have to be coordinated exactly. Get it wrong and the two turrets collide, or the part deflects because the balancing cut isn’t where it should be.
- Superimpose / interpolative motion across spindles. With superimposed or interpolative functions on both spindles, a tool’s real motion is a composition of more than one axis — often across channels. Read one channel and you’ve seen half the motion; a wrong superimpose state produces compound motion the listing never showed.
- L/R spindle synchronization and direct transfer. The direct transfer from the left spindle to the right needs the two spindles matched in speed and phase (phase recognition is central to multitasking here). A transfer out of phase, or timed wrong, machines the second side out of position or crashes the handoff.
- Turret / channel / station assignment. With an upper and a lower turret (and multi-holders adding tools per station), assigning the wrong turret, channel, or station drives the wrong tool at the wrong place — valid code, wrong tool.
- Main vs sub coordinate systems. The right (sub) spindle uses its own work-coordinate system, with the Z direction reversed relative to the main. A wrong coordinate system or sign puts the sub-side features out of position.
Why these are serious on a twin-turret Nakamura
The defining feature — two turrets able to work one part at once — is also the defining risk. Two turrets sharing a small work zone around a single part is the highest inter-turret collision exposure there is, and it depends entirely on timing and coordination that no single channel’s listing contains. Add opposed spindles with direct transfer, superimposed motion, and multiple channels, and the machine is doing several coordinated things at every instant. When the coordination is right, cycle time collapses and the part comes off complete. When a wait, a pinch position, a superimpose state, or a transfer phase is wrong, it’s a collision or an out-of-position part — on medical, aerospace, and EV components where that’s expensive.
Why a listing and CAM simulation miss them
The failure is in the coordination, not one channel. A missing wait, a pinch position off, a superimpose state wrong, a transfer out of phase — none of these are bad geometry. They’re the relative timing and state of two turrets and two spindles running together, which a read-through of one channel can’t reveal.
CAM simulates its own plan. A CAM renders the toolpaths it generated with its assumptions about the channels, the pinch coordination, and the transfer — not the real posted ISO across all channels, with the actual waiting M-codes, superimpose functions, and L/R synchronization the control executes. The superimposed motion (a sum across channels) and the two-turret timing are exactly what a toolpath render of one channel’s plan doesn’t reproduce.
Catching these needs the real ISO executed across every channel the way the control coordinates them — pinch, superimpose, transfer and all — on a twin of the actual Nakamura.
Where Eureka G-Code fits
Eureka G-Code builds a digital twin of your specific Nakamura-Tome — twin spindles, upper and lower turrets (both Y), the B-axis on an NTJ/NTX upper turret, multi-holders — and executes the real ISO across every channel the way the control (Nakamura NT / Fanuc) runs it, composing the superimposed motion and coordinating the turrets and spindles in their real relative timing. So the coordination surfaces where you can fix it at a desk:
- A missing waiting M-code that desyncs the channels shows up as one turret advancing into the shared zone — a collision or near-miss on the twin.
- Pinch turn/mill coordination shows up truthfully, because both turrets run on the twin at once — a two-turret collision or a balancing cut in the wrong place is visible before it happens on the part.
- Superimposed / interpolative motion is composed the way the control composes it, so you see the tool’s true summed path across the spindles, and any collision on it.
- The L/R spindle synchronization and direct transfer run on the twin in their real phase and timing, so an out-of-phase transfer or a handoff collision shows up before the part is machined out of position.
- A wrong turret/channel/station or coordinate system shows up as the wrong tool or an out-of-position feature, checked against the model.
Because it reproduces the control and reads the real ISO regardless of origin — posted, conversational-exported, or hand-edited — the Nakamura program is verified as your machine will run it, across both turrets and both spindles, with collision, near-miss, overtravel, and part-vs-model in one pass, and a cycle time from the real program.
> Take a Nakamura program that pinch-cuts with both turrets and transfers to the right spindle — the part where the two turrets share the zone and the transfer is timed to the phase — and run the real ISO across every channel on a twin of your machine in Eureka G-Code. Watching the turrets and spindles coordinate the way the control will, before the machine does, is how a two-turret collision or an out-of-phase transfer gets caught at a desk.
FAQ
What are the most common programming errors on a Nakamura-Tome twin-spindle, twin-turret machine?
Multi-channel synchronization and waiting-M-code mistakes, pinch turn/mill coordination errors (two turrets on the same part), wrong superimpose/interpolative state across the spindles, L/R spindle synchronization and direct-transfer phase errors, wrong turret/channel/station assignment, and main-vs-sub coordinate-system mistakes. They’re coordination and state errors, not bad geometry.
What is pinch turning/milling and why is it risky to program?
Pinch cutting uses both turrets on the same part at once, one balancing the other’s cutting force. It’s fast, but it puts two turrets in a shared work zone whose positions and timing must be coordinated exactly — the highest inter-turret collision exposure on the machine, and one that a single channel’s listing can’t show.
Why can't CAM simulation catch these?
CAM renders the toolpaths it generated with its own assumptions about the channels, pinch coordination, and transfer — not the real posted ISO across all channels with the actual waiting M-codes, superimpose functions, and L/R synchronization. The coordination and the composed (superimposed) motion only appear when the real program runs across the channels on a twin.
Does Eureka G-Code handle superimpose and the L/R transfer?
Yes. It composes the superimposed/interpolative motion the way the control does and runs the L/R spindle synchronization and direct transfer in their real phase and timing on the twin, so compound-motion collisions and out-of-phase transfers show up before the machine runs.
Which Nakamura controls does it work with?
It reproduces the machine’s control behaviour — the Nakamura NT Smart X / NT-IPS layer on a Fanuc 31i-B (or older Fanuc) — and executes the real ISO across every channel, whether the program was posted, exported from conversational, or hand-edited.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Run the real ISO across both turrets and both spindles on a twin of your Nakamura — pinch, superimpose and transfer — before the machine coordinates them for real