Understanding Post‑Processors in Mastercam

A post‑processor is a script that translates the toolpath data created in Mastercam into the specific code your machine tool understands – typically G‑code or a proprietary dialect. While Mastercam ships with hundreds of standard posts for common machines, custom setups (e.g., machines with non‑standard controllers, unique rotary axes, or special automation interfaces) often require a tailor‑made post‑processor. The post‑processor file carries the .pst extension and contains all the logic for output formatting, cycle definitions, safety blocks, and machine‑specific functions. Understanding how to modify or create these files is a critical skill for any advanced CAM programmer.

Without a correct post‑processor, even the most perfectly generated toolpath will produce garbage at the machine – crashes, mismatched coordinates, or missing codes. Custom posts bridge that gap, ensuring every line of output respects the machine’s physical limits and controller syntax. For unique machine setups such as a mill‑turn with a live tooling Y‑axis, a wire EDM with a rotary submergence tank, or a five‑axis gantry, building a custom post is the only way to achieve reliable, unattended operation.

Steps to Create a Custom Post‑Processor

The process of building a custom post in Mastercam follows a logical, iterative workflow. Below is a detailed breakdown of each stage, with practical advice drawn from real‑world implementations.

1. Identify Machine Requirements

Before writing a single line of post code, you must document every aspect of the target machine and its controller. Start with the controller model and firmware version – a Fanuc 31i‑B5 with option packages behaves very differently from a Siemens 840D or a Haas NGC. The controller dictates the syntax for canned cycles, subprogram calls, and even basic motion commands.

Next, map the machine’s kinematic layout. For a three‑axis vertical mill, note the axis travel limits, rapid traverse speeds, and maximum spindle RPM. For multi‑axis machines, record the rotary axis zero positions, the direction of positive rotation, and any mechanical interference zones. Additional details include:

  • Tool changer type (arm‑style, carousel, or automatic pallet changer) and the required M‑codes for tool selection, clamping, and release.
  • Coolant options: flood, through‑spindle, air blast, and programmable coolant nozzles.
  • Probing capability – whether the machine uses Renishaw or Blum probes, and the standard macro calls for calibration and measurement.
  • Safety equipment: door interlocks, chip conveyor, mist extractor, and any custom interlocks.
  • Special cycles such as rigid tapping, high‑speed peck drilling, or polygon turning.

Collect this information from the machine manual, the controller parameter list, and by observing the machine running a known‑good program from a previous part. If possible, obtain a sample program written by the machine tool builder – it will show the exact formatting expected.

2. Access the Post‑Processor Editor

Mastercam provides two primary ways to edit posts: the built‑in Post‑Processor Editor and a standard text editor. The Post‑Processor Editor (found under the Machine Type menu → Post Processing → Post Processor Editor) is integrated into the Mastercam environment and offers syntax highlighting, line numbers, and a tree view of the post structure. It also allows you to run a debug trace on the post logic.

Alternatively, you can open the .pst file in Notepad++ or any text editor that supports line‑based editing. Many experienced programmers prefer external editors because they can use find/replace across multiple post files and integrate with version control systems. Whichever tool you choose, always keep a backup of the original post before making any changes – a single misplaced bracket can crash a machine.

3. Start with a Base Post

Never write a custom post from scratch. Mastercam’s post library includes hundreds of base posts that match popular controllers and machine configurations. For example, if you have a Fanuc‑controlled three‑axis mill, start with MPFAN.PST or FANUC_3X_MM.MCAM‑POST. For a Siemens 840D, use MPSIEM.PST or one of the Siemens‑specific posts.

The base post gives you correct motion logic, canned cycle definitions, and a tested output structure. Your job is to modify the sections that differ – such as the tool change sequence, the coolant codes, or the addition of a fifth axis. Selecting the closest base post reduces errors and saves hours of debugging.

To choose the right base post, open Mastercam’s Select Post dialog and review the description field. Look for controllers that share the same major version as your machine. If your machine is a 2022 model with a Fanuc 32i, a post for Fanuc 31i is likely a safe starting point – the differences are usually minor M‑code adjustments.

4. Customize the Code Output

With the base post loaded, begin customizing the output. The post file is divided into logical blocks called “post blocks” – each block handles a specific event, such as tool change, linear move, arc move, or coolant on/off. You will edit these blocks to insert machine‑specific commands, change formatting, or add conditional logic.

Modifying Tool Change Event

The tool change block (ptlchg$ or psof$) is the most commonly edited section. Here you can add M‑codes for the tool changer (e.g., M06 for an automatic tool change), commands to move the machine to a safe Z‑height, or to engage a chip wash cycle. Example modifications:

  • Insert a G91 G28 Z0 safe move before every tool change to retract to the Z home position.
  • Add an M50 to engage coolant during the change if your machine uses through‑spindle coolant.
  • Include a dwell (G04 P1) to allow the spindle to orient fully before the arm engages.

Always test these changes with a simple single‑tool program before trying multi‑tool sequences.

Customizing Canned Cycles

Mastercam’s drill, tap, and bore cycles are translated into the corresponding G‑codes (G81, G83, G84, G85, etc.) by the post. If your machine uses a different cycle variant – such as a rigid tap with reverse spindle orientation – you must edit the pdrill$, ptap$, or pzhl$ blocks. For example, a Brother speedio might require a special “high‑speed peck” cycle using G73 with a K parameter. You can add custom parameter fields in Mastercam’s toolpath parameters and then reference them in the post using peck1$, peck2$, etc.

Adding Machine‑Specific Codes

Unique machine setups often require non‑standard M‑ or G‑codes. For instance, a machine with a sub‑spindle may need an M‑code to clamp/unclamp the sub, or a machine with a tool‑breakage detector might require an M‑code to activate the sensor after each tool change. In the post, you can add these codes conditionally using user‑defined post variables or by hard‑coding them in the appropriate event block.

To add a user‑defined M‑code, create a new post variable (e.g., fmt "M" 5 "custom_m") and set its value in the post block. This gives you the flexibility to turn the code on or off via a checkbox in Mastercam’s operation parameters.

5. Test the Post‑Processor

Testing is the most critical step. Begin with a simple toolpath – a single contour or a drill cycle – and post‑process it. Open the output file in a text editor and visually inspect every line against your machine manual. Check for correct decimal formatting, leading zeros, and the presence of required safety blocks.

Next, run the program on the machine in dry‑run mode (no material). Many machines have a “graphic simulation” or “dry run” mode that shows the motion without actual cutting. Use this to verify tool changes, axis limits, and rapid moves. If possible, use a machine simulator like CNC Simulator Pro or the machine builder’s own simulation software (e.g., Siemens SinuTrain). Simulators catch catastrophic errors like axis overtravel or out‑of‑range feedrates without risking the machine.

When you are confident in the dry run, cut a test part in foam or wax. Measure the result and compare it to the Mastercam stock model. Discrepancies in depth, hole locations, or surface finish often point to post errors – for example, a missing G41/G42 for cutter compensation, or incorrect arc center output (I, J, K vs. R).

6. Refine and Save

No custom post is perfect on the first try. Document every change you make and the reason for it. Keep multiple versions of the post file with descriptive names, e.g., FANUC_3X_V1.PST, FANUC_3X_V2.PST. Use a version control system like Git to track changes and allow rollback. Mastercam’s post editor can also save a “change log” if you enable the option in its settings.

After the post passes all tests, save the final version in a secure location and consider exporting it as a .mcam‑post file for easy deployment across your CAM stations. Perform a final validation by posting a real production part and running it on the machine with full supervision.

Advanced Customization Techniques

Once you are comfortable with basic edits, explore more powerful capabilities that can dramatically extend your machine’s functionality.

Adding Custom Macros and Subroutines

Many controllers allow the use of parametric subprograms (macros) that accept variables – e.g., Fanuc custom macro B, Siemens R‑parameters, Haascustom macro. Your post can generate calls to these macros with calculated values from Mastercam. For instance, you can create a macro to perform a tool‑life management routine, or to measure a workpiece using a probe. In the post, use pbld, n$, *smacro, e$ to output a macro call with the required arguments.

Mastercam also supports user‑defined post variables that can be passed as macro arguments. This allows the post to dynamically generate macro parameters based on toolpath geometry (hole diameters, pocket depths, etc.).

Supporting Rotary Axes and Multi‑Axis Machines

For machines with rotary axes (4‑axis, 5‑axis, indexers), the post must handle kinematic transformation from toolpath coordinates to machine coordinates. Mastercam’s post engine includes built‑in functions for common configurations (table/table, head/table, head/head). However, unique setups – such as a B‑axis with an offset trunnion, or a dual‑spindle mill‑turn – require you to override these functions.

Start by understanding the machine’s kinematic chain. Use Mastercam’s Machine Definition Manager to define the axis layout and limits. Then, in the post, modify the pindx$, pmap$, or pcan1$ blocks to match the actual behavior. For example, a machine with a tilting B‑axis that uses a “tool center point control” (TCPC) mode needs special handling of the rotation commands to keep the tool tip stationary. Add conditional logic: if the operation uses TCPC, output G43.4 instead of G43.

Testing multi‑axis posts requires caution. Simulate in Mastercam’s Backplot and Verify, then use a machine simulator that supports the specific controller. Always run a single‑axis rotation test before attempting simultaneous five‑axis moves.

Integrating with Automation and Probing Cycles

Modern shops often integrate machine tools with robotic loaders, conveyors, and in‑process measurement. The post can include M‑codes to signal these devices. For example, before cutting, add an M‑code to close the door interlock, then after the program end, output an M‑code to open a pallet clamp. Probing cycles – such as tool length measurement, part location, or on‑machine inspection – can be inserted as subprogram calls within the post logic.

Mastercam’s Probe plugin can generate probing toolpaths; you then customize the post to output the correct macro calls and variables. Many probing routines use common variable names (#150 for measured length, #102 for X shift, etc.). Ensure your post sends these variables in the same order the controller expects. A mismatch will cause crashes or inaccurate measurements.

Common Pitfalls and How to Avoid Them

  • Incorrect G‑Code or M‑Code Conflict: Using a code that conflicts with machine parameters – e.g., G30 for second home when G30 is also used for a macro. Always verify with the manual and test on a single block.
  • Missing Safety Blocks: Forgetting to retract to a safe Z, or to include a G40/G49/G80 reset. Add these in the post’s pheader$ and ptlchg$ blocks.
  • Wrong Arc Output Format: Some controllers require I‑J‑K (incremental center) while others need absolute or radius R. Set the arctype$ variable in the post accordingly.
  • Tool Change Sequence Errors: Forgetting to orient spindle (M19) or to stop the coolant before the change. Watch for such sequences in the machine manual.
  • Decimal Point Formatting: Some controls require no leading zeros (e.g., X.5 instead of X0.5) and others require a fixed number of decimal places. Use Mastercam’s fmt function to match the controller.
  • Ignoring Subprogram Call Differences: A Fanuc control uses M98 Pxxxx to call subprograms, while Siemens uses EXTCALL. Modify the psub_call$ block to match.

Prevent these by keeping a checklist of your machine’s requirements and verifying each one during the test phase. Create a test part that exercises every possible function – drilling, tapping, contouring, tool change, coolant, rotary indexing – and run it in simulation before production.

Tools and Resources for Post‑Processor Development

Mastercam provides extensive built‑in documentation, including the Post‑Processor Reference Guide. The guide explains every post block, variable, and formatting option. For example, it covers how to use the fmt function, how to create conditional logic with if/else, and how to access toolpath parameters.

The Mastercam Forums are an active community where users share custom posts, ask questions, and troubleshoot issues. Search for your controller name or common problems to see existing solutions.

Third‑party tools like Cimco Edit include advanced post‑processor editors with integrated syntax checking and back‑plotting capabilities. Some users prefer to debug posts using the Mastercam Post Debugger (available from the Utilities tab) which steps through the post logic line by line.

Machine tool builders often provide sample post‑processors for their machines. Check the manufacturer’s support portal – for example, Haas has a library of posts for their NGC control, and Mazak offers posts for the SmoothG controller. These are excellent starting points because they already include the correct M‑codes, cycle definitions, and safety sequences.

Finally, consider investing in formal training. CNC Software, Inc. offers instructor‑led and online Mastercam Post Processor Training courses. These cover the advanced concepts of custom variable creation, macro integration, and complex kinematic post editing.

Conclusion

Creating a custom post‑processor for a unique machine setup is not a trivial task, but it is one of the highest‑value investments a CAM programmer can make. A well‑crafted post eliminates manual editing, reduces setup errors, and unlocks the full capability of your machine tool. By following a systematic workflow – understanding the machine, starting from a solid base post, methodically customizing each block, and rigorous testing – you can produce a post that runs reliably in production for years.

Remember: the post‑processor is the final link between the virtual world of CAM and the physical reality of the machine. Treat it with the same care as a fixturing plan or a machining strategy. Document your changes, back up your files, and never stop learning from the machine itself. The time you invest in post development will pay for itself many times over in reduced cycle times, fewer crash recoveries, and peace of mind.