What Should a New CNC Programmer Ask Before Touching Post-Processor Settings on an Unfamiliar Control?

Before changing anything, find out what the post-processor was actually built and validated against, because a post that's never been proven on this control, this machine's kinematics, and this shop's tooling conventions is a liability no matter how correct the CAM output looks on screen. The questions that matter aren't about syntax. They're about what assumptions are already baked in.

Who validated this post, and on what

Ask that first.

A post-processor is only as good as the last person who checked its output against a real machine cutting a real part. Ask whether this specific post has run parts before on this specific control version, or whether it was adapted from a similar machine and never fully proven out. Controls that look alike on paper, two Fanuc-flavored controls from different builders, for instance, can differ in how they handle canned cycles, tool length compensation, or rotary axis behavior in ways that don't show up until a program actually runs.

What does the machine's kinematics actually look like

If the machine has a rotary axis, a trunnion, a rotary table, a tilting head, find out the pivot point locations and whether the post is doing RTCP (rotation around the tool center point) correctly for this specific configuration. Getting this wrong doesn't throw an error. It moves the tool to the wrong place with total confidence, and on a 5-axis job that can mean a crash before anyone notices the program is wrong. Ask specifically whether tool center point management is handled in the control or in the post, because that changes what you're responsible for checking in CAM.

What are this shop's conventions, not just the control's defaults

Every shop that's been running a while has accumulated conventions that live in the post and nowhere else: which work offset number is reserved for what, how tool numbers map to a specific magazine layout, whether coolant is turned on by default or requires an explicit call, what the safe retract height assumes about clearance. None of that is documented in the control's manual. Ask the people who've been running this machine, not just the post-processor's comment header, because the comment header often lags behind what actually changed on the floor.

What happens at program start and program end

Confirm what the post assumes is already true when a program starts: spindle orientation, work offset active, tool already loaded or not, coolant state. Also confirm what it leaves the machine in when the program ends. A mismatch here is one of the more common causes of a first-part crash that has nothing to do with the toolpath itself: the program was written correctly, but it assumed a starting state that wasn't actually there.

Run it in the air first, then take the cut in stages

None of the above replaces dry-running a new program in the air, single-blocking through the first few moves, and backing off feed override on the first real cut until the tool is confirmed in the right place doing the right thing. Post-processor questions reduce the odds of a surprise. They don't eliminate the need to verify in person before trusting the program at full speed.

If the shop doesn't have clear answers to who validated the post and what the machine's specific rotary configuration looks like, treat every existing program from that post as unverified until proven otherwise. Not because the post is necessarily wrong. Because nobody yet knows for certain that it's right.