Turning, milling and a counter spindle in one setup — where the pains cluster around offsets, origins and orientation
The DMG MORI NTX 1000 is built to finish a complex part in a single setup: a main spindle and a synchronous counter spindle, a B-axis milling spindle for any-angle work, a Y-axis for off-centre machining, and an optional lower BMT turret for parallel machining at both spindles. DMG MORI is explicit that simple, fast programming reduces errors on this class of machine — because the errors that do occur cluster in the same few places, and they’re the places where one setup, two spindles, and a swivelling B-axis interact. Tool offsets that rotate with the head. Origins that differ between spindles. A post that doesn’t quite match the kinematics. A one-setup program that assumes the machine is already where it thinks it is.
None of these are dramatic on the page. They’re the quiet mismatches that pass a read-through and then machine a feature out of position, or drive the head where the program never pictured. Here are the pains that come up most on the NTX 1000, and how running the real posted program on a digital twin of the actual machine catches them first.
Main pain points
- Tool offsets that rotate or go inconsistent with the B-axis or sub-spindle. When the B-axis swivels or the counter spindle takes the part at a different orientation, the logical zeros shift, and wear offsets that were straightforward on one orientation get confusing on another. An offset that was right for one setup of the head is wrong once the head or the part is turned.
- Wrong coordinates or origins between the main spindle, the sub-spindle, and B-axis operations. With work referenced to the main spindle, the counter spindle, and a tilted B-axis plane, it’s easy to machine against the wrong origin — a feature cut in the right shape at the wrong place.
- A post-processor not aligned to the real machine kinematics. Especially when switching between turning, milling, and part transfers, a post that doesn’t exactly match the NTX’s kinematics outputs motion the machine interprets differently than intended.
- A wrong part- or spindle-handoff sequence. The transfer between the main and counter spindle, and the coordination of integrated operations, can create collisions or synchronization errors if the handoff sequence doesn’t match the machine state.
- Insufficient handling of the one-setup workflow. The program assumes everything is already in position and ready — the part transferred, the spindle oriented, the tool in place — but the machine side isn’t actually there yet, so an operation runs against a state that doesn’t exist.
Why these are serious on the NTX 1000
The NTX packs a main spindle, a counter spindle, a DDM B-axis head, a Y-axis and a lower turret into one compact envelope, running turning and milling — sometimes in parallel — complete in one setup. That concentration sharpens every pain above:
- An offset or origin error becomes a mis-positioned part, not a warning. The part is machined precisely — to the wrong place — and the scrap shows up at inspection, or after a batch.
- A handoff or one-setup assumption becomes a collision. With two spindles and a swivelling head sharing the space, an operation that runs before the machine is actually in the assumed state drives the head or a tool into the part or the opposing spindle.
- A kinematics mismatch is invisible until it moves. A post that’s slightly off the real kinematics produces plausible code that the machine executes differently — and on a 5-axis turn-mill, “slightly off” is a crash or a mis-cut.
On a machine bought to run complex parts complete in one setup, these are exactly the mistakes that turn a clean single-setup cycle into a stopped job or a scrapped part.
Why a listing and CAM simulation miss them
The failure isn’t in the toolpath the CAM drew. An offset that rotates with the B-axis, an origin referenced to the wrong spindle, a handoff timed against the wrong state — none of these change the geometry the CAM generated. They change what the control does with the posted code, on this machine, at this orientation. A toolpath render on the CAM’s own model has nothing to flag.
The post/kinematics gap is the whole point. When the pain is that the post doesn’t match the real kinematics, a simulation that runs on the CAM’s idealized kinematics can’t reveal it — it shows the motion the CAM intended, not the motion the real machine will make from the posted code. Only executing the posted program against the real kinematics exposes the mismatch.
Catching these needs the real posted ISO executed the way the control interprets it, on a twin of the actual NTX 1000 kinematics — turning, milling, transfers and all.
Where Eureka G-Code fits
Eureka G-Code builds a digital twin of your NTX 1000 from its real kinematics — main and counter spindle, DDM B-axis head, Y-axis, lower turret — and executes the real posted ISO the way the control (FANUC/MAPPS or SIEMENS) will. Because the twin is the real kinematics and it runs the code that actually reaches the control, the NTX pains surface where you can fix them at a desk:
- Offsets that rotate with the B-axis or sub-spindle are applied on the twin in the real orientation — tool-length and work offsets, tilted plane, tool-centre-point behaviour — so an offset that shifts a feature at a tilted orientation shows up as a collision, near-miss, or a part that doesn’t match the model.
- Wrong origins between spindles surface because the twin runs the program under the real main/counter/B-axis references — a feature cut against the wrong origin is machined out of position on the twin, visible against the CAD model.
- A post/kinematics mismatch is exposed because the posted code is verified against the real kinematics, not the CAM’s — motion the machine will make differently than intended shows up as wrong motion on the twin. (For a single clean chain, Eureka NC Coder can generate the ISO for the machine, which the twin then verifies.)
- A wrong handoff sequence shows up as a sub-spindle transfer collision or a synchronization error, executed the way the control coordinates it.
- A one-setup assumption that the machine isn’t actually ready for shows up as the operation running against the real state on the twin — before it runs against the real machine.
Because it reproduces the control and the kinematics and reads the real ISO regardless of origin, the NTX program is verified as your machine will run it — B-axis overtravel (the ±120° range), near-miss, part-vs-model and all — including the hand edits and offsets a CAM never saw.
> Take an NTX program that works both spindles with the B-axis head — the one-setup part where the offsets and origins shift with orientation and the transfer is timed to the sequence — and run the real posted ISO on a twin of your machine in Eureka G-Code. Watching the offsets, origins and handoff resolve the way the control will, before the machine does, is how a mis-positioned feature or a transfer collision gets caught at a desk.
FAQ
What are the most common programming pains on the DMG MORI NTX 1000?
Tool offsets that rotate or go inconsistent when the B-axis swivels or the counter spindle changes orientation, wrong coordinates/origins between the main spindle, sub-spindle and B-axis operations, a post-processor not aligned to the real kinematics, wrong part/spindle handoff sequences, and one-setup programs that assume a machine state that isn’t actually there.
Why do tool offsets get confusing with the B-axis or sub-spindle?
Because when the head swivels or the part is taken by the counter spindle at a different orientation, the logical zeros shift and wear offsets that were straightforward at one orientation apply differently at another. The offset can be right for one setup of the head and wrong once the head or part is turned.
Why doesn't CAM simulation catch a post/kinematics mismatch?
Because CAM simulation runs on the CAM’s own idealized kinematics and shows the motion it intended — not the motion the real machine will make from the posted code. Only executing the posted program against the real machine kinematics exposes a post that doesn’t match.
Can Eureka G-Code verify the sub-spindle handoff and one-setup sequence?
Yes. It executes the real posted ISO on a twin of the NTX 1000, reproducing the main/counter spindle and B-axis, so a mistimed handoff, a synchronization error, or a one-setup operation that runs before the machine is in the assumed state shows up as a collision, near-miss, or wrong motion before the machine runs.
Does it check offsets and origins against the actual part?
Yes. It applies the real tool and work offsets in the real orientation and compares the machined result against the CAD model, so an offset that rotated wrong or an origin referenced to the wrong spindle shows up as a feature machined out of position — even when nothing collided.
Next step
Request a demonstration on a digital twin of your own machine
Run the real posted ISO on a twin of your NTX kinematics — and see the offsets, origins and handoff resolve the way the control will, before the machine does.