Skip to main content Scroll Top
Nomura NN-20J3: Programming a Compact Swiss-Type Lathe with Overlapped Front and Back Machining from Your Existing CAM with Eureka NC Coder
Program the Nomura NN-20J3 from your existing CAM. Synchronize front and back machining, part transfer and both spindles, then verify the final G-code.
Blog & Articles

While one side is cutting, the other side is already working. The program has to know it.

The Nomura DS NN-20J3 is a 20 mm Swiss-type lathe with a main spindle and a sub-spindle, both with C axes, and live tooling on both sides of the part. It is a compact, flexible machine used for precision parts in fields such as medical, aerospace and electronics.

Its productivity comes from overlapping. Front working and back working run at the same time, and the part is handed from one spindle to the other in the middle of the cycle. That is also where the programming effort goes.

What the NN-20J3 gives the programmer to coordinate

The features that shape the NC program are:

  • A main spindle and a sub-spindle, both with C axis, running up to 10,000 rpm on the main side
  • Front-side tooling on the main spindle: OD tools, static front and back drilling stations, and live cross drill and mill spindles
  • Back-side tooling on the sub-spindle: static back drilling tools, OD tools, live cross drill and mill tools, and live off-center drill and mill tools
  • Part transfer between the spindles, with cut-off and back working
  • Guide bush operation for long, slender parts

Each of these is an opportunity to shorten the cycle. Each is also a dependency that the program must express correctly.

Valid code that runs wrong

On a machine that works front and back at once, the typical failure is not a syntax error. The NC program loads, the control accepts it, and the result is still wrong:

  • a waiting point is missing or misplaced, so one side runs ahead of the other
  • the sub-spindle closes on the part before the cut-off is complete
  • a sub-spindle tool and a main-side tool reach the shared zone at the same moment
  • the part transfer works, but only after waits that a better sequence would have avoided
  • the back-side program assumes a stock position that the front-side program has changed
  • 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 scrapped bar, or a cycle time nobody can explain.

Why the usual workflow misses it

A conventional workflow for a machine like the NN-20J3 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 decide how work should be divided between the main side and the sub-spindle side, where each side should wait for the other, 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 for the NN-20J3. 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 for the Nomura.

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 Swiss-type work, including Fusion 360, Mastercam, Siemens NX, PTC Creo and hyperMILL.

Where Eureka G-Code fits

NC Coder produces the program. Eureka G-Code verifies the program the machine will actually run.

Eureka G-Code simulates the final, post-processed NC program on a digital twin of the NN-20J3 and its Mitsubishi control. It interprets the real program, the machine kinematics, the controller logic, macros and variables, work and tool offsets and machine limits, and runs both sides in their real relative timing. That is what exposes the problems that only exist when the two sides interact:

  • collisions and near-misses between main-side tools, sub-spindle tools and the spindles
  • a sub-spindle closing on the part at the wrong moment
  • axis limit violations
  • a back-working operation that assumes the wrong part position after transfer
  • material removal errors, checked by comparing the simulated part with the design model

In practice: from handwritten G-code to a verified workflow

Stingray Surgical Products, a family-run manufacturer of electrosurgical instruments in Boca Raton, Florida, makes tiny titanium, stainless steel and advanced plastic parts, some so delicate that they are finished under a microscope. For years the company programmed its complex Swiss machines with handwritten G-code. When it moved into 8-axis Swiss machining for high-value parts, the stakes rose with the complexity: with micro components, one wrong line of code can be costly.

Before NC Coder, the workflow was to generate code fragments in Fusion or HSMWorks and piece them together by hand. With NC Coder, the toolpaths are brought in from Fusion 360, assigned to channels and simulated before anything touches the machine. The company’s president, Brian McBrinn, puts the result simply: “What I see in Eureka Simulation is exactly what happens on the machine.”

The results Stingray reports:

  • Fewer revisions. Programs that used to go through around ten revisions before production now need one or two.
  • Fewer trips to the machine. The programmer no longer goes back and forth between the office and the shop floor to prove out the program.
  • Problems found offline. The simulation also revealed that one of the company’s machine axes was off by a full millimeter, an issue the machine’s manufacturer had missed.
  • A safer machine. On a machine worth hundreds of thousands of dollars, avoiding a crash is reason enough.
  • A smoother transition for the team. Younger employees already knew Fusion, so they could move into CNC programming without learning a new CAM system, and training took a few hours.

Read the full story: Stingray Surgical Products meets Eureka NC Coder.

Small parts, small margins

A 20 mm machine makes small parts, often in demanding materials and for demanding industries. Features are small, tolerances are tight and there is little room for a timing error between the two sides.

Front and back operations that overlap are exactly where a program that looks correct can still be wrong: the geometry is right, the sequence is not. Verifying the complete sequence on a digital twin, before it runs on the machine, is what lets overlapped machining 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:

  • one side sitting idle while the other finishes
  • waiting points that could be moved earlier
  • back-side operations that could start sooner
  • a part-transfer sequence that spends more time synchronizing than cutting

For small parts made in volume, seconds recovered per cycle add up. They can only be found when the full sequence can be seen and measured before it runs.

The NN-20J3 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 NN-20J3 and its Mitsubishi control
  Collision detection
  Limits
  Material removal
  Complete sequence, front and back

↓
Nomura NN-20J3

The program that is generated is the program that is simulated, and the program that is sent to the machine.

Running a Nomura NN-20J3 or another multi-channel Swiss-type 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 Nomura NN-20J3 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 NN-20J3 harder to program than a conventional lathe?

It works the front and the back of the part at the same time, with a main spindle, a sub-spindle and live tooling on both sides. The difficulty is not any single toolpath but coordinating the two sides: waiting points, part handover and clearance in the shared zone.

Is a postprocessor enough for multi-channel Swiss-type 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 NN-20J3?

It simulates the real post-processed NC program on a digital twin of the machine and its Mitsubishi control: kinematics, controller logic, macros and variables, work and tool offsets, machine limits, collisions between main-side tools, sub-spindle tools and spindles, timing across both sides, 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.

Does this also apply to the NN-20J3 variants with B axes?

The same approach applies. Variants with B axes on the main spindle or on both spindles add angular machining and more kinematics to verify, so the digital twin should be built for the exact configuration of your machine.

Can simulation help reduce cycle time on the NN-20J3?

Yes. With both sides 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.

Request a free demonstration

Related Articles

Debug Multi-Channel & Parametric G-code the Way Developers Debug Code

Single-block on a multitasking machine is defusing a bomb with the timer running. Step through the real G-code off-machine on a digital twin — watch where a variable actually drives the tool, follow subprogram flow across channels — and find the bug at a desk. Eureka G-Code runs and edits the true G-code on a twin of your machine. Request a demo on a twin of your machine.

Verifying Probing & In-Process Measurement Before the Machine Runs It

A probing cycle sets offsets at runtime and changes what every later move does — yet it’s the part of the program almost nobody simulates, because a toolpath render doesn’t run it. Eureka G-Code executes probing cycles on a digital twin of your machine, and checks pre-holes for tapping too. Request a demo on a twin of your machine.

Feedrate Optimization with Eureka Chronos

Cut cycle time, extend tool life and save energy by re-modulating feedrates based on real tool engagement. Optimize G-code programs offline

Reducing Scrap Through Offline G-Code Verification

Most scrap isn’t a crash—it’s a valid program making an out-of-spec part. Compare real ISO simulation to CAD models to catch shifted offsets offline

Rotary Axis Programming Mistakes

How shortest-path rollover, degrees/min feed errors, and C-axis wind-up cause 5-axis crashes. Verify multi-axis kinematics and TCP cycles on a digital twin.

The Programming Pains of the Bumotec s191 / 191neo

Master Bumotec s191 process orchestration across turning, milling, and grinding. Discover how digital twin simulation prevents costly first-cut errors.

Reusing Old CNC Programs on a Horizontal Machining Center

Moving legacy CNC programs to new horizontals risks costly crashes. Learn what breaks in G-code, offsets, and M-codes, and how to verify them

The Programming Pains of the GROB G350

Master horizontal spindle kinematics, A’/B’ swivel table logic, and undercut operations on the GROB G350 with Eureka G-Code digital twins.

Verifying Programs on a Large Vertical Lathe (Pietro Carnaghi AP80)

Prevent slow, costly collisions on large vertical lathes like the Pietro Carnaghi AP80. Verify part zero, attachments, and G-code before production.

Single-Block Threading (G32): The Mistakes That Scrap the Thread or Crash the Tool

G32 cuts a thread one pass per block — every pass, infeed, chamfer and pull-out is on the programmer, and the feed must match the pitch in sync with the spindle. It’s valid code that scraps the thread or crashes the tool when a value is off. Eureka G-Code runs the real G32/G92/G76 passes on a digital twin of your machine

How to Verify G83 Cycles on Any CNC Machine

Why G83 peck depths, G98/G99 retracts, and control-specific behaviors cause crashes and scrap. Simulate real canned cycles on a digital twin offline.

Subprogram and Macro Call Errors

How wrong call numbers, missing M99 returns, and carried modal states cause program flow crashes. Verify nested M98/M99 call structures on a digital twin

Eureka Cloud: Distributed NC Verification on Your Own Servers — a Private Cloud, Not the Public One

Eureka Cloud turns every PC on your network into a simulation agent, so a whole shift’s worth of NC programs is verified overnight, in parallel — cleared or flagged before they reach the machine. And despite the name, it runs on your own servers: a private cloud, so your NC programs, geometry and IP never leave your network. Highly customizable, it integrates with your CRM, MES or other apps through APIs and scripting, and can automate post-processing, simulation, and feedrate optimization end to end. Request a demo

What Should Every CNC Safe Start Block Include?

Ask any experienced machinist ‘what’s in your safe start?’ and you’ll get a line like G17 G40 G49 G80 G90 — the block that forces the control into a known state so your program doesn’t inherit leftover modal settings from whatever ran before.

Citizen Cincom M32: Programming a Multi-Channel Swiss-Type Lathe from Your Existing CAM with Eureka NC Coder

Program the Citizen Cincom M32 from your existing CAM. Synchronize channels and part transfer with NC Coder, then verify the final G-code on a digital twin.

Verifying Deep-Hole Drilling & Milling Programs for Molds (IMSA / CHETO)

Deep-hole drilling for injection and die-casting molds (IMSA, CHETO) isn’t just a toolpath: depth vs diameter, chip evacuation, guide bushings, special cycles and process monitoring all matter

The Programming Pains of the DN Solutions SMX 2100ST

Master B-axis signs, sub-spindle logic, and Fanuc cycles on the SMX 2100ST. Verify actual ISO code with Eureka G-Code digital twins

Absolute vs Incremental Programming Errors (G90/G91)

How G90/G91 modal errors, lathe U/W mix-ups, and subprogram mode shifts cause wild moves and crashes. Verify real ISO reference frames on a digital twin

Okuma MULTUS U4000 2SW: Programming Upper Turret, Lower Turret and Opposing Spindles from Your Existing CAM with Eureka NC Coder

Meta description: Program the Okuma MULTUS U4000 2SW from your existing CAM. Synchronize the B-axis head, lower turret and opposing spindles, then verify the final G-code.

Swiss-Type / Sliding-Headstock G-Code Simulator

A digital twin of your sliding-headstock (Swiss-type) machine that reads the real ISO code and proves it out before the bar runs. Any controller, any kinematics

Your CAM Simulation Doesn’t Read the Real G-code

CAM simulation checks the toolpath it generated. The machine runs the posted G-code — with constructor cycles, macros, variables, subprograms and probing the CAM never modeled. On multi-channel and sliding-headstock machines, that gap is where the crash lives. Eureka G-Code simulates the true G-code on a digital twin of your machine. Request a demo on a twin of your machine.

Plane Selection Errors (G17/G18/G19)

Why wrong plane selection causes arcs to cut into parts and canned cycles to plunge off-axis. Verify modal G17/G18/G19 plane state on a digital twin.

Why CAM Verification Misses G43 Errors

CAM simulations assume correct offsets and miss wrong H numbers or missing G43 codes. Verify runtime control offsets and G49 states on a digital twin

The Programming Pains of the DMG MORI NTX 1000

On the DMG MORI NTX 1000, the recurring pains cluster around tool offsets that rotate with the B-axis or sub-spindle, wrong origins between the main and counter spindle, a post that doesn’t match the real kinematics, and one-setup programs that assume a machine state that isn’t there. Eureka G-Code runs the real posted ISO on a digital twin of the actual kinematics. Request a demo on a twin of your machine.

An Enterprise Workflow for NC Program Validation

Standardize program verification across plants with automated, on-premises batch simulation. Eliminate bottlenecks and ensure no G-code runs unverified

Multi-Channel Turn-Mill Simulator

A digital twin of your multi-channel turn-mill that reads the real ISO of every channel — synchronization, multiple spindles, sub-spindle transfer, constructor cycles and hand edits included — and proves it out before the turrets move. Any controller, any kinematics, no axis limit. Request a demo on a twin of your machine.

Eureka Chronos in Production: Real Cycle-Time Results Across Molds, Castings and 5-Axis Parts

Feedrate optimization isn’t a lab trick. Across real production — hardened-steel molds, aluminum castings, precision components, large gantry work and continuous 5-axis parts like impellers — Eureka Chronos has cut cycle time by roughly 6–26% while holding surface quality and dimensional accuracy, with tool wear reduced or unchanged. And it needs no material or tool libraries to do it. Request a demo.

Overtravel on Rotary and B-Axis: The End-of-Travel Crash CAM Doesn’t Reach

A move that’s geometrically fine can still drive a rotary or B-axis into its travel limit — and because it isn’t a geometry error, a toolpath simulation doesn’t catch it. Eureka G-Code checks overtravel and near-miss against your real machine’s travels on a digital twin. Request a demo on a twin of your machine.

Lights-Out on a Bar: What Must Be Crash-Proof Before You Leave

Unattended bar work turns a crash from one scrapped part into a stopped run and a damaged machine. Here’s the checklist of what has to be verified before you walk away — and how Eureka Cloud runs those simulations overnight, in queue, so the whole night’s programs are proven before the lights go off. Request a demo on a twin of your machine

Wait Codes and Sync Points: The Multi-Channel Mistake That Crashes Two Turrets

On a multi-channel turn-mill, each channel’s program can be flawless and the machine still crashes — because the collision lives in the timing between channels, not in any one line. Eureka G-Code simulates the real ISO of every channel, synchronization commands included, on a digital twin of your machine, so wait-code mistakes surface before the turrets meet. Request a demo on a twin of your machine.

Verifying Aerospace Complex Parts — Blisks, Casings & 5-Axis Interference

Aero-engine blisks and casings push machining to the edge: tough titanium and superalloys, thin deformable parts, and airflow passages between blades so narrow the tool can interfere on a five-axis move

The Retract That Crashes After a Coordinate Rotation

After a coordinate rotation or a tilted working plane, ‘up’ isn’t machine-up anymore — so a retract programmed in the rotated frame, or with the wrong axis order, drives the head straight into the part instead of clearing it. It’s a crash during what should be a safe disengage. Eureka G-Code runs the real ISO — rotation and kinematics included — on a digital twin. Request a demo on a twin of your machine.

The Part Transfer Nobody Simulates: Main-to-Sub-Spindle Handoff Crashes

The main-to-sub-spindle handoff is a timed dance — advance, grip, match, release before cut-off — and getting it wrong drops the part or crashes the spindles. It’s timing, not geometry, so a listing and a toolpath sim both miss it. Eureka G-Code executes the real transfer on a digital twin of your machine. Request a demo on a twin of your machine.

Head-Change Programming on Large PAMA Boring Machines (Speedram / Speedmat)

Verify automatic head changes, kinematic transforms, and large-envelope ISO code on PAMA Speedram and Speedmat machines with Eureka G-Code

Mazak INTEGREX i-350H ST: Programming Milling Spindle, Lower Turret and Second Spindle from Your Existing CAM with Eureka NC Coder

Meta description: Program the Mazak INTEGREX i-350H ST from your CAM. Synchronize the milling spindle, lower turret and second spindle, then verify the final G-code.

The Programming Pains of the Mazak Integrex i-300 ST

Prevent head order errors, turret mirror mismatches, and EIA/ISO sequence crashes on the Mazak i-300 ST with Eureka G-Code digital twins

The Most Common Multichannel Programming Errors on an Okuma Multus U4000

Discover common multichannel sync errors on the Okuma Multus U4000. Prevent crashes and deadlocks by simulating real ISO code on a digital twin.

Incorrect Safe Z Positions

Why safe Z heights set below clamps or raised features cause rapid collisions between operations. Verify real ISO rapids over actual fixtures on a twin

DVF 5000 Gen 2: The Hidden 5-Axis Setup Limits That Affect Real Production

On paper the DVF 5000 Gen 2 gives you a big envelope and full 5-face access. In real setups it’s tighter: at tilt the reach shrinks, the fixture and trunnion interfere, the tool setter gets in the way, and the table sits off-center from the spindle. That gap between brochure envelope and usable envelope is where setups crash.

Thread Milling by Helical Interpolation

Why rewrite the same helical interpolation code for every thread size when a macro can generate it from a few parameters? Eureka G-Code simulates the real G-code with macro expansion and helical interpolation, before you cut

The Programming Pains of Nakamura-Tome Twin-Spindle, Twin-Turret Machines

Avoid two-turret crashes on Nakamura-Tome machines. Learn to verify pinch turning, superimpose modes, and waiting M-codes across channels.

Swiss-Type (Sliding-Headstock) G-Code: The Traps That Don’t Exist on a Conventional Lathe

A Swiss-type lathe flips the geometry, packs the tool zone, and lets one tool do many jobs — so the mistakes that scrap parts and crash gang tools are ones a conventional-lathe programmer has never had to think about.

The Programming Pains of the Citizen Cincom L20

On a Citizen Cincom L20, the pains are multi-system ($1/$2/$3) synchronization, the G600-series machining-mode calls that govern gang, front, back and superimposed work, wait codes that must appear in every system, and Z-shift and guide-bushing traps. Eureka G-Code runs the real ISO across every system on a digital twin of the machine. Request a demo on a twin of your machine.

Your Cycle Time Is a Guess: Accurate Machining Time on Multi-Channel & Swiss

CAM cycle-time math is optimistic on any machine — and on parallel channels with synchronization waits it’s worst of all, because the waits and the interleaving aren’t in the toolpath. Eureka G-Code computes cycle time from the real ISO on a twin of your machine, and Eureka Chronos optimizes it. Request a demo on a twin of your machine

The Programming Pains of the Nomura NN-20J3

Prevent sub-spindle handoff crashes, front/back side errors, and XB B-axis mismatches on Nomura NN-20J3 Swiss machines with Eureka G-Code.

Digital Twin Verification of Complex Macro Programs

Static checks miss parametric logic errors. Execute Macro B variables, IF/WHILE loops, and family-of-parts math on a digital twin to catch crashes off-line.