One pass per line — every pass, infeed, chamfer and pull-out is on you
Cutting a screw thread with G32 is the most manual, most controllable, and most unforgiving way to thread on a lathe. G32 is a single-block threading command: each line cuts one pass of the thread, along a straight or tapered path, with the axis feed synchronized to the spindle encoder so the tool tracks the exact pitch. It gives you full control — which is exactly why it gives you so many ways to be wrong. Unlike the threading cycles, G32 doesn’t calculate anything for you. Every pass, every increment of depth, the lead-in chamfer, the pull-out at the end — you program all of it, by hand, one block at a time.
That control is why G32 stays the tool of choice for custom pitches, tapered threads, multi-start threads, and lead-critical profiles behind shoulders — the work that lands on Swiss-type and turn-mill machines. And it’s why a threading program made of G32 blocks is full of plausible-looking numbers, any one of which quietly ruins the thread or drives the tool into a shoulder.
G32 vs the cycles — what "single-block" actually means
It helps to place G32 against the two cycles it’s often confused with, because the difference is the amount of work left to the programmer:
- G32 — single-block threading. One pass per block. The programmer writes each pass and computes each infeed. The feed word carries the pitch, synchronized to the spindle. There’s no automatic return at the end of the pass, and chamfering must be programmed explicitly.
- G92 — single-block threading cycle. One block performs a whole pass — approach, cut, retract, return — so you repeat it with a changing depth per pass. Simpler than G32, less flexible.
- G76 — multiple-repetitive threading cycle. A compound cycle that runs all the passes automatically, with infeed angle, depth reduction per pass, spring passes, and taper handled for you.
G32 is the one with nothing automated. Its power is that taper, lead and path can be controlled continuously, pass by pass; its risk is that everything a cycle would compute is now a number you typed.
The mistakes that ride along with G32
Each of these is valid code. Each cuts a thread. The thread is just wrong — or the tool is gone:
- Feed doesn’t equal the pitch. The feed word is the lead. Off by a decimal or a units slip and you cut a thread of the wrong pitch — a part that gauges as scrap.
- Spindle RPM changes between passes. G32 synchronizes to the spindle so repeated passes follow the same helix — only if the RPM is identical every pass. Change it and the passes no longer line up on the same thread, tearing it.
- G32 left modal. G32 is modal and has no automatic position return. Leave it active into the next move and that move is still a synchronized threading feed — somewhere you never meant to thread.
- Missing chamfer or pull-out. With no automatic retract, a pass that isn’t given an explicit chamfer or exit drives straight into the shoulder at the end of the thread.
- Wrong manual infeed per pass. Too aggressive a depth increment overloads the threading insert and snaps it; too shallow or a wrong final depth leaves the thread under-formed. Broken tool / scrap.
- Lead error near shoulders. As a pass ends and the axis decelerates while the spindle keeps turning, a lead step can appear near the block boundary — which is why lead-critical threads are chained carefully. Get the chaining wrong and the thread has a visible step.
- Multi-start or taper set wrong. A start offset that isn’t exactly half the pitch (for a two-start), or a taper value off, produces a thread that’s geometrically wrong in a way no single line reveals.
Why a listing and a CAM sim miss it
The code is valid. None of the above is a syntax error. Every G32 line loads and runs; the thread comes out — just at the wrong pitch, wrong depth, or into the shoulder. The mistake is in whether the value is right and whether the control executes the synchronized pass the way you assumed.
The thread form and the sync are runtime. Whether the feed truly matches the pitch, whether the passes land on the same helix, whether a modal G32 carries into the next move — these are properties of the program executing on the control, synchronized to the spindle, not of the text on the page.
A CAM simulation shows its own plan. If the thread came from CAM, the CAM likely posted its own thread cycle and simulates that, at the pitch it intended — so it looks right. It doesn’t reproduce the real G32 passes the control will run, the spindle synchronization, the manual chamfer and pull-out, or a hand edit made at the machine. And a toolpath render doesn’t turn the spindle in sync with the feed, so the one thing that defines threading isn’t in the picture.
Catching it needs the real ISO — the actual G32 (or G92, or G76) passes — executed the way the control runs them, spindle synchronization included, on a twin of the machine.
Where Eureka G-Code fits
Eureka G-Code reads and executes the true ISO — G32 single-block threading, G92, G76, and control-specific threading cycles alike — on a digital twin of your machine, running the passes and the spindle-synchronized feed the way the control does. So the thread is cut on the twin, pass by pass, and both halves of what threading risks become visible:
- The thread form is verified by comparing the machined part against the CAD model — so a feed that didn’t match the pitch, a wrong final depth, or a mis-set taper or multi-start shows up as a thread that doesn’t match, even though nothing collided.
- The crash is caught by collision and near-miss detection — the pass that runs into a shoulder for want of a chamfer, the tool that drives in on a missing pull-out, the threading tool clipping something in a packed gang zone, or the move a modal G32 left synchronized when it shouldn’t be.
Because it runs the real ISO regardless of origin — posted from CAM, generated by Eureka NC Coder, or hand-written and edited at the control — the G32 passes you tuned by hand are verified exactly as they’ll run, on any controller and kinematics. G32 single-point threading and thread whirling are the two ways these parts get threaded; for the whirled multi-start threads of bone screws and worm shafts.
> Take a part threaded with hand-programmed G32 passes — a custom pitch, a tapered thread, or a thread cut behind a shoulder — and run the real ISO on a twin of your machine in Eureka G-Code. Watching the passes cut in sync, and the tool exit the thread, before the machine does it, is how a wrong pitch or a shoulder crash gets caught at a desk.
FAQ
What is G32 threading?
G32 is a single-block thread-cutting command: each line cuts one pass of a straight or tapered thread, with the axis feed synchronized to the spindle so the tool tracks the pitch. Unlike the threading cycles, it automates nothing — the programmer writes every pass, infeed, chamfer, and pull-out by hand.
What's the difference between G32, G92, and G76?
G32 is single-block threading — one pass per line, everything programmed manually. G92 is a single-block threading cycle — one block does a whole pass, repeated with changing depth. G76 is a multiple-repetitive cycle that runs all passes automatically, including infeed angle, depth per pass, spring passes, and taper. G32 gives the most control and the most room for error.
Why did my G32 thread come out at the wrong pitch or torn?
Usually the feed didn’t equal the pitch (the feed word is the lead), or the spindle RPM changed between passes so they no longer followed the same helix. Both run as valid code and produce a thread — just the wrong one — which is why verifying the executed passes matters.
Why doesn't my CAM simulation catch a G32 threading error?
CAM simulation shows the thread cycle it posted, at the pitch it intended, on its own model — it doesn’t reproduce the real G32 passes, the spindle synchronization, the manual chamfer and pull-out, or edits made at the control. Eureka G-Code executes the real ISO on a twin, so the actual passes and their sync are verified.
Does Eureka G-Code verify the thread form, not just collisions?
Yes. It compares the machined part against the CAD model, so a wrong pitch, wrong depth, or mis-set taper or multi-start shows up as a thread that doesn’t match — even when nothing collided. Collision and near-miss detection separately catch the shoulder crash, the missing pull-out, and a modal G32 left active.
Does it handle threading on any controller?
Yes. It executes G32, G92, G76 and control-specific threading cycles on a twin that reproduces your machine’s real controller and kinematics, whether the program was posted from CAM, generated by Eureka NC Coder, or written by hand.
Next step
Eureka G-Code — request a demonstration on a digital twin of your own machine and controller.
Verify the real threading passes — in sync, on a digital twin of your machine — before the pitch is wrong or the tool finds the shoulder.