Turning, 5-axis milling, a lower turret and a second spindle. One setup, and one program to coordinate them.
The Mazak INTEGREX i-350H ST is a horizontal multi-tasking machine that combines turning with 5-axis milling, and adds a second spindle and a lower turret. A part can be finished complete in a single setup, with several tools working on it at the same time.
That is the value of the machine. It is also the reason a valid set of toolpaths is not yet a safe or efficient program.
What the i-350H ST gives the programmer to coordinate
The features that shape the NC program are:
- A main spindle and a second spindle, for transfer and back-side machining
- A milling spindle with B axis for 5-axis contouring, angled drilling and multi-surface machining
- A lower turret, optionally with rotary tools
- Balance cutting with the milling spindle and the lower turret, machining with two tools at the same time
- Automatic jaw changing on both spindles, with several sets of chuck jaws
- A MAZATROL SmoothAi control, with programs in conversational or ISO/EIA form
Each of these is an opportunity to shorten the cycle. Each is also a dependency between parts of the machine that share the same working area.
Valid code that runs wrong
On a machine with a milling spindle, a lower turret and a second spindle, the typical failure is not a syntax error. The NC program loads, the control accepts it, and the result is still wrong:
- the milling spindle and the lower turret reach the same zone at the same moment
- the B axis swings the milling head while the lower turret is still close to the part
- the second spindle picks up the part before the cut-off is complete
- a balance cut starts on one tool before the other is in position
- one side sits waiting for the other far longer than necessary
- a hand edit made at the machine never returns to the CAM model, so the next revision reintroduces the original problem
None of these produce an alarm at load time. They show up as a crash, a damaged part, or a cycle time nobody can explain.
Why the usual workflow misses it
A conventional workflow for a machine like the i-350H ST looks like this:
CAM > individual operations > postprocessor > manual synchronization > manual edits > prove-out on the machine
Three weaknesses stand out.
The postprocessor is not a programming layer. It converts operations into NC code. It does not, by itself, decide how work should be divided between the milling spindle, the lower turret and the second spindle, where each should wait for the others, or how the part should be handed over.
Manual refinement becomes part of the process. Synchronization and handover logic are added by hand after posting. That work is repeated for every part and depends on the individual programmer.
Simulation usually runs before the postprocessor. CAM simulation shows what the CAM system intended to produce. It does not see waiting codes, macros, offsets or hand edits added afterwards. Toolpath simulation tells you what the CAM system intended to produce. G-code simulation tells you what the CNC machine has actually been instructed to do.
Where Eureka NC Coder fits
Eureka NC Coder is the layer between your existing CAM and the final NC program. It is not a replacement for CAM, and it does not require you to change CAM platform.
The division of work is straightforward:
- CAM creates the machining operations, in the system your team already uses.
- NC Coder assigns operations to the machine’s channels, manages synchronization and part transfer, and applies the machine-specific postprocessing logic.
The result is a multi-channel NC program in which waiting points, handovers and channel assignments are generated in a controlled way rather than typed in afterwards. Because NC Coder works from the operations rather than from a single postprocessor, it applies to the CAM systems already used for multi-channel work, including Fusion 360, Mastercam, Siemens NX, PTC Creo and hyperMILL.
Where Eureka G-Code fits
NC Coder produces the program. Eureka G-Code checks the program the machine will actually run.
Eureka G-Code simulates the final, post-processed NC program on a digital twin of the i-350H ST and its control. It interprets the real program, the machine kinematics, the controller logic, macros and variables, work and tool offsets and machine limits, and runs all channels in their real relative timing. That is what exposes the problems that only exist when the parts of the machine interact:
- collisions and near-misses between the milling head, the lower turret, the spindles and the chucks
- a B-axis move that swings the milling head into the lower turret zone
- a second spindle closing on the part at the wrong moment
- axis limit violations
- material removal errors, checked by comparing the simulated part with the design model
Balance cutting and 5-axis milling: powerful, and unforgiving
Balance cutting with the milling spindle and the lower turret puts two tools on the part at once, which removes material faster and reduces deflection. 5-axis milling with the B axis removes secondary setups.
Both remove the safety margin that a sequential program enjoys. In balance cutting, two tools depend on each other’s timing. With a tilting milling head, the tool position depends on the kinematics of the entire head, not only on the programmed coordinates. A small error is not a wasted second, it is a collision on a machine that costs a great deal to repair.
Verifying these moves on a digital twin that reproduces the real machine kinematics, before the program runs, is what allows them to be used with confidence.
It is also about cycle time
Once the whole sequence is visible, the question changes from “Will the program work?” to “Is this the best way to run the machine?” You can see:
- the lower turret or second spindle sitting idle while the milling spindle finishes
- waiting points that could be moved earlier
- operations that could be overlapped or balanced instead of run in sequence
- a part-transfer sequence that spends more time waiting than cutting
On a machine of this class, minutes per part are at stake. They can only be found when the full multi-channel sequence can be seen and measured before it runs.
The M32 workflow, end to end
CAM (Fusion 360, Mastercam, NX, Creo, hyperMILL)
Machining operations
↓
Eureka NC Coder
Channel assignment
Synchronization
Part transfer
Machine logic
Postprocessing
↓
Final multi-channel NC program
↓
Eureka G-Code
Digital twin of the i-350H ST and its control
Collision detection
Limits
Material removal
Complete multi-channel sequence
↓
Mazak INTEGREX i-350H ST
The program that is generated is the program that is simulated, and the program that is sent to the machine.
Running a Mazak INTEGREX or another multi-channel mill-turn machine? Request a demonstration on a digital twin of your own machine and controller, and see how Eureka NC Coder and Eureka G-Code connect your CAM, synchronization, postprocessing and G-code simulation in one workflow.
FAQ
Can I program a Mazak INTEGREX i-350H ST from my existing CAM system?
Yes. Eureka NC Coder sits between the CAM system and the final NC program, so you keep the CAM you already use. It takes the machining operations, assigns them to the machine’s channels, manages synchronization and part transfer, and produces the machine-specific multi-channel NC program.
Why is the i-350H ST harder to program than a conventional lathe or machining center?
It combines a milling spindle with B axis, a lower turret and a second spindle in one working area. The difficulty is not any single toolpath but coordinating the parts of the machine: waiting points, part handover, balance cutting and clearance between the milling head and the lower turret.
Is a postprocessor enough for multi-tasking machine programming?
A postprocessor converts operations into NC code, but it does not normally distribute operations across channels or design the synchronization between them. That work is often done by hand after posting, which is where errors and lost cycle time come from. NC Coder is designed to handle that step.
What does Eureka G-Code check on the i-350H ST?
It simulates the real post-processed NC program on a digital twin of the machine and its control: kinematics including the B axis, controller logic, macros and variables, work and tool offsets, machine limits, collisions between the milling head, lower turret, spindles and chucks, timing across all channels, and material removal.
Why simulate the NC program instead of the CAM toolpaths?
CAM simulation runs before the postprocessor and before any manual edits. It shows what the CAM system intended. Simulating the final NC program shows what the machine has actually been told to do, including synchronization codes and hand modifications.
Can simulation help with balance cutting?
Yes. Balance cutting depends on precise timing between the two tools. Running all channels together on the digital twin shows whether both tools are in position when the cut starts, and whether they clear each other throughout.
Can simulation help reduce cycle time on the i-350H ST?
Yes. With all channels visible in one simulation, idle time, late waiting points and inefficient part-transfer sequences become easy to spot. The program can be rebalanced offline before it runs on the machine.
Do I need to change my CAM system to use NC Coder?
No. NC Coder works with the CAM systems already used for multi-channel work, including Fusion 360, Mastercam, Siemens NX, PTC Creo and hyperMILL.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Verify the real ISO program — on a digital twin of your sliding-headstock machine, before the first bar.