On a multichannel machine, the hardest problems are sequence and configuration — not geometry
The Mazak Integrex i-300 ST is a multitasking, multichannel turn-mill: a main spindle and a second turning spindle (head 1 and head 2), a B-axis milling spindle, and a lower turret, coordinated across channels under a Mazatrol Smooth control. That integration is the point — turning, milling, and a spindle-to-spindle transfer, all in one setup — and it’s also where the pain concentrates. On a single-channel lathe, the programmer manages toolpaths. On the i-300 ST, the programmer manages machine logic: which head to start on, how and when to transfer, how the turret mirrors, whether the post matches the real spindle/head configuration, and how the turning, milling and transfer steps stay consistent across two spindles. The geometry is usually the easy part. The sequence and the configuration are what bite.
That’s why Mazak leans on early 3D visualization to catch these before the machine — because the failures here don’t look like bad geometry in a listing. They look like a wrong head order, a mirrored turret, a post that doesn’t match the machine, a transfer against a state that isn’t there.
Common pains
- Head order and transfer logic. Should the part start on head 1 or head 2? The process sequence and the transfer strategy across the two spindles are a genuine programming decision on the ST platform, and getting the order or the transfer state wrong means an operation runs against the wrong spindle, or the transfer happens before the machine is ready — a collision or a wrong-sequence stall.
- Turret mirror-image configuration. The lower turret works from the opposite side, so its X is mirrored — and a post or channel setup that gets the mirroring wrong misbehaves. A reported i300 post-processor issue surfaced as a 963 TURRET MIRROR IMAGE N/A error: a mismatch between the mirroring the program assumed and what the channel/turret supports. The result is an alarm, or motion mirrored to the wrong side.
- Post-processor mismatch to the spindle/head configuration. If the CAM output doesn’t match the machine’s actual spindle/head configuration — which channel owns which spindle, how the heads are addressed — the program hits control alarms or produces wrong motion. The toolpath can be right while the machine configuration it’s posted for is wrong.
- Tool setup and alignment that don’t match the real machine state. Integrex setup depends on accurate tool and machine alignment; when the assumed setup doesn’t match the real machine, correct-looking code turns into offset and motion errors.
- Operation sequencing on multitasking parts. The real challenge isn’t the shape — it’s keeping turning, milling, and transfer steps consistent across both spindles and heads, in the right order, with the right state at each handoff.
- The EIA/ISO layer underneath. When these parts are programmed in EIA/ISO (for 5-axis surfacing or CAM-posted work), the same pains show up as G-code: the wrong work-coordinate system (e.g. 5 vs G54) so the tool-length offset isn’t applied and every Z drives toward a crash, or a spindle-select / mill-mode M-code left in the wrong state.
Why the i-300 ST is tricky
The Integrex i-series is built for multitasking and high integration, so the programmer has to manage far more than toolpaths — machine logic, head orientation, transfer states, channel configuration. Two spindles and multiple tool carriers share one envelope and coordinate across channels; the mirroring, the head addressing, and the transfer sequence all have to match the real machine, not just the CAM’s idea of it. That’s why the hardest problems on this machine are sequence and configuration rather than raw geometry — and why a mistake in any of them is a collision or a control alarm mid-cycle, on a machine meant to finish complex parts complete in one hit.
Why a listing and CAM simulation miss them
The failure isn’t in the geometry the CAM drew. Head order, transfer state, turret mirroring, spindle/head configuration — none of these change the toolpath the CAM generated. They change what the control does with the posted program across this machine’s channels. A toolpath render on the CAM’s own model has nothing to flag.
A post/configuration mismatch is exactly what the CAM can’t self-check. If the post doesn’t match the real spindle/head configuration, the CAM still simulates the motion it intended, on its own idealized machine — not the motion the real i-300 ST will make from that posted code. The turret mirror-image mismatch, the wrong head addressing, the transfer against the wrong state: all of them live in the gap between the CAM’s plan and the machine’s execution.
Catching these needs the real posted program executed across every channel the way the control coordinates them, on a twin of the actual i-300 ST — both spindles, the turret, the mirroring, the transfer.
Where Eureka G-Code fits
Eureka G-Code builds a digital twin of your Integrex i-300 ST — main and second spindle, B-axis milling head, lower turret — and executes the real posted program across every channel the way the control will, reproducing the machine’s configuration: the head addressing, the turret mirroring, the transfer coordination. Because it runs the code that actually reaches the control on the real kinematics, the i-300 ST pains surface where you can fix them at a desk:
- A wrong head order or transfer state shows up as an operation running against the wrong spindle, or a transfer before the machine is ready — a collision or a synchronization error on the twin.
- A turret mirror-image mismatch shows up as motion mirrored to the wrong side, or the machine state the program assumed not matching the twin — before it alarms or crashes on the floor.
- A post/head-config mismatch is exposed because the posted program is verified against the real machine configuration and kinematics, not the CAM’s — so motion the machine will actually 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 sequencing error across channels shows up as the turning/milling/transfer steps colliding or desyncing when run in their real relative timing.
- The EIA/ISO coordinate and offset errors — the G54-vs-5 case where the offset isn’t applied and every Z crashes — show up as the tool driving in on the twin.
Because it reproduces the control behavior and the kinematics and reads the real ISO regardless of origin, the i-300 ST program is verified as your machine will run it — both channels, the mirroring, the transfer — with overtravel, near-miss, and part-vs-model checked in the same pass. It’s the desk-side complement to catching these early in 3D, before the spindle turns.
> Take an i-300 ST program that transfers between head 1 and head 2 — the two-spindle part where the sequence, the turret mirroring, and the transfer state all have to match the machine — and run the real posted program across every channel on a twin of your machine in Eureka G-Code. Watching the heads, the turret and the transfer coordinate the way the control will, before the machine does, is how a mirror-image mismatch or a wrong transfer state gets caught at a desk.
FAQ
What are the most common programming errors on the Mazak Integrex i-300 ST?
Head order and transfer logic (whether to start on head 1 or head 2 and how to transfer), turret mirror-image configuration mismatches (such as a 963 TURRET MIRROR IMAGE N/A post error), post-processor output that doesn’t match the machine’s spindle/head configuration, tool setup and alignment that don’t match the real machine state, and keeping turning, milling and transfer sequencing consistent across both spindles.
Should I start on head 1 or head 2?
That’s a real process-sequence decision on the ST platform, not a fixed rule — it depends on the part and the transfer strategy. The risk is getting the order or the transfer state wrong, so an operation runs against the wrong spindle or the transfer happens before the machine is ready. Running the real program on a twin lets you see the whole sequence before committing to it.
What causes a "963 TURRET MIRROR IMAGE N/A" error?
It points to a post or channel/mirroring mismatch — the mirroring the program assumed doesn’t match what the turret/channel supports, because the lower turret works from the opposite side with a mirrored X. The result is an alarm or motion mirrored to the wrong side. Verifying the real posted program against a twin of the actual machine configuration surfaces the mismatch first.
Why does a post-processor mismatch cause problems on the i-300 ST?
Because if the CAM output doesn’t match the machine’s real spindle/head configuration, the toolpath can be correct while the configuration it’s posted for is wrong — so the control alarms or the motion comes out wrong. A CAM simulation shows the intended motion on its own model; only executing the posted program against the real machine configuration exposes the mismatch.
Does Eureka G-Code verify Mazatrol or EIA/ISO?
It reads and executes EIA/ISO (G-code) programs — the format used for 5-axis surfacing and CAM-posted work on the Integrex — across every channel on a twin of the machine, so the head/transfer, mirroring, configuration, sequencing, and coordinate/offset pains are verified as the control will run them.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Run the real posted program across both channels on a twin of your i-300 ST — and see the heads, the turret mirroring and the transfer resolve the way the control will, before the machine does.