The part dances around a horizontal spindle — so the program has to reflect the real orientation, not just the path
The GROB G350 doesn’t machine like a conventional VMC. The spindle is horizontal, and the part sits on a swivel-rotary table that tilts through 230° in the A’-axis and rotates 360° in the B’-axis — so the workpiece effectively dances around the spindle, reaching five sides in one setup, and even machining upside-down and into undercuts. That’s the machine’s great strength: negative angles, deep cavities, complex geometry, one clamping. It’s also what makes the G350 harder to program than a standard 3-axis mill. On this machine, the program has to reflect the real orientation of the part and the machine’s unusual kinematics — not just an idealized toolpath.
That shifts where the mistakes come from. The geometry is usually fine. What bites is orientation, kinematic transformation, interference within the swivel envelope, and a post that doesn’t respect the GROB axis logic. Get any of those wrong and the code can look perfect in CAM and be wrong — or a collision — on the machine.
Most frequent errors
- Wrong part orientation. Because the part swivels around the spindle, an error in the initial orientation or positioning propagates into everything after it — easily a collision, or a part machined mirrored from what was intended. The orientation isn’t a detail here; it’s the frame the whole program is built on.
- Kinematics / post mismatch. The G350 uses a particular axis arrangement, with the linear axes and the A’/B’ rotary table coordinated in the GROB way. If the post-processor doesn’t respect that logic, the program can be geometrically correct in the CAM system and still drive the machine wrong — because the CAM’s idea of the kinematics isn’t the machine’s.
- Interference and usable space not verified. The G350 has a declared interference envelope (the “tunnel” within which even long tools and large parts can swivel without collision) and real travel limits. If the programmer doesn’t check envelopes, fixturing, and the rotations, the part or fixture can swing into the machine, or run out of travel, as the table tilts and rotates.
- Inconsistent tool management and lengths. With high tool-capacity configurations and possible additional changers, a wrong tool length or a wrong selected tool becomes a dimension error or a collision — and on a machine that uses the full tool length in any axis position, length errors matter in every orientation.
- Improper use of undercuts and flips. The G350 is built for complex, undercut, upside-down work — but exactly those operations depend on the axis transformations being right. An undercut or a flip programmed against a wrong transform reaches the feature from the wrong side, or drives the tool where the model never intended.
Why the G350 is delicate to program
GROB builds the G350 around its unique kinematics and its ability to machine complex geometry — which is precisely what makes programming it less standard than a conventional VMC. The programmer has to think in terms of machine transformations, interferences, and real orientation, not just tool paths. The part’s pose relative to the horizontal spindle, the swivel of the A’/B’ table, the tunnel envelope, the full-tool-length reach in any position — all of it is machine state the program has to get right. On a machine designed to hit five sides, machine upside-down, and reach into undercuts in one setup, a small orientation or transformation error doesn’t stay small.
Why a listing and CAM simulation miss them
The failure isn’t in the toolpath geometry. Orientation, the GROB axis arrangement, the swivel envelope, the tool length applied in each pose — none of these change the toolpath the CAM drew. They change what the machine does with the posted program, in this kinematic. A toolpath render on the CAM’s own model has nothing to flag.
A post/kinematics mismatch is exactly what the CAM can’t self-check. If the post doesn’t respect the GROB kinematics, the CAM still simulates the motion it intended, on its own idealized machine — not the motion the real G350 will make from that posted code. The wrong orientation, the mirrored operation, the collision as the table swivels into the tunnel envelope: all of them live in the gap between the CAM’s plan and the machine’s execution.
Catching these needs the real program executed the way the installed control runs it, on a twin of the actual G350 kinematics — the horizontal spindle, the A’/B’ swivel table, the tunnel envelope and all.
Where Eureka G-Code fits
Eureka G-Code builds a digital twin of your G350 from its real kinematics — horizontal spindle, swivel-rotary table (A’ 230° / B’ 360°), the GROB axis arrangement, the interference envelope — and executes the real ISO the way the installed control (Heidenhain, Siemens) runs it, with the part in its real orientation. Because the twin is the real kinematics and it runs the code that reaches the control, the G350 pains surface where you can fix them at a desk:
- A wrong orientation shows up as the part reaching a feature from the wrong side, or a mirrored operation, on the twin — before it’s a collision or a scrapped part on the machine.
- A post/kinematics mismatch is exposed because the posted program is verified against the real GROB kinematics, not the CAM’s — so motion the machine will actually make differently than intended shows up as wrong motion or a collision on the twin.
- Interference and travel are checked against the real machine as the table swivels and rotates — collision, near-miss, and overtravel with the real part, fixture, and long tools inside the tunnel envelope.
- Tool lengths and selection are applied the way the control will, so a wrong length or wrong tool shows up as a dimension error or a collision in the orientation where it actually bites.
- Undercuts and flips are executed with the real axis transformations, so an operation reaching the wrong side, or a transform that wasn’t right, shows up as wrong motion or a machined result that doesn’t match the model.
Because it reproduces any kinematics and controller — including 5-axis simultaneous and the G350’s unusual arrangement — and reads the real ISO regardless of origin, the program is verified as your machine will run it, in the real orientation, with part-vs-model in the same pass. It’s the desk-side check that catches the orientation, transform, and envelope errors a toolpath simulation can’t.
> Take a G350 program that machines an undercut, or flips the part to reach five sides — the work where the orientation and the axis transforms have to be exactly right — and run the real ISO on a twin of your machine in Eureka G-Code. Watching the part swivel around the spindle in its real orientation, before the machine does it, is how a mirrored operation or a swivel-into-the-envelope collision gets caught at a desk.
FAQ
What are the most common programming errors on a GROB G350?
Wrong part orientation (the part swivels around the spindle, so an initial orientation or positioning error causes collisions or mirrored machining), a post/kinematics mismatch that’s correct in CAM but wrong on the machine, unverified interference and usable space within the swivel envelope, inconsistent tool lengths or wrong selected tools, and undercut/flip operations run against wrong axis transformations.
Why does the GROB kinematics cause a post-processor mismatch?
Because the G350’s axis arrangement — linear axes plus the A’/B’ swivel-rotary table, around a horizontal spindle — isn’t a standard VMC layout. If the post doesn’t respect that logic, the CAM simulates the motion it intended on its own model, while the real machine makes different motion from the posted code. The program looks right in CAM and is wrong on the machine.
How do orientation errors lead to mirrored machining or collisions?
Because the part’s orientation is the frame the whole program is built on. On a machine where the workpiece swivels around the spindle and can be machined upside-down, an initial orientation or positioning error propagates into every move — reaching features from the wrong side, mirroring an operation, or swinging the part into the machine.
Does Eureka G-Code reproduce the G350's kinematics?
Yes. It builds a twin of the real G350 kinematics — horizontal spindle, A’ 230° / B’ 360° swivel table, the GROB axis arrangement, and the interference envelope — and executes the real ISO the way the installed control runs it, so orientation, transformation, interference, tool-length, and undercut errors show up as collision, near-miss, overtravel, or a part that doesn’t match the model.
Can it verify undercut and upside-down machining?
Yes. It executes the real axis transformations on the twin, in the part’s real orientation, so an undercut or flip that reaches the wrong side or runs against a wrong transform shows up before the machine cuts it.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Run the real ISO on a twin of your G350 — and watch the part swivel around the spindle in its real orientation, before the machine does.