MP Ref Guide - Vol 1 PDF

LEGACY DOC -- VERSION 9.
1
Version 9
MP Post Processor
Reference Guide
V olume 1
Basic MP Post Processing
sample text
LEGACY DOC -- VERSION 9.1
Volume 1 Chapter 1 How to Use the MP Post Processor Reference Guide
1 How to Use the MP Post Processor Reference

Guide
Welcome to Volume 1 of the MP Post Processor Reference Guide. The Guide contains information
that will assist you in modifying post processors written in the MP language, CNC Software’s
proprietary scripting language for Mill, Lathe, Wire, and Router applications. It is not intended to teach
you how to write a post processor. Your Mastercam dealer is your best source of assistance in
developing and customizing postprocessors.
The MP Post Processor Reference Guide consists of three volumes:
Volume 1, Basic MP Post Processor Programming. Presents basic concepts, principles, and rules
you must understand to modify an MP post processor: postblocks, variables, formulas, functions, NCI
Gcode, drill cycles, canned text, etc. If you are planning to modify an MP post processor or just want
to understand how it is organized, you should read this volume.
Volume 2, Advanced MP Language Concepts and Applications. Describes how the MP language
implements special applications including subprograms, mill/turn applications, lathe canned and
threading cycles, and wire processing. Also discusses how MP language uses buffer files, handles
intersections, and breaks up motion.
Volume 3, MP Post Language Reference. Contains detailed descriptions of syntax and dependencies
of postblocks, variables, formulas, NCI Gcode, and parameters.
Volume 1 contains a Glossary.

Note: The MP Post Processor Reference Guide is designed to be used online, although you can also
print it.
How to contact CNC Software

Important Information
Address CNC Software, Inc.
671 Old Post Road
Tolland, Connecticut, 06084-2830 USA
Phone (860) 875-5006
Fax (860) 872-1565
Internet Address http://www.mastercam.com
E-mail support@mastercam.com
February 2004 Mastercam Version 9.1 MP Post Processor Reference Guide 1-1
Chapter 1 How to Use the MP Post Processor Reference Guide Volume 1
Additional resources
Please email any comments, suggests and/or corrections to the MP Post documentation to
posts@mastercam.com
For an ongoing discussion of Mastercam-related topics, visit the eMastercam online forum at
www.emastercam.com
1-2 Mastercam Version 9.1 MP Post Processor Reference Guide February 2004
Volume 1 Chapter 2 Introduction to MP Post Processors
2 Introduction to MP Post Processors
This section presents an overview of the MP post processing language. It is intended to provide
direction for someone who wants to modify an existing MP post processor. It is not intended to teach
you how to write a post processor.
To be able to modify a post processor and understand the material in this Reference Guide, you should
have a basic understanding of how a computer program is structured and operates. As a minimum, you
should understand:
how the syntax of a programming language affects program operation
the use of variables to store and pass information
branching within a program based on conditional and Boolean expressions
jumping within a program through subroutine calls
mathematical expressions and formulas
nesting in formulas and a program language structure
general debugging techniques
In addition, you must be familiar with Mastercam and have a thorough understanding of NC code
(Gcode) and the specific requirements of the machine tool and control for which you want to create a
post processor.
Note: This Reference Guide does not describe “legacy posts”, also called family posts, which are no
longer supported by Mastercam. These posts are MS-DOS® based and can be identified by their use
of .COM executable files.
What is an MP post?
An MP (Mastercam Post) post processor is a combination of three (or four) files:
the post processor customization file (.PST)
the post processor customization text file (.TXT)
the post processor executable file (.DLL)
the post processor ‘binned file (.PSB) this is usually only with some “high end” posts
The MP post processor customization file (*.PST) is written in CNC Software, Inc.’s proprietary
scripting language, the MP language, which is a programming language designed to enable someone
with limited programming experience to customize a post processor for use with Mastercam. The MP
post processor executable (*.DLL) is a program that interprets the MP post customization files (*.PST
and *.PSB), processes the Mastercam intermediate file (*.NCI) and produces the NC output file
(*.NC).
February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-1

Chapter 2 Introduction to MP Post Processors Volume 1
The MP post processor is a combination of a configuration-type post, where all output is controlled in
the post executable by a series of questions the user answers to control output, and a language-based
post. Although a language-based is more difficult to use than configuration-type post , it is also more
powerful because there are no restrictions placed on the post writer by the capability of the post
executable. Using the MP language, the post writer can accomplish practically any task in the post
processor.
The MP post processor needs three main files:
A post customization file (.PST), which is an ASCII text file containing MP language instructions
that define exactly what NC code will be produced and its format.
A post executable file (.DLL), which can be considered the “engine” of the post processor. It
reads the post customization file (.PST), reads the intermediate file (.NCI) and writes the NC file.
You do not modify the post executable file but you can control some of its behavior through the
post customization file.
The Mastercam intermediate file (.NCI), which is the generic NCI file format generated from the
toolpaths that are created in Mastercam. Continuing the analogy, this is the fuel for the engine.
The information that is read from the NCI file is converted by the post process operation into NC
code.
There are two (optional) additional files:
A post text file (.TXT) file, which is an ASCII text file containing custom text prompts that allow
the post to alter (some) of the text data displayed inside of Mastercam.
A post ‘bin file (.PSB) file, which is a BINARY file containing some of the information from the
original .PST text file. This allows the post writer to protect sections of the .PST in a non-readable
(by humans) binary file format. This is usually only with some “high end” posts.
How does an MP post work?

Each operation you create in Mastercam generates a toolpath. The operation contains, in addition to
the toolpath motion, parameter information such as tool descriptions, speeds and feeds, and more. This
information is written to an intermediate file, the ASCII NCI file, when an operation is posted.
For more information on the NCI, see Volume 1, The NCI File.
For a detailed description of each NCI Gcode, see Volume 3, The NCI file.
What happens when you post an NCI file in Mastercam, in simple terms, is:
The post executable file first reads the currently active post’s customization file for instructions.
(The currently active post is the post that is active when Mastercam starts, the post associated with
the currently active configuration file (*.CFG), or the post selected specifically by the user.)
The post executable file then reads the NCI file, translates the NCI data into NC output based on
the instructions it obtained from the post customization file.
The post executable writes the NC output to an NC file and transmits this NC program to the
machine tool’s control to drive the machine tool.
2-2 Mastercam Version 9.1 MP Post Reference Guide February 2004

Post processing in greater detail

What actually happens during the post process operation is:
Mastercam first opens the post executable file.
The post executable builds lists of variables and labels that are predefined in the post executable
itself.
The post executable opens and reads the post customization file and converts the MP language,
which is coded in a human-readable form, into an instruction list that is readable by the post
executable.
The post executable adds user-defined variables and labels to the lists of predefined variables and
labels.
Once these tasks are complete, the post executable is able to perform the instructions contained in
the post customization file.
Reading the NCI file

The post executable next opens the NCI file and begins reading two lines of the NCI file at a time
(parsing the NCI file). This starts a process of reading two-line sets from NCI file and producing
corresponding calls to the instruction list retained in the computer’s memory in order to generate the
NC output.
The first line in the two-line set is the NCI Gcode. This line contains a single value. It is the key to
how the next line is interpreted and how the information is processed by the post executable. The
second line in the two-line set contains parameters (for example, the X, Y, Z position, feed rate) that
complete the data to be passed with the NCI Gcode.
Actual NCI line set for a linear move at rapid feed rate:
0
0 2.375 2.375 2.5 –2. 0
Definition:
g (NCI Gcode)
1 2 3 4 5 6 (six parameters)
Where:
g
123456
g 0: Linear Move at Rapid Feed Rate (NCI Gcode)
1 Cutter Compensation
2 Final X position
3 Final Y position
4 Final Z position
5 Feed rate settings
6 Contour flag

The post executable applies these parameter values to the appropriate predefined MP variables,
performs additional calculations to generate values for other predefined variables that are commonly
used for the NCI Gcode type being processed, and performs any routines enabled by the post
customization file appropriate for the NCI Gcode type. (An example of such a routine is breaking an
arc at its quadrants.)
Next the post executable begins executing MP instructions, which are contained in postblocks.
Postblocks
A postblock is an MP language mechanism - a named series of lines of MP statements, called postlines,
that can perform calculations, call other postblocks, and produce NC output. Based on the value of the
NCI Gcode in the two-line set it is parsing, the post executable calls a specific predefined postblock.
For more information on the correlation between NCI Gcodes and predefined postblocks,
see Volume 1, The NCI file and Volume 1, Postblocks
A predefined postblock called as a result of an NCI Gcode is an entry postblock because it is the
starting point in the post customization file where the instructions in the postblock are executed. There
are other types of predefined postblocks, which will be described later.
The post executable file interprets each postline, following the flow of the logic defined by the
postblock. Each postline is interpreted by examining the MP language statements contained in the line
in order from left to right. Depending on the statement type, a character string may be assembled that
becomes a line of NC output (although not all postlines result in output).
When the post executable determines that an NC output line is complete, it writes the line to the NC
output file. The post executable then continues processing postlines in the entry postblock until the
final instruction is processed. When all statements according to the logic flow of one postblock have
been processed, the post executable reads another two-line set from the NCI file. This produces a call
to another entry postblock and the process repeats. The posting process continues in this way until the
entire NCI file has been read.
The following diagram illustrates MP post processor flow.
Mastercam starts or user changes the post processor
selection.
Mastercam reads numbered system questions in .PST

file and text from .TXT file.
Mastercam sets values and modifies menus and

dialog boxes according to post numbered system
questions and .TXT file.
User prepares Mastercam job.
User posts Mastercam job (one or more operations).

Mastercam writes ASCII NCI file.
Mastercam launches MP.DLL, MPL.DLL, or

MPWIRE.DLL.
Post .DLL reads and parses active PST file.
Post executes pre-process and preparatory functions

and postblocks.
A Post reads the ASCII NCI file, two lines at a time.
Based on first line Gcode, passes parameters as

variables, executes associated internal routines.
Based on first line Gcode, calls a predefined entry

postblock.
Post interprets postline statements and writes NC

output line(s).
Post returns to A to continue reading NCI line sets

until the end of the .NCI file.
What files do I need for the posting process?

The post customization file (*.PST)
The post customization file is the file you select when you chose a post processor in Mastercam. You
can use or modify an existing customization file, or write a new post customization file to generate NC
code for your particular machine tool requirements. Mastercam comes equipped with an extensive
library of post customization files. In addition, your Mastercam dealer can assist you in developing or
modifying a post customization files to meet your needs.
The post text file (*.TXT)

With each post customization file, there can also be a post text file. The post text file is an optional file
that allows you to replace the text displayed in certain menus and dialog boxes in Mastercam. Its
purpose is to customize Mastercam text based on the post customization file. The post text file must
have the same file name as the post customization file but with the .TXT extension and resides in the
same directory as the post customization file. (Each PST should have a related TXT file)
See Volume 1, Using the Post Text File for more information on the post text file.

The post ‘bin file (*.PSB)

Some post customization files make use of a .PSB file. This binary .PSB file must have the same file
name as the post customization file but with the .PSB extension and resides in the same directory as the
post customization file. This is usually only with some “high end” posts. You want to make sure that
if your post processor uses a .PSB file, that you back up it along with the .PST and .TXT files!
The post executable file (*.DLL)

The post executable file is located in the Mastercam Chooks directory. There is an MP post executable
file for each Mastercam product - MP.DLL for Mill/Router, MPL.DLL for Lathe and MPWIRE.DLL
for Wire. Mill/Turn applications can use either MP.DLL or MPL.DLL for the post executable file
The post executable file must have two additional files:
The post executable text file (also *.TXT). This text file has the same file name as the post
executable (.DLL) file but with the .TXT file name extension. It contains the warning and error
messages that are displayed if there are problems during the posting process. It must be located in
the same directory as the post executable (\Chooks directory).
If the post executable file was compiled since the release of Mastercam V8.0, the file
MPPARAM.DLL must be located in the directory with the Mastercam executable. (NOT the
\Chooks directory) This DLL is loaded by the post executable file to read the operation parameter
(*.OPS) file. The operation parameter file is a binary file that contains most the information that
was entered in the Operation Parameters pages in Mastercam.
See Volume 3, Parameter Information for more information on parameters.
What are the components of the MP language?

Note: The MP_EZ post, which is supplied with Mastercam Mill V9, will be used to illustrate the MP
language and typical post construction. You can find the MP_EZ.PST file in the Posts folder
within the MCAM9\MILL product folder. Having a copy of the MP_EZ.PST file available for
reference will make it easier to understand the MP language discussions that follow.
See Sample Post: MP_EZ.PST later in this chapter for excerpts from this file.
The MP language offers the following features, which are explained in the sections that follow:
Predefined variables and strings
User-defined variables and strings
Predefined postblocks
User-defined postblocks
Bracketed or nested postblocks
Conditional branch statements (while, if, else)
Math operators
Formula functions for trigonometric functions
Formula functions for string manipulation
Formula functions for file manipulation
Formula functions for vector math

Formula functions for intersecting geometry

User prompts, which are displayed in Mastercam when the post is run. The user can enter
information to the post with this feature.
Post comments
String select function, lookup tables and buffer files
Support for subprograms and Lathe canned cycles
Support for drilling canned cycles and drilling long code
System numbered questions, also called numbered questions, which can be used to alter specific
Mastercam functions and settings to work with the post processor.
Variables
Variables are labels given to specific values or strings the post processor uses. The variables may
represent numeric values (numeric variable) or character strings (string variable). They can be
parameters passed from the NCI, values calculated within the post executable file, or switches that are
used to enable or disable posting options. Variables allow the post processor to pass and manipulate
information by using the variable label to represent the value or string itself.
Variables may be predefined or user-defined.
Predefined variables are variables that exist in the post executable file. They do not need to be
declared in the post customization file except to apply an initial value to them or to format them for
output. A list of all pre-defined post variables is located at the end of Volume3, Numeric Variables
User-defined variables must be declared in the post customization file. User-defined numeric variables
must be initialized and/or formatted before they can be used in the post customization file. User-
defined string variables must also be declared before they are used. String variable labels always begin
with the letter “s”, for example, scoolant. User-defined numeric variables can start with any letter
(including “s”).
Using variables to construct output
The post processor constructs a line of NC output by assembling a series of variables found on a
postline. To be output, a variable must simply appear on a postline, but it must not be part of a formula
or conditional expression. For example, the following line would output the values and strings for the
variables, n, scoolant, and next_tool. ‘e’ creates a carriage return/line feed at the end of the line:
n, scoolant, next_tool, e
Note: Modality and Variable Modifiers affect whether a variable is actually output to the NC file.
See Volume 1, Numeric Variables for a description of modality.
String literals
The MP language also supports string literals, which are characters contained within quotes, for
example, “M00”. Literal strings are converted to a string variable internally when they are found on a
postline. They are output exactly as you see them in the post customization file.

Command variables
A special type of predefined numeric variable in the MP language is the command variable. This type
variable starts a process or action that is part of the post executable. They are normally used alone on a
postline. MP language command variables include, for example, comment, which buffers and outputs
comments where the post writer would like them, and fleader, which writes leader and trailer characters
for punched tape.
See Volume 1, Numeric Variables for information on the declaration and use of variables. For a full
description of predefined variables, and for a complete listing of commands, see Volume 3, Numeric
Variables.
Postblocks
A postblock is a labeled series of postlines containing MP statements that produce NC output,
conditionally branch, perform calculations, call other postblocks and trigger routines in the post
executable. A postblock label, which declares a postblock, usually begins with the letter “p” and
begins in the first column. Postblock labels can also begin with “l” or “m”. This format is usually used
for mill/turn applications. The postblock label must be on a separate line before the postlines included
in the block. The only other text that can appear on the same line as a postblock definition is an optional
#comment (text that follows the “#” character).
There are several kinds of postblocks. An entry postblock is one that is called automatically by the post
executable file as a result of the NCI code. Another is the bracketed postblock, which is a user-defined
postblock nested within another postblock. Bracketed postblocks are implied postblocks. By using the
open and close brackets ([,]) to surround the postlines, the post executable interprets this as a separate
block of instructions. Bracketed postblocks are used to make the post customization file more readable
and are normally used with conditional branching.
Postlines
Postlines can start in any column except the first. Use consistent indentation to make the organization
of the post clear. All postlines that are not nested within a bracketed postblocks are considered part of
the preceding labeled postblock until a label in the first column is encountered. This label can be
another postblock label, a variable label or post function declaration. Post comments are ignored and
do not end the postblock.
There are three types of postlines:
Formula postline
Boolean postline
Output postline
Formula postlines
Formula postlines are used for assignments or equations. The equal sign (=) after a result variable as
the first item on the postline is what identifies the formula postline. A formula postline can be
considered a postline statement called a formula statement. A formula statement is limited to one line
and cannot continue over multiple lines in the post customization file. It can be part of a Boolean
postline but cannot be included in an output postline.

For example, this is a formula postline and a formula statement:

speed = abs(ss)
Boolean postlines
Boolean postlines begin with a conditional branching statement.
This is a formula statement in a Boolean postlines:
if speed > maxss, speed = maxss
Boolean postlines are very similar to formula postlines except, instead of using an equal sign with a
result variable, a Boolean postline uses the conditional operators ‘if’, ‘else’ or ‘while’ as the first entry
on the postline. In addition, a formula in the conditional branching statement can continue over several
lines until a comma (,) that is not part of a formula function is encountered. Both the conditional
operator and the Boolean formula are considered a postline statement.
For example:
This is a Boolean postline and a conditional branching statement:
if speed > maxss,
This is also a Boolean postline and a conditional branching statement:
else,
Following the comma delimiter in the Boolean postline, it is legal to have any statement type except
another conditional branching statement.
Output postlines
“Output postline” is a misleading term because the statements allowed on this type of postline can
imply that a variable will necessarily be output. However, output postlines can perform any or the
following tasks:
modify variable attributes with or without variable output
call a command routine
output a string literal
output an ASCII character
prompt the user
call a postblock
All of these statements are called output statements.
What identifies an output postline is the fact it is not interpreted as a formula postline, formula
statement or Boolean postline by the post executable. Each of the output statements listed above can
occur in an output postline and must be separated by a comma (,). Statements that are legal for an
output postline are also valid as statements following the conditional branching statement in a Boolean
postline. For example, this is a Boolean postline with output statements:
if speed <> 0, n, speed, next_tool, pblockcall, e

An output statement that contains another postblock name performs a call to the named postblock.
Similar to an entry postblock, this type of postblock passes control to the position of the called
postblock declaration. When the output statement contains more than one postblock name, each
postblock name passes control to its postblock in turn. When all instructions in the called postblock(s)
have been completed, control returns to the calling output statement.
See Volume 1, Postblocks for more information.
Conditional branching
The MP language supports the conditional operators (if, else, while). These are used with conditional
branching statement in the MP language to control what instructions are processed in the post
customization file.
See Volume 1, Postblocks for more information on conditional branching.
Mathematical operators
The MP language supports a large number of operators, including the common mathematical operators:
(open and close parentheses, +. -, *, /), comparison operators (=, <>, <, >, <=, >=), Boolean or logical
operators (&, |, not). (& is the Boolean ‘and’ operator and | is the Boolean ‘or’ operator.)
See Volume 3, Formulas for a complete listing of MP language operators.
Formula functions
An MP formula function performs a defined routine using one or two passed arguments and returns
some result, which is applied or assigned to the variable on the left of the equation, for example, gear =
frange (one, speed) or string2 = lcase (string). Formula functions are part of the MP language; you cannot
define your own functions. The MP language provides a Math Library that includes the following
types of functions:
arithmetic
trigonometric
2D intersection
vector/matrix
string and file manipulation
See Volume 3, Formulas for a complete listing of MP language functions.
Note: Some formula functions are designed to take the left value and assign it to the argument that is
the right value. This is contrary to normal convention.
User prompts
You can display prompts or questions in the Mastercam prompt area at the bottom of the Mastercam
application screen. A unique method is used to trigger a user prompt. The post function for user
prompt (fq) is declared and a trigger placed on a postline in the post customization file. The trigger is
not a variable but is a combination of the letter ‘q’ and the matching number of the post function for
question; for example, q1. When the trigger is encountered as an output statement, the post processor
pauses, displays the prompt text in Mastercam and waits for the user’s response.
See Volume 1, How Prompt Questions Work for more information.

Post comments
A post comment is used to document in the post customization file any information the post writer may
feel is needed. The pound symbol (#) marks the start of a comment. However, because the comment
ends at the end of the line in the post customization file, it is not possible to nest comments or insert
them in between postline statements. All comments are ignored when the post customization file is
parsed by post executable file.
String select function

The string select function is a powerful feature of the MP language that allows the post processor to
assign a string variable from a list of string variables to a target string variable based on the value of a
numeric variable used in this selection function.
A frequent use of the string select function is to output a motion NC code to the NC file based on the
NCI Gcode read from the NCI file. Based on the NCI Gcode, a string variable is selected and placed in
the target string variable for output.
One advantage of this function is the output of the string variable is controlled by the modality of the
numeric variable. For example, if the NCI Gcode read by the post executable is 0, and then output
might be G0 if the variable’s modality dictates output or nothing if it doesn’t.
See Volume 1, Numeric Variables for more information on modality and its effect on output.
The MP_EZ post provides string selects for the following:
Motion Gcode (G0, G1, G2, G3, or G4)
Work plane Gcode (G17, G18, or G19)
English or metric code (G20 or G21)
Reference return code (G28 or G30).
Cutter compensation Gcode (G40, G41, or G42)
Canned drill cycle Gcodes
Absolute or incremental Gcode (G90 or G91)
Canned drill cycle reference height (G98 or G99)
Spindle Mcode (M3, M4 or M5)
Coolant Mcode (M8 or M9)
See Volume 1, Post Functions for more information on defining and using string select tables.
Lookup tables
Lookup tables are essentially two-column tables that associate a value in the first column with a value
or variable in the second column. There are two types of lookup tables:
Lookup tables used to associate an input value with an output value
Lookup tables used to associate an operation parameter Gcode with a numeric or string variable
Lookup tables are normally of the type that associates an input value with an output value. Spindle
gear selection is a good example of this type of lookup table. The spindle speed is passed as an
argument and matched to a value in the second column. The value from the first column is returned.

Lookup tables are declared in the post customization file. The MP_EZ.PST post provides a lookup
table (lookup table 1) to select a gear range based on spindle speed.
See Volume 1, Post Functions for more information.
Buffer files
Buffer files are temporary files used to store and retrieve numeric or string data. They normally exist
only while the post is running. You can convert them to text files or open existing text files as a buffer
files.
Note: MP_EZ.PST does not contain an example of buffer files.
See Volume 2, How Buffer Files Work for more information.
Support for subprograms and canned cycles

Mastercam Version 8 and 9 provide methods to generate subprograms and canned cycles. These are
supported for Fanuc-type controls in the MPFAN.PST and MPLFAN.PST files. MP_EZ.PST does not
provide this support and should not be referenced for this functionality. Drilling canned cycles are
supported in the MP_EZ.PST file.
See Volume 2, How Subprograms Work and Volume 2, How Lathe Canned Cycles Work for more
information.
System numbered questions

The system numbered questions are a numbered list of questions at the end of the post customization
file that are read by Mastercam when the post is loaded. The system questions set certain parameters in
Mastercam and turn certain Mastercam features on and off. When Mastercam starts and loads the
default post customization file or when the operator changes the post customization file, Mastercam
reads the system numbered questions.
See Volume 1, Using Numbered Questions for more information.
How is an MP post organized?

Organization in this context refers to the order in which post comments, declarations, postblocks, and
statements should occur, or sometimes must occur, in the post customization file. As the MP post
language has evolved, the organization requirements have become less stringent. Although not strictly
required, the organization guidelines presented here will make it easier to understand and maintain the
post customization files.
Note: Please refer to the MP_EZ.PST sample post customization file for code examples.
In general, post customization files should be organized into three major areas:
The Definition area containing the post header (post comments), declarations (initializations,
formats, global formulas), and lookup tables.
The Postblock area containing both user-defined and predefined postblocks.
The System Questions located at the end of the post customization file.

Definition area
The Definition area contains the following sections:
Header containing the title block, revision log, and feature list. This entire section is series of
comments, which is indicated by the pound character (#). (The post executable ignores the # and
everything following it on that line.) Comments are generally documentation intended to be read
by the post’s users.
Debug switches, program constants and other program switches. Debug switches allow you to
generate information about which NCI line and postblocks have produced each line of NC output.
See Volume 1, Post Debugging Techniques for more information. Program constants are numeric
variables that have a single constant value that should never be changed. Program switches turn
program features on and off or select a behavior from a list of options. Both program switches and
variables are given initial values by the post in this section of the customization file.
Numeric variable initialization is a continuation of the debug switches, program constants, and
other program switches section. Some are predefined numeric variables that may be initialized to a
different value depending on the post writer’s requirements. Others are user-defined numeric
variable declarations that are required in the post customization file. A numeric variable
initialization is always defined with the colon “:” and, as the name implies, assigns only the initial
value of the numeric variable.
Format statements describe the numeric format of every numeric variable you will output to the
NC file. Format statements are referred to by number. By default, format statement 1 is associated
to a numeric variable.
String variables, string select functions declare string variables and the string select
functions, which are used to obtain a character string based on a numeric variable. The string
variable label always starts with the letter ‘s’ and the declaration uses a space between the label and
the character string.
Lookup Tables define tables. The post function declaration is entered followed by the table
entries.
Buffers define the buffers used to access or save data. MP_EZ.PST does not use buffer files and it
is generally best to avoid their use unless absolutely needed.
Global formulas are numeric variable declarations that are evaluated whenever the declared
numeric variable is encountered as a postline statement or in a postline formula. This evaluation
occurs before any output. Although any numeric variable declarations (initialization or global) can
have a formula assignment, a global formula is different in that it uses the equal sign (=) instead of
the colon (:) for the assignment. Note: Use of global formulas is not recommended and can lead to
confusion when debugging. Try to put the formula in the postblock where it is used.
Format assignments assign both a prefix character and defined format statement to a numeric
variable. When the numeric variable is output, these formatting assignments are applied.

Postblock area
The Postblock area contains Postblock declarations.
User-defined postblocks must always be declared by defining the postblock with a postblock label
following the syntax rules for postblocks. A user-defined postblock must be called from a predefined
postblock.
Note: To produce output, predefined postblocks must be declared, and postlines with statements for
processing the output must be written. If they are not found in the post customization file as a
declaration, control is immediately returned without any warning to the user. If output statements that
produce output are not present in your post customization file, the NC file will be empty or missing
critical motion output.
System numbered question area

The System Question area contains the following:
System numbered questions, which are evaluated by Mastercam when the post is loaded. They
can also be evaluated in the post.
User numbered questions are the same form as the system questions but are evaluated in the post.
The system questions can also be evaluated in the post.
Sample post: MP_EZ.PST

MP_EZ.PST is a generic post, which means that, while it provides commonly used output codes and
formats, it is not customized for a particular machine or control. It is intended to be customized.
Examine the sections of MP_EZ.PST illustrated below to familiarize yourself with its format and
organization. (Note: This is not the complete post.) You may not understand all statements. Post
comments (marked by #) help explain each line. The title block, revision log, and feature list should be
read carefully to understand what is supported by the post customization file and instructions on how it
is intended to be used.
Definition area
Title block # Post Name : MP_EZ
# Product : MILL
# Machine Name : GENERIC FANUC
# Control Name : GENERIC FANUC
# Description : GENERIC FANUC 3 AXIS MILL POST
# Associated Post : NONE
# Mill/Turn : NO
# 4-axis/Axis subs. : NO
# 5-axis : NO
# Subprograms : NO
# Executable : MP 9.10
#
# WARNING: THIS POST IS GENERIC AND IS INTENDED FOR MODIFICATION TO
# THE MACHINE TOOL REQUIREMENTS AND PERSONAL PREFERENCE.
Revision log # ---------------------------------------------------------------------
# Revision log:
# ---------------------------------------------------------------------
# Programmers Note:
# CNC 01/12/01 - Initial post setup v8.1
# CNC 01/09/02 - Initial post update for V9.0
# CNC 05/01/02 - Set "helix_arc:2", support helix arc output in XY plane
# CNC 02/04/03 - Initial post update for V9.1
#

Feature list # --------------------------------------------------------------------------

# Features:
# --------------------------------------------------------------------------
# This post supports Generic Fanuc code output for 3 axis milling and was
# derived from the MPFAN post which supports 4 axis milling and subprograms.
# It is designed to support the features of Mastercam Mill V9.
#
#
# Following Misc. Integers are used:
#
# mi1 - Work coordinate system
# 0 = Reference return is generated and G92 with the
# X, Y and Z home positions at file head.
# 1 = Reference return is generated and G92 with the
# X, Y and Z home positions at each tool.
# 2 = WCS of G54, G55.... based on Mastercam settings.
#
# mi2 - Absolute or Incremental positioning at top level
# 0 = absolute
# 1 = incremental
#
# mi3 - Select G28 or G30 reference point return.
# 0 = G28, 1 = G30
#
#Canned text:
# Entering cantext on a contour point from within Mastercam allows the
# following functions to enable/disable.
# Cantext value:
# 1 = Stop = output the "M00" stop code
# 2 = Ostop = output the "M01" optional stop code
# 3 = Bld on = turn on block delete codes in NC lines
# 4 = bLd off = turn off block delete codes in NC lines
#
#
#Drill:
# All drill methods are supported in the post.
#
#Additional Notes:
# 1) G54 calls are generated where the work offset entry of 0 = G54,
# 1 = G55, etc.
# 2) Metric is applied from the NCI met_tool variable.
# 3) Incremental mode calculates motion from home position at toolchanges.
# The home position is used to define the last position of the tool
# for all toolchanges.
# 4) The variable 'absinc' is now pre-defined, set mi2 (Misc. Integer) for
# the absolute/incremental program output.
#
# END_HEADER$
Debug # --------------------------------------------------------------------------
# Debugging and Factory Set Program Switches
switches, # --------------------------------------------------------------------------
program m_one : -1 #Define constant
constant zero : 0 #Define constant
one : 1 #Define constant
definitions, two : 2 #Define constant
program three : 3 #Define constant
switch and four : 4 #Define constant
variable five : 5 #Define constant
c9k : 9999 #Define constant
initialization
fastmode : 1 #Posting speed optimization
bug1 : 2 #0=No display, 1=Generic list box, 2=Editor
bug2 : 30 #Append postline labels, non-zero is column position?
bug3 : 0 #Append whatline no. to each NC line?
bug4 : 1 #Append NCI line no. to each NC line?
whatno : yes #Do not perform whatline branches? (leave as yes)
skp_lead_flgs : 1 #Do NOT use v9 style contour flags

get_1004 : 1 #Find gcode 1004 with getnextop?
rpd_typ_v7 : 0 #Use Version 7 style contour flags/processing?
strtool_v7 : 2 #Use Version 7+ toolname?
tlchng_aft : 2 #Delay call to toolchange until move line
cant_tlchng : 1 #Ignore cantext entry on move with tlchng_aft
newglobal : 1 #Error checking for global variables
getnextop : 0 #Build the next variable table


# --------------------------------------------------------------------------
# General Output Settings
# --------------------------------------------------------------------------
sub_level : 0 #Enable automatic subprogram support
breakarcs : 1 #Break arcs, 0 = no, 1 = quadrants, 2 = 180deg. max arcs
arcoutput : 1 #0 = IJK, 1 = R no sign, 2 = R signed neg. over 180
arctype : 2 #Arc center 1=abs, 2=St-Ctr, 3=Ctr-St, 4=unsigned inc.
do_full_arc : 0 #Allow full circle output? 0=no, 1=yes
helix_arc : 2 #Support helix arc output, 0=no, 1=all planes, 2=XY plane
arccheck : 1 #Check for small arcs, convert to linear
atol : .01 #Angularity tolerance for arccheck
ltol : .002 #Length tolerance for arccheck
vtol : .0001 #System tolerance
maxfeedpm : 500 #Limit for feed in inch/min
ltol_m : .05 #Length tolerance for arccheck, metric
vtol_m : .0025 #System tolerance, metric
maxfeedpm_m : 10000 #Limit for feed in mm/min
force_wcs : yes #Force WCS output at every toolchange?
spaces : 0 #No. of spaces to add between fields
omitseq : no #Omit sequence no.
seqmax : 9999 #Max. sequence no.
stagetool : 0 #0 = Do not pre-stage tools, 1 = Stage tools
use_gear : 0 #Output gear selection code, 0=no, 1=yes
max_speed : 10000 #Maximum spindle speed
min_speed : 50 #Minimum spindle speed
nobrk : no #Omit breakup of x, y & z rapid moves
progname : 1 #Use uppercase for program name
Format # ---------------------------------------------------------------------
# Format statements - n=nonmodal, l=leading, t=trailing, i=inc, d=delta
statements # ---------------------------------------------------------------------
#Default english/metric position format statements
fs2 1 0.7 0.6 #Decimal, absolute, 7 place, default for initialize (:)
fs2 2 0.4 0.3 #Decimal, absolute, 4/3 place
fs2 3 0.4 0.3d #Decimal, delta, 4/3 place
#Common format statements
fs2 4 1 0 1 0 #Integer, not leading
fs2 5 2 0 2 0l #Integer, force two leading
fs2 6 3 0 3 0l #Integer, force three leading
fs2 7 4 0 4 0l #Integer, force four leading
fs2 9 0.1 0.1 #Decimal, absolute, 1 place
fs2 14 0.3 0.3d #Decimal, delta, 3 place
fs2 16 1 0 1 0n #Integer, forced output
Format # ---------------------------------------------------------------------
# Format assignments – prefix, fs#, variable
assignments # ---------------------------------------------------------------------
fmt T 4 t #Tool No: prefix T, fs4, variable t
fmt T 4 first_tool #First Tool Used: prefix T, fs4, first_tool
fmt T 4 next_tool #Next Tool Used: prefix T, fs4, next_tool
fmt D 4 tloffno #Diameter Offset No: prefix D, fs4, tloffno
fmt H 4 tlngno #Length Offset No: prefix H, fs4, tlngno
fmt G 4 g_wcs #WCS G address: prefix G, fs4, g_wcs
fmt P 4 p_wcs #WCS P address: prefix P, fs4, p_wcs
fmt S 4 speed #Spindle Speed: prefix S, fs4, speed
fmt M 4 gear #Gear range: prefix M, fs4, gear
String and # --------------------------------------------------------------------------

#String and string selector definitions for NC output
string select # --------------------------------------------------------------------------
definitions
#Address string definitions
strm "M"
strn "N"
stro "O"
strp "P"
srad "R"
srminus "R-"
sblank
#Cantext string definitions (spaces must be padded here)

sm00 "M00"
sm01 "M01"
strtextno
strcantext


# --------------------------------------------------------------------------
# General G and M Code String select tables
# --------------------------------------------------------------------------
# Motion G code selection
sg00 G0 #Rapid
sg01 G1 #Linear feed
sg02 G2 #Circular interpolation CW
sg03 G3 #Circular interpolation CCW
sg04 G4 #Dwell
sgcode #Target for string
fstrsel sg00 gcode sgcode

# --------------------------------------------------------------------------
# Select work plane G code
sg17 G17 #XY plane code
sg19 G19 #YZ plane code
sg18 G18 #XZ plane code
sgplane #Target string
fstrsel sg17 plane sgplane #Target string
Lookup # Define the gear selection code

flktbl 1 3 #Lookup table definition - table no. - no. entries
Table #entries
40 0 #Low gear range
41 400 #Med gear range
42 2250 #Hi gear range
Postblock area
# --------------------------------------------------------------------------
# Tool Comment / Manual Entry Section
# --------------------------------------------------------------------------
ptoolcomment #Comment for tool
tnote = t
toffnote = tloffno
tlngnote = tlngno
"(", pstrtool, *tnote, *toffnote, *tlngnote, *tldia, ")", e
pstrtool #Comment for tool

if strtool <> sblank,
[
strtool = ucase(strtool)
*strtool, " "
]
pcomment #Comment from manual entry (must call pcomment2 if booleans)

pcomment2
pcomment2 #Comment from manual entry

scomm = ucase (scomm)
if gcode = 1007, "(", scomm, ")"
else, "(", scomm, ")", e
# --------------------------------------------------------------------------
# Start of File and Toolchange Setup
# --------------------------------------------------------------------------
psof0 #Start of file for tool zero
psof
psof #Start of file for non-zero tool number

toolchng = one
if ntools = one,
[
#skip single tool outputs, stagetool must be on
stagetool = m_one
!next_tool
]
"%", e
*progno, e
"(PROGRAM NAME - ", progname, ")", e
"(DATE=DD-MM-YY - ", date, " TIME=HH:MM - ", time, ")", e
pbld, n, *smetric, e
pbld, n, *sgcode, *sgplane, "G40", "G49", "G80", *sgabsinc, e
sav_absinc = absinc
if mi1 <= one, #Work coordinate system
[
absinc = one
pfbld, n, sgabsinc, *sg28ref, "Z0.", e
pfbld, n, *sg28ref, "X0.", "Y0.", e
pfbld, n, "G92", *xh, *yh, *zh, e


absinc = sav_absinc
]
pcom_moveb
ptoolcomment
comment
pcan
if stagetool >= zero, pbld, n, *t, "M6", e
if mi1 > one, absinc = zero
pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout,
*speed, *spindle, pgear, strcantext, e
pe_inc_calc
ps_inc_calc
absinc = sav_absinc
pbld, n, sgabsinc, e
pbld, n, "G43", *tlngno, pfzout, scoolant, next_tool, e
pcom_movea
toolchng = zero
System numbered question area

# --------------------------------------------------------------------------
# Numbered questions for Mastercam Mill
# --------------------------------------------------------------------------
38. Rapid feedrate? 300.0
1538. Rapid feedrate (metric)? 10000.0
80. Communications port number for receive and transmit (1 or 2) ? 2

81. Data rate (110,150,300,600,1200,2400,4800,9600,14400,19200,38400)? 1200
82. Parity (E/O/N)? E
83. Data bits (7 or 8)? 7
84. Stop bits (1 or 2)? 2
85. Strip line feeds? N
86. Delay after end of line (seconds)? 0
87. Ascii, Eia, or Binary (A/E/B)? A
88. Echo keyboard to screen in terminal emulation? n
89. Strip carriage returns? N
90. Drive and subdirectory for NC files?

91. Name of executable post processor? MP
92. Name of reverse post processor? RP
93. Reverse post PST file name? RPFAN
100. Number of places BEFORE the decimal point for sequence numbers? 3
101. Number of places AFTER the decimal point for sequence numbers? 0
Post modification guidelines

Note: The post you need might already exist. Always contact your Mastercam dealer to see if an
appropriate post is available.
Most importantly, before you make any changes to a post customization file, create a copy of
the original file as a backup. Until you have complete confidence in a post version, you
should keep previous versions, uniquely named, so that you can return to a previous version
if necessary.
Try to find an existing post that produces a format similar to your requirement.
Try to use a post that was written for the Mastercam version you are using. Determine if the post
supports any new features in Mastercam. It is much easier to modify a post customization file that
supports the new features than to add support for new features to an older post.
Have the NC control's operator or programming guide available before starting to make any post
modifications. Most controls are very specific about the data they expect to receive and will not
function properly if there are any NC code syntax errors. Carefully test the NC code you generate
for your machine control. Machine builders can change the format of the NC code or the behavior
of the machine tool with machine tool parameter settings. The documentation that is provided with
the machine tool may be out of date or inaccurate.

Understand how the post customization file you are about to modify works and the NCI Gcode
input before making any changes to the post. Do not blindly use a post comment (#) to remove MP
code in the post customization file. Required procedures may be removed and adversely impact
the NC output.
Read all of the revision, features, and usage notes at the beginning of the .PST file before making
any changes. Log and document any changes you make in the Revisions area.
Check the toolpaths, parameter page entries, and the NCI file data to be sure that input from your
sample Mastercam file is correct.
Test and debug all changes you make to the post customization file before using the posted NC
output in a production environment.
MP language syntax rules

This section summarizes the MP language syntax rules that apply to the most frequently used language
features. Additional rules may be found in the reference sections that describe the feature.
See Numeric Variables, String Variables, Postblocks, etc. for more information. For detailed syntax
descriptions, see Volume 3.
General post formatting rules

Although the MP language is not case-sensitive, it is recommended to use lowercase for all the MP
language features.
Features that begin in the first column
The first column (that is, the first character position next to the left margin) is reserved. The following
features must begin in the first column and are the only features that can begin in the first column:
Numeric variable initialization
Global formula
String variable initialization
Format statement
Format assignment
String select function
User prompt function
Lookup table function
Parameter table function
Buffer file function
Postblock declaration
System numbered questions
Post comments
Features that must be indented
Output postlines
Formula postlines
Boolean postlines
Lookup table entries
Parameter table entries
Post comments
Variable initialization rules

Predefined variables do not have to be initialized or formatted. See Volume 3, Numeric Variables
and Volume 3, String Variables for a complete list or predefined variables.
Predefined numeric variables are initialized in the post executable file to 0 by default. The
predefined variables: atol, arc_tol, chord_tol, helix_tol, ltol, vtol, xtol, scalex, scaley, scalez, date, time,
mon and the post constants (pi, deg2rad, rad2deg, etc.), are initialized to values appropriate for them.
You can also initialize them to different values in the post customization file.
Labels used for predefined variables and predefined postblocks are reserved. When defining user-
defined variables, make sure not to use the label of a predefined variable or postblock.
See Volume 3, Numeric Variables and Volume 3, Postblocks for a complete list.
Numeric variable labels must start with an alpha (a-z) character.
String variable labels must start with the letter “s”.
User-defined numeric variables must be formatted and/or initialized.
User-defined string variables are only initialized. Do not attempt to initialize or format them using
the syntax for numeric variables. They may be initialized without a character string to define an
empty (null) string.
If a numeric variable will not be output because it will be used for calculations only, it does not
have to be formatted.
Format and/or initialize a variable only once. You can reassign a value or string to a variable
within a postblock by using a formula statement.
If you do not assign a format to a numeric variable, the format statement 1 is assigned by default.
Use the colon (:) to initialize numeric variables, for example:
newx : 10.
Use a space (at least one) to initialize a string variable, for example:
snewstring “G01”
Do not use the equal sign (=) to initialize a string or numeric variable. This creates a global
formula when used outside a postblock. Always use the (:) colon to initialize a numeric variable.
A Variable used in a formula that is part of an assignment in either a global formula or initialization
must be defined before it is used in the assignment formula.
Postblock and postline rules

Postblock labels must begin in the first column.
Postblock labels begin with letter “p”. Although the letters “m” or “l” are also used, they are
intended for use with mill/turn applications.
A postblock label must be on a line by itself (except for post comments).
User-defined postblock labels must not duplicate predefined postblock labels.
Any MP language feature that starts in the first column following a postblocks postline(s) indicates
the end of that postblock. The exception is the post comment (#).
It is recommended that the open and close brackets ([,]) that enclose the postlines in a bracketed
postblock be on lines by themselves.
Do not nest bracketed postblocks more than 25 levels deep.
Indent the brackets used with the bracketed postblock.
Postlines must always be indented.

NC lines are built in the order in which the output statements occur on the postline. What you see
in the post customization file is what you get in the NC output. Keep in mind that modality and
other factors control what is actually output to the NC file.
See Volume 1, Numeric Variables for more information on modality.
Use commas (,) to separate output statements.
Output statements can continue over multiple lines by placing a comma at the end of the line (and
before any post comment).
Terminate a series of output statements that are intended to produce NC output with the “e”
command variable. This tells the post executable to write the end-of-block characters.
Output statements may follow the comma delimiter on a Boolean postline.
A formula statement must be on a single line. Do not put more than one formula statement on a
line.
A single formula statement on a single line can follow the comma delimiter on a Boolean postline.
A conditional branching statement can never follow the comma delimiter on a Boolean postline.
A conditional branching statement can continue over multiple lines until the comma delimiter is
found.
Never use the colon (:) as an assignment operator in a postline formula statement. The colon is
reserved for initialization only.
In a conditional branching statement, use a space to separate the Boolean keyword (if, else, while)
from the formula.
Limits
Feature Maximum
Numeric variable label length 25 characters

String variable label length 25 characters
Postblock label length 25 characters
String assignment length 120 characters
Number of nested postblock calls 50
Number of nested bracket postblocks 50
Number of format statements (fs/fs2) 30
Format assignment (fmt) prefix length 15 characters
Format assignment (fmt) suffix length 15 characters
Numeric variable definitions 32,700
String definitions 32,700
String length in buffer file 80 characters
Postblock definitions 32,700
Number of user prompt questions 20

ADDENDA
Using regions to organize your post

The Code Expert editor that was introduced in Mastercam X7 supports the use of
collapsible regions in your post. Regions are a useful way to organize the resources in your
post, and make it easy for other people to understand how your post is organized.
When you hover over a region, Mastercam displays a tooltip with a preview of the region’s
contents:
To create a collapsible region in your post, follow these steps:

1 Insert the #region keyword at the beginning of the line where you want the
region to begin.
2 Follow it with the name of the region. You can use any phrase or string; MP will
simply treat it as a comment.
3 Insert the #endregion keyword at the beginning of the line where you want the
region to end.
Please pay attention to the following guidelines:
 The #region and #endregion keywords are not case-sensitive, but lower-case is
the typical convention.
ADDENDA
 You cannot have a space between the # and region or endregion.

 You cannot place a #region keyword before the first line (the
[POST_VERSION]... header).
 You cannot use regions in the post text area of your post. All of your regions must
be closed before your first post text tag.
Note that the region keywords are meaningless to MP itself. They are only used by the Code
Expert editor; MP treats them like any other comment in your code.
Nested regions—You can nest regions inside one another, so long as each region has its own
#endregion keyword. When nesting regions, it is a good practice to include a comment
before each #endregion keyword that indicates which region it is closing. Please note that
when you nest regions, you cannot indent them; nested regions should still start in the first
column of the line.
Common post tasks or How do I …?

This section provides brief descriptions of how to make changes to the MP_EZ post to perform some
of the more common tasks. These changes affect the NC output file. These techniques often relate to
other post customization files. Please refer to the sections cited for details.
How do I …?
Change the start-of-file Search for the postblock psof in the post customization file. Replace the % character in this line:
character "%", e
with the one needed on for your machine tool. If the character cannot be typed, replace the “%”
characters with the ASCII decimal equivalent. For example:
35, e # This will output a ‘#’ pound symbol character
Remove (or #comment out) the line if no special character is needed.
Change the end-of-file Search for the postblock peof in the post customization file. Follow the procedure used in “Change
character the start-of-file character.
Pre-stage tools for the MP_EZ post was set up to do this. Search for the numeric variable stagetool and find this line:
machines tool changer stagetool : 0 #0 = Do not pre-stage tools, 1 = Stage tools
and set the initialization to 1.
stagetool : 1 #0 = Do not pre-stage tools, 1 = Stage tools
At the end of the NC Search for the postblock peof in the post customization file. Find the line:
file, I want the first tool #if stagetool = one, pbld, n, *first_tool, e
pre-staged
and remove the # character. The # makes this statement a comment. Removing it exposes the code to
the post executable.
Separate the tool This change must be done in two postblocks. Search for the postblock psof in the post customization
number and tool file. Replace the entire line:
change command if stagetool >= zero, pbld, n, *t, "M6", e
with these lines:
if stagetool >= zero, pbld,
[
n, *t, e
n, "M6", e
]
By reordering the lines, you can reverse where the tool and command appear. Search for the postblock
‘ptlchg’ and repeat the process.
Use G92 instead of The Miscellaneous Integer number 1 is used to control this feature in this post. Search for “301.” in the
G54 post customization file. Change the response to 0. The next time the post is loaded, the setting takes
effect.
If you have existing operations, you will need to modify them from the Operations Manager in
Mastercam. Right-click and select Options, Edit Common Parameters. In the Tool Parameters dialog
box, select the Misc. values button and change the first Integers to 0.

Do not break the arcs Search for the numeric variable breakarcs and find this line:
breakarcs : 1 #Break arcs into quadrants?
at the quadrants
Set the initialization to 0.
breakarcs : 0 #Break arcs into quadrants?
Output I,J,K with arcs MP_EZ is coded to output R or I,J,K automatically with a user-defined numeric variable as a switch.
Search for the numeric variable ‘arcoutput’ and find this line:
Output R signed when Follow the procedure used in “Output I,J,K with arcs” but set the initialization to 2.
the sweep exceeds arcoutput : 2 #0 = IJK, 1 = R no sign, 2 = R signed neg. over 180
180 degrees
Allow sequence Search for the numeric variable seqmax and find this line:
numbers to be greater seqmax : 9999 #Max. sequence no.
than N9999
Set the initialization to the appropriate value. Note: You control the initial sequence number and
increment amount in the Mastercam toolpath parameters dialog box.
Omit sequence Search for the numeric variable use_gear and find this line:
numbers entirely omitseq : no #Omit sequence numbers?.
Set the initialization to yes.
omitseq : yes #Omit sequence numbers?.
Set up a gear range Search for the numeric variable use_gear and find this line:
table use_gear : 0 #Output gear selection code, 0=no, 1=yes
use_gear : 1 #Output gear selection code, 0=no, 1=yes
Next search for the post function ‘flktbl’ and find this line:
flktbl 1 3 #Lookup table definition - table no. - no. entries
A lookup table equates the spindle speed to gear range value. The postline here:
gear = frange (one, speed)
from the postblock ‘pgear’ returns the selected value to the numeric variable gear, which is
subsequently formatted and output. Adjust the table to your requirements by modifying and adding to
the lookup table entries. Remember to keep the ‘no entries’ current on the table declaration line.
Search for the post function fstrsel and find this line:
Modify the motion
Gcode
The string variables above this line are used in the string selection and are placed in the target string
variable sgcode, which is used as an output statement. To modify the output, simply modify the string
variables character string. For example, change:
sg00 G0 #Rapid
to:
sg00 G00 #Rapid
to output “G00” instead of “G0”.

Change the numeric The post function fs and fs2 are used to define the numeric format for numeric variables. These are
format of a numeric assigned to the numeric variable label with the post function ‘fmt’. First, determine the numeric variable
variable name that you want to modify. Search for the variable name in the post and see if it is in a format
assignment (you may need to create a format assignment for the numeric variable). For example, to use
feed:
fmt F 15 feed #Feed rate
The third parameter (second if there were no prefix) indicates that the format assignment is from format
statement number 15. Now search for Format statement number 15 and find:
Refer to Volume 1, Numeric Variables for information on modifying the numeric format.
Change the prefix of a Following the procedure used in “Change the numeric format of a numeric variable”, stop at the
numeric variable point where you found the format assignment. Between the keyword ‘fmt’ and the format statement
number is the optional prefix string. In the above example, you can replace F with E:
fmt E 15 feed #Feed rate
to output something like E1.5
Use double quotes if the prefix string has spaces.
Select long code or The usecan… predefined numeric variables control the post executable to determine which process to
canned cycle drilling use. Search for the partial string usecan to find the numeric variable initialization.
output See Volume 1, Working with Drill Cycles for more information.
Change the order of You can change the order of the words output to the NC file simply by rearranging the output statements
words in the NC output on a postline. For example, this line is copied from the postblock plinout:
pcan1, pbld, n, sgplane, `sgcode, sgabsinc, pccdia,
pxout, pyout, pzout, feed, strcantext, scoolant, e
possible output: N10G1G90X10.Y10.F5.M8
can be rearranged to:
pcan1, pbld, n, ` sgabsinc, sgcode, sgplane, pccdia,
pxout, pyout, pzout, strcantext, scoolant, feed, e
possible output: N10G90G1X10.Y10.M8F5.
Prompt the user for You must declare a user prompt function to display a prompt on the Mastercam screen. In the Definition
information during section of the post customization file, enter a user prompt function. For example:
posting
fq 1 omitseq Enter 1 to omit sequences, 0 to use sequences>
Call the question by inserting “q” with the fq definition number (for example, q1) on a separate postline
in the postblock where you want to prompt the user. pq would be a logical postblock for this user
prompt function call. See Volume 1, How Prompt Questions Work for details.
Control the number of Search for the numeric variable spaces and find this line:
spaces between words spaces :0 #No. of spaces to add between fields
in the NC output
Set the initialization to the appropriate number of spaces (10 is the maximum). Spaces are padded in
front of the output word.

Volume 1 Chapter 3 Changes to the MP Post
3 Changes to the MP Post
[This chapter has been removed. It is obsolete.]
Chapter 3 Changes to the MP Post Volume 1
Volume 1 Chapter 4 Post Debugging Techniques
4 Post Debugging Techniques
[This chapter is obsolete and has been removed. This functionality has been replaced by the Mastercam
Post Debugger. See the Debugger User’s Guide to learn more.]
Chapter 4 Post Debugging Techniques Volume 1
Volume 1 Chapter 5 Using Numbered Questions
5 Using Numbered Questions
[This chapter is obsolete and has been removed. This functionality has been moved to the control
definition. See the current control definition documentation to learn more.]
Chapter 5 Using Numbered Questions Volume 1
Volume 1 Chapter 6 Using the Post Text File
6 Using the Post Text File
[This chapter is obsolete and has been removed. This functionality has been moved to the control
definition. See the current control definition documentation to learn more.]
Chapter 6 Using the Post Text File Volume 1
Volume 1 Chapter 7 Postblocks
7 Postblocks
A postblock is a labeled block, or series of lines, of MP language code in the post customization file
(.PST file). The post executable file (the .DLL file) interprets the code in the postblocks to create a list
of instructions that produce the NC output, perform calculations and call other postblocks. These
blocks of MP language code produce the NC output.
For a list of postblock descriptions, see Volume 3, Postblocks.
The postblock role

To produce an NC file, a post processor interprets a Mastercam intermediate NC file (called the NCI
file). To do this, the post executable opens the NCI file and begins reading two lines at a time. Each
two-line set produces a call to a specific predefined entry postblock in the post customization file.
Predefined postblocks are postblocks defined as part of the MP language (whereas postblocks defined
by a post writer are called user-defined postblocks). An entry postblock is the point in the post
customization file where the post executable begins executing postblock instructions.
The first line in the two-line set that the post executable reads from the NCI file is the NCI Gcode. This
line contains a single value - the NCI Gcode - which is the key to how the second line will be
interpreted and how the information will be processed by the post executable.
The second line in the two-line set contains parameters that complete the data to be passed with the
NCI Gcode. The post executable places these parameters values into appropriate predefined MP
variables.
A typical scenario for a motion NCI Gcode (for example, Gcode 2) follows:
1. The post executable reads the first NCI line of a two-line set and stores the single parameter on
that line as the NCI Gcode in the variable gcode.
2. The post executable then stores the parameters on the second line of the two-line set into
appropriate predefined numeric variables. For NCI Gcode 2, this would be the plane variable
(plane), cutter compensation (cc), X (x), Y (y), arc center in X (xc), arc center in Y (yc), Z (z)
position, feed rate (fr) and the contour flag. The order of the parameters in the second NCI line
determines in which predefined variable the value on the line is stored.
3. Additional calculations are performed to generate values for other predefined variables that are
commonly used for the NCI Gcode type.
4. Routines in the post executable that were enabled in the post customization file are performed.

Chapter 7 Postblocks Volume 1
5. Based on the value of the NCI Gcode, the post executable calls a specific MP language
mechanism called a predefined postblock. For NCI Gcode 2, the post executable calls the
predefined postblock pcir. The predefined postblock that is called based on the NCI Gcode is
an entry postblock because it is the point in the post customization file where the instructions in
the postblock begin executing.
Following the flow of the logic in the postblock, the post executable file interprets each line in
the postblock, which are called postlines. Each postline is interpreted by examining the MP
language statements contained in the line, in order, from left to right.
6. Depending on the MP language statement type, a character string is assembled that is the NC
output.
7. When the post executable determines that the NC output line is complete, it writes the line to
the NC output file.
8. The post executable continues processing MP language statements until the final instruction in
the entry postblock is processed.
9. The post executable reads two more lines and repeats the process.
From this description, you can see that the role of the predefined entry postblock is to provide a starting
point for processing the post writer’s MP language instructions in the post customization file. The
mechanism that controls the postblock entry also gives the post writer control over which instructions
are executed based on the NCI Gcode. The postblock structure allows the post writer to jump to other
postblocks and to nest postblocks.
Postblocks support the MP language features that allow the post writer to:
Perform calculations and MP language functions
Perform conditional branching
Manipulate processing in the post executable (beyond what was done with initializing
numeric variables that are post switches)
Call routines in the post executable
Generate NC code
Postblock structure
A postblock is a labeled series of postlines containing MP language statements that produce NC output,
branch conditionally, perform calculations, call other postblocks, and trigger routines in the post
executable.
There are two possible postblock structures:
Traditional postblock
Bracketed postblock

Traditional postblocks
A traditional postblock has two components:
Postblock label
One or more postlines
The postblock label declares the traditional postblock. A postblock label usually begins with the letter
“p” (although “l” and “m” can also be used), must be in the first column, and must be on a line by itself
(with the exception of any #comment).
See Postblock rules summary for a more complete list of rules.
Bracketed postblocks
Another form of postblock is the bracketed postblock, which is a user-defined nested postblock. The
post writer declares a bracketed postblock by using the open and close brackets ([,]) as postline
statements surrounding the postlines to be nested.
Bracketed postblocks are intended to make the post customization file more readable and are always
used within the traditional postblocks.
Bracketed postblocks are implied postblocks, which means they do not have postblock labels declared
by the post writer.
Note: The post executable assigns labels to implied postblocks, which are used internally when the post
customization file is parsed.
Postlines
Postlines are the remaining components of the postblock. A postblock can be declared without any
postlines but this serves no useful purpose.
Postline format rules

Can start in any column except the first.
Must use consistent indentation to make the organization of the post clear.
All postlines that are not nested in bracketed postblocks are considered part of a postblock
until another label in the first column is encountered. This label can be another postblock
label, a variable label, or post function declaration.
Post comments are ignored and do not end the postblock.

Traditional postblock examples

pblock # This is traditional postblock declaration, a comment is allowed.
x, y, z, e # This is postline with output statements.
pcomment2 # This is traditional postblock declaration, using Boolean logic IF/ELSE branching.
if gcode = 1007, “(“, scomm, “)”
else, “(“, scomm, “)”, e
An example of a traditional postblock with bracketed postblocks:

pblock # This is a traditional postblock declaration, a comment is allowed.
x, y, z # This is postline with output statements.
if cc_pos, # This is postline with a conditional branching statement.
[ # This is postline with start of a bracketed postblock.
tloffno, e # This is postline in the bracketed postblock.
] # This is postline ends a bracketed postblock.
else, # This is postline with an else condition for the previous if postline.
[ # This is postline with start of a bracketed postblock.
“D0”, e # This is postline in the bracketed postblock.
] # This is postline ends a bracketed postblock.
Postblock declaration
Traditional and bracketed postblocks are declared differently.
Traditional postblocks
A traditional postblock label is used in the following ways:
to declare the postblock
to identify the postblock
in a postline statement to call a postblock
Traditional postblock labels:
Must always start in the first column
Must begin with the letter “p”, “l”, or “m”
May contain letters (a - z), numbers(0 - 9), and the underscore character ( _)
May be a maximum of 25 characters long
Must be on a separate line except for a post comment ( # )
Note: Both predefined and user-defined postblocks are declared the same way.
All postlines that are not nested in bracketed postblocks are considered part of the postblock until a
label in the first column is encountered. This label can be another postblock label, a variable label or
post function declaration. Post comments are ignored and do not end the postblock.

A bracketed postblock is declared not by a label but by the open and close brackets ([,]) as postline
statements surrounding the postlines to be included in the bracketed postblock.
The post executable assigns a label to bracketed postblocks when the post customization file is parsed.
The assigned labels can be seen when the debugging options are enabled. The labels are created by
concatenating the string “p__”, a number that is the occurrence of the bracket set, the colon “:” and the
line number in the post customization file that the open bracket was on. For example, the first
bracketed set found with the “[” on line 100 would result in the post executable assigning ‘p__0:100’.
Bracketed postblocks:
Are always inside a traditional postblock
Start with the “[“ as an output statement on an output postline
End with the “]“ as an output statement on an output postline
Should have the nesting brackets on separate lines except for a post comment (#)
Can be nested to a maximum of 50 levels deep
Are always user-defined type postblocks
Postblock types
There are many postblock types. Each type serves a purpose in the posting process. Listed here are the
main types and subtypes:
Standard user-defined postblocks
Pre-process postblocks
Preparatory postblocks
Pre-output postblocks
Standard postblocks
Command postblock
Post-process postblock
User-defined postblocks are declared by the post writer. User-defined postblocks can be called (or
jumped to) only from another postblock and can never be called as entry postblocks based on the NCI
Gcode or from an internal post executable routine.
Predefined postblocks are an integral part of the MP language. The labels for the predefined postblock
are part of the post executable and are called by specific NCI Gcode, command statements, or post
processing order.

All predefined postblocks attempt an entry into the instruction list that was parsed from the post
customization file. If there is no postblock declaration for the predefined postblock, the attempt to enter
the instruction list fails and control is returned to the post executable.
At the end of this chapter you will find descriptions all predefined postblocks.
Pre-process postblocks
Pre-process postblocks are called before post processor reads the NCI file. These postblocks do not
have access to the NCI file data. The following are preprocess postblocks:
pprep
Allows post instructions after the post is parsed but before the NC and NCI file are opened. Do not
attempt to output to the NC file in this postblock because the NC output file is not yet opened.
pq
Allows post instructions after the NC and NCI file are opened but before reading NCI data.
Preparatory postblocks
Preparatory postblocks have access to limited NCI data and are called optionally before the normal
processing NCI file read loop. Preparatory postblocks are called on the NC tool change Gcodes and
NCI parameter Gcodes.
The following are preparatory postblocks:
ptooltbl
An obsolete routine that should no longer be used. It was used to create a tool table.
pwrtt
Provides tool change data from the NCI and scanned information from the toolpaths themselves.
Note: Both ptooltbl and pwrtt are called when the NCI tool change Gcodes are found by the post
executable in the NCI file.
pwrttparam
Called by the NCI parameter Gcodes; similar to the pparameter predefined postblock routine but is part
of the preparatory NCI file scan.
Note: Calls to these postblocks must be enabled in the post customization file by inserting and setting
the post switch variable tooltable to 1 (on).
ptooltbl and pwrtt are mutually exclusive. If you have used ptooltbl (not recommended) then you
should not have pwrtt in your post customization file and vice versa.
See How Preparatory Postblocks Work for more information.

Pre-output postblocks
Pre-output postblocks are called based on the NCI Gcode but before internal calculations are performed
in the post executable. Pre-output postblocks have labels with a “0” or “00” suffix, for example psof00,
ptlchg00, plin0, pcir0, and peof00. If pre-output postblocks are present in the post customization file, the
post executable first calls the preparatory postblock with the same name, for example, pcir0, and then
the standard postblock pcir.
Important Note: Postblocks psof0, ptlchg0, and peof0 are not pre-output postblocks. The “0” suffix with
psof0 and peof0 indicate to the post to call them if the tool number (t) is zero. The “0” suffix with
ptlchg0 indicates that the postblock is called for a null tool change (a tool change information block
where the tool number has not changed from the prior tool change).
See tool_zero in Volume 3, Numeric Variables for important related information.
Standard postblocks
Standard postblocks are called based on the NCI Gcode after internal calculations are performed in the
post executable.
Command postblocks
Command postblocks are called during the normal NCI file processing but perform delayed calls to
output comments, subprograms and canned cycles at locations in the NC code where the user and NC
code require them. They are provided to add flexibility when generating output of comments,
subprograms and canned cycles. The following are command postblocks:
pcomment
Outputs comments to the NC file.
psub_st_m
Called for transform subprograms to write the subprogram header.
psub_call_m
Used for transform subprograms and a single tool to call the subprogram.
psub_call_mm
Used for transform subprograms and many tools to call the subprogram.
prcc_setup
Used to capture information from the roughing tool with lathe canned cycles.
Post-process postblock
A post-process postblock is called after posting has completed and all the files have been closed.
ppost
The only post-process postblock, it allows manipulating the NC file after posting.
Note: The post writer is responsible for opening the files before attempting to write to them.

Postlines
Postlines are the lines of MP language instructions within the postblock. They may appear only after
the postblock declaration and constitute the body of a postblock. Because certain conditions can allow
a postline to continue over more than one line in the post customization file, you must determine where
each postline ends. Never declare variables or post functions on a postline.
For example, this postblock is from the MPFAN.PST post:
ptlchg # Tool change
pcuttype
toolchng = one
if mi1 = one, # Work coordinate system
[
]
pbld, n, "M01", e
pcom_moveb
c_mmlt # Multiple tool subprogram call
ptoolcomment
comment
pcan
pbld, n, *t, "M6", e
pindex
sav_absinc = absinc
pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout,
pfcout, *speed, *spindle, pgear, strcantext, e
absinc = sav_absinc
pcom_movea
toolchng = zero
c_msng # Single tool subprogram call
Postline types
Some postlines generate output and some provide logic within the post customization file.
Basic postline types are determined by the type of statement at the beginning of the postline. Listed
here are the basic postline types:
Output
Formula
Boolean
Output postline
The term output postline is misleading because the statements on this postline often do not generate
output. An output postline may contain variables, commands, string literals, ASCII decimal equivalent,
and postblock call statements. It is considered an output postline, as long as the line is not a formula
postline or Boolean postline.

Formula postline
Formula postlines are assignments or equations. A result variable followed by an equal sign (=) as the
first item on the postline identifies a formula postline.
The following function calls should always be entered as formula postlines:
Lookup table function call
Parameter table function call
Buffer file function call
Boolean postline
Boolean postlines begin with the conditional operators “if”, “else”, or “while”.
Postline statements
Postline statements are the components that make up the postline. MP language rules determine where
the statement types can appear on a postline, how they are delimited and which basic postline types
they can be used with.
Postline statement definitions include both the variables that can be used and an action. Conditional
branching statements and formula statements are identified by formula components and keywords.
Output statements include variable modifiers.
Following are the major postline statement types:
Conditional branching statement
Formula statement
Output statements
Output line variables
• Numeric variable
• User-defined numeric variable
• Forced numeric variable
• Update numeric variable
• Format numeric variable
• Dependent numeric variable
• Debug numeric variable
• Command variable
• Previous numeric variable
• User-defined string variable
• String variable
• Forced string variable
• Dependent string variable
• Debug string variable
String select function call
• Selector string variable
• Selector forced string variable
• Selector dependent string variable

• Selector debug string variable

String literal
Dependent string literal
ASCII literal
Postblock call
User prompt function call
Conditional branching statement
The conditional branching statement begins with the conditional operators “if”, “else” or “while”,
contains a Boolean formula (see “Formula statement” below) and ends at the comma (,) delimiter that
is not part of a formula function.
For example:
if speed > maxss,
Formula statement
The formula statement begins with a result variable before the equal sign (=) that is part of an equation,
assignment or formula and ends where the actual postline ends (ignoring spaces and post comments).
The formula statement must remain on a single line in the post customization file:
speed = abs(ss)
Formula statements and conditional branching statements are similar, differing from each other only in:
The keyword that determines the type (for a formula, “variable =”, or for conditional
branching, “if”, “else”, “while”).
The end delimiter (for formula, the end of the postline, or for conditional branching, a
comma).
The way the result is interpreted also differs:
A conditional branching statement is tested for true or false and the result is zero or non-zero.
A formula statement result is returned directly in the result variable.
The following are allowed as components in the formula equation.
Math operator
Formula function
Numeric variable
User-defined numeric variable
Previous numeric variable
String variable
User-defined string variable
String literal
Note: What is allowed with any particular function or operator depends on the argument types. The
components of the formula are not considered as postline statement types; the entire statement
includes the type key and the type delimiter. See Formulas for more information.

Output statements
The term output statement is misleading, like output postline, because the statements might not
generate output. Output statements are not allowed in a formula statement or a conditional branching
statement. Output statements can continue over multiple lines in the post customization file and even
continue through postblock calls or jumps. Output statements are separated by a comma (,) between
each statement. If a postline statement was not identified as a formula statement or a conditional
branching statement, it is then assumed to be one of the output statement forms.
Output statements may contain:
String literal
ASCII literal
Postblock call
User prompt function call
Any variable that is defined, either by the post executable or in the post customization file, can be
placed on a postline as an output statement. You can modify how the post executable handles
processing of the variable by adding a prefix called a variable modifier (!, *, @ ~, etc.) The following
may be output line variables:
Numeric variables
Variables predefined in the post executable file (without any modifiers). Output to the NC file is
expected based on modality. For example:
x
User-defined numeric variables

Variables defined by a post writer in the post customization file when the declaration is made (the
undressed form of the variable); appears as declared in the post customization file postline. Output to
the NC file is expected based on modality. For example:
xabs
Variable modifiers
When added to numeric variables, variable modifiers change processing as follows:
Forced numeric variable (*)
Both user-defined numeric variables and numeric variables can be forced to output. The prefix asterisk
(*) overrides modality and forces output to the NC file. For example:
*x, *xabs

Update numeric variable (!)

Both user-defined numeric variables and numeric variables can be forced to update. The prefix
exclamation (!) updates the stored (prv_[variable name]) previous value for the variable. No output to
the NC file is expected. For example:
!x, !xabs
Format numeric variable (@)

User-defined numeric variables and numeric variables can be formatted. The prefix at symbol (@)
formats the current value for the variable base on the formatting assigned to the variable. No output to
the NC file is expected. For example:
@x, @xabs
Dependent numeric variable (`)

Both user-defined numeric variables and numeric variables can be prefixed with the grave accent (`) to
permit output to the NC file only when there is other valid output on the assembled NC line. Sequence
(n) already behaves this way. For example:
`x, `xabs
Debug numeric variable (~)

Both user-defined numeric variables and numeric variables can be forced to output without affecting
the values internal to the post executable for the variable. The prefix tilde (~) forces output to the NC
file for debugging. Do not use this for normal output. For example:
~x, ~xabs
Command variable
Command variables are unique in that they trigger an event or routine in the post executable, possibly
calling back to the post customization file for some postblock instructions. All command variables are
predefined numeric variables. Most cannot be prefixed with a variable modifier. For example:
comment

User-defined numeric variables and numeric variables are all automatically assigned a duplicate
variable (prv_[variable name]) for storing the previous value of the variable. This controls modality by
comparing the value stored in prv_[var] with the current [var]. Previous numeric variables should not be
used for normal output and cannot be prefixed with a variable modifier. These are usually output when
debugging. For example:
prv_xabs
User-defined string variable

Defined in the post customization file by the user when the declaration is made, this is the undressed
form of the variable and appears as declared in the post customization file postline. Output to the NC
file is expected. For example:
sm00

String variable
Variables of this type are the predefined variables in the post executable file. This is the undressed
form of the string variable. Output to the NC file is expected. For example:
snamenc
When added to string variables, the variable modifiers change processing as follows:
Forced string variable (*)
Both user-defined string variables and string variables can be forced to output. The prefix asterisk (*)
override forces output to the NC file. This is only necessary when the string output is based on the
modality of a (fstrel) string select function. Output to the NC file is expected. For example:
*snamenc, *sm00
Dependent string variable (`)

Both user-defined string variables and string variables can be prefixed with the grave accent (`) to
permit output to the NC file only when there is other valid output on the assembled NC line. For
example:
` snamenc, ` sm00
Debug string variable (~)

Both user-defined string variables and string variables can be forced to output. The prefix tilde (~)
forces output to the NC file for debugging. Do not use this for normal output. For example:
~ snamenc, ~ sm00
String select function calls

The string select function call is the target string in a string select function. The placement of the target
string name as an output statement is sufficient to call the mechanism.
Selector string variable
The selector string variable is the target string in a string select function. The function allows the string
to inherit the modality of the numeric variable selector. Output to the NC file is expected based on the
modality of numeric variable selector. For example:
sgcode
When added to selector variables, the variable modifiers change processing as follows:
Selector forced string variable (*)
The selector string variable can be forced to output. The prefix asterisk (*) forces output to the NC file.
Output to the NC file is expected. For example:
*sgcode
The selector string variable can be prefixed with the grave accent (`) to permit output to the NC file
only when there is other valid output on the assembled NC line. Sequence (n) already behaves this way.
For example:
`sgcode

Selector debug string variable (~)

The selector string variable can be forced to output. The prefix tilde (~) forces output to the NC file for
debugging. Do not use this for normal output. For example:
~sgcode
String literals (“ “)
A string literal is actually a form of user-defined string declaration. The character string is enclosed
within double quotes (“”). The syntax implies a user-defined string variable when parsed by the post
executable. Output to the NC file is forced. For example:
”M12”
Dependent string literals

A dependent string literal is identical to a string literal except that the character string is enclosed
within single quotes (‘’). This permits output to the NC file when there is other valid output on the
assembled NC line. For example:
’M12’
ASCII literals
Any of the standard ASCII characters can be output to the NC file by entering the decimal equivalent
(0 to 255 ) of the desired character as an output statement. Output to the NC file is forced. For
example, the pound character (#) is ASCII 035:
35
Postblock calls
To call a postblock, place the name of the postblock as an output statement. The post executable marks
the position where the jump occurs and passes processing of postline instructions to the called
postblock. No output is generated by the placement of the postblock name, but output may occur in the
postblock that is called. For example:
pblock
User prompt function calls

The prompt function call is not a variable but is a combination of the letter ‘q’ and the matching
number of the post function for user prompt function (fq). When the trigger is encountered as an output
statement, the post processor pauses, displays the prompt text in Mastercam, and waits for the user’s
response. No output is generated to the NC file. For example:
q1

Restrictions on using postline types and statements

Postline types have restrictions that limit the postline statements that can be used with a postline.
Additional restrictions define where delimiters must be placed for postline statements.
Formula postline
Formula postlines are identified by a result variable followed by an equal sign (=) as the first item on
the line. This postline type is the most restricted—it can have only a single formula statement. No
other statement types are allowed and the postline cannot continue on another line in the post
customization file. A post comment can be included at the end of the postline.
Output postline
The post executable identifies a postline as an output postline when it does not succeed in identifying it
as a formula postline or a Boolean postline. Each statement on the output postline must be separated by
a comma (,). Any output statement can be placed on the output postline as long as it is separated by the
comma delimiter. For clarity, it is better to place the command variables and user prompt function calls
on separate lines.
The output postline can continue over multiple lines in the post customization file if a comma is placed
after the last output statement on the line (and before an #comment on that line). The command
variable (e) should be placed at the end of any output postline that has output statements that generate
NC code. The command variable (e) calls the NC line ‘end of block’ characters, normally carriage
return and line feed.
No Boolean statements or formula statements are allowed in an output postline.
Boolean postline
The Boolean postline is the most complicated of the postline types. Because it performs conditional
branching in the postblock, an action must follow the conditional branching statement. The conditional
branching statement is identified by the conditional operators ‘if’, ‘else’ or ‘while’, the formula, and the
ending comma.
After the conditional branching statement comma delimiter, you may enter either an output statement
or a single formula statement. You may not enter another conditional branching statement. If you
enter a series of output statements, they must be a continuous series with a comma used to continue the
series. In other words, the action cannot be a ‘multiple postline type’ structure.
To use multiple postlines as an action, you must call the postblock by using either a declared postblock
name or a bracketed postblock.
The ‘if’ and ‘while’ Boolean postlines can stand alone and are independent of any other coding
requirements. The ‘else’ Boolean postline must always immediately follow an ‘if’ Boolean postline.
The ‘if-else’ structure is limited to a single ‘else’ Boolean statement. To expand the ‘if-else’ to an ‘if’-
‘if-else’-‘else’ type structure, you must use the bracketed postblocks and nest consecutive ‘if-else’
structures.
Postblock/postline examples
Following are examples of the postblocks, postline types, and postline statements from MPFAN.PST.
The MP language code here is commented with the post comment and highlighted to identify each of
the types on the postline.
psof #Start of file (Predefined postblock, Standard postblock)
#Output postline, Postblock call
pcuttype
#Formula postline, Formula statement
toolchng = one
#Boolean postline, Conditional branching statement
if ntools = one,
#Bracketed postblock, begin
[
# Formula postline, Formula statement
stagetool = m_one
#Output postline, Update numeric variable
!next_tool
#Bracketed postblocks, end
]
#Output postline, String literal, Command variable
"%", e
#Output postline, Forced numeric variable, Command variable
*progno, e
#Output postline, String literal, Numeric variable, String literal, Command variable
#Output postline, String literal, Command variable, String literal, Command variable, String literal, Command
variable
"(DATE=DD-MM-YY - ", date," TIME=HH:MM - ", time, ")",e
#Output postline, Postblock call, Numeric variable, Selector forced string variable, Command variable
pbld, n, *smetric, e
#Output postline, Postblock call, Numeric variable, Selector forced string variable, Selector forced string variable,
String literal, String literal, Selector forced string variable, Command variable
pbld, n, *sgcode, *sgplane, "G40", "G49", "G80", *sgabsinc, e
#Formula postline
sav_absinc = absinc
#Boolean postline, Conditional branching statement
if mi1 <= one,
#Bracketed postblock, begin
[
#Formula postline
absinc = one
#Output postline, Postblock call, Numeric variable, Selector string variable, String literal, Command variable
pfbld, n, sgabsinc, *sg28ref, "Z0.", e

#Output postline, Postblock call, Numeric variable, Selector forced string variable, String literal, String literal,
Command variable
#Output postline, Postblock call, Numeric variable, String literal, Forced numeric variable, Forced numeric
variable, Forced numeric variable, Command variable
#Formula postline
absinc = sav_absinc
#Bracketed postblock, end
]
pcom_moveb
#Output postline, Command variable
c_mmlt #Multiple tool subprogram call
ptoolcomment
comment
pcan
#Boolean postline, Conditional branching statement, Output statement
if stagetool >= zero, pbld, n, *t, "M6", e
pindex
#Boolean postline, Conditional branching statement, Formula statement
#Output postline, Postblock call, Numeric variable, Selector forced string variable, Selector forced string variable,
Postblock call, Postblock call, Postblock call, Forced numeric variable, Selector forced string variable, Postblock
call, String variable, Command variable
pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, pfcout,
*speed, *spindle, pgear, strcantext, e
#Output postline, Postblock call, String literal, Forced numeric variable, Postblock call, Selector string variable,
Numeric variable, Command variable
#Formula postline
absinc = sav_absinc
pcom_movea
#Formula postline
toolchng = zero
c_msng #Single tool subprogram call
Studying these code examples should give the novice post writer a basic understanding of how
statements and postline types are assembled.

Postblock rules summary

Two types of postblock exist in the MP language: the traditional postblock that has a label
identification and the bracketed postblock that is an implied postblock.
Traditional postblocks must have the postblock label begin in the first column.
Postblock labels begin with letter “p”. The letters “m” or “l” identify postblocks used with
mill/turn applications.
A postblock label must be on a line by itself (except for trailing post #comments).
A postblock label may contain a maximum of 25 characters consisting of letters (a - z), numbers
(0 - 9), and the underscore ( _ ).
User-defined postblock labels must not duplicate predefined postblock labels.
Any MP language function or definition that starts in the first column following continuous
traditional postblock postline(s) ends that postblock. The exception is the post comment (#), which
is ignored.
Postlines encapsulated in the open and close brackets ([,]) define a bracketed postblock.
The post executable file assigns an internal postblock label to bracketed postblocks. The labels are
created by concatenating the string “p__”, the number that represents the occurrence of the bracket
set, the colon “:”, and the line number in the post customization file that the open bracket was on.
This is displayed when debugging (bug2) is enabled or with error messages.
The open and close brackets ([,]) that encapsulate the postlines in a bracketed postblock should be
on lines by themselves.
The brackets used to define the bracketed postblock must be indented following the same rules as a
postline.
Bracketed postblocks must be wholly contained in a single traditional postblock. Nested bracketed
postblocks must be wholly contained in the brackets of the nesting bracketed postblock.
Bracketed postblocks may be nested to 50 levels deep.
Postline rules summary

Postlines must always be indented. Never start the postline in the first column!
NC lines are built in the order in which the output statements occur on the postline. Modality,
variable modifiers, and other factors control what is actually output to the NC file.
Separate output statements with commas.
Output statements can continue over multiple lines by placing a comma at the end of the line (and
before any post #comment, if one exists on that line).

A series of output statements that are intended to produce NC output should be terminated with the
e command variable. This tells the post executable to write the end-of-block characters.
Output statements may follow the comma delimiter on a Boolean postline.

A single formula statement on a single line can follow the comma delimiter on a Boolean postline.
A formula postline must be on a single line. Do not put more than a one formula statement on a
postline.
A conditional branching statement can never follow the comma delimiter on a Boolean postline.
Use a bracketed postblock or call a traditional postblock.
A conditional branching statement can continue over multiple lines until the comma delimiter is
found.
In a conditional branching statement, use a space to separate the Boolean keyword (if, else, while)
from the formula.
Postblock call dependencies

The processing of the NCI data and the predefined postblock that is eventually called depends on:
the settings in the post customization file
the linear motion type that is being processed
Different predefined postblocks may be called for the same initial NCI Gcode passed to the post
executable file depending on these variables. This section describes the logic used to determine the
postblock called in those cases where the predefined postblock call is conditional.
Note: The postblock calls for the ‘whatno’ processing are described here. ‘whatno’ processing is based
on the occurrence of motion after a tool change and is not a recommended practice. Future versions of
MP language may no longer support this type of processing.
Postblock calls for Gcode 0 and 1 in Mill/Router/Lathe

The following list shows postblock calls with the NCI Gcode 0 and 1 for rapid and feed linear motion.
After examining output conditions in Determine if general linear or broken/Z only motion call, jump to
either Z only motion postblock calling or General motion postblock calling to determine the final
output postblock. See Volume 3, Numeric Variables for more information on the numeric variables
used in the presented logic.
Determine if general linear or broken/Z only motion call
If Z moved (difference z to prv_z)
and not on a tool change
and not 5 axis drill (drill5)
and not lathe (posttype)
and no_brk = 0 and gcode = 0 or no_brk = 2 –
Z only moved – Z only motion postblock calling
Z moved negative –
• General motion postblock calling

• Z only motion postblock calling
Z moved positive –
• Z only motion postblock calling
• General motion postblock calling
otherwise – General motion postblock calling
Note: When motion is broken as XY then Z or Z then XY, the output is controlled by the post executable
by writing the previous (prv_var) value of the numeric variable x, y or z to the appropriate current
numeric variable x, y or z. Manipulating these variables prior to the break up motion can result in
unexpected behavior in your NC output.
Z only motion postblock calling
rotaxtyp >= 6 or whatno is yes –
NCI Gcode = 0 – Call pzrapid
NCI Gcode = 1 - Call pz
otherwise –
whatline = 1 – Call pz1
whatline = 2 – Call pz
whatline = 0 or > 2 –
• NCI Gcode = 0 – Call pzrapid
• NCI Gcode = 1 - Call pz
General motion postblock calling
NCI Gcode = 0 –
• posttype = 1 (Mill/Router) –
o mrapid in post – Call mrapid
o otherwise – Call prapid
• posttype = 2 (Lathe) –
o lrapid in post – Call lrapid
o otherwise – Call prapid
NCI Gcode = 1 –
o mlin in post – Call mlin
o otherwise – Call plin
o llin in post – Call llin
o otherwise – Call plin
otherwise –
whatline = 1 – Call plin1
• NCI Gcode = 0 – Call prapid
• NCI Gcode = 1 - Call plin


The NCI Gcode 2 or 3 for circular motion. Follow the structure shown here for postblock calling.
NCI Gcode = 2 or 3 –
o mcir in post – Call mcir
o otherwise – Call pcir
o lcir in post – Call lcir
o otherwise – Call pcir
otherwise –
whatline = 1 – Call pcir1
whatline = 2 – Call pcir2
whatline = 0 or > 2 – Call pcir
Postblock calls for Gcode 11 in Mill/Router

NCI Gcode 11 defines continuous 5-axis motion in Mill type toolpaths. The numeric variable rotaxtyp
determines the routines called with 5-axis motion. This section defines the routines and postblock calls
for NCI Gcode 11 when rotaxtyp is less than 6. When rotaxtyp is greater than 6, refer to the section
Postblock calls for Gcode 0 and 1 in Mill/Router/Lathe. Assume the NCI Gcode of 1 when applying
the logic to Postblock calls for Gcode 0 and 1 in Mill/Router/Lathe.
Note: The routines shown here are obsolete. In prior versions of Mastercam, the post would
generate many of the moves to and from a 5-axis toolpath, modify the lead and lag angles, etc. It is
recommended that any motion that can be generated in Mastercam be used before using the
routines in the post executable to creating motion or modify motion.
The following variables influence the postblock called for output when rotaxtyp is less than 6. They
also enable the routines that add lead in and lead out moves to a toolpath and apply lead and lag to the
tool.
A two-part lead in move is added to a toolpath and a two-part lead out move is added to the end of a
toolpath if the following numeric variables are not zero for the move they are applied to.
ldinl1
The length of first lead-in move, measured from first point in cut. If ldinl1 = 0, this move will be
eliminated.
ldina1
The lead-in angle measured from first cut segment, in degrees. A lead-in angle of 0 would yield a
tangent lead-in.

ldinl2
The length of second lead-in move. This allows for a change from rapid to plunge feed rate. if ldinl2 =
0, this move will be eliminated.
ldina2
The lead-in angle measured from first cut segment, in degrees. A lead-in angle of 0 would yield a
tangent lead-in.
ldoutl1
The length of lead-out move, measured from last point in cut. If ldoutl1 = 0, this move will be
eliminated.
ldouta1
The lead-out angle measured from last cut segment, in degrees. A lead-out angle of 0 would yield a
tangent lead-out.
ldoutl2
The length of second lead-out move. This allows for a change from rapid to plunge feed rate. If ldoutl2
= 0, this move will be eliminated.
ldouta2
The lead-out angle measured from last cut segment, in degrees. A lead-out angle of 90 would yield a
lead-out normal to surface.
Figure: 5-axis lead in/lead out
The drawing shows the relative location on the 5-axis toolpath where each move is generated by the
post executable. These moves are not part of the NCI file but are created in the post executable.
CALCULATED LDINL2
VECTOR
LDOUTL2
LDOUTL1
CALCULATED
VECTOR
The lead in motion is started when the NCI Gcode 11 is passed to the internal routine and the numeric
variable whatline is 0. The post executable delays this first position until the second position is read
from the NCI file so that the cut direction can be determined. Normally, whatline is set to 0 in
ptlchg1002 when using the programming technique enabled with tlchng_aft. This routine (tlchng_aft) is
designed to include the motion NCI data after the tool change NCI gcode (1000, 1001 and 1002) line as
part of the tool change series of lines. Otherwise, whatline is assigned 0 in the psof, and ptlchg
postblocks.

The lead out motion is triggered when the numeric variable cutpos, read from the NCI file, is equal to 3.
The called postblock depends on the setting of the lead in and lead out variables. If the move was
eliminated because the numeric variable was 0, a call is not generated to the predefined postblock.
Before each output postblock call, the internal routine to apply the numeric variables tilt (for tilt along
cut direction) and rhtilt (tilt perpendicular to cut direction) is called. At the end of the routine that
applied the tilt (if non-zero), a call is made to the postblock pmx0. Now, the postblock is called for the
NC output instructions in the post customization file.
Postblock calling for Gcode 11
whatline = 2 –
Lead in Line 1 is valid – Call pmx1
Lead in Line 2 is valid –
• whatline is set to 3
• Call pmx1
Original position is output – Call pmx2
whatline = 4 and cutpos <> 3 - Call pmx
cutpos = 3 –
Lead out Line 1 is valid – Call pmx1
Lead out Line 2 is valid – Call pmx1

Canned drilling cycles can be output as long code or as canned drilling cycles. See Working with Drill
Cycles for more information. The structure here represents the calling order when output has been
designated for canned cycles. Long code output calls to the Postblock calls for Gcode 0 and 1 in
Mill/Router/Lathe output structure.
Postblock calling for NCI Gcode 81
drillcyc = 0 –
posttype = 1 (Mill/Router) –
• mdrill in post – Call mdrill
• otherwise – Call pdrill
posttype = 2 (Lathe) –
• ldrill in post – Call ldrill
• otherwise – Call pdrill
drillcyc = 1 –
• mpeck in post – Call mpeck
• otherwise – Call ppeck
• lpeck in post – Call lpeck
• otherwise – Call ppeck
drillcyc = 2 –
• mchpbrk in post – Call mchpbrk
• otherwise – Call pchpbrk

• lchpbrk in post – Call lchpbrk
• otherwise – Call pchpbrk
drillcyc = 3 –
• mtap in post – Call mtap
• otherwise – Call ptap
• ltap in post – Call ltap
drillcyc = 4 –
• mbore1 in post – Call mbore1
• otherwise – Call pbore1
• lbore1 in post – Call lbore1
drillcyc = 5 –
• mbore2 in post – Call mbore2
• lbore2 in post – Call lbore2
drillcyc = 6 –
• mmisc1 in post – Call mmisc1
• otherwise – Call pmisc1
• lmisc1 in post – Call lmisc1
drillcyc = 7 –
• mmisc2 in post – Call mmisc2
• lmisc2 in post – Call lmisc2

Postblock calling for NCI Gcode 100

drillcyc = 0 –
• mdrill_2 in post – Call mdrill_2
• otherwise – Call pdrill_2
• ldrill_2 in post – Call ldrill_2
• otherwise – Call pdrill_2
drillcyc = 1 –
• mpeck_2 in post – Call mpeck_2
• otherwise – Call ppeck_2
• lpeck_2 in post – Call lpeck_2
• otherwise – Call ppeck_2
drillcyc = 2 –
• mchpbrk_2 in post – Call mchpbrk_2
• otherwise – Call pchpbrk_2
• lchpbrk_2 in post – Call lchpbrk_2
• otherwise – Call pchpbrk_2
drillcyc = 3 –
• mtap_2 in post – Call mtap_2
• ltap_2 in post – Call ltap_2
• otherwise – Call ptap_2
drillcyc = 4 –
• mbore1_2 in post – Call mbore1_2
• otherwise – Call pbore1_2
• lbore1_2 in post – Call lbore1_2
drillcyc = 5 –
• mbore2_2 in post – Call mbore2_2
• lbore2_2 in post – Call lbore2_2

drillcyc = 6 –
• mmisc1_2 in post – Call mmisc1_2
• otherwise – Call pmisc1_2
• lmisc1_2 in post – Call lmisc1_2
drillcyc = 7 –
• mmisc2_2 in post – Call mmisc2_2
• lmisc2_2 in post – Call lmisc2_2
Postblock calls for tool end in Mill/Router/Lathe

The end of a toolpath can be assumed to be the NCI Gcode 1011 that starts the tool change series of
NCI lines. The structure here represents the calls to the postblock based on the numeric variable
posttype. This postblock is not called on the very first NCI Gcode 1011 because no toolpath exists
before that NCI line.
NCI Gcode = 1011 –
• mtoolend in post – Call mtoolend
• otherwise – Call ptoolend
• ltoolend in post – Call ltoolend
• otherwise – Call ptoolend
Postblock calls for Gcode 0, 1, 20, 21 in Wire

This indented structure shows the postblock calling with the NCI Gcode 0, 1, 20 and 21 for rapid and
feed linear motion.
Note: “General motion postblock calling” is the only routine used to determine the output postblock in
Wire.
whatno is yes –
NCI Gcode = 0 or 20 – Call prapid
NCI Gcode = 1 or 21 – Call plin
otherwise –

• NCI Gcode = 0 – Call prapid

• NCI Gcode = 1 - Call plin
Note: Output calls for Direct Wirepaths are based on the numeric variable uvflag. The post executable
actually reads four lines from the NCI, but the first set (20s NCI Gcode) determines the actual call.
Postblock calls for Gcode 2, 3, 22, 23 in Wire

This indented structure shows the postblock calling with the NCI Gcode 2, 3, 22 and 23 for circular
motion. The heading General motion postblock calling is the only routine used to determine the output
postblock in Wire.
whatno is yes –
NCI Gcode = 2, 3, 22 or 23 – Call pcir
otherwise –
whatline = 1 – Call pcir
• NCI Gcode = 2, 3, 22 or 23 - Call pcir
Note: Output calls for Direct Wirepaths are based on the numeric variable uvflag. The post executable
actually reads four lines from the NCI, but the first set (20s NCI Gcode) determines the actual call.

ADDENDA
Passing arguments to postblocks

Beginning with Mastercam X8, the MP language supports passing values with postblock
calls. This means that you can define a postblock with a list of parameters, and then pass
arguments to it when you call it from another postblock.
Quick Start
To do this, simply include the list of parameters in the postblock definition. Use
parentheses and separate them by commas:
# Define postblock with parameters
pcalc_position( xcoord, ycoord, zcoord, start_angle )
If you want, you can break out the parameters on separate lines, but the initial
parenthesis must be on the same line as the postblock name:
# Define postblock with parameters
pcalc_position(
xcoord,
ycoord,
zcoord,
start_angle )
Spaces before/after the parentheses and commas are ignored.

The parameters must be numeric variables; strings are not supported. However, you are
allowed to use variable names that have not already been declared or initialized. MP will
automatically create the variables for you (and initialize them to 0) if they do not already
exist.
While you cannot specify an explicit return value for a postblock, you can accomplish the
same thing by passing references to variables (as described below). Also, any variables
whose values are changed inside the postblock are visible outside the postblock as well.
Once you define the postblock, you can call it and pass values to it; for example:
pcalc_position( xdrl$, ydrl$, zdrl$, 30 )
The values that you pass to the postblock can be any valid numeric expression:
 User-defined or predefined numeric variables. This includes prv_ variables and
variables defined as constants.
 Numbers—for example, 30.
 Formulas/functions that return a numeric value—for example, (abs(xnci$)).
In this case, the formula or function will be evaluated before the postblock is
called, and the return value matched to the parameter list. Only formulas and
functions that return a numeric value can be used.
As a general rule, it is a good practice to enclose formula arguments in
parentheses.
 Expressions—for example, 3*my_var.
You cannot skip any arguments when calling the postblock. If you include fewer
arguments than are defined in the postblock definition, MP will not generate an error.
However, the parameters for which no argument has been supplied will continue to have
whatever value they were last assigned.
Conversely, if your postblock call has more arguments than have been defined for the
postblock, the extra arguments will be ignored. The typical best practice is for the
postwriter to ensure that the number of arguments matches the number of parameters.
You are allowed to use a negative number as an argument; for example, –30. However, if
you use the minus sign in front of a variable name in your argument list, you must
enclose it inside parentheses; for example, (–ynci$).
ADDENDA
Passing values by reference; updating argument values

Normally, when you include the name of a variable in a postblock call, only the value of
the variable is passed to the postblock. The original variable is left unchanged. For
example, in the previous section, when the postblock is called with
pcalc_position( xdrl$, ydrl$, zdrl$, 30 ), the following things happen:
Quick Start
 The current values of xdrl$, ydrl$, and zdrl$ are copied to xcoord, ycoord,
and zcoord.
 The values of xcoord, ycoord, and zcoord are manipulated by the postblock
code.
 The values of xdrl$, ydrl$, and zdrl$ are not changed.
You can change this behavior by including the ! (force update) character in your
argument list when calling the postblock. When you do this, the variable in the argument
list will be updated when the postblock has finished.
For example, if you include the ! like this when you call the postblock:
pcalc_position( !xdrl$, !ydrl$, zdrl$, 30 )
then after pcalc_position has finished executing, the values of xdrl$ and ydrl$ will
be updated with the values of xcoord and ycoord.
Note that variables defined as constants will not be updated, if you pass them as
arguments to a postblock.
You are also allowed to include the ! character in the postblock definition. However, this
is only a convenience to make your post more readable, to specify that the postblock is
expecting an argument in this form. It does not have any other effect.
Scope and visibility

Numeric variables that are created in the parameter list of the postblock definition are
created and initialized on the second parsing loop in MP. They are initialized to 0 and
assigned to format statement 1.
Once they have been created, they can, technically, be used anywhere else in your post.
They function just like any other user-defined variable, and their values persist after the
postblock has finished executing. However, they cannot be used before the postblock
definition. As a best practice, you should normally use such variables within the
postblock, and copy their values to other variables if you want to access them elsewhere.
In other respects, postblocks with parameter definitions can access other variables and
their values just like any other postblock.
Previous values
Not only can you use the prv_ value of a variable as an argument when calling a
postblock, you can use it in the parameter list when you define the postblock. When you
do this, MP will also automatically create the regular variable when the postblock
definition is processed.
The prv_ states of the argument and the parameter definition do not need to match. For
example, if the postblock definition includes a prv_ in its parameter list, you can still
pass it a regular variable as an argument.
Global variables
You are allowed to use global variables both when defining and calling a postblock.
ADDENDA
Global variables used in a postblock definition are assigned the value that is passed in
when the postblock is called.
Global variables used as an argument when calling a postblock are not solved when the
postblock is called. They are assigned a value on return.
Quick Start
Versions of Mastercam before X8
Note that if you use these techniques in versions of Mastercam earlier than X8, MP will
not give you an error. However, they have not been tested in earlier versions of
Mastercam, and their use is not supported or recommended.
Example
Example: Defining and calling a postblock with arguments
The following example shows how different types of argument values are processed
and manipulated when they are passed to a postblock called pblockvars that is
defined with three parameters.
var_1 : 5
var_2 : 10
var_3 : 15
# Postblock definition with list of parameters

pblockvars(var_a, var_b, var_c)
# Output the values that were passed in as arguments
"IN CALL -> ", ~var_a, ~var_b, ~var_c, e$
var_a = var_a + 100, var_b = var_b + 100, var_c = var_c + 100
pheader$
# Output original values

"BEFORE CALL: ", ~var_1, ~var_2, ~var_3, e$
# Call to postblock with arguments

pblockvars(!var_1, 13, (–var_3))
# Output values after called postblock and compare

"AFTER CALL: ", ~var_1, ~var_2, ~var_3, e$
" : ", ~var_a, ~var_b, ~var_c, e$
It results in the following output:

BEFORE CALL: var_1 5. var_2 10. var_3 15.
IN CALL -> var_a 5. var_b 13. var_c -15.
AFTER CALL: var_1 105. var_2 10. var_3 15.
: var_a 105. var_b 113. var_c 85.
You can see the effects of passing argument values in three different forms:
 The value of var_1 is passed with the ! character, meaning var_1 is updated by
the postblock pblockvars.
 The sign of var_3’s value is reversed before it is passed.
 Instead of var_2, a simple number (13) is passed.
Volume 1 Chapter 8 How Preparatory Postblocks Work
8 How Preparatory Postblocks Work
Preparatory postblocks are postblocks that are called during a preparatory reading (processing) of the
NCI file. This preparatory processing allows information about the tool changes and toolpaths
contained in the NCI file to be captured prior to the normal processing of the NCI file. Although this is
commonly used to create a tool table that is then written to the head of the NC output, preparatory
processing is much more powerful than simply creating tool tables.
When combined with buffer files, preparatory processing permits the capture and retrieval of
information about the next tool change. (Buffer files are temporary files that can be created within the
MP language to store and retrieve data. See Volume 2, How Buffer Files Work.) Information about the
extent of motion in the NCI, cutting planes used, parameters and comments in the NCI can also be
extracted.
In this chapter, you will find the following topics:
Preparatory postblock lists and descriptions
Enabling preparatory postblocks using the tooltable numeric variable
What happens during preparatory processing
Preparatory processing with pwrtt
Preparatory processing with ptooltbl
Preparatory processing with pradlist (Wire only)
Preparatory processing with ptprlist (Wire only)
Ending the preparatory processing procedure
Using tooltable as command variable
The preparatory postblocks

The preparatory postblocks available to the post customization file are:
ptooltbl, which previously was intended for creating a tool table.
Note: This is an obsolete routine and should no longer be used.
pwrtt, which provides tool change data from the NCI and scanned information from the
toolpaths themselves.
pwrttparam, which is called by the NCI parameter Gcodes. This behaves similarly to the
pparameter predefined postblock routine but is part of the preparatory NCI file scan.
pradlist, which provides wire offset registers and wire offset values from the NCI.
ptprlist, which provides the wire taper angle programmed on each operation.

Chapter 8 How Preparatory Postblocks Work Volume 1
Enabling the preparatory postblocks

To enable the preparatory postblocks, the post writer must initialize and declare certain predefined
postblocks, system numbered questions and a predefined numeric variable. How the posting process
ultimately behaves depends on how these predefined postblocks and numeric variable are presented in
the post customization file.
The predefined postblocks are:
ptooltbl
pwrtt
pwrttparam
pradlist (Wire posts only)
ptprlist (Wire posts only)
The predefined numeric variable is tooltable, which must be set to a positive value
The system numbered questions (in the PST file) are:
1501. Insert parameter information in the ascii NCI? n
1502. Write operation information to binary file (.ops)? n
1503. Write transform operations (0=transform ops, 1=source ops, 2=both)? 1
See Volume 2, Parameter Information for more information.
Setting the tooltable variable

Set the predefined numeric variable tooltable to one of the following positive values:
tooltable value Action
1 Activates the pre-read routine for calls to the ptooltable postblock.

1 or 3 Activates the pre-read routine for calls to the pwrtt and pwrttparam
postblocks.
3 Provides an additional call to the pwrtt postblock at the end of the NCI file
read on the NCI Gcode 1003. Use this when it is necessary to capture
information scanned from the last toolpath motion (for example, x_min,
x_max, ttplane, etc.).
Note: In older posts, tooltable may be set to a value of 2. This option is no longer supported by the MP
language and is interpreted as 1.
The following “Effect of the tooltable variable on postblock calls” table shows the precedence of the
postblock calls when tooltable is set to 1 or 3 and the postblocks have been declared in the post
customization file.

Effect of the tooltable variable on postblock calls
Postblocks declared in post Postblocks called from executable

pwrtt pwrtt
pwrtt pwrtt
ptooltbl
pwrtt pwrtt
pwrttparam pwrttparam
pwrtt pwrtt
ptooltbl pwrttparam
pwrttparam
ptooltbl ptooltbl
ptooltbl ptooltbl
pwrttparam
pwrttparam No legal calls
What happens during the preparatory processing procedure

Once the tooltable numeric variable has been enabled by being set to a positive value, the following
occurs:
The post executable knows to perform a call to the pre-read routine. This call occurs at the
start-of-file NCI Gcode (1001) after normal processing has started.
The post executable calls the pre-read routine and, based on the declared postblocks in the
post customization file, processes the entire NCI file.
After the pre-read routine is complete, the following occurs:
The NCI file is rewound and then restarted.
The NCI lines are reprocessed up to the start-of-file NCI Gcode (1001), then the control is
passed back to the normal processing NCI file read and processing continues.
tooltable is set to -1 by the post executable when it returns from the pre-read routine.

Preparatory processing flowchart

Here is a graphical representation of how the processing occurs to and from the call to the pre-read
routine:
NCI file read loop is started.
Variable tooltable is set to 1 or 3 before the start of the read loop.
NCI Gcode lines are read and processed as normal.

1050 NCI Gcode
1011 NCI Gcode
1012 NCI Gcode
1013 NCI Gcode
1014 NCI Gcode
1015 NCI Gcode (Wire only)
1016 NCI Gcode
1017 NCI Gcode (Mill/Router/Lathe only)
1025 NCI Gcode
1020 NCI Gcode
1018 NCI Gcode (Optional Mill/Router/Lathe transform subprograms)
10000s NCI Gcode (Optional by system numbered question)
20000s NCI Gcode (Mill/Router/Lathe only)
NCI Gcode line 1001 is read and internal processing occurs as follows:
Postblock ‘prot0’ is called (Mill/Router/Lathe only)
Postblock ‘psof00’ is called (Mill/Router//Lathe only)
Postblock ‘pheader’ is called
Postblock ‘ptprlist’ is called (Wire only)
Postblock ‘pradlist’ is called (Wire only)
The internal pre-read routine is called, select one:
The ‘pwrtt’ Preparatory Processing Procedure
The ‘ptooltbl’ Preparatory Processing Procedure
Control is passed back from the pre-read routine and processing continues.
Postblock ‘psof’ or ‘ptlchg1002’ is called
Variable tooltable is set to -1
The preparatory processing procedure may be performed with either the pwrtt or ptootbl postblocks.

The pwrtt preparatory processing procedure

pwrtt may be declared in the post customization file as shown in this example below:
pwrtt #Write tool table, scans entire file, repeated tools are negative.
tnote = t
toffnote = tloffno
tlngnote = tlngno
if t >= 0, # if not a repeated tool number
"(", *tnote, " ", *toffnote, " ", *tlngnote, " ", *tldia, " ", *sopnote, ")"
The post executable will be aware that the predefined postblock pwrtt has been declared and the
numeric variable tooltable has been set to a positive value and will processes the NCI file according to
the procedure for calls to pwrtt.
Note: This includes calls to pwrttparam if it also was declared in the post customization file.
At this point, the preparatory processing procedure from the normal NCI processing will have been
completed up to the point where the internal pre-read routine is called. The NCI file will be rewound
and processing of the NCI file will be restarted with the standard two line set NCI file read.
See Volume 3, Postblocks for more information and which variables are read during the pre-read
routine.
As each toolpath section in the NCI file is read (that is, from tool change to tool change), the NCI
Gcode is processed in the read loop. The following events occur in the order listed here:
1050 NCI Gcode – Read the parameters.
1015 NCI Gcode – Read the parameters. (Wire only)
1017 NCI Gcode – Read the parameters. (Mill/Router/Lathe only)
1020 NCI Gcode – If the system numbered question 1502 is set to write to the operation file
(.OPS file) and pwrttparam is present in the post customization file, then the 10000s parameters
are processed in prmcode and sparameter. A call is made to the pwrttparam postblock.
1018 NCI Gcode (Optional Mill/Router/Lathe transform subprograms) – Read the parameters.
10000s NCI Gcode – If the system numbered question 1501 is set to write to the operation
parameters to the NCI file, then the 10000s parameters are processed in prmcode and sparameter. A
call is made to the pwrttparam postblock.

20000s NCI Gcode (Mill/Router/Lathe only) – Read the parameters into the variables prmcode and
sparameter. A call is made to the pwrttparam postblock. NCI Gcode 20001 holds the comment from
the tool definition is assumed to be the tool name. This is placed in the predefined string variables
strtoolpath, strtool and strtoolext if the numeric variable strtool_v7 is set to 1.
See Volume 2, Parameter Information and Volume 1, Changes to the MP Post for more
information.
1000, 1001, 1002 NCI Gcode – Read the parameters. Set the look ahead variables directly from the
NCI file for next_dc, nextop, nextccomp, nextcflg and mill5 (Mill/Router only). The numeric variable
for tool number ‘t’ is checked to see if it has been used at any time prior to this tool change and is
signed negative if it has. Call the postblock pwrtt.
NCI Gcode in the toolpath – Read the parameters. The NCI motion extents for each toolpath
segment (tool change to tool change) are captured in the numeric variables x_max, y_max, z_max,
x_min, y_min, z_min. Additionally, any arc plane is captured in the variable ttplane. Wire looks for
the maximum taper angle in 2D contour wirepaths and stores that in the numeric variable wt_max.
• 1005-1008 NCI Gcode – Read the parameters into the variables prmcode and sparameter. A call
is made to the pwrttparam postblock. These NCI Gcodes can be at the beginning of the tool
change series of NCI lines.
• 1018 NCI Gcode (Optional Mill/Router/Lathe non-transform subprograms) – Read the
parameters. Set the numeric variable for rcc_flg, lower_x, lower_y, lower_z, upper_x, upper_y,
upper_z, to track lathe canned cycles.
See Volume 2, Lathe Canned Cycles for more information.
• 1019 NCI Gcode (Optional Mill/Router/Lathe non-transform subprograms) – See the 1018
NCI Gcode above.
1003 NCI Gcode – When the variable tooltable is set to 3, a final call the postblock pwrtt is
performed. The purpose of this call is to allow the information scanned from the last tool change to
the end of the file to be captured. In particular, the numeric variables x_max, y_max, z_max, x_min,
y_min, z_min, ttplane and wt_max (Wire only).
See Ending the Preparatory Processing Procedure below.
Note: Variables read in the actual toolpath are overwritten by the next set of NCI lines read.
Only the last values read before the call to pwrtt or pwrttparam are available.
The ptooltbl preparatory processing procedure

Note: It is recommended that you use the pwrtt Preparatory Processing Procedure.
If ptooltbl has been declared in the post customization file and pwrtt has not been declared, then the post
executable will process the NCI file using the ptooltbl procedure. The numeric variable tooltable must be
set to a positive value to activate the procedure. Setting the numeric variable tooltable to 3 does not
change the way the procedure functions.
The preparatory processing procedure from the normal NCI processing will have been completed up to
the point where the internal pre-read routine is called. The NCI file will be rewound and processing of
the NCI file will be restarted with the standard two line set NCI file read.
See Volume 1, Postblocks and Volume 3, Postblocks for more information.
As each toolpath section in the NCI file is read, the NCI Gcode is processed in the read loop.
The following events occur in the order here:
1015 NCI Gcode (Wire only) – Read the parameters.
1017 NCI Gcode (Mill/Router/Lathe only) – Read the parameters.
1018 NCI Gcode (Optional Mill/Router/Lathe transform subprograms) – Read the parameters.
10000s NCI Gcode – Parameters are not read.
20000s NCI Gcode (Mill/Router/Lathe only) – Parameters are not read except the NCI Gcode
20001 (comment from the tool definition) is placed in the predefined string variables strtoolpath,
strtool and strtoolext if the numeric variable strtool_v7 is set to 1.
See Changes to the MP Post for more information.
1000, 1001, 1002 NCI Gcode – Read the parameters. Set a flag to trigger a call to ptooltbl on the
next two line set NCI file read.
NCI Gcode in the toolpath – Read the parameters. The post executable checks to see if the flag
was set from the 1000, 1001, 1002 NCI Gcode NCI file read. The flag is removed and no call to
the ptooltbl postblock occurs if the numeric variable for tool number t has been used at any time
prior to the tool change (Mill/Router/Lathe only). Each case that calls ptooltbl is listed here:
• 0, 1, 2, 3, 200 NCI Gcode (Mill/Router/Lathe) – Parameters are not read.
Call the postblock ptooltbl.
• 0, 1, 2, 3, 20, 21, 22, 23, 30, 31, 32, 33 NCI Gcode (Wire) – Parameters are not read.
• 11, 81 NCI Gcode – Read the parameters.
See Ending the Preparatory Processing Procedure below.

Note: Variables read in the actual toolpath are overwritten by the next set of NCI lines read. Only the
last values read before the call to ptooltbl are available. It is recommended that you use the pwrtt
Preparatory Processing Procedure.

Ending the preparatory processing procedure

After the pre-read routine is complete, the NCI file is rewound and then restarted and the lines are
reprocessed up to the start-of-file NCI Gcode (1001). Control is passed back to the normal processing
NCI file read and processing continues from the point where it initially called the internal pre-read
routine.
The following numeric variables are restored to the original state they held before the call to the internal
pre-read routine:
cutpos2
mill5 (Mill/Router/Lathe only)
rcc_flg (Mill/Router/Lathe only)
nextop
nextdc (Mill/Router/Lathe only)
nextcflg (Mill/Router/Lathe only)
The numeric variable (command variable) tooltable is set to -1 by the post executable when it returns
from the pre-read routine and has completed the call to the postblocks psof or lsof or msof or ptlchg1002.
The postblock calls are dependent on product and processing options.
See Volume 3, Mill / Turn Applications and Volume 1, Changes to the MP Post for more information.
Using tooltable as a command variable

Note: Using tooltable as a command variable is NOT recommended. Because of the embedded calling
that occurs, variables can be overwritten by the preparatory read routine and create unexpected
results!
The numeric variable tooltable has the special characteristic of also being a command variable.
See Volume 3, Numeric Variables for more information on command variables.
When this variable appears in the predefined postblock psof as an output postline statement, it initiates a
call to the pre-read routine.
psof # Start of file for non-zero tool number
toolchng = one
if ntools = one,
[
stagetool = m_one
!next_tool
]
tooltable # *** Initiates call to pre-read routine ***
pbld, n, *smetric, e # Set for Inch or Metric mode
pbld, n, *sgcode, sgplane, "G40", "G49", "G80", *sgabsinc, e
sav_absinc = absinc # Save active Abs/Inc mode

Note: tooltable should not be initialized when used as a command variable. If it is desired to recall pwrtt
on the NCI Gcode 1003, set tooltable to 3 in the postblock pwrtt.
This example shows this technique:
pwrtt #Write tool table, scans entire file, repeat tools are negative.
tooltable = 3
tnote = t
toffnote = tloffno
tlngnote = tlngno
Using the taper and radius list in Wire

The taper and radius lists are used on some wire EDM machines to replace an explicit address and
values on the NC motion line with the machine tools register that holds the value. For example:
O0100 (T )
N100 H1=0.0
N100 H2=3.0
N100 H3=1.0
N100 G00 G20 G90
N110 G75 X-.70479 Y.20024
N120 G92 X-.70479 Y.20024 I-.375 J0.
N130 S1 D1
N140 M37
N150 G42 G51 G01 X-.715 Y.1301 H2
N160 Y.062
N170 X-.25
N180 Y.012
N190 X-.2601 G60 R.007
N200 Y-.301 H3
N210 X-.5634
N220 G50 Y-.58923 H1
N230 X-1.01 Y-.84708
N240 G40 X-1.00616 Y-.91045
N250 M45
N260 M30
%
The H offset register is read for the taper to be used in the toolpath.
Enabling the taper and radius lists

To enable the taper and radius lists, the tool table routine must be enabled. This routine processes
through the NCI file as a pre-read routine and finds all the 2D contour motion that contains the wire
tapers. It also finds all the NCI lines (1010 and 1013) that have wire diameters and calculates the wire
radius. These are then written to the appropriate list.
bldnxtool : 1 # Builds table of taper and radius
After the lists are written, the post writer must place them in the head of the NC file. A couple steps are
required to call the output to write the lists. In the post customization file, you must enable the call to
the list read loop for each list (see below):
listtpr : 1 # Enable taper list output, see ptprlist
listrad : 0 # Enable radius list output, see pradlist

The list read loop is a routine in the post executable. The read loop reads each record that was written
to it, in ascending order and on each read calls a specific postblock in the post customization file. The
postblock must be in the post customization file and output postlines within the postblock to write the
lists. For the wire taper list, the ptprlist postblock must be present:
ptprlist # List of taper angles, only tofs (index) and wt are read
# List is checked in linear/circular (0,1,2,3) and "tofs" set
*tofs, " = ", *wt, e
For the radius list, the pradlist postblock must be present:

pradlist # List of wire radii, only offset and tlrad are read
*offset, " = " , *tlrad, e
The above postblocks, when enabled, are called immediately after the predefined postblock pheader.
They are called in the order ptprlist and then pradlist. There is no way to alter the calling order.
Taper and radius list specifics

The taper list captures the numeric variable for wire taper wt from the NCI Gcode 0, 1, 2 and 3 lines.
These are then written to the list in the order they are found if it is not a duplicate. The list starts at base
of 1 (tofs = 1) and this is pre-assigned the value zero.
When the list is generated in the post customization file, the predefined postblock call ptprlist is called at
each list entry that was written in ascending order starting at 0. The numeric variable wt is assigned the
saved taper value and the numeric variable tofs is assigned the index position.
During the processing of the NCI file, each time the post executable reads an NCI Gcode 0, 1, 2 and 3,
it takes the current value for wire taper wt from the NCI parameters and compares it to the taper list. It
returns the index in the list to the variable tofs. tofs is the variable that is used as the output statement.
plin # A postblock
n, x, y, z, tofs, e
Note: The taper list is generated starting at base zero but was written starting at base 1.
The radius list captures the calculated numeric variable for wire radius tlrad from the NCI Gcode 1010
and 1013 lines. These are then written to the list using the value from the numeric variable offset as the
index position.
When the list is generated in the post customization file, the predefined postblock pradlist is called each
list time a list entry is written (in ascending order) with a non-zero offset entry. The list is read starting
at 0. The numeric variable tlrad is assigned the saved wire radius value, and the numeric variables lofs
and offset are assigned the index position (the original offset value that wrote the radius).
The numeric variable offset should be used in your tool change postblocks and condition change
postblock pconchg to refer to the listed values in the NC file.
Note: Both these tables are limited to 1000 entries each.

Volume 1 Chapter 9 Numeric Variables
9 Numeric Variables
Numeric variables are variables that represent numeric values in the MP language. The MP language
has only two types of variables: numeric values and character strings. The numeric variables are all
stored internally by the post executable as double real values.
A numeric variable is identified by a label. The label represents a specific memory location that holds
the value of the numeric variable. By using the variable label in the post customization file, you can
access the value the variable represents. The numeric variables can be parameters passed from the NCI
file, values calculated in the post executable for a specific routine, switches that enable or disable
posting options, variables defined by the post writer to be used within the post customization file.
Some numeric variables do not use the value associated with them but use the label or name to trigger a
routine in the post executable. These variables are called command variables.
For a list of numeric variable descriptions, see Volume 3, Numeric Variables.
Numeric variable label/initialization

A numeric variable label is used to identify the numeric variable. The post executable already holds a
list of predefined numeric variable. Numeric variables can be declared in the post as user-defined
numeric variables. To create a numeric variable, a numeric variable initialization is inserted in the post
customization file. The numeric variable initialization can also define the initial value of a predefined
numeric variable. The numeric variable label must adhere to the following rules:
Always starts in the first column of the post customization file.
Begins with a letter (a-z).
Consists of letters (a-z), numbers (0-9), and the underscore (_).
Can have a maximum of 25 characters in the label.
Must be defined outside of a postblock.
There is one exception. A numeric variable can also be declared as part of the post function for format
assignment fmt. Format assignments are described in detail in Formatting Numeric Variables. This
allows you to skip the numeric variable initialization. The numeric variable label in a format
assignment follows these rules:
Begins with a letter (a-z).
Consists of letters (a-z), numbers (0-9), and the underscore (_).
Can have a maximum of 25 characters in the label.
The format assignment must be defined outside of a postblock.
To assign an initial value to a numeric variable, a value, an existing numeric variable (user-defined or
predefined), or a formula is written on the same line in the post customization file as the numeric
variable label. The value, numeric variable, or formula is separated from the numeric variable label by
either a colon (:) or the equal sign (=). The meaning of the colon (:) or the equal sign (=) in the numeric
variable declaration is vastly different and it is critical to understand the difference.
Chapter 9 Numeric Variables Volume 1
Initialization (:)
When a numeric variable is declared with a colon (:), the value, numeric variable, or formula that is to
be assigned to the variable is evaluated when the post customization file is parsed. This occurs before
any processing of the NCI file. These values are written to the appropriate numeric variable as the
initial setting. These are the values seen when the NCI file read is started and the post executable starts
calling internal routines and postblocks. The post executable never re-evaluates the value, numeric
variable, or formula after the post customization file parsing is completed.
Global formulas (=)

When a numeric variable is declared with the equal sign (=), the value, numeric variable, or formula
that is assigned to the variable is evaluated whenever the post executable encounters the numeric
variable in a postblock. See the numeric variable newglobal in Volume 3, Numeric Variables, which
controls global formula behavior. The post executable re-evaluates the value, numeric variable, or
formula that was assigned in the declaration every time the post executable encounters the numeric
variable on a postline and before the numeric variable output or evaluation when in a formula.
Note: The use of global formulas is NOT recommended. In addition to introducing excess overhead
during processing, they can make debugging difficult if you are not aware that a numeric variable was
declared as a global formula. If you chose to use global formulas, the numeric variable newglobal
should always be set to 1.
Examples
Here are examples of numeric variable initialization cases.
Initialization with a value
real_var1 : 12 # Initialize user defined variable with a value
x : 12 # Initialize predefined variable with a value
Initialization with a numeric variable

real_var1 : 12 # Initialize with a value
real_var2 : real_var1 # Initialize with a numeric variable
Note: The assigned numeric variable must be predefined or declared before the initialization with a
numeric variable.
Initialization with a formula statement
real_var1 : year + 2000 # Initialize with a formula statement
Global formula with a value

real_var3 = 12 # Initialize with a value
Global formula with a numeric variable

real_var3 = x # Initialize with a numeric variable

Note: The assigned numeric variable must be predefined or declared before the Global formula
initialization with a numeric variable.
Global formula with a formula statement
real_var3 = real_var3 + 2 # Initialize with a formula statement
real_var3 = fsg3(x) # Initialize with a formula statement
Format assignment
A numeric variable declared in a format assignment, but not declared with a numeric variable
initialization, is assigned an initial value of 0. It is allowed to have both a numeric variable
initialization and format assignment for a particular variable.
See Formulas for more information.
Implied numeric variable definitions

Not all numeric variables are explicitly declared in the post customization file. Values located in a
formula statement or conditional branching statement are assigned to a numeric variable label by the
post executable when the post customization file is parsed.
Value in formula statement or conditional branching statement

The post executable creates a label for this in the internal numeric variable array. The label is built with
the characters v__ followed with its position in the internal list, for example, v_750. Do not create any
user-defined numeric variables with similar labels. For example:
real_var = (1 + x) * 10
The post executable creates a label for 1 and 10 in the formula statement.
Note: It is more efficient to initialize the numeric variables than to imply them if the value is repeated.
The post executable creates an entry in the internal list for each implied numeric variable.
ASCII literal
The ASCII literal is implied as a string by entering the decimal equivalent (0 to 255 ) of the desired
character as an output statement. This is NOT converted to a numeric variable in this context. For
example:
n, 35, e
The number 35 is converted to the pound character # as a string variable.

See www.asciitable.com for ASCII code values.

Formatting numeric variables

When you format a numeric variable, you specify how it should appear in the NC program. Formatting
numeric variables in the post customization file processor requires the use of two post functions:
The format statement, which is a general definition of the numeric format for the numeric
variables. This component is required.
The optional format assignment, which defines a prefix string, the format statement to
associate to the numeric variable, and a suffix string. The format assignment can also be
used to declare a numeric variable as previously mentioned.
Format statements
The MP language supports two format statement functions:
fs defines a single numeric format.
fs2 defines a numeric format that changes automatically depending on the Mastercam
configuration, inch or metric, at the time the NCI file was generated. The post executable
applies the appropriate numeric format (either inch or metric) based on the value of the
met_tool numeric variable.
Either format statement function may be used in the post customization file but cannot share the same
enumerator. For example, this would not be valid:
fs 1 0.7 #Decimal, absolute, 7 places
fs2 1 0.7 0.6 #Decimal, absolute, 7/6 places
You can define a maximum of 30 format statements. The following tables describe the form required
for the two format statements:

Format Statement (fs):

fs 1 2 3 4 5 6 7 8 9 10 11 12
Legend Description Syntax Setting Description

fs Format Statement fs Standard Format Statement function
function
1 space A space is required
2 Format statement id 0 - 30 Used by fmt function to identify the format
number statement
3 Sign (optional) + Force positive sign.
s Output space before.
omitted Sign the value as normal
4 Number of integer 0-9 Digits before decimal (or implied decimal)
digits
5 Integer/fraction . Use decimal point.
separator
, Use comma
space Omit separator
^ Omit decimal point for whole numbers only
% Omit comma for whole numbers only
6 Number of fraction 0-9 Digits after decimal (or implied decimal)
digits
7 Round off flag omitted Normal round off as required by number of
(optional) fraction digits.
2 Round to nearest even number.
5 Round to nearest multiple of 5.
9 Truncate the decimal at number of fraction digits
8 Keep leading zeroes l Keep/add leading zeroes.
flag (optional)
omitted Omit leading zeroes.
9 Keep trailing zeroes t Keep/add trailing zeroes.
flag (optional)
omitted Omit trailing zeroes.
10 Modality (optional) n Force non-modal.
omitted Use default modality.
11 Coordinate format omitted Absolute
(optional)
d Delta; incremetal but if zero do not output
i Incremental
12 Keep trailing zero z Keep a trailing zero with a whole number after
(optional) the decimal or comma.
omitted No trailing zero (depending on format).

Format Statement (fs2):

fs2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

fs2 Format Statement fs2 Standard Format Statement function
function
2 Format statement id 0 - 30 Used by fmt function to identify the format statement
number
3 Sign (optional) + Force positive sign.
s Output space before.
omitted Sign the value as normal
digits
separator
, Use comma
digits
7 Round off flag omitted Normal round off as required by number of fraction
(optional) digits.
digits
separator
, Use comma
digits

12 Round off flag omitted Normal round off as required by number of fraction
(optional) digits.
13 Keep leading zeroes l Keep/add leading zeroes.
flag (optional)
omitted Omit leading zeroes.
14 Keep trailing zeroes t Keep/add trailing zeroes.
flag (optional)
omitted Omit trailing zeroes.
15 Modality (optional) n Force non-modal.
omitted Use default modality.
16 Coordinate format omitted Absolute
(optional)
d Delta; incremetal but if zero do not output
i Incremental
17 Keep trailing zero z Keep a trailing zero with a whole number after the
(optional) decimal or comma.
omitted No trailing zero (depending on format).
To build a format statement, assemble the components from the entries in the Syntax column. Notice
that many of the entries can be omitted (or must be omitted) to generate the desired format. Only use
one selection if multiple choices are offered for any one component. The format statement must be
started in the first column and cannot be part of a postblock. For example, this defines format
statement one:
fs2 1 0.4 0.3t
This assembles the post function name fs2, and syntax components 1, 2, 4, 5, 6, 8, 9, 10, 11 and 14.
The components 3, 7, 12, 13, 15, 16 and 17 are implied by their omission.
The numeric formatter does nothing to control the number of integer digits written to the output. The
number of integer digits is only useful to pad the leading zeros if the l for leading format is used. The
delta d format outputs the absolute value if it is not zero, delta meaning output if a change. Incremental
output is calculated in the post executable as the difference from the previous move to the current
move. You should use incremental carefully because, at the moment after the NC output occurs, the
value is zeroed. If you do not define any format statements in the post customization file, format
statement number 1 is assigned 0 0 as the numeric format. This effectively removes any numeric
output.
The following table contains some examples of format statement. It is not practical to attempt to
display all the possible combinations of generated output.

Format statement examples
Statement Meaning Results

fs 1 0.1 Format statement ID #1 Input: 1.235
0 integer digits Output: 1.2
Decimal point Input: 123.0
1 fraction digits Output: 123.
fs 2 0^2 Format statement ID #2 Input: 1.235
Decimal point (omit with whole Input: 123.0
number) Output: 123
1 fraction digits
fs 3 4.4lt Format statement ID# 3 Input: 1.235
Decimal point Input: 123.0
4 fraction digits Output: 0123.0000
Both leading and trailing zeros
fs +4 4 4lt Format statement ID #4 Input: 1.235
Plus sign displayed Output: +00012350
4 integer digits Input: -1.235
No decimal point Output: -00012350
4 fraction digits Input: 123.
Both leading and trailing zeros Output: 01230000
fs2 5 0.4 0.3 Format statement ID #5 Input: 1.1235
0 integer digits Output, Inch: 1.1235
decimal point Output, metric: 1.124
4 fraction digits, Inch Input: 123.0
3 fraction digits, metric Output, Inch: 123.
(met_tool determines inch/metric) Output, metric: 123.
fs 6 1,32z Format statement ID #5 Input: 1.235
1 integer digit Output: 1,236
comma Input: 123.0
3 fraction digits Output: 123.0
rounded to the nearest even
zero trails on whole number

Format assignments
Once the format statements have been defined, use the format assignment function to associate a format
statement with a variable. The format assignment allows you to:
Declare the numeric variable (if it is user-defined).
Assign the numeric format from the format statement ID.
Prefix the value with a character string (optional).
Apply a suffix character string (optional).
Format assignment examples
fmt 1 2 3 4 5 6 7 8

fmt Format Assignment function fmt Format Assignment function
1 space A space is required.
2 Prefix (optional) Maximum of 15 characters. When the prefix
contains spaces or reserved character, enclose
the prefix in quotation marks (“ “).
3 space A space is required after a prefix
4 Format statement ID number 0 - 30 Identifies the format statement to be associated
with the variable.
5 space A space is required.
6 Numeric Variable Variable label to use the format.
7 space A space is required before a suffix.
8 Suffix (optional) Maximum of 15 characters. When the suffix
contains spaces or reserved character, enclose
the suffix in quotation marks (“ “).
To build a format assignment, assemble the components from the entries in the Syntax column the
same as for format statements. The format assignment must be started in the first column and cannot
be part of a postblock.
For example, the following line assigns the format statement 1 to the numeric variable x:
fmt X 1 x
assembling the post function name fmt, and syntax components 1, 2, 3, 4, 5 and 6. The components 7
and 8 are omitted so there is no suffix.
Here are some format assignment examples:
fmt T 4 t # Tool number
fmt N 4 n # Sequence number
fmt X 2 xabs # X position output (absolute)
fmt Y 2 yabs # Y position output (absolute)
fmt Z 2 zabs # Z position output (absolute)

fmt X 3 xinc # X position output (incremental)

fmt Y 3 yinc # Y position output (incremental)
fmt Z 3 zinc # Z position output (incremental)
fmt "TOOL - " 4 tnote “USED” # Note format
When a format statement/assignment is not made

Numeric variables can be declared and formatted in several different ways. This impacts how the
variable is displayed when written to the NC output, as shown in the following table:
Conditions Format Statement Prefix/Suffix Initial Value
Initialized ID #1 Variable label/none Assigned
Format assignment Assigned Assigned/assigned Zero
Initialized Assigned Assigned/assigned Assigned
format assignment
A global formula behaves the same as an initialized formula except that a global formula is evaluated
every time it is encountered. If a numeric variable is not to be output to the NC file, for example, when
the variable is used for calculations in the post customization file, it is not necessary to use the format
assignment.
Default format assignments

fs0
There are several numeric variables that are treated in a special way when the post executable is first
started. These variables are given default format statements and/or prefixes. You can overwrite the
default format by using a format assignment.
These predefined numeric variables are unique in that they are given the format statement 0 (fs0). Do
not attempt to create fs0 in the post customization file or assign it to a variable in a format assignment, it
is reserved for internal use by the post executable. The fs0 defines a numeric variable as a command
variable. Command variables typically call a routine in the post executable when they are encountered
on a postline. They do not display their internal value.
The following command variables are assigned fs0:
time
date
day
mon
year
month
progname
tlname
mergesub
mergeaux
mergeext

clearsub
clearaux
clearext
newsub
newaux
newext
c_msng
c_mmlt
c_rcc_setup
comment
tooltable
ex
exitpost
nci_rewind
fs1
These pre-formatted numeric variables are given a default prefix when the post executable is first
started. Along with all the remaining predefined numeric variables, they are given the default format
statement 1 (fs1).
Conditions Prefix
x, y, z X, Y, Z
xh, yh, zh X, Y, Z
xr, yr, zr X, Y, Z
i, j, k I, J, K
startx, starty, startz X, Y, Z
threadx, thready, threadz X, Y, Z
You can overwrite the default format by using a format assignment in the post customization file.
Note: It is possible to format a command variable and there are cases when you would do this (for
example, time and date variables). However, you would not normally assign a format to them because
they no longer can call the internal routine they are designed to access.
Numeric formatting rules summary

The function labels fs, fs2 and fmt begin in the first column.
Up to 30 format statements may be defined.
Numeric formats (defined by the format statement) must not exceed 15 characters in length,
excluding leading and trailing zeroes. For example, a format statement of fs 1 +3.9 has a total
of 14 characters. A format statement of fs 1 9.9 would overflow the memory.
If you do not assign a format statement to a variable, it is assumed to be fs1 (except for
command variables, which are fs0).
Prefixes and suffixes used with output variables must not exceed 15 characters in length.
If a prefix or suffix contains spaces or reserved characters, the characters must be enclosed in
quotation marks (" ").
Variables to be output to the NC program are normally formatted.
If an unformatted variable is output, its format will be fs1 and the variable label will be the
prefix in the output. This can be useful for debugging.
Modality with numeric variables

Numeric variable are identified by a label and this label represents a specific memory location that
holds the value of the numeric variable. When the post executable records the label in its internal
database, it also creates a duplicate entry for the numeric variable specifically to hold the last or
previous value that was generated. The variable label is prefixed with the characters prv_ and this label
is now assigned to the specific memory location that holds the previous value. For example:
x creates the previous variable prv_x
y creates the previous variable prv_y
z creates the previous variable prv_z
Having the previous variable value permits the post executable to test the current and previous value to
determine modality. The numeric variables that are to be output can be given the attribute of being
modal or non-modal.
A modal variable does not produce output if its current value is the same as its previous value, that is, if
its value hasn’t changed since the last time it was output. If the values are different, the current value
held by the numeric variable replaces the previous value held by the prv_variable when output is
complete.
A non-modal variable is always output regardless of the state of the current and previous value.
Numeric variables are modal by default, which means a variable will not be output unless its value has
changed (that is, its current value [var] does not equal prv_[var] value).
Forcing output of modal numeric variables

Modal numeric variables can be forced to output by using the asterisk variable modifier in the output
statement, for example, *x, or by declaring it non-modal in its assigned format statement.
The n parameter in the format statement defines it non-modal, for example, fs 1 0.4n. (see fs and fs2)
Numeric variable output statements

The numeric variable output statement is placed on the output postline. When the numeric variable is
encountered on the output postline, the global formula, if associated, is evaluated. The current value is
rounded according to the assigned format statement and compared with the previous value (prv_[var]).
The current value may be written to the NC output, depending on modality. The previous value
(prv_[var]) is updated with the current value if NC ououtput occurred. The modifier, if any, that
decorates the numeric variable is used to control the output behavior. Output is also controlled based
on the modality of the numeric variable.
Presented next are the numeric variable output forms as they should appear on an output postline.

Numeric variables
Variables of this type are the predefined variables defined in the post executable file or initialized in the
post customization file with a unique label as a user-defined numeric variable. This is presented on the
output postline with out any modifier. Output to the NC file is expected based on modality.
For example:
n, gcode, x, y, z, real_var, e
Forced numeric variables (*)

Both user-defined numeric variables and numeric variables can be forced to output. The prefix asterisk
(*) overrides modality and forces output to the NC file. Output to the NC file is expected.
For example:
n, *gcode, *x, *y, *z, *real_var, e
For another way to force outputs, see the force() function in Volume1, Functions.
Update numeric variables (!)

Both user-defined numeric variables and numeric variables can be forced to update. The prefix
exclamation (!) updates the previous value for the numeric variable. This takes the current value for the
variable, for example, x, and copies it’s value into the previous value for the variable, which is prv_x.
No output to the NC file is expected. For example:
!x, !real_var
This is a useful technique to control the output of a modal variable. When this is done prior to the
numeric variable’s normal output, the normal output does not occur because of modality.
Format numeric variables (@)

User-defined numeric variables and numeric variables have the current value formatted to the assigned
format statement. The prefix symbol (@) updates the current value for the variable but produces no
output to the NC file. For example:
@x, @real_var
The @ modifier can be used before comparing values of current to previous or any place the rounded
value is needed and output or updating the previous value is not desired. See the formula fmtrnd in
Volume1, Formulas when comparing in a conditional branching statement and the rounded value is
needed.
Dependent numeric variables ( ` )

Both user-defined numeric variables and numeric variables can be prefixed with the grave accent (`).
This controls output to the NC file based on any other valid output on the assembled NC line.
Sequence (n) already behaves this way. For example:
n, `gcode, x, y, z, e
In this output line, if x, y and z are modal (no output unless the previous output was different) and any
one previous value was different for x, y and z, you would expect output similar to:
N10G00X1.Y2.Z3.
If all the previous values were the same for x, y and z, then you would expect the entire line to be
omitted from the NC output, even if the value for gcode is changed.
This is useful in preventing undesirable output such as would happen if gcode had been 1 in the
example above. In this case, the following would have been generated.
N10G01
Debug numeric variables (~)

Both user-defined numeric variables and numeric variables can be forced to output without affecting
the values internal to the post executable for the variable. The prefix tilde (~) forces output to the NC
file for debugging. For example:
~x, ~real_var
Note: Do not use this for normal output!
Command variables
Command variables are unique in that they trigger an event or routine in the post executable, possibly
calling back to the post customization file for some postblock instructions. All command variables are
predefined numeric variables. Most should not be prefixed with a variable modifier or assigned a
format statement. For example:
comment

Both user-defined numeric variables and numeric variables are all automatically assigned a duplicate
variable for storing the previous value of the variable. The post executable controls modality by
comparing the value stored in prv_[var] with the current [var]. However, because the current value is
rounded before the previous value is updated, the previous numeric variable is always the rounded
value. This can create problems when comparing the current value to the previous value if the current
value is not rounded.
For example, suppose the NCI data for x on two concurrent moves is 1.234567 and the format
statement is fs 2 0.4 to get four fractional digits. On the first output, the values would be:
x = 1.2345 and prv_x = 1.2345
However, because of rounding, before the second output and after the second NCI data read, the values
would be:
x = 1.234567 and prv_x = 1.2345

If a comparison is performed on these values, you will get a false return. See the formula fmtrnd in
Volume1, Formulas when comparing in a conditional branching statement and the rounded value is
needed. Previous numeric variables (prv_[var]) should not be used for normal output and cannot be
prefixed with a variable modifier. These are usually output when debugging or used in formula
statements or conditional branching statement.
For example:
prv_xabs
The following table shows the effect of variable modifiers on the output statement:
Modifier Solve Round Force Update Usage
Syntax Global Current Output pr_[var]
Formula Value Value
Variable var yes yes no yes Normal behavior.
(no
modifier)
Forced *var yes yes yes yes Force output.
Variable
Update !var yes yes no yes Access the prv_[var] to update it
Variable
without output.
Format @var yes yes no no Round the current value.
Variable
Debug ~var no no yes no Force output for debugging.
Variable
Dependent `var yes yes no yes Output is dependent on other output
Output
Variable on the postline.
See Volume1, Postblocks for more information on postblocks and postlines.
Numeric variable types

The numeric variable type indicates to the post writer where the numeric variable value originated. For
example, when arc motion is processed, the information on the NCI parameter line does not contain the
arc radius directly. To present this value in the numeric variable arcrad, the post executable must
calculate the distance from the center of the arc to the end point of the arc. Therefore, arcrad is given
the type of calculated variable.
Listed here are the variable types used within this documentation for the predefined numeric variables:
NCI variable – The value for the variable is taken directly from the NCI file parameter line.
Calculated variable – This type of numeric variable receives its value as the result of
calculations from NCI variable data.

Post switch variable – The post switch variable is initially set to a default value of zero by
the post executable. Its value is set in the post customization file with a numeric variable
initialization if a different value is desired. This type of variable allows the post writer to
specify which processing option is used with various routines in the post executable.
Note: Some post switch variables are also returned values when the NCI file processing
begins within the post executable.
Constant - The constant is a numeric variable that is set to an initial value by the post
executable when it is first started.
Note: A constant in the MP language is not protected in any manner. Be careful not to
assign a value to a constant or use it in a formula that can modify the value.
Command variable – Command variables do not normally take values. The variable label
is used as a trigger to execute a post executable routine. The time and date variables are the
exception. Formatting these variables exposes the value of the variable and they become
system data variables.
Helper variable – Similar to a calculated variable, this variable is the result of a formula
calculation. They are global variables that are required when the number of parameters
required for a post formula cannot be passed within the argument space available.
Boolean result – As this description implies, the value is the result of a conditional
branching statement or formula that returns –1, 0, or 1 as a result.
System data variable – Values from either the system (computer) or from Mastercam
directly.
Post data variable – Value from a post numbered question in the PST file.
File name variable – The command line file name strings passed to the post executable.
For a list of numeric variable descriptions, see Volume 3, Numeric Variables.
Numeric variables in formulas and conditional branching

Numeric variables cannot use any of the variable modifiers when used in the conditional branching
statements or formula statements. See the formula fmtrnd when comparing in a conditional branching
statement and the rounded value is needed. See Volume1, Formulas for more information.

Volume 1 Chapter 10 String Variables
10 String Variables
For a description of each string variable, please see Volume 3, String Variables.
String variables are variables that represent character strings in the MP language. The MP language
has only two types of variables — numeric values and character strings. Character strings contain
characters from the ASCII character set (decimal 1 to 255). String variables are identified by labels
assigned to the character strings. By using the variable label in the post customization file, you can
access the character string it represents. The string variables can be parameters passed from the NCI
file, file paths, names and extensions, or comments passed from the NCI. String variables can be
defined by the post writer to be used within the post customization file.
String labeling and initialization

A string label is used to identify the string variable. The post executable already holds a list of
predefined string variables. String variables can be declared in the post as user-defined string variables.
To create a string variable, a string variable initialization is inserted in the post. The string variable
initialization can also define the contents of a predefined string variable. The string label must adhere
to the following rules:
Always start in the first column of the post customization file
Begin with the letter “s”
Consist of letters (“a-z”), numbers (“0-9”), and the underscore (“_”)
Have a maximum of 25 characters in the label
Be defined outside of a postblock
The character string must adhere to the following rules:
The string length cannot exceed 80 characters.
At least one space must be used a delimiter between the label and the character string.
To assign a character string to a string variable, the character string is placed on the same line in the
post customization file as the string label. The character string is separated from the string label with at
least a single space. For example:
string1 character_string
Note: You must be careful when creating a string variable initialization that you do not use the colon
(:) or the equal sign (=). This error makes the post executable interpret the label as a numeric
variable!
Often it is necessary to have spaces, the colon, equal sign, double quotes, single quotes, or other
characters in the character string that can cause the post executable to misinterpret the character string.
To read these characters as part of the character string, enclose the character string with double quotes
or single quotes.
Chapter 10 String Variables Volume 1
Note: In all cases, the pound sign (#) is interpreted as a post comment. You must use the ASCII literal
(35) in your code or convert the ASCII number to a string.
Here are examples of string variable initializations cases:
To create an empty string, place the string label on the line by itself or with spaces and the post
comment.
string1 # Initialize with nothing following
To create a string with spaces, place the character string in double quotes.
string1 “space s” # Initialize with spaces
To create a string with characters that can confuse the post executable, place the character string in
double quotes.
string1 " : = "
To create a string that contains double quotes, place the character string inside single quotes.
string1 ‘“double quotes”’ # Initialize with ‘ (single) ‘ quotes
To create a string that contains single quotes, place the character string inside double quotes.
string1 “’single quotes’” # Initialize with “ (double) “ quotes
The pound sign and any other characters in the standard ASCII characters set in the range of 1 to 255
can be assigned to a string using the string function no2asc. This must be coded as part of a postblock,
preferably a pre-process postblock, and the resulting string can be used with the string math functions
to append the characters. For example:
string1 # Initialize an empty string
string2 TOOL # Initialize a string
pprep
string1 = no2asc(35) # Convert (ASCCI value) 35 to the ‘#’ character
string2 = string2 + string1 # String2 now is ‘TOOL#’
See Volume 1, Formulas for more information.
Implied string definitions

Not all string variables are explicitly declared in the post customization file. Some output statements
located on a postline (specifically string literal, dependent string literal and ASCII literal) are assigned
to a string label by the post executable when they are encountered on a postline when the post
customization file is parsed. See Volume 1, Postblocks for more information.
String literal
A string literal is a character string is enclosed by double quotes (“ ”). The syntax implies a user-
defined string variable. Output to the NC file is forced.
For example:
”M11”
The post executable creates a label for a string literal in the internal string array. The label is built with
the characters “s__” followed with its position in the internal list, for example, s__50. Do not create
user-defined string variables with similar labels.

The dependent string literal differs from the string literal in one way—the character string is enclosed
with the single quotes (‘ ’) instead of double quotes (“ ”). This controls output to the NC file based on
any other valid output on the assembled NC line. For example:
’M11’
The post executable labels dependent string literals the same as normal string literals.
ASCII literal
The ASCII literal is implied as a string by entering the decimal equivalent (0 to 255) of the desired
character as an output statement. Output to the NC file is forced.
For example:
35
is converted to the pound sign (#). The post executable creates a label for an ASCII literal in the
internal string array. The label consists of the character “s” followed by the decimal equivalent entered
on the postline, for example, s__35. Do not create user-defined string variables with similar labels.
Note: It is more efficient to initialize string variables than to imply them if the string is repeated
because the post executable creates an entry in the internal list for each implied string variable.
This is an example of the output line variables on a postline:
# String literal
"M11", e
# Dependent string literal

'M11', e
# ASCII literal
65, 35, 65, e
Null character definition

Null characters cause problems with strings because they represent the string terminator to the post
executable. When you define the ASCII literal for the 0 decimal equivalent, the post executable must
convert the character to a token string to recognize it when the NC output is generated. This token is
_NULL_CHAR_ and can be is implied by placing the “0” ASCII literal on a postline or defining a string
with the token string. Both techniques are illustrated next:

snull “_NULL_CHAR_” # String defined with the null token string
ppostblock # A user-defined postblock

0, 0, 0, 0, 0, 0, 0, 0, 0, 0
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
snull, snull, snull
Note: Only ten ASCII literal null “0” decimal equivalents are allowed on a single postline. Do not
concatenate the token string with a formula. The token is only recognized as the token string as shown.
String variable output statements

The string output statement is placed on the output postline. When a string variable, string literal, or
ASCII literal is encountered on the output postline, the string value is written to the NC output. Output
can be prevented based on modality or the modifier that decorates the string variable.
The next sections describe the string variable output forms as they should appear on an output postline.
String variable
A string variable is predefined in the post executable or initialized in the post customization file with a
unique label as a user-defined string variable. It is presented on the output postline with out any
modifier. Output to the NC file is forced. For example:
n, stck_matl, sg00, e
Forced string variable (*)

String variables can be modified with the force output character. The asterisk (*) prefix forces output
to the NC file, although this is not necessary for a string variable. See Selector string variable. For
example:
n, *stck_matl, *sg00, e
Dependent string variable ( ` )

String variables can be modified with the dependent output character. When the string variable is
prefixed with the grave accent (`), the entire output postline that contains the dependent string variable
is output to the NC file only if there is some other valid output. For example:
sg00 “G00” #Initialize the string variable
Below is a valid output postline.

n, `sg00, x, y, z, e
If x, y and z are modal (that is, there will be no output unless the previous output was different) and any
one previous value was different, output would be similar to:
N10G00X1.Y2.Z3.
If all the previous values were the same, then the entire line would be omitted from the NC output.
Debug string variable (~)

The tilde (~) prefix forces output to the NC file for debugging, although it is not necessary for a string
variable. See Selector string variable below. For example:
~ snamenc, ~ sg00, e

The string select function call is the target string in a string select function. The target string variable is
declared like a normal string variable. The placement of the string label as an output statement is
sufficient to invoke the string select mechanism. The selector string variable inherits the modality of
the numeric variable selector in the string select function.
See Volume1, Functions for more information.
The variable modifier is more useful with the selector string variable in controlling how the NC output
occurs. The selector string variable, selector forced string variable, selector dependent string variable
and selector debug string variable are described below.
Assume that the following string selector function
# Motion G code selection
sg00 G0 # Rapid
sg01 G1 # Linear feed
sg02 G2 # Circular interpolation CW
sg03 G3 # Circular interpolation CCW
sg04 G4 # Dwell
sgcode # Target for string
Selector string variable

The selector string variable output to the NC file is controlled by the modality of numeric variable
selector gcode. For example, below is a valid output postline.
n, sgcode, x, y, z, e
If gcode is modal (that is, will not be output unless the previous output was different), and the previous
value was different, output (gcode = 0) would be:
N10G00X1.Y2.Z3.
If the previous value of gcode was the same, output would be similar to:
N20X2.Y3
Selector forced string variable

A selector string variable can be modified with the force output character (*). The asterisk (*) prefix
forces output to the NC file and overrides the modality of the numeric variable selector gcode. For
example:
n, *sgcode, x, y, z, e
The NC output on each call to this output postline would produce the output following strings:
N10G00X1.Y2.Z3.
N20G00X2.
N30G00Y3.
Selector dependent string variable ( ` )

The selector string variable can be modified with the dependent output character (`). When the selector
string variable is prefixed with the grave accent (`), the entire output postline that contains the
dependent string variable is output to the NC file only if there is some other valid output. For example,
in this output postline:
n, `sgcode, x, y, z, e
If gcode, x, y and z are modal (that is, will not be output unless the previous output was different), and
any previous value was different for x, y and z, output would be similar to:
N10G00X1.Y2.Z3.
If all the previous values for x, y and z were the same, then the entire line would be omitted from the
NC output, even if the value for gcode is changed.
Selector debug string variable (~)
The selector string variable can be forced to output. The tilde (~) prefix forces output to the NC file for
debugging. Do not use this for normal output. For example:
~sgcode, e
String literal
A string literal is a character string enclosed with the double quotes (“ ”). The syntax implies a user-
defined string variable when parsed by the post executable. Output to the NC file is forced. For
example:
n, “G40”, “G80”, e
Dependent string literal (‘ ‘)

The dependent string literal differs from the string literal—the character string is enclosed by the single
quotes (‘ ’) instead of double quotes (“ ”). Output to the NC file is controlled in the same manner as the
dependent string variable. For example:
n, sgcode, x, y, z, ‘M12’, e
If gcode, x, y and z are modal and all the previous values were the same, then the entire line would be
omitted from the NC output.
ASCII literal
Any of the standard ASCII characters can be output to the NC file. Enter the number of the decimal
equivalent (0 to 255) of the desired character as an output statement. Output to the NC file is forced.
For example, to output the pound character (#), which is ASCII value 035:
n, “TOOL”, 35, e # This would output something like N150 TOOL#
4 # This would output the control character CTRL-D, (which mean End-Of-Transmission to some machines)
Note: Numbers in output postlines are interpreted as the ASCII decimal equivalent. In a formula
postline or Boolean postline, they are always interpreted as numbers.
See Volume 1, Postblocks for more information on postblocks and postlines.
String functions
String functions are used to convert and manipulate string variables or numeric variables with string
data associated to them. This table is an overview of the functions available for string variables.
Note: It is not recommended to use the string literals with math functions.
See Formulas for more information.
Function Name Description and example
+ String variable concatenation. Limit total line length to 79 characters.
string1 = string2 + string3 + string4
= Assignment formula. Copies string variable into result string variable.
string1 = string2
= Boolean formula. Compares string variables; case sensitive. Returns 1 if
exact match, 0 if not exact match.
if string1 = string2, paction
<> Boolean formula. Compares strings; case sensitive. Returns 0 if exact
match, 1 if not exact match.
if string1 <> string2, paction
lcase Converts a string variable to lowercase characters.
string1 = lcase(string1)
string1 = lcase(string2)
ucase Converts a string variable to all uppercase characters.
string1 = ucase(string1)
string1 = ucase(string2)
strlen Gets the number of characters in a string variable.
real_result = strlen(string1)

strstr Given two string variables, determines if the first string variable parameter
is a sub string of the second string variable parameter. The return value is
the index of the starting index of the first string variable in the second string
variable, or 0 if no match is found.
real_result = strstr(string1, string2)
brksps Breaks a string variable at the character position specified by the numeric
variable of the first parameter. The original string (the second parameter)
holds the start of the broken string and the result string variable holds the
end of the original string variable.
string2 = brksps(real_result, string1)
scan Given two string variables, determines if the first string variable parameter
is a sub string of the second string variable parameter. If the sub string is
found, the second string variable is scanned for a number starting
immediately after the location where the sub string was matched in the
second string variable parameter. The return value is the number scanned
from the second string, or -9999 if no sub string or no number is found.
real_result = scan(string1, string2)
updstr Updates the target string variable in a string select function. Prior to the
formula function, set the value for the numeric variable selector in the string
select function. The target string variable is updated (that is, holds the
correct string for the numeric variable selector) but does not produce NC
output like a typical string select function call. The result is 1 if the current
and previous of the numeric variable selector are unequal, or 0 if they are
equal.
real_result = updstr(string1)
rpar Extracts numeric variables from a space-delimited string variable. A list of
unique user-defined numeric variables that corresponds to the parameters in
the delimited string must be in the post customization file. The target
numeric variable of the formula function is the first entry in the list of
numeric variables. The first parameter in the function is the string variable
with the space-delimited numeric entries. The second parameter (numeric
variable) in the function indicates the number of entries in the list.
real_var1 : 0 #User-defined numeric variables
real_var2 : 0
real_var3 : 0
real_var4 : 0
real_var5 : 0
real_var1 = rpar(string1, 5)

plcval Extracts a value from a string variable that contains numbers. Based on the
position relative to the decimal location or the implied decimal location, a
single integer value is extracted. To the left of the decimal position are
positive locations and to the right are negative locations. If the string
variable is signed, the sign is applied to the leftmost digit only. A position
selected out of range returns 9999 to the resulting numeric variable.
Otherwise the return value is the extracted integer argument as a string and
the second argument is a value.
real_result = plcval(string1, 2)
no2asc Converts the ASCII decimal equivalent (1-255) into the ASCII character.
string1 = no2asc(35)
no2str Converts the value of a numeric variable and returns it to the result string
variable. The resulting string variable holds the results of the numeric
variable rounded to the format statement assigned to the numeric variable.
string1 = no2str(real_var)
nwadrs Changes the prefix string assigned with a format statement for a numeric
variable. It returns a 0 if the prefix string was truncated to 15 characters
(maximum characters for a prefix string), or 1 if not truncated.
real_result = nwadrs(string_x, real_var)
mprint Displays a message (a string variable) to the screen. The output message is
not written to the NC output. mprint takes a single string variable or a single
numeric variable. The return value is 0 if numeric variable was passed or 1
if a string variable was passed to the function.
real_result = mprint(string1)
real_result = mprint(real_var)
Capturing system numbered questions

The system numbered questions are a list of questions at the end of the post customization file (.PST)
that control how Mastercam and the post behave. The responses to system numbered questions can be
captured in a string variable. When the post customization file is parsed, the system number questions
are also parsed.
The integer value of the system numbered question is compared to any user-defined string variables
that are prefixed with the characters “sq” and followed by a number, for example, “sq38”. The number
following the “sq” prefix (38 in this case) is checked to see if it matches the system numbered question
being parsed and, if a match is made, the remainder of the string is parsed. The response to the system
numbered question is then returned to the string variable.
Note: If the response is a number, you must convert the string to a number using one of the post
functions for string conversion. Do not create user-defined string variables with similar labels (sq38)
that are not intended to capture the system numbered question response.
The technique is illustrated next.

If the system numbered question in the post customization file to be captured is:
38. Rapid feedrate? 300.0
The proper syntax for the user-defined string variable is:

sq38 # User-defined string variable to capture feedrate
After the post customization file has been parsed, the user-defined string variable will contain “300.0”.
Volume 1 Chapter 11 Post Functions
11 Post Functions
This chapter describes the functions in the MP language. Functions are unique mechanisms in the MP
language that support the numeric variable format definition and assignment, string select feature, look
up table features, buffer files, user prompt feature, and tape leader/trailer generation. These function
mechanisms rely on a declaration in the post customization file for the feature, for example, defining a
look up table or buffer file, and a math formula or a command variable as the method to call the feature.
Difference between formulas and functions

Formulas refer to math operators and math formulas. Functions are the unique mechanisms in the MP
language that support the string select feature, look up table features, buffer files, and the user prompt
feature. These function mechanisms rely on a declaration in the post customization file for the feature
and a formula as the calling method.
See Volume 1, Formulas for information on formulas.
MP post functions
These are the post functions in the MP language. Because the functions are diverse and some are
complex, not all the functions are described in detail in this chapter. Refer to the chapter that is
referenced in this list for more detail on a specific function.
delay – The function stops processing for the time entered in seconds. The minimum time
accepted is a millisecond. See Volume 2, Graphics Functions for information.
fs, fs2 – The format statement is a general definition of the numeric format for the numeric
variables. See Volume 1, Numeric Variables for information on this function.
fmt – The format assignment defines a prefix string, the format statement to associate to the
numeric variable, and a suffix string. See Volume 1, Numeric Variables for information on this
function.
fnewsub – The function supports renaming a subprogram with nested subprograms for Version
9. See Volume 2, Subprograms for information on subprograms.
fstrsel – The string select function allows the post processor to assign a string variable from a
list of string variables to a target string variable based on the value of a numeric variable
selector used in this selection function.
flktbl – Lookup tables are two-column tables that associate a value in one column with a value
or variable in the matching column and returns the value from the matching column. The
formulas used to access lookup tables are: flook, frange, and finc.
Chapter 11 Post Functions Volume 1
fq – The user prompt function allows you to display prompts or questions in the Mastercam
prompt area at the bottom of the Mastercam application screen. The return value can be used in
the post customization file. See Volume 1, Prompt Questions for information on this function.
fbuf – Buffer files are files that you can use with the MP language as a place to store and
retrieve data. See Volume 2, How Buffer Files Work for information on this function.
fprmtbl – The NC parameters read from the NCI file or operation parameter file are not
assigned variable names but must be assigned to numeric and string variables with the
Parameter table function. See Volume 3, Parameter Information for information on this
function.
fleader – The tape leader and trailer is not truly a function, but behaves more like a command
variable. It has remained part of the post functions because of earlier design implementation.
force – This function forces the variable to output on the next output call. Modality is reapplied
from the format (fmt) statement.
fnewsub function
The fnewsub function was added to support renaming a subprogram with nested subprograms for
Version 9. V9 nested subprograms (where sub_level is initialized to 3 or 4) use the current nesting level
to control the subprogram naming. V8-type subprograms (where sub_level is initialized to 1 or 2) use
the command words newsub, newaux and newext to close a subprogram and reopen it with a different
name. V8-type subprograms were able to use the existing post subfile structure in MP, and this
mechanism remains fully functional even with nested subprograms enabled.
V9 nested subprograms are not able to use the existing subfile structure because the nesting levels are
not limited. To allow the same functionality, the fnewsub function was added. The first argument is a
string variable with the complete path and file name. The second argument is the nested level that you
want to rename the output file. The return value is 1 if successful or 0 if it fails. The numeric variable
subfile is used to determine if the file is opened new (subfile = 1) or the contents are appended (subfile =
2).
snewname "c:\mcam9\mill\nc\newname.nc"
postblock #A postblock
subfile = 1
result = fnewsub (snewname, 2)
The above closes the output file for the subprogram level two (subprogram levels are returned in the
variable sub_level) and reopens it as new with the file name (c:\mcam9\mill\nc\newname.nc).
With the subfile structure, the code would be:
snewname "newname"
postblock #A postblock
auxprg = 1
snameaux = snewname
newaux
String select function (fstrel)

The string select function (fstrel) allows the post executable to choose a character string from a list of
string variables for assignment to a specific string label. The selection is based on the value of a
numeric variable selector. This permits the string variable’s assigned character string to change based
on the selection process described here. Normally, this function results in output to the NC file.
String select tables

A string select table is created in the post customization file for each string select function that is
needed. You may add as many of the string select tables as you want. The structure consists of an
implied array of string variable initializations. The implied array is simply an ordered list of the
initializations. The start index in the implied array is 0. Immediately after the implied string array, the
string variable that is to be the target (the string variable to be reassigned) of the selection process is
declared. Next, the actual function declaration fstrsel is made.
The string select function declaration must be started in the first column of the post customization file.
All the elements must be included in the declaration. The function declaration for fstrsel is assembled
with the following elements:
String Select Function (fstrsel) description

f s2 1 2 3 4 5 6
Legend Description Syntax

fstrsel String Select Function declaration fstrsel
1 space (required) at least 1 space
2 Label of the string variable at the start of the implied array 1 – 30 characters
4 Label of numeric variable (the selector)
6 Label of the string variable (the target) 1 – 30 characters
For example, a string select table can be used to output a different M code based on the value of the
numeric variable coolant. The following code illustrates this example.
# Coolant M code (string selection table)
sm09 M9 # Coolant Off

sm08 M8 # Coolant Flood
sm08_1 M7 # Coolant Mist
sm08_2 M8 # Coolant Tool
scoolant # Target variable for string
fstrsel sm09 coolant scoolant
Example output postline contains the scoolant target string.

plin # Linear line move - at feedrate
n, sgcode, x, y, z, fr, scoolant, e
In the example, the string select function, fstrsel, marks the string variable scoolant as the target of a
string select function. It also associates the string variable sm09 as the beginning of the implied array
(table) to make selections from, and associates the numeric variable selector coolant as the index
position in the implied array to make the selection. Each time the target string variable scoolant is
encountered on a postline, the post executable performs the following steps:
1. Get the value of the of the numeric variable selector coolant.
2. Go to the start of the implied string array sm09.
3. Index (from base zero) to the array position using the value of the numeric variable coolant.
Select the string variable in the implied string array at this index.
4. Copy the selected string variable contents to the target string variable scoolant.
5. Output the target string variable using the modality of the numeric variable selector coolant.
Update the numeric variable coolant as if it had been output to maintain modality.
For the example above:

If the numeric variable selector coolant equals 0, the post executable will copy the contents
(“M9”) of the first (index 0) string variable sm09 to target string variable scoolant and outputs
M9.
If the numeric variable selector coolant equals 1, then the post executable will copy the contents
(“M8”) of the second (index 1) string variable sm08 to target string variable scoolant and
outputs M8.
The logic above applies to all string select functions.
Using updstr
The formula updstr is used to update the target string variable without NC output. For example:
real_result = updstr(scoolant)
See Volume 1, Formulas for more information.
ADDENDA
Looking up values in tables

Use the flktbl function to define a table of values. The flook, frange and finc
functions can then be used to access the table.
Note: You should use buffer files for very large tables. See Volume 2, Buffer Files for
information on buffer files.
Declaring lookup tables with flktbl

A lookup table is created in two parts. It follows the structure shown here.
flktbl table number number of table entries
code 1 match 1
code 2 match 2
[Additional code—match pairs...]
The first line declares the table. It includes two integers. It must begin in the first column of
the line.
 The first integer identifies the table.
 The second number is the number of entries in the table.
The following lines are the individual table entries. Each consists of two numbers or
strings. The flook, frange and finc functions will use the value from the first column to
access the value from the second column.
 The number of lines must match the number stated in the declaration.
 Each line must be indented at least one space.
 The columns of a lookup table can consist of integers, real numbers, or strings (see
below for special rules for string usage).
The following table summarizes these elements:
Table 1: flktbl elements

flktbl Lookup table declaration
table number Table number from 1 to 32000. Each lookup table in
your post should have a different number.
number of table entries Number of items in table
code 1 First code in table (output)
match 1 First lookup value (the match closest to an input value )
in table
code 2 Second code in table
match 2 Second match in table
Additional code/match pairs…
The following code is an example of a lookup table.

Example 2: Declaring a lookup table with flktbl
flktbl 1 3 #Lookup table definition for spindle gears
40 0 #Low gear range
41 400 #Med gear range
42 2250 #Hi gear range
Note: Be sure that the “number of items in table” correctly matches the actual number of
code/match pairs! This is the only way that your post can correctly interpret the table.
ADDENDA
Using strings in lookup tables

The use of strings in lookup tables has been supported beginning with Mastercam X4.
However, there are a couple of restrictions that you need to keep in mind.
 If the lookup table contains string values, you cannot use the finc function to
access it.
 The frange function does not make any sense if the second column of the table
(the lookup value) has strings. So if you have strings in the second column, flook
is the only supported function.
 When you are looking up a string value, there must be an exact match in order to
return a value. When you are looking up numbers, the flook function can return a
value based on the closest match, but it cannot do this for string values.
 Both flook and flook support strings in the first column of the table.
Example 3: Declaring a lookup table that uses string values
flktbl 1 3 #Lookup table definition for spindle gears
“Low” 0 #Low gear range
“Med” 400 #Medium gear range
“High” 2250 #High gear range
Table functions: flook, frange, finc

Mastercam includes three functions that let you access lookup tables. They all use the
same general format:
target = command ( number , value )
where
target Variable to assign returned value to

command flook, frange, or finc command
number Table number to be used
value Variable or numeric value to compare table items to
flook
The flook function looks up the closest match to a given value in column 2 and returns a
value from column 1. The following example shows a sample lookup table to look up
spindle codes (sscode) for a range of spindle speeds (ss$). The lookup value can be either
a string or numeric value.
Example 4: Using flook to return values from a table
flktbl1 10 # Define table number one with ten entries.
58 64 # sscode = 58, if ss$ < 64, = 64, or closer to 64 than 112
63 112 # sscode = 63, if ss$ is closer to 112 than 64 or 180.
75 1400# sscode = 75, if ss$ is closer to 1400 than 900 or 1800.
76 1800# sscode = 76, if ss$ is closer to 1800 than 1400 or 2800.
77 2800# sscode = 77, if ss$ is > 2800.
Note that the logic for the above table returns an sscode value of 77 if ss$ is closer to 2800
than 1800, and also returns the same value if ss$ is greater than 2800.
When placed on a postline, the following formula causes the post processor to return a
code from the lookup table #1 (shown above) based on the current ss$ value:
sscode = flook( 1, ss$ )
ADDENDA
The logic works as follows:

 If ss$ is 24, then sscode will be 58.
 If ss$ is 425, then sscode will be 67, because 425 is closer to the higher match
value.
 If ss$ is 1150, then sscode will be 74, because 1150 is closer to the lower match
value.
frange
You can use the frange function on a lookup table to return the greatest match from
column 2 that is less than or equal to a given value, and return the corresponding value
from column 1.
For example, when the following formula is placed on a postline, it causes the post
processor to return a value from the lookup table #1 based on the current ss$ value:
sscode = frange( 1, ss$ )
The logic works as follows:

Note that the frange function can return a string value, but the lookup value must be a
number.
finc
The finc function increments the output column of a lookup table. It looks up the closest
match in column 2 to a value and increments the code in column 1. This makes it possible
to keep count of the number of times a tool is used. The incremented count is returned.
The count then may be accessed (for reading) by flook or frange.
1 Set up the lookup table like this example:
flktbl 1 30 # Lookup table for tool usage tracking (30 entries)
0 1 # Tool number
0 2
0 3
[…remainder of the table is not shown…]
Notice that each value in the first column is 0. The second column contains a list of
tool numbers.
2 Create a user-defined variable, incorporating the finc function:
ntimesused = finc( 1, t$ ) # Increase count each time "t" is used
The first time this postline is executed, ntimesused will have the value 1, since
the initial value in column 1 is 0. At that time, the value in column 1 in the lookup
table will be incremented by 1—in whichever row corresponds to the value of t$.
Note that you cannot use finc if either column in the lookup table contains strings.
Fleader command/function
The post function fleader will output a series of a selected character to the NC output. This function is
intended to provide the tape leader and tape trailer when punching paper tape. This function behaves
like a command variable. It is left over from an early design implementation and has remained
(incorrectly) as a post function.
The function operates by using the function label fleader as a trigger on an output postline. When the
function label fleader is encountered, an internal routine in the post executable is called. This routine
takes the values in the numeric variables ldrcode and ncldr and processes a program “while” loop that
continues for the value of ncldr. On each iteration of the “while” loop, the character with the ASCII
decimal equivalent of the value of ldrcode is output to the NC file.
To have a different length trailer or character, the variables ldrcode and ncldr must be reassigned locally
in the postblock and before the trigger label fleader.
Normally, fleader is placed in the beginning of the postblock pheader and at the end of the postblock
peof. For example:
ncldr : 25 # Initialize the number of leader characters to output

ldrcode : 0 # Initialize the leader character to output ( 0 = decimal equivalent of the “null” character)
pheader #Call before start of file

fleader # Output the tape leader
"%", e
*progno, e
"(DATE, Day-Month-Year - ", date, " TIME, Hr:Min - ", time, ")"
peof #End of file

n, "M30", e
"%", e
ncldr = 30 # Alter the number of leader characters to output
ldrcode = 42 # Alter the leader character to output decimal equivalent( 42 = the “*” character)
fleader # Output the tape trailer
Note: You can find an ASCII code chart at www.asciitable.com
Force function
The force function was added in Version 9. It allows forcing a variable to be output on the next output
call. Modality is then reapplied from the format (fmt) statement assigned to the variable.
The following output calls reset this flag: normal output, forced output (*), and dependent output (`).
Because this function takes two arguments, a range of variables can be forced to output.
The first argument is the lower index position in the variable database. The second argument is
the higher index in the variable database. If multiple variables are specified, the variables MUST have
been defined in an “ordered-list” fashion in the post customization file!
Example 1:
result = force(x ,z)
Forces output of x, y, z on the next output postline call that references the x, y, z variables.
Example 2:
result = force(x, x)
Forces out only x on next on the next output postline call that references the x, variable.
The selector variable of a string select table can be set to be forced, the string output is then forced on
the next output.
Example 3:
result = force(gcode, gcode)
sgcode # G-code will be forced to output
Note: Strings cannot be directly forced with this function.
Volume 1 Chapter 12 Formulas
12 Formulas
This chapter describes use of formulas in the MP language. For a description of each formula, please
see Volume 3, Formulas.
Formulas, in this discussion, are applied to the two MP language statement types that allow formulas:
the formula statement
the conditional branching statement
Both of these statement types use the same syntax in the argument portion of the statement. The major
difference between the two types are the Boolean statement, which evaluates for zero or non-zero in the
result of the formula, and the formula statement, which makes an assignment to the variable that is the
target of the formula.
Difference between formulas and functions

Formulas refer to math operators and math formulas described in this chapter. The term function is
used to describe the unique mechanisms in the MP language that support the string select feature,
lookup table features, buffer files, and the user prompt feature. These function mechanisms rely on a
declaration in the post customization file for the feature and a formula as the calling method.
See Volume 1, Post Functions for more information.
Formula usage
Assignment formula types
Formula statements are assignment formulas. Assignment formulas are of three basic types:
Simple assignment—a direct assignment of a value from the right side of the equation to the
variable on the left of the equals sign.
Operator assignment—an assignment of a value calculated using the math operators. The result
of the equation is assigned to the left side variable.
Formula assignment—similar to the operator assignment but the result of a formula function.
Formula functions are different from operators in that parameters are passed enclosed in the
parenthesis following the function label.
See MP Post Formula Types for more information.
Simple assignment example:
result assignment argument
x = 2
Chapter 12 Formulas Volume 1
Operator assignment example:

result assignment argument operator argument
x = 2 + 2
Formula assignment example:

result assignment function argument <argument>
c = atan2(x, y)
Operator and function assignments can be mixed and the order of evaluation controlled through the use
of parentheses.
x = abs(x) + int(y)
c = atan2((x + z), (y - 2))
Assignment formula usage

Assignment formulas are used in the definition and postblock areas in the post customization file
(.PST). There are several different ways to interpret the assignment formula depending on the location
and the assignment operator used. Care must be taken to use the correct assignment operator within the
context of the post customization file area to avoid an incorrect interpretation by the post executable file
or illegal syntax. See Volume 1, Introduction to MP Post Processors for more information.
Assignment formulas in the definition area
Using the colon (:) (initialization)
When the assignment formula is used in the definition area of the post customization file, use the colon
(:) as the assignment operator to initialize a numeric variable. You may recognize this as the way to
declare a user-defined numeric variable.
Initialization assignment formulas must start in the first column of the post customization file.
Example of a numeric variable initialization:
real_var1 : 0
real_var2 : real_var1
Using the equal sign (=) (global formula)

The equal sign (=) makes the formula a global formula. Global formulas are evaluated any time the
target numeric variable is used as a postline statement or in a postline Boolean or formula.
Global assignment formulas must start in the first column of the post customization file.
Example of a global formula:
real_var1 = x
real_var2 = abs(x)
Initializing strings
Never use either the colon (:) or the equal sign (=) with a string variable initialization.
Example of a string variable initialization:
string1 “STRING”
Assignment formulas in the postblock area (=)

When the assignment formula is used in the postblock area of the post customization file, the
assignment formula can be used as a formula postline where it is evaluated when the postblock is
executed, or as the action in a Boolean formula. The equal sign (=) is the only valid assignment
operator in this scenario.
Example of a formula postline:
ppostblock #A postblock declaration
real_result = real_var1 + real_var2
string_result = string1 + string2
Example of a Boolean postline with the action an assignment formula:

if real_var, real_result = real_var1 + real_var2
if real_var, string_result = string1 + string2
Boolean formulas
Boolean statements that use the keyword ‘if’ or “while” use a Boolean formula to evaluate for a zero or
non-zero condition. Any non-zero is interpreted as a true condition. In the ‘if’ Boolean statement, a
true condition allows the action to be executed. In the “while” Boolean statement, a true condition
allows the action to be executed in a continuous loop.
The form of the Boolean formula is the same as the assignment formula except that the
‘result assignment’ is replaced with the keyword, and the action follows the statement.
Boolean formula examples:
keyword argument, action
if x, p_action
keyword argument operator argument, action

if x = y, p_action
keyword function argument <argument>, action

if fmtrnd(x) , p_action
Boolean formula usage

The Boolean formula can only be used within the context of a Boolean postline.
Example of a Boolean formula:
if real_var1 = real_var2, p_action
if string1 = string2, p_action
Definitions
Before examining the operators and functions available in the MP language, you must understand the
terms that used in the operator and function descriptions. You also must understand some of the
underlying structures in the post executable, including the database order, to comprehend how the
formulas work. An understanding of these concepts is also needed to grasp the mechanism used with
functions.
Basic definitions
Cartesian coordinate system
A system that describes a point in space using three coordinate axes, any two of which are
perpendicular to one another. Each axis is labeled. The location of a point in space can be described
using ordered triple sets of positions along the three axes. Cartesian coordinate systems are also known
as rectangular coordinates, for example, x, y, z:
Right hand rule

The right hand rule is used to illustrate the standard Cartesian coordinate system. The middle finger on
the right hand represents the Z axis vector, the index finger represents the Y axis vector, and the thumb
represents the X axis.
Use this method to determine the resulting vector direction in the 3D cross product. The middle finger
on the right hand represents the first vector, the index finger represents the second vector and the thumb
represents the resulting vector.
Z axis
Y axis X axis
Scalar
A scalar value is a single numeric value that can be defined as a point on a number scale.
Vector
A vector is defined as a direction and magnitude. Three values are normally required to define a
vector. MP math functions always use vectors defined in the Cartesian coordinate system. The start
point is always 0,0,0 and is implied in the vector definition. The second point is a position some
distance from the start point. Thus any vector can be defined by the endpoint of the vector or the
second point. A 2D vector is a 3D vector with the Z component implied as zero.
Array
In the MP language, an array is defined by an ordered list of numeric variables that are formatted,
initialized, or predefined in the declared order. All arrays in the MP language are one-dimensional, but
you can imply multi-dimensional arrays by ordering several single dimension arrays.
var1 : 0 #User-defined numeric variables
var2 : 0
var3 : 0
var4 : 0
var5 : 0
Matrix
A matrix used in Mastercam and the MP math functions is described as the vector components of a
rectangular coordinate system. There are always nine elements in the matrix definition. The first 3D
vector describes the X axis, the second 3D vector the Y axis, and the third 3D vector the Z axis. Each
vector in the definition is unitized (see the next paragraph for a definition).
Vector and matrix definitions

Unitized vector
A unitized vector has a unit length of one. Unitizing a vector allows simpler trigonometric, 2D, and 3D
mathematical evaluation of the vector.
Dot product
A dot product is the product of two unitized vectors with the resulting magnitude equal to the cosine of
the product. The result is a scalar value.
Cross product
A cross product is the product of two unitized vectors with the resulting magnitude equal to the sine of
the product and a direction perpendicular to both vectors. The right hand rule is used to determine the
vector direction in a 3D cross product.
Arrays in MP
All arrays in the MP language are one-dimensional because an array in the MP language is simply an
ordered list of variables. The order of this list is determined by the order in which the variables are
formatted, initialized, or predefined in the post executable. These can be described as implied arrays
because nothing other than the actual positions of the variables in the database denotes an array. They
are extremely sensitive to where the variables in the array are declared.
Note: Be very careful not to use predefined variables in a list of user-defined variables. It is difficult to
detect this error, and it causes unrelated variables to appear to change inexplicably.
Initialize and format numeric variables in identical order. You access the rest of the variables in the
array by selecting the first variable declared in the array. Functions using an array form as an argument
expect that the post writer has set up the variables in the correct order.
Note: A common mistake is to use the predefined variables t1 or t2 as user-defined variables in an
implied array. These labels have already been used in the intersection routines.
See Volume 1, Numeric Variables and Volume 1, String Variables for more information. Detailed
descriptions and a listing of the database order for all predefined numeric variables and predefined
string variables are provided in Volume 3, Numeric Variables and Volume 3, String Variables.
Entity and variable type definitions

Formula functions receive arguments and return values of specific types. The MP language has only
two types of variables:
numeric values
character strings
You can imply additional types by using the order of the variables in the database to create vectors,
matrixes, arrays, and lists used with buffers and parameter reading functions. Listed here are the types
and the structure that is expected:
value: A number, real or integer, directly inserted in the formula. For example:
10.
string literal: Character string consisting of alphanumeric characters surrounded by double quotes (“”).
For example:
“ABC123”
Note: MP does not support the use of string literals in formulas. Declare a user-defined string
and use the string variable name as an argument.
string: Character string variable consisting of alphanumeric characters. For example:
string1 “ABC123”
scalar: A single numeric variable representing a scalar value. For example:

var1 : 1
angle: A single numeric variable representing an angle in degrees. For example:

ang1 : 45
2d vector: Two numeric variables representing a planar vector. This form is also used to represent a
planar point. For example:
Note: It is recommended that you always use 3D vectors, even with 2D vector routines.
v2_x : 1
v2_y : 1
v2_z : 1 # Not used but recommended
3d vector: Three numeric variables representing a vector with direction in space. This form is also
used to represent a point in space. For example:
v3_x : 1
v3_y : 1
v3_z : 1
line: Two 3D vectors representing the line end points in space. For example:
v3_x1 : 1 # Endpoint one
v3_y1 : 1
v3_z1 : 1
v3_x2 : 1 # Endpoint two
v3_y2 : 1
v3_z2 : 1
arc: One 2D vector, a scalar, and two angle variables. Five ordered variables are expected; arc center
on X, arc center on Y, radius, start angle, and the arc sweep. For example:
v2_xc : 1
v2_yc : 1
radius : 1
astart : 1
asweep : 1
matrix: Three 3D vectors representing the X axis, Y axis, and Z axis. For example:
v3_xx : 1 # Vector representing X axis
v3_xy : 0
v3_xz : 0
v3_yx : 0 # Vector representing Y axis
v3_yy : 1
v3_yz : 0
v3_zx : 0 # Vector representing Z axis
v3_zy : 0
v3_zz : 1
array: The array or listing can be any size that is needed. If the variables are user-defined, they must
be declared in the post customization file in the order required by the function. For example:
Note: Be careful to avoid using predefined variables in the ordered declarations. If you are using
predefined variables, check the database order tables to determine how they are listed in memory.
Numeric variables and string variables cannot be mixed in the implied array. Each type is considered
separately.
If the array consists of user-defined numeric variables and you must format and initialize the variables.
The full array should then be included in both definitions.
Following is an example of 3D array initialization and format assignment.
v3_x : 1
v3_y : 1
v3_z : 1
fmt X 1 v3_x
fmt Y 1 v3_y
fmt Z 1 v3_z
Following is an example of string variables in an implied array:

string1 “FIRST”
string2 “SECOND”
string3 “THIRD”
string4 “FOURTH”
string5 “FIFTH”
Formula structure
A formula can be structured in many different ways depending on where it is used (assignment formula
or Boolean formula) and what arguments are contained in it. This section describes what variable types
can be combined in a formula, order of precedence, and the return types. The individual formula
descriptions give a detailed explanation of use and function.
Nesting types
Formulas are of three basic types:
Simple assignment
Operator assignment
Formula assignment
These types can be combined or nested in an equation to perform calculations or resolve conditional
branching statements (‘if’ and “while”). The return type for the conditional branching statement must
always be a numeric value. This return value is a predefined numeric variable in the post executable
and has the label bool____result. The post executable examines this variable to see if it is 0 (false) or
non-zero (true) in evaluating the branching statement.
Note: Do not use bool____result directly because it is for internal use only in the post executable!
Formula assignments can be nested wherever the return type is a single numeric or string variable that
matches the argument type to be passed, for example:
result = (no2asc(65) = str_cap_a) + 1
Notice that the ASCII decimal “65” is converted to the character “A”, making a Boolean comparison to
the string (assuming it is also “A”), and adding the result of the comparison to the value 1. The result in
this case is 2.
The preceding example illustrates that the assignment types can be freely mixed as long as the rules are
followed relating to type matching. For example:
# Simple assignments
x = 1
x = y
str1 = str2
# Operator assignments
x = x + y
x = x^y
str1 = str2 + str3
# Formula assignments
c = abs (c)
c = atan2 (x, y)
str1 = no2str (65)
# Formula assignment and Operator assignment

x = fmtrnd(abs(x/2)) + y * 2
Do not nest vector or matrix function that return to a vector, matrix or implied array. These functions
must be coded on a separate line in the customization file and return to a vector, matrix or implied array
that is declared in the post or as predefined variables.
Only formulas that return a scalar or single string may be nested. For example, assume these defined
arrays:
v3_x1 : 1
v3_y1 : 1
v3_z1 : 1
v3_x2 : 1
v3_y2 : 1
v3_z2 : 1
# This is not a legal formula, nesting a returned vector

v3_x2 = vequ(vscl(real_var,v3_x1))
# This is the correct form when the return is not a scalar

v3_x1 = vscl(real_var,v3_x1)
v3_x2 = vequ(v3_x1)
Understanding vector and matrix functions

Because the MP language was not designed with arrays as a native type, they must be implied by the
order in which they are entered into the internal database. The design of a formula function allows only
a single variable name to be passed on each argument and only a single variable name to be the return
variable. The formula functions rely on the user passing the first variable defined in the implied array
as the argument names in the function, for example:
Given the arrays:
v3d_x1 : 1
v3d_y1 : 2
v3d_z1 : 3
v3d_x2 : 1
v3d_y2 : 2
v3d_z2 : 3
v3d_xr : 0
v3d_yr : 0
v3d_zr : 0
The function call would use the first variable name from the implied array definitions and access the
immediately following variable names:
v3d_xr = vadd (v3d_x1, v3d_x2)
The resulting vector would be:

v3d_xr would equal 2.
v3d_yr would equal 4.
v3d_zr would equal 6.
Note: Operators (+,-,*,/,<,>,<=,>=,<>) always pass a single variable.
Precedence of operation
How a formula is evaluated is based on the precedence of its operators in relation to each other.
Following is a chart that describes the precedence of operation in MP language formula parsing. Those
operators with the highest precedence are at the top of the table. Highest precedence operators are
evaluated first from the left to the right in the formula statement.
Precedence can be controlled by using open and close parentheses. Do not confuse them with the
parentheses that encapsulate the formula parameters in formula functions. These must be used to
define the arguments passed with a function and can be considered part of the individual formula.
Precedence Operator
Highest Nesting parentheses and formulas: (, ), and f( )

Unary minus: -x
Power: ^
Multiplication, division: *, /
Addition, subtraction: +, -
Comparison operators: <, >, >=, <=, =, <>
Lowest Logical operators: &, | (and, or)
Examples of evaluation of a formula statement with precedence:
y = x * z – 6 evaluates x * z and subtracts 6 from the result.
y = x * (z – 6) evaluates z - 6 and multiplies the result with x.
Boolean formula usage

Boolean formulas are conditions or comparisons that can be evaluated true or false (non-zero or zero;
the post executable returns 1 or 0). They are used in the conditional branching statement with the
keywords 'if' or “while”. The Boolean or logic operators for comparison are:
Symbol Description
= equal
<> not equal
< less than
> greater than
<= less than or equal
>= greater than or equal
not opposite result of a logic statement
The logic operators for comparison are combined with the logic operators “and” (&) or “or” ( | ) to
evaluate the true and false intermediate results in the following way:
Symbol Description (result) (logic operator) (result) = evaluation
& logical and true & true = true

true & false = false
false & true = false
false & false = false
In logical and, all results must be true to
evaluate true.
| logical or true | true = true
true | false = true
false | true = true
false | false = false
In logical or, if any result is true, the
evaluation is true.
For example, the following will be evaluated to true or false:
x+1 > y
abs (x) < 1
x >= 0
The logic operators for comparison(<, >, =, and not) can be combined with & and | .
For example:
x>0&y>0 # Using the & (and) logic operator
abs (x) > 1 | x = 0 # Using the | (or) logic operator
The result of evaluating these examples when x = 1 and y = 0 would be:

x >= 0 & y >= 0 then 1 and 1, so true and true evaluates true
x=0&y=0 then 0 and 1, so false and true evaluates false
x = 0 | y+1 then 0 or 1, so false or true evaluates true
x<0 |y<0 then 0 or 0, so false or false evaluates false
The logic operators are used with the “if” and “while” keywords and a comma “end” delimiter to
complete the conditional branching statements. A true evaluation allows the action (the statement
following the conditional branching statement after the comma “end” delimiter) to be executed. The
action always follows the comma, for example:
if x = y, x = prv_x
if x > 0 & y > 0, "both x and y are positive"
while x < 10, pincx
while x > y | z = 0, pdoit
A single “else” keyword can be used to follow a Boolean postline (conditional branching statement and
action). If the conditional branching statement evaluates true, then the action after the statement is
executed. If the conditional branching statement evaluates false, then the action after the “else”
keyword is executed instead. For example:
if x = y, x = prv_x
else, y = prv_y
Rules for using “if”, “while” and “else” conditional branching statements
“if,” “while”, and “else” keywords cannot start in the first column.
Put a space between the keyword “if,” or “while” and the Boolean formula. For example:
valid : if x = 1, x = 0
invalid: ifx < y, x = y # Requires a space
Put a comma delimiter after the Boolean formula. For example:
valid : if abs (x) <= 1, pdoit

invalid: if x = 0 | x = 1 pdoit # Requires a comma after the Boolean conditionals
When using the “else” keyword, also put a comma following that statement on the same postline as
a delimiter.
valid : if abs (x) > 1, pdoit
else, pdontdoit
invalid: if abs(x) + abs(y) > 0, pdoit

else pdontdoit # Requires a comma after the else (else,)
invalid: if x > 0,
“x is positive”, e
else # Requires a comma on this line (else,)
, “x is negative or zero”, e # Cannot have the comma start on the line
A conditional branching statement can be continued onto the next postline. To continue the
expression on the next postline, break the line at any point in the expression other than in a variable
label. For example:
valid: if (x <> prv_x) |

(y <> prv_y) |
(z <> prv_z), pmotion
else, pnomotion
An “else” conditional branching statement, if used, must appear immediately after the postline(s) in
the preceding “if” Boolean postline. For example:
valid : if x=0, pzero
else, pnonzero
valid : if x > 0,
else,
“x is negative or zero”, e
invalid: if x = 0, pzero
n, x, y, z, e
else, pnonzero
invalid: if x > y, x = y, else, x = 0
The post executable considers only a single statement after the delimiter comma to be part of the
preceding conditional branching statement. For example:
valid: if x > 0,
invalid: if x > 0 & y > 0,
“y is positive”, e # “y is positive,” will be output even
# if “(x > 0) & (y > 0)” evaluates to false.
invalid: if x = 0 | y = 0, “x or y, or both, are zero”
else, “x is nonzero”
“y is nonzero” # “y is nonzero” will always be
# output, whether “x = 0 | y = 0”
# evaluates to true or false.
Note: If more than one postline is needed with an “if”, “while” or “else”, call a separate postblock or
use bracketed postblocks.
A conditional branching statement cannot be the action of the conditional branching statement.
For example:
invalid: if x > 0, if y > 0, “both x and y are positive”, e

invalid: if x > 0,
if y > 0, “both x and y are positive”, e
invalid: if x = 0, pzero1
else, if y = 0, pzero2
Note: Use a separate postblock or use bracketed postblocks to nest the conditional branching
statement.
Using ESC to break out of “while” loops

Prior to X4 MU1, MP used to have an internal limit on the number of iterations that would be
processed for a while loop. This was to prevent infinite loops that would result if the while
state never changed. However, for some users this limit was too low.
Instead of changing the limit, for MU1 the limit has been removed. Beginning with X4 MU1 you
can use the Escape key to terminate a while loop. When the Escape key is pressed, MP will
terminate the while loop and continue processing the rest of the post.
MP post formula types

Formulas can be divided into categories as represented here. When reading this document online, you
can use the links to jump to a list of the specific operators or functions in each category. For a detailed
description of each formula or function, see Volume 3, Formulas.
.
Basic math functions – Math operators that perform the basic math functions (the assignment operator
(=), addition, subtraction, multiplication, division, etc.).
Logic operators – Logical operators for Boolean evaluation. Operators to test for equal, greater than,
less than, and, or, etc.
Advanced math functions – Math functions including square root, logarithms, absolute values,
rounding and others.
Trigonometric functions– Standard trigonometric functions for sine, cosine and tangent of an angle.
An extremely useful function atan2 returns the solution of the arc tangent within the 360 degree range.
2D vector math – Single plane functions for vector addition and subtraction, and scaling. Even when
working in a single plane, it is recommended that you describe numeric variables as 3D positions. 2D
vector math functions are used less frequently because the 3D vector math functions are more
powerful.
3D vector math – 3D functions for vector addition and subtraction. Functions to rotate vectors and
points about an axis are also provided in this category.
Matrix math – Matrix functions allow for mapping within the matrix that defines a Cartesian coordinate
system. Other matrix manipulation functions such as matrix transpose are also available.
Special MP functions– Calls to the lookup table functions and buffer file function. Other unique
formulas to determine the negative, zero, or positive of a numeric variable are provided here.
Intersection functions – Planar intersection routines for line-line, arc-line and arc-arc.
String functions – String manipulation functions. String variables can be broken, values scanned from
a string, case changed, etc.
Conversion functions – Formulas to convert strings to numeric variables.
File functions – Powerful file manipulation functions to rename and remove files. File functions also
allow launching another program or Mastercam C-Hook.
Precedence functions – Parentheses are used to control the precedence in an assignment formula or a
Boolean formula.
Binary functions – Bit-wise functions.
Post formulas by type

Please see Volume 3, Formulas for a description of the syntax of each formula.
Basic math functions
-
- (unary)
*
/
^
+
=
Logic operators
&
|
<
<=
<>
=
>
>=
not
Advanced math functions

abs
fmtrnd
frac
int
log
log10
round
sqrt
Trigonometric functions
acos
atan
atan2
cos
sin
tan
2D vector math
axb
dot
lng
rot
vad
veq
vlh
vnr
vrh
vsa
vsb
vsc
3D vector math
dot3
lng3
rotp
rotv
vadd
vaxb
vequ
vnrm
vsca
vscl
vsub
Matrix math
matt
mmap
mmul
mteq
vmap
Special MP functions
finc
flook
fprm
frange
fsg1
fsg2
fsg3
updgbl
rbuf
rpar
slin
slout
vlin
vlout
wbuf
Intersection functions
xaa
xla
xll
String functions
brksps
lcase
nwadrs
scan
strlen
strstr
ucase
updstr
Conversion functions
newfs
no2asc
no2str
plcval
File functions
dll
fclose
fexist
launch
mprint
remove
rename
runvbs
Precedence functions
(
)
Binary functions
and
ger
good
ior
xor
Volume 1 Chapter 13 The NCI File
13 The NCI File
[This material in this chapter has been replaced by the NCI & Post Parameter Reference.]

Chapter 13 The NCI File Volume 1
13-2 Mastercam version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 14 Getting the next move
14 Getting the Next Move

[This chapter is obsolete and has been removed. Please see the entry for getnextop$ in the Volume 3
Reference.]
Volume 1 Chapter 15 Working with Drill Cycles
15 Working with Drill Cycles

Drill cycles programmed in Mastercam can be processed in the post executable and the post
customization file using several different methods, depending on several factors:
If the drill cycle will be output as a canned cycle that produces the NC output code as
parameterized lines, either the machine tool will generate the discrete moves to produce the drilled
hole, or the post executable will generate the discrete tool motion in the NC output.
Prior to Mastercam V8, the NCI data for the drill cycles did not provide for a rapid position after
the tool change series of NCI lines and it did not accommodate subprograms. The NCI format for
drill cycles was redesigned with Mastercam Version 8 to correct these deficiencies. Posts not
written specifically for the new NCI format are processed in a special manner so that the behavior
and output is the same as when it was originally written.
Other factors, such as the drill operation type (3- or 5-axis) and the procedure used in the post
customization file also influence how the NC output is generated.
Version 8 NCI drill cycle format changes

Mastercam Version 8 changed the NCI drilling format to a universal drilling format that is used by
3-, 4-, and 5-axis drilling operations. This change was made to support subprograms with drilling and
to avoid the need to generate null tool changes in the NCI for every drill position with 4 -axis drilling.
Null tool changes (NCI Gcode 1000) had been required to introduce the tool plane matrix necessary to
determine the angular movement, which required the drill cycle to be cancelled (NCI Gcode 80) for
each drill position in a new tool plane.
The new format also simplified the interpretation of 5-axis drilling because formerly there was no
vector data on the actual drill cycle (NCI Gcode 81). The post executable had to save the drill data
until the position move with 5-axis drilling.
Because of these changes, it has been necessary to provide a conversion process in the post executable
file to support the thousands of posts that were created before Mastercam V8 universal drilling format.
The new NCI drill data

This section describes the data as it comes from the NCI file and how it is processed for the post writer
prior to the calls to the output postblocks.
In the new NCI drilling format, the position data is described as a line with 3-dimensional endpoints at
the position represented by the bottom of the hole and the initial position of the tool above the drill
hole. Scalar positions along this line are then presented for the reference point, the top of stock, and the
point selected in Mastercam for the drill location.
To keep the existing post customization files compatible and, in general, to provide more usable data to
the post writer, the NCI data is then converted to represent the data as in the earlier NCI format. The
data presented for 3-axis drilling and 5-axis drilling has always been different, and those differences
have been maintained.
NCI Gcode 81
The following table describes the two-line set of NCI Gcode 81 (which defines the drill cycle) data
read from the NCI file. The second line shows the parameters that are written to the line. Below the
represented NCI line set is a table with a description of each parameter that was written.
Note: The table does not list the specific variable labels for the NCI values, just a description of each
parameter value. See Volume 3, The NCI File for detailed descriptions.
81
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Parameter Description
1 Drill cycle type

2 Absolute X position of the drill point at the bottom (Z in Lathe)
3 Absolute Y position of the drill point at the bottom (X in Lathe)
4 Absolute Z position of the drill point at the bottom (zero in Lathe)
5 Dwell time
6 Feed rate
7 First peck amount
8 Subsequent peck amount
9 Peck clearance
10 Chip break retract
11 Distance from the selected drill position to the initial height, sign positive for above
selected drill position
12 Distance from the selected drill position to the reference height, sign positive for above
13 Distance from the selected drill position to the top of stock, sign positive for above
14 Boring bar clearance shift amount
15 Absolute U position of the initial height point (W in Lathe)
16 Absolute V position of the initial height point (U in Lathe)
17 Absolute W position of the initial height point (zero in Lathe)

18 Control flags
19 Reverse the drill direction from the UVW point to the XYZ point.
NCI Gcode 81 variables (3-axis)

The following table describes the resulting numeric variables and the form of the values for 3-axis
drilling with NCI Gcode 81 data before any manipulation by rotary axis routines.
Variable Description
Label
drillcyc Drill cycle type (as read):
0: Simple drilling
1: Peck drilling
2: Chip break
3: Tap
4: Bore #1
5: Bore #2
6: Misc. #1
7: Misc. #2
8-19: Custom cycles
xnci Absolute X position of the drill point at the bottom
ynci Absolute Y position of the drill point at the bottom (zero in Lathe)
znci Absolute Z position of the drill point at the bottom
depth Absolute Z position of the drill point at the bottom
dwell Dwell time (as read)
frplunge Feed rate (as read)
peck1 Incremental distance, first peck amount (as read)
peck2 Incremental distance, additional peck amounts (as read)
peckclr Incremental distance, peck clearance (as read)
retr Incremental distance, chip break retract (as read)
shftdrl Incremental distance, boring bar clearance shift amount (as read)
zdrl Absolute position of the Z location of the selected drill point
Label
refht Absolute position of the Z location of the reference height
initht Absolute position of the Z location of the initial height
tosz Absolute position of the Z location of the top of stock
u Absolute X position of the initial height point
v Absolute Y position of the initial height point (zero in Lathe)
w Absolute Z position of the initial height point
cur_cflg Control flags
rev_drl5 Reverse the drill direction from the UVW point to the XYZ point (as read).

Label
drillcyc Drill cycle type (as read):
100: Simple drilling
101: Peck drilling
102: Chip break
103: Tap
104: Bore #1
105: Bore #2
106: Misc. #1
107: Misc. #2
108-119: Custom cycles
depth Incremental distance from reference height to the bottom.
Label
peck1 Incremental distance, first peck amount (as read)
peck2 Incremental distance, additional peck amounts (as read)
peckclr Incremental distance, peck clearance (as read)
retr Incremental distance, chip break retract (as read)
shftdrl Incremental distance, boring bar clearance shift amount (as read)
zdrl The selected drill point (always zero)
refht Incremental distance from the selected drill point to reference height.
initht Incremental distance from the selected drill point to initial height.
u Absolute X position of the reference height point
v Absolute Y position of the reference height point
w Absolute Z position of the reference height point
NCI Gcode 82 variables (Additional Drill / Canned Cycle Parameters)

Mastercam Version 8 added additional parameters to the drill cycle NCI output, the NCI Gcode 82
line, which is output in the NCI file just prior to the NCI Gcode 81 line. These parameters are provided
for custom use when the number of parameters on the standard NCI Gcode 81 line is not adequate.
The following illustration shows the dialog box used to enter the values in Mastercam.
See Volume 3, NCI File for more information.
The text that appears on this dialog can be customized. See Volume 1, Post TXT File
The following table documents the two-line set of NCI Gcode 82 (which defines “additional” custom
parameters that may be used for a canned drill cycle) data read from the NCI file.
82
1 2 3 4 5 6 7 8 9 10
Label
drl_prm1 Drill parameter 1
Note: The drl_prm# variables do not have a specific meaning; they are values that the post
customization file can use for whatever purpose needed for that cycle.
NCI Gcode 100

This line represents the “two line set” of NCI Gcode 100 (which defines drill point positions after the
initial cycle point) data read from the NCI file.
Note: Mastercam Lathe toolpaths are not expected to produce the NCI Gcode 100.
100
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
1 Drill cycle type
2 Absolute X position of the drill point at the bottom
3 Absolute Y position of the drill point at the bottom
4 Absolute Z position of the drill point at the bottom
5 Distance from the selected drill position to the initial height, sign positive for above
6 Distance from the selected drill position to the reference height, sign positive for above
7 Dwell time
8 Feed rate
9 Absolute U position of the initial height point
10 Absolute V position of the initial height point
11 Absolute W position of the initial height point
12 Control flags
13 Reverse the drill direction from the UVW point to the XYZ point.
14 Top of stock, the distance from the selected drill position (zdrl) to the top of stock, sign
positive for above zdrl
15 Drilling matrix XX
16 Drilling matrix XY
17 Drilling matrix XZ
18 Drilling matrix YX
19 Drilling matrix YY
20 Drilling matrix YZ
21 Drilling matrix ZX
22 Drilling matrix ZY
23 Drilling matrix ZZ
See Volume 3, Numeric Variables for addition ‘drl_???’ variables that MP calculates from this NCI
data.
See Volume 3, The NCI File for additional details.

The NCI Gcode 100 variables are unique in that the numeric variables for u, v and w are relative to the
original tool plane matrix defined with the NCI Gcode 81 tool change preceding the NCI Gcode 100.
This rotation, which is defined with the rotary axis selection in Mastercam, is used by the post
executable to create a new tool plane matrix relative to the NCI Gcode 100 drill position. Backwards
compatibility is maintained by rotating the NCI data for the endpoints into the new tool plane.
Label
depth Absolute Z position of the drill point at the bottom
zdrl Absolute position of the Z location of the selected drill point
refht Absolute position of the Z location of the reference height
u Absolute X position of the initial height point
v Absolute Y position of the initial height point (zero in Lathe)
w Absolute Z position of the initial height point

The table below describes the resulting numeric variables and the form of the values for 5-axis drilling
with NCI Gcode 100 data before any manipulation by rotary axis routines.
Label
depth Incremental distance from reference height to the bottom.
zdrl The selected drill point (always zero)
refht Incremental distance from the selected drill point to reference height.
u Absolute X position of the reference height point
v Absolute Y position of the reference height point
w Absolute Z position of the reference height point
Processing with rpd_typ_v7

The numeric variable rpd_typ_v7 was added to the MP language for Mastercam Version 8. It alters
internal post executable routines and data reading functions to avoid version change problems that
occur when features are added and data changed.
Processing with rpd_typ_v7 enabled (old form)

Mastercam V8 always writes the tool change rapid position from the tool change line (NCI Gcode
1000, 1001 and 1002) after the tool change line in the NCI file. The move is written as a rapid position.
This can be in the form of the NCI Gcode 0 or 11 with feed rate set to –2, depending on the toolpath
type.
In earlier versions of Mastercam, this rapid position was never written and the post customization file
would either call back to the tool change postblock or create the rapid positioning during the drill cycle
postblock calls. With the introduction of the mandatory rapid position in the NCI file, errors during
posting and in the NC output can be generated in posts written for the earlier NCI format when the
added rapid NCI line is encountered.
To avoid these problems, the numeric variable rpd_typ_v7 is added to the post customization file and is
set to 1. rpd_typ_v7 skips the rapid position after the tool change in the NCI file and reads the next two-
line set from the NCI file. This is usually the drill cycle definition (NCI Gcode 81) that was expected
by the older post customization file. rpd_typ_v7 also skips the new long code drilling calls if set on and
rotaxtyp is set to less than 6. See Volume 2, Rotary Processing for more information.
Processing with rpd_typ_v7 disabled (new form)

With the rpd_typ_v7 numeric variable set to 0 (that is, disabled), the post executable reads the added
rapid NCI line. This is desirable for two reasons:
The tlchng_aft (tool change after) routine functions correctly in all cases. You can retrieve a valid
position move. This is required with 5-axis if you want to know the rotary positions in the tool
change postblock.
The enhanced long drill cycles are available.
Processing long code

To enable drill cycle long code, set the numeric variables in the post customization (.PST) file as
follows:
usecandrill : no # Use canned cycle for drill
usecanpeck : no # Use canned cycle for peck
usecanchip : no # Use canned cycle for chip break
usecantap : no # Use canned cycle for tap
usecanbore1 : no # Use canned cycle for bore1
usecanbore2 : no # Use canned cycle for bore2
usecanmisc : no # Use canned cycle for misc1
1
usecanmisc : no # Use canned cycle for misc2
2
Drill cycle long code processing has been enhanced in the post executable file when the numeric
variable rpd_typ_v7 is disabled (that is, omitted or set to 0). The enhanced drill cycle long code provides
support in the post executable for tap, bore1, bore2, misc1 and misc2 drilling and boring cycles. All
these cycles are also supported with 5-axis drilling.
When numeric variable rpd_typ_v7 has been enabled, as required for earlier post customization files, the
long cycle drill motion must be explicitly generated in the post customization file for 5-axis drilling and
the tap, bore1, bore2, misc1 and misc2 drilling and boring cycles.
Note: With rpd_typ_v7 enabled, tap, bore1, bore2, misc1 and misc2 drilling and boring cycles call the
drill (feed in, rapid out) long code output.
The following tables describe the enhanced drill cycle long code, the variables modified, and postblock
calls generated.
Simple drill (drillcyc = 0)

Action Description Variables Calls
Rapid If initial height does not gcode = 0 prapid or pzrapid

equal reference height, bug9 = 1
xnci, ynci, znci, fr, fr_pos, ipr_actv
rapid to reference height.
Feed in Feed to depth. gcode = 1 pz or plin
bug9 = 2
Dwell Dwell, if not 0. gcode = 4 pdwl_spd

bug9 = 3
dwell
Rapid out If retrefht = 0, current gcode = 0

prapid or pzrapid
position is initial height. bug9 = 6
If retrefht = 1, current
position is reference
height.
Rapid to current position.
If retrefht = 0 and initial gcode = 0
height does not equal bug9 = 8
reference height, rapid to
initial height.
Peck drill (drillcyc = 1)


rapid to reference height. xnci, ynci, znci, fr, fr_pos, ipr_actv
Peck loop, continue until depth reached…

Feed in Feed from reference gcode = 1 pz or plin
height incremental first bug9 = 2
peck distance on first
peck. Add second peck
distance on additional
pecks.
bug9 = 3
dwell
Rapid out Rapid to reference gcode = 0 prapid or pzrapid

height. (Not done when bug9 = 4
depth reached.)
Rapid in Rapid to last depth plus gcode = 0
clearance distance. (Not bug9 = 5
done when depth
reached.)
End Peck Loop
prapid or pzrapid
height.
initial height.
Chip break drill (drillcyc = 2)


Peck Loop, continue until depth reached…
Feed in Feed from reference gcode = 1 pz or plin
height incremental first bug9 = 2
peck distance on first
peck. Add second peck
distance on additional
pecks.
bug9 = 3
dwell
Rapid up Rapid from current depth gcode = 0

prapid or pzrapid
by retract distance. (Not bug9 = 4
done when depth
reached.)
Rapid in Rapid to last depth plus gcode = 0
clearance distance. (Not bug9 = 5
done when depth
reached.)
End Peck Loop
prapid or pzrapid
height.
If retrefht = 0 and initial
height does not equal
initial height.
Tap (drillcyc = 3)

bug9 = 2

bug9 = 3
dwell
Reverse Spindle reversal. Mill gcode = 4 pdwl_spd

Spindle changes sign of ss. bug9 = 3
ss, spdir, css_actv
Lathe changes sign of
spdir.
Feed out If retrefht = 0, current gcode = 1 pz or plin

height.
Feed to current position.
Restore Spindle is reset to initial gcode = 4 pdwl_spd
Spindle setting. bug9 = 7
ss, spdir, css_actv
Rapid out If retrefht = 0 and initial gcode = 0 prapid or pzrapid

initial height.
Bore, feed out (drillcyc = 4)


bug9 = 2

bug9 = 3
dwell
Feed out If retrefht = 0, current gcode = 1 pz or plin

height.
Feed to current position.
initial height.
Bore, stop, rapid out (drillcyc = 5)


bug9 = 2

bug9 = 3
dwell
Spindle Spindle stop. Mill ss = 0. gcode = 4 pdwl_spd

Stop Lathe spdir = 0. bug9 = 3
ss, spdir, css_actv
Rapid out If retrefht = 0, current gcode = 0 prapid or pzrapid

height.
ss, spdir, css_actv

initial height.
Bore, fine (drillcyc = 6)


bug9 = 2

bug9 = 3
dwell
Spindle Spindle stop. Mill ss = 0. gcode = 4 pdwl_spd

Stop Lathe spdir = 0. bug9 = 3
ss, spdir, css_actv
Rapid out If retrefht = 0, current gcode = 0 prapid or pzrapid

height.
ss, spdir, css_actv

initial height.
Bore, standard (drillcyc = 7)


bug9 = 2

bug9 = 3
dwell

prapid or pzrapid
height.
initial height.
Canceling drill cycles

The NCI Gcode 80 indicates the end of a drill cycle and drilled positions in the NCI file.
The pcanceldc postblock is called automatically, if a canned drilling cycle is active.
New (starting with MP Version 9.10) are some additional commands and post switches that allow the
post writer to control canceling and re-stating of canned drill cycles.
canceldc allows the post to directly call the pcanceldc postblock to cancel the active cycle.
drl_cycle_actv allows the post to “see” the active state of a canned drill cycle.
See Volume 3, Numeric Variables for information on canceldc and drl_cycle_actv
The variable rtnrefht controls the Z-axis location where a drill cycle returns, as follows:
When rtnrefht = 0, return to the location of the initial height (initht).
When rtnrefht = 1, return to the location of the reference height (refht ).
This is important with canned drill cycle calls because the last Z location perceived by the post
executable is at the final drill depth. With the long code output enabled (that is, when one of the
usecan… variables is set to 0), the final position is controlled by the position output with linear motion
generated in the post executable. The canned drill cycle output returns the Z location internally just
before the call to the postblock pcanceldc by setting the numeric variable z. There is no Z location
adjustment if this is a 5-axis drill routine (drill5 = 1). In the postblock pcanceldc the numeric variable z
should be updated.
pcanceldc # Cancel canned drill cycle
!z
n, "G80", e
Any other position can be stated as the last Z drill position by explicitly defining z or prv_z in the
postblock pcanceldc. For example:
pcanceldc # Cancel canned drill cycle
z = 10.
!z
n, "G80", e
Custom drill cycles

Custom drill cycles 8 through 19 were added in Mastercam Version 8. These are not supported as long
code and are for customized cycles only. The NCI Gcode 81 line is processed as any other canned drill
cycle. The exception is that only a single predefined postblock pdrlcst is called for all NCI Gcode 81
when the drillcyc number is in the range of 8 – 19. In Wire, the single predefined postblock pcancst is
called.
Additional drill hole locations (NCI Gcode100 line) within these custom drill cycles range call
postblock pdrlcst_2 in Mill and Lathe and call the postblock pdrlcst_2 in Wire. The post customization
file must have code to handle any conditional branching required for the particular drill cycle selection
drillcyc.
For example:
pdrlcst # Custom drill cycles 8 - 19 (user option)
if drillcyc = 8, pdrlcst8 # first position, define the cycle
if drillcyc = 9, pdrlcst9 # first position, define the cycle
pdrlcst_2 # Custom drill cycles 8 - 19, additional points (user option)

if drillcyc = 8, pdrlcst8_2 # call the cycle for position(s) after the initial position
if drillcyc = 9, pdrlcst9_2 # call the cycle for position(s) after the initial position
pdrlcst8 # Custom drill cycle 8 (define the cycle)

n, “DEF”, x, y, z, e
pdrlcst9 # Custom drill cycle 9 (define the cycle)

n, “DEF”, x, y, z, e
pdrlcst8_2 # Custom drill cycle 8 (call active cycle for subsequent positions)
n, “REP”, x, y, z, e
pdrlcst9_2 # Custom drill cycle 9 (call active cycle for subsequent positions)
n, “REP”, x, y, z, e
Version 9.1 Drill Cycle sample

MPFAN.PST canned drill cycle sample
(Note that all this code is NOT in the MPFAN.PST on the Mastercam Version 9.1 CD.)
This is for aggregate mapped drilling (not toolplane) and rotary drilling.
The basic format for code in ‘pdrill0’ to cancel a cycle automatically is:
if drl_cycle < 8 & opcode <> 16, # Std. drilling cycle (0-7) and NOT a 5-axis drill path
[
if test_drl, canceldc # This for cancel restart cycle
]
Where ‘test_drl’ is a user condition to cancel the cycle so the next cycle is the definition cycle. Use
usecan…. as shown below to control if the cycle remains off and long code is generated.
ss_underflow : 1 # Allows the string select variable to be less than zero
canceldc : 1 # Allows the post to call the postblock pcanceldc to cancel an # active
canned drill cycle
drl_usecan : 0 # (User-defined)
sav_plane : 0 # Save plane when drilling (User-defined)
drillrefx : 0 # Vector to test for initht <> refht (User-defined)
drillrefy : 0 # Vector to test for initht <> refht (User-defined)
drillrefz : 0 # Vector to test for initht <> refht (User-defined)
# --------------------------------------------------------------------------
# Select work plane G code
sg-17 G17 # XY plane code
sg17 G17 # XY plane code
sg19 G19 # YZ plane code
sg18 G18 # XZ plane code
sgplane # Target string
fstrsel sg17 plane sgplane
# --------------------------------------------------------------------------
# Drilling
# --------------------------------------------------------------------------
pdrill0 # Pre-process before drill call
sav_dgcode = gcode # Capture gcode for 5 axis drill
sav_plane = plane # Save the current ‘plane’ setting
if drl_cycle < 8 & opcode <> 16, # Std. drilling cycle (0-7) and NOT a 5-axis drill
path
[
# Do not compare drl_plane if the cycle was off
if drl_cycle_actv < one, !drl_plane # Active cycle? (after a Gcode 100 NCI line has
been read)
# Cancel the drill cycle?
# If drl_plane does not match a standard direction (X,Y, or Z) and it has just
changed to this condition, cancel drill active drill cycle.
if drl_plane = m_one | prv_drl_plane <> drl_plane, canceldc
# Use the canned drillcycle?
# If drl_plane does not match a standard direction (X,Y, or Z), turn OFF the canned
cycle output option.
if drl_plane = m_one, zero = vlin(drl_cycle, usecandrill)
else,
[ # Retrieve the prior setting for this canned cycle and make it the active mode.

drl_usecan = vlout(drl_cycle, prv_usecandrill) # Get the prior setting
drl_usecan = vlin(drl_cycle, usecandrill) # Make it the active setting
]
]
!drl_plane # Update current value of ‘drl_plane’ into ‘prv_drl_plane’
pdrlcommonb # Canned Drill Cycle common call, before
if sav_dgcode = 81,
[
result = newfs (two, zinc)
if drillcyc = three, drlgsel = fsg1(-ss) + drillcyc * two
else, drlgsel = fsg2(dwell) + drillcyc * two
drillrefx = vsub(drl_init_x, drl_ref_x)
if lng3(drillrefx) > vtol, drillref = zero
else, drillref = one
prv_refht_a = c9k
prv_refht_i = c9k
prv_dwell = zero
]
if cuttype = three, sav_dgcode = gcode
if cuttype = one, prv_zia = initht + (rotdia/two)
else, prv_zia = drl_init_z
x = vequ(drl_depth_x)
pcom_moveb
feed = fr_pos
comment
pcan
plane = drl_plane
prdrlout #Drill position based on plane
if drl_plane = one, pyout, pzout, pfxout # Direction is in X axis
else,
[
if drl_plane = two, pxout, pzout, pfyout # Direction is in Y axis
else, pxout, pyout, pfzout # Direction is in Z axis
]
prdrlrout #R (refht) drill position
if cuttype = one, # Axis substitution
[
refht_i = refht - initht
refht_a = refht + (rotdia / two))
]
else,
[ # NOT doing axis substitution
if drl_plane = one, # Direction is in X axis
[
refht_i = drl_ref_x - drl_init_x # Calculate for incremental ‘R’
refht_a = drl_ref_x # Calculate for absolute ‘R’
]
else,
[
if drl_plane = two, # Direction is in Y axis
[
refht_i = drl_ref_y - drl_init_y
refht_a = drl_ref_y
]
else,
[ # Direction is in Z axis
refht_i = drl_ref_z - drl_init_z
refht_a = drl_ref_z
]
]
]
if absinc = zero, refht_a, !refht_i # Output absolute ‘refht’
else, refht_i, !refht_a # Output incremental ‘refht’
pdrill #Canned Drill Cycle (0)
pdrlcommonb
pcan1, pbld, n, *sgplane, *sgdrlref, *sgdrill, prdrlout, pcout,
prdrlrout, dwell, *feed, strcantext, e

pcom_movea
ppeck #Canned Peck Drill Cycle (1)
pdrlcommonb
prdrlrout, *peck1, *feed, strcantext, e
pcom_movea
pchpbrk #Canned Chip Break Cycle (2)
pdrlcommonb
prdrlrout, *peck1, *feed, strcantext, e
pcom_movea
ptap #Canned Tap Cycle (3)
pdrlcommonb
result = newfs(17, feed) # Set for tapping Feedrate format
prdrlrout, *feed, strcantext, e
pcom_movea
pbore1 #Canned Bore #1 Cycle (4)
pdrlcommonb
prdrlrout, dwell, *feed, strcantext, e
pcom_movea
pbore2 #Canned Bore #2 Cycle (5)
pdrlcommonb
prdrlrout, *feed, strcantext, e
pcom_movea
pmisc1 #Canned Misc #1 Cycle (6)
pdrlcommonb
prdrlrout, shftdrl, dwell, *feed, strcantext, e
pcom_movea
pmisc2 #Canned Misc #2 Cycle (7)
pdrill
pdrill_2 #Canned Drill Cycle, additional points
pdrlcommonb
pcan1, pbld, n, pxout, pyout, pzout, pcout, prdrlrout, dwell,
feed, strcantext, e
pcom_movea
ppeck_2 #Canned Peck Drill Cycle
pdrill_2
pchpbrk_2 #Canned Chip Break Cycle
pdrill_2
ptap_2 #Canned Tap Cycle
pdrill_2
pbore1_2 #Canned Bore #1 Cycle
pdrill_2
pbore2_2 #Canned Bore #2 Cycle
pdrill_2
pmisc1_2 #Canned Misc #1 Cycle
pdrill_2
pmisc2_2 #Canned Misc #2 Cycle
pdrill_2
pdrlcst #Custom drill cycles 8 - 19 (user option)
#Use this postblock to customize drilling cycles 8 - 19
pdrlcommonb
"CUSTOMIZABLE DRILL CYCLE ", pfxout, pfyout, pfzout, pfcout, e
pcom_movea
pdrlcst_2 #Custom drill cycles 8 - 19, additional points (user option)
#Use this postblock to customize drilling cycles 8 - 19
pdrlcommonb
"CUSTOMIZABLE DRILL CYCLE ", pfxout, pfyout, pfzout, pfcout, e

pcom_movea
pcanceldc #Cancel canned drill cycle
result = newfs (three, zinc)
z = initht
if cuttype = one, prv_zia = initht + (rotdia/two)
else, prv_zia = initht
pxyzcout
!zabs, !zinc
prv_gcode = zero
pcan
pcan1, pbld, n, "G80", strcantext, e
pcan2
plane = sav_plane
<end of sample code>
Cut type
This is a user-defined variable in the MPFAN.PST that designates the cut type.
cuttype : 0 #Cut type flag
# 0 = Tool Plane, 1 = Axis Subs, 2 = Polar, 3 = 4/5 axis
Drill cycle Gcode

This is a user-defined variable using a string select function to select the drill cycle G-code.
# Canned drill cycle string select
sg81 G81 #drill - no dwell
sg81d G82 #drill - with dwell
sg83 G83 #peck drill - no dwell
sg83d G83 #peck drill - with dwell
sg73 G73 #chip break - no dwell
sg73d G73 #chip break - with dwell
sg84 G84 #tap - right hand
sg84d G74 #tap - left hand
sg85 G85 #bore #1 - no dwell
sg85d G89 #bore #1 - with dwell
sg86 G86 #bore #2 - no dwell
sg86d G86 #bore #2 - with dwell
sgm1 G76 #misc #1 - no dwell
sgm1d G76 #misc #1 - with dwell
sgm2 G81 #misc #2 - no dwell
sgm2d G82 #misc #2 - with dwell
sgdrill #Target for string
fstrsel sg81 drlgsel sgdrill
M R canceldc
Variable Type Command
Category Drilling (v9.1+)
Description The command post variable and post switch combination
variable canceldc allows the post to call the postblock pcanceldc
to cancel an active canned drillcycle .
Initialize this variable with one (1) and MP uses the state of the
canned cycle to re-initialize the canned cycle if cancelled.
When a canned drill cycle is called and the NCI Gcode is 100
(repeat cycle), the state is checked and the Gcode 100 is
converted to Gcode 81 and the canned drillcycle definition
postblock is called.
Values
0 Not active
1 Active
Code Example None
Notes See drl_cycle_actv for related information.
M R L drillcyc
Variable Type NCI variable
Category Drill
Description Type of canned drill cycle.
Values (See note below)
0 Simple
1 Peck
2 Chip break
3 Tap
4 Bore #1
5 Bore #2
6 Misc #1
7 Misc #2
8-19 Custom cycles
Code Example None
Notes When doing 5-axis drilling, each value shown above has ‘100’
added to it when the pdrill0 postblock is called. On exit from the
pdrill0 postblock, this ‘100’ gets subtracted out by MP
executable.
See the related drl_cycle variable (v9.1)
M R drl_cycle
Variable Type NCI
Description The drill cycle code value from the Gcode 81 NCI line.
This is not manipulated for 5-axis drill cycle reverse
compatibility.
Values
0 Simple
1 Peck
2 Chip break
3 Tap
4 Bore #1
5 Bore #2
6 Misc #1
7 Misc #2
8-19 Custom cycles
Code Example None
Notes See the related drillcyc variable, which has ‘100’ added to it
when 5-axis drilling.
M R drl_cycle_actv
Variable Type Calculated
Description Added to allow the post to see the active state of a canned cycle.
Values
0 Not active
1 Active
-1 Active (after a Gcode 100 NCI lines has been read)
Code Example None
Notes When pdrill0 is called on the cycle definition start, the setting of
drl_cycle_actv is 0.
Once the canned cycle is active, drl_cycle_actv is set to 1.
In this state, a call to the pcanceldc postblock; either from an NCI
gcode 80 or from the command variable canceldc will
successfully call the pcanceldc postblock. A call to pcanceldc sets
drl_cycle_actv to 0.
If a NCI gcode 100 is read, drl_cycle_actv is set to -1. This forces
an artificial call to the drillcycle definition postblock and
reestablishes the drill cycle.
See canceldc for related information.
M R drl_init_x, drl_init_y, drl_init_z

Description The drill position for the (initial) height point in space.
(rotated or mapped based on post processor settings).
Values Value
Code Example None
Notes These variables were added in v9.1 to support mapped drilling.

The drill direction is no longer confined to the Z axis so each
parameter needs to become a point in space.
M R drl_plane
Description The plane relative to the drill direction motion.
Values
-1 no match
0 for direction only in Z
1 for direction only in X
2 for direction only in Y
Code Example None
Notes
M R drl_ref_x, drl_ref_y, drl_ref_z

Description The drill position for the (reference) point in space.
(rotated or mapped based on post processor settings).
Values Value
Code Example None
Notes These variables were added in v9.1 to support mapped drilling

The drill direction is no longer confined to the Z axis so each
parameter needs to become a point in space.
fsg1
Formula Type Advanced Math Functions
Description Returns:
0 for values less than 0.
1 for values greater than or equal to 0.
Form function argument
Argument numeric variable, value (scalar)
Return Type numeric variable (scalar)
Formula Code Ex. real_result = fsg1(x)
Boolean Code Ex. if fsg1(x), “THE VALUE IS LESS THAN ZERO”
Notes Nested return values are stored internally to the post executable.
fsg2
Formula Type Advanced Math Functions
Description Returns:
0 for values equal to 0.
1 for values not equal to 0.
Argument numeric variable, value (scalar)
Formula Code Ex. real_result = fsg2(x)
Boolean Code Ex. if fsg2(x), “THE VALUE IS NOT ZERO”
Notes Nested return values are stored internally to the post executable.
M R opcode
Category Tool change information, Operation type
Description Operation code of the current Mill / Router operation.
Values
0 Neither
1 2D contour
2 3D contour
3 Drill
4 Pocket
5 Ruled
6 2D swept
7 3D swept
8 Revolution
9 Loft
10 Coons
11 Fillet
12 Flowline
13 Multisurface finish
14 Multisurface rough
15 Point
16 Drill 5-axis
17 Swarf 5-axis
18 Curve 5-axis
19 Face
Code Example None
Notes opcode is for general classification of a toolpath. Use tool_op

for the specific toolpath.
M R L plane
Category Motion
Description Current cutting plane.
Values
0 XY plane, G17
1 YZ plane, G19
2 XZ plane, G18
Code Example Mill exmaple:
parc # IJK arc center output
if plane = zero, *i, *j, k # G17 plane - force I & J output
if plane = one , i, *j, *k # G19 plane - force J & K output
if plane = two , *i, j, *k # G18 plane - force I & K output
Notes
ss_underflow
Variable Type Post switch variable
Category Post switch, Process modification
Description Allows the string select variable to be a value less than zero.
Values
0 Not active
1 Active
Code Example sg-17 G17 # Plane code whnd drill direction is skewed
sg17 G17 # XY plane code
sg19 G19 # YZ plane code
sg18 G18 # XZ plane code
sgplane
fstrsel sg-17 plane sgplane
Notes If the ss_underflow switch is not active, and the string selector
variable is less than zero, MP will halt with an error.
New starting with Version 9.10 of the MP DLLs
lng3
Formula Type 3D vector math function
Description Returns the length of the argument (vector).
Argument numeric variable (3D vector)
Formula Code Ex. real_result = lng3(v3_x1)
Boolean Code Ex. Not allowed as a Boolean statement
Notes
vlin
Formula Type Special MP function
Description Writes a value to a numeric variable at specified offset from the
numeric variable passed as the second argument. The first parameter
indicates the position to offset from the base position, represented by
the second argument, relative to the database order of the numeric
variables.
Note the usual direction of this function. real_var1 is on the left side of
the equation (the “=” sign), but it is really the input variable. The
output of this function is loaded into the numeric variable whose
address is derived from the address of real_var2 plus the offset (1 in the
example below). The numeric variable represented by what would
normally be considered the return variable is passed to the offset of the
second argument.
Form function argument, argument
First Argument numeric variable, value (scalar)
Second Argument numeric variable
Return Type numeric variable
Formula Code Ex. real_var1 : 1 #User-defined numeric variables
real_var2 : 0
real_var3 : 0
pblock # A postblock
real_var1 = vlin(1, real_var2)
In this example, real_ var3 would receive the value 1 from real_var1.
Notes This function can be used in a “while” loop to assign a value to an

implied array or any database ordered variables.
See vlout for related information.
vlout
Formula Type Special MP function
Description Reads a value from a numeric variable located at a specified offset
from the numeric variable passed as the second argument. The first
parameter indicates the position to offset from the base position,
represented by the second argument, relative to the database order of
the numeric variables. The contents of the numeric variable at the
offset from the second argument is passed to the return variable
First Argument numeric variable, value (scalar)
Second Argument numeric variable
Return Type numeric variable
Formula Code Ex. real_var1 : 0 #User-defined numeric variables
real_var2 : 0
real_var3 : 1
real_var1 = vlout(1, real_var2)
In this example, real_ var1 would receive the value 1 from real_var3.
Notes This function can be used in a “while” loop to assign a values from the
database ordered variables.
See vlin for related information.
vsub
Description Subtracts two vectors. The elements in the implied array are
subtracted: argument one – argument two.
First Argument numeric variable (3D vector)
Second Argument numeric variable (3D vector)
Return Type numeric variable (3D vector)
Formula Code Ex. v3_resx = vsub(v3_x1, v3_x2)
Boolean Code Ex. Not allowed as a Boolean statement.

Notes
vequ
Description Copies a vector. Copies the argument (vector) to the result (vector).
The term used for this formula is vector equate.
Argument numeric variable (3D vector)
Return Type numeric variable (3D vector)
Formula Code Ex. v3_resx = vequ(v3_x1)
Boolean Code Ex. Not allowed as a Boolean statement.

Notes Whereas the assignment operator (=) copies only the single variables in
the statement, this formula copies all the elements in the implied array.
Volume 1 Chapter 16 Working with Cantext
16 Working with Cantext

New canned text for Version 8 and 9
Starting in Mastercam Version 8, canned text changed to allow multiple events on a single move.
Canned text in Version 8 and Version 9 allows you to define a list of up to 99 items that can be used to
output strings or values to the NC file, to make post calculations, or call a postblock.
MP posts from versions prior to Version 8 must be modified to take advantage of this new feature.
When selecting canned text and processing with an older MP-style post, the first canned text entry from
the Canned Text Gcode 1025 line is placed in the variable cantext and is processed as in prior versions.
All other entries are ignored.
The 1025 canned text line

Canned text will allow up to 10 parameters to be written on the same NCI line. The 1025 line is a list
of 10 parameters, which are each broken down the same way. Each of the 10 parameters contains
information for two variables:
cant_pos indicates the output position of the canned text.
cant_val indicates which canned text will be output.
Each of the 10 parameters has a 1-, 2-, or 4-place value (for example, 0, 12, or 1012). An unused
parameter will always be 0. Unused parameters exist because there are 10 parameters available and
you may need to use only one or two.
Note: All logic to interpret the cant_pos position flag and the cant_val canned text value must be written
into the post customization file.
Format of the 1025 canned text line in the NCI

Canned Text (1025) (Common)
g
1 2 3 4 5 6 7 8 9 10
g 1025: Canned text (gcode).

1 Cantext parameter (cant_pos1) (cant_val1)
‘cant_val#’ is a value (1-99) extracted from the lower three digits.
The 1000s digit is represented by ‘cant_pos#’ where:
0: Canned text before
1: Canned text with
2: Canned text after
Cant_pos1 … cant_pos10
The variables cant_pos1 … cant_pos10 represent the position where the canned text will be output for
parameters 1 through 10 on the 1025 line. The possible values of cant_pos are:
–1 = off (no output)

0 = before the move appearing on the next NCI line
1 = with the move appearing on the next NCI line
2 = after the move appearing on the next NCI line
1 and 2 are the only 1000s place values that appear on the 1025 line. A cant_pos value of –1 (off) is
indicated by no 1000s place value and 0 (unused) for the parameter. A cant_pos value of 0 is indicated
by no 1000s place value and a value greater than 0 for the parameter.
cant_val1 … cant_val10
The variables cant_val1 through cant_val10 represent the actual cantext value for parameters 1 through
10 on the 1025 line. There can be up to 99 different canned text values, so cant_val will equal a value
of 1 through 99. Mastercam and the MP language associate the user’s canned text selection only with a
value of 1 through 99.
The post writer must modify the post .TXT file to display the proper text in the Mastercam Canned
Text dialog box for the up to 99 canned text possibilities.
For more information, see Customizing the post.TXT file to display text in Mastercam.
The post writer must also modify the post to output the correct string or value based on the value (1-
99) of cant_val. For more information, see Customizing the post to associate the cant_val with the
correct output string, output variable, or post action.
cant_no
The variable cant_no represents the number of non-zero parameters on the 1025 line (that is, the
number of canned text parameters used on that particular 1025 line.) Cant_no can be used to determine
whether there is any canned text being output from a 1025 line.
With a test such as “if cant_no > 0”, you can determine whether it is necessary to break down the
parameters on the 1025 line or skip the line and move on, that is, when cant_no is not greater than 0 and
there is no canned text to be output.
Example of a 1025 canned text line from an NCI

1025
2 9 1006 2010 0 0 0 0 0 0
1025 is the NCI Gcode that indicates a canned text line. The 10 values on the next line are the 10
canned text parameters that will be output by this line. (Up to 10 canned text parameters can be output
at the same time.) In this case, there are four (non-zero) parameters for output, so cant_no would equal
4.
The first parameter is 2, so cant_val1 = 2. There is nothing in the 1000s place, so cant_pos1 = 0 and it
will be output before the linear move that appears on the next NCI line.
The second parameter is 9, so cant_val2 = 9. There is nothing in the1000s place, so cant_pos2 = 0 and
it will be output before the linear move that appears on the next NCI line.
The third parameter is a 1006, so cant_val3 = 6. There is a 1 in the 1000s place, so cant_pos = 1 and it
will be output with the linear move that appears on the next NCI line.
The fourth parameter is a 2010, so cant_val4 = 10. There is a 2 in the 1000s place, so cant_pos = 2 and
it will be output after the linear move that appears on the next NCI line.
The remaining six parameters are 0, so they are unused.
Parameters will be output in order of their ‘before’, ‘with’, and ‘after’ designations, and then in the
order they were selected from the Canned Text dialog box. Notice that parameter 1 and parameter 2
are both to be output before the linear move that appears on the next NCI line. In this example,
parameter 1 will be output, and then parameter 2 will be output. Parameter 3 will be output with the
linear move. Finally, parameter 4 will be output after the move.
Customizing the post .TXT file to display text in Mastercam

When customizing a post .TXT file, you should refer to each product’s main text file; LATHE9.TXT,
MILL9.TXT, ROUTER9.TXT or WIRE9.TXT for a full list of customizable text. You will find that
the correct heading for Mill, Router and Lathe canned text is:

[canned text]
And the correct heading for Wire canned text is:

[wire canned text]
To customize the text that appears in Mastercam’s Canned Text dialog box, list the text to be displayed
line after line in a numeric list. You can have up to 99 lines or items in this list. This text is for display
in Mastercam only. It is not the text that will appear in the NC output, which is defined in the post
customization (.PST) file. Both the post .PST and .TXT files must be updated when making changes to
canned text.
This also means the text in the post .TXT file (which will be displayed in Mastercam’s canned text
dialog box) does not have to be the same text that will be output to the NC file. For example, the post
.TXT file can display “Stop”, as seen in the example below, and the post .PST file can be set up to
output “M00”. However, you should associate cant_val1 with line 1, cant_val2 with line 2, etc.
Here is an example of the canned text section of a Lathe post .TXT file:
[canned text]
1. "Stop"
2. "Ostop"
3. "Bld on"
4. "bLd off"
5. "rEt. tlstk"
6. "adV. tlstk"
7. "Ret. chute"
8. "Adv. chute"
9. "eXstp on"
10. "exstP off"
11. "Canned Text 11"
12. "M12"
13. "M13"
14. "M14"
15. "M15"
16. "M16"
See Volume 1, Post TXT File for more information
Associating cant_val with the correct output string

Following are some sections of a post processor to show how canned text can be implemented in a post
.PST file. This will describe the general flow of canned text through the post.
Note: The notes in bold italics describe how the post handles the canned text. With the exception of the
plinout postblock, the outlined text is code copied directly from the MPFAN.PST post processor file.
The calls to pcan, pcan1, and pcan2 must be made by adding them into postblocks in the appropriate
places to create ‘before’, ‘with’, and ‘after’ results. Look at the following a plinout postblock as an
example of how the calls to pcan, pcan1, and pcan2 might be made. pcan is called ‘before’, pcan1 is
called ‘with’, and pcan2 is called ‘after’. strcantext is the string that actually outputs canned text.
plinout # Output to NC of linear movement - feed

pcan, e # pcan for ‘before’
pcan1, pbld, n, sgfeed, sgplane, `sgcode, # pcan1 for ‘with’,
sgabsinc, pccdia, pxout, pyout, pzout,
pcout, feed, strcantext, scoolant, e # strcantext on output line for ‘with’
pcan2, e # pcan2 for ‘after'
# -------------------------------------------------------
# Canned Text
# -------------------------------------------------------
The pcan postblock will be called by a postblock such as plinout. pcan clears any existing value to
strcantext, and then tests cant_no to see if there is any canned text to be output. If not, it returns to plinout
and continues processing.
If there is canned text to be output, it tests each of the 10 positions on the 1025 line to see if the canned
text is to be output ‘before’. (It’s currently in the pcan postblock, which is only going to output ‘before’
parameters.) If anything is found that should be output ‘before’, the appropriate pcant_? postblock is
called to extract the cant_val and take it to the pcant_out postblock, where the output string (strcantext) is
built. Finally, it returns here to pcan, outputs the strcantext string, and continues until all ‘before’
parameters have been processed and it can return to plinout.
pcan # Canned text - before output call ‘BEFORE’

strcantext = sblank
if cant_no > zero,
[
if cant_pos1 = zero, pcant_1
#… Positions 2-9 here (removed for clarity in this example.)
if cant_pos10 = zero, pcant_10
pbld, n, strcantext, e
strcantext = sblank
]
The pcan1 postblock works very similarly to pcan, except for two major differences:
pcan1 allows canned text to pass when cant_pos = 1 for ‘with’ output.
Upon returning from pcant_out to pcan1, pcan1 does not output the strcantext string. Since it is being
output ‘with’, it is left so strcantext can be output on the line it is supposed to be ‘with’. This way, it
can be output in the desired order on the output line (on the NC line that is generated in postblock
plinout in this example).
pcan1 # Canned text - with move ‘WITH’

strcantext = sblank
if cant_no > zero,
[
if cant_pos1 = one, pcant_1
#… Positions 2-9 here (removed for clarity in this example)
if cant_pos10 = one, pcant_10
]
if cstop, strcantext = strcantext + sm00
if cgstop, strcantext = strcantext + sm01
# Output of strcantext occurs at the end of the output line
pcan2 works almost the same as pcan, except pcan2 is looking for ‘after’ parameters.
pcan2 # Canned text - after output call ‘AFTER’

strcantext = sblank
if cant_no > zero,
[
if cant_pos1 = two, pcant_1
#… Positions 2-9 here (removed for clarity in this example.)
if cant_pos10 = two, pcant_10
pbld, n, strcantext, e
strcantext = sblank
]
pcant_1 through pcant_10 simply set the variable cantext equal to the cant_val being processed and call
pcant_out to build the output string.
pcant_1 # Canned text - output call

cantext = cant_val1
pcant_out
#... pcant_2 - pcant9 here (removed for clarity in this example.)
pcant_10 # Canned text - output call
cantext = cant_val10
pcant_out
The pcant_out postblock builds the output string, that is, turns a value such as 1 into M00. In this post,
the last five lines of code mean any cantext value (or cant_val – cantext was set equal to cant_val? in the
previous postblock) greater than 4 will simply output the cantext value with an “M” in front of it. A
cantext value of 5 would output an “M5” to the NC file (lines marked #8 through #12).
pcant_out # Canned text - build the string for output #1

# Assign string select type outputs #2
if cantext = three, bld = one #3
if cantext = four, bld = zero #4
# Build the cantext string #5
if cantext = one, strcantext = strcantext + sm00 #6
if cantext = two, strcantext = strcantext + sm01 #7
if cantext > four, #8
[ #9
strtextno = no2str(cantext) #10
strcantext = strcantext + strm + strtextno #11
] #12
Adding canned text options to a Version 9 MP post

The pcan through pcant_out postblocks shown in the preceding sections were copied directly from the
standard MPFAN.PST file on the Version 9 CD. The following steps describe how to customize the
post to output M52 when selecting the fifth option from the list in Mastercam’s canned text dialog box.
In most cases, adding more options to the list of available canned text requires just a few simple steps:
Modify the post .TXT file to display the correct text.
Define the output string.
Make two changes to the pcant_out postblock.
Note: Refer to the numbers at the end of each line in the pcant_out postblock shown in the preceding
section for this example.
1. Customize the post .TXT file, which is the only way to enable the use of the modifications you
make and have them visible while in Mastercam. Line 5 of the canned text section in
MPFAN.TXT has been modified here:
[canned text]
1. "Stop"
2. "Ostop"
3. "Bld on"
4. "bLd off"
5. "M52"
2. Initialize a string for this output by adding

sm52 “M52”
to the string definitions section of the post. Remember that string definitions start in the first column
(that is, at the left margin) and do not use “:” or “=” between the string name and its value.
3. Add a postline to pcant_out to build the sm52 string into the strcantext output string when cantext = 5.
After line 7, add the following line:
If cantext = 5, strcantext = strcantext + sm52
4. Since a cantext value of 5 now has special output defined, it is necessary to modify the line
(if cantext > 4,) to read:
if cantext > 5,
Original MPFAN.PST:
pcant_out # Canned text - build the string for output
# Assign string select type outputs
if cantext = three, bld = one
if cantext = four, bld = zero
# Build the cantext string
if cantext = one, strcantext = strcantext + sm00
if cantext = two, strcantext = strcantext + sm01
if cantext > four,
[
strtextno = no2str(cantext)
strcantext = strcantext + strm + strtextno
]
Altered MPFAN.PST:
sm52 “M52” # Define the string that will be output for cantext option 5
pcant_out # Canned text - build the string for output
# Assign string select type outputs
if cantext = three, bld = one
if cantext = four, bld = zero
# Build the cantext string
if cantext = one, strcantext = strcantext + sm00
if cantext = two, strcantext = strcantext + sm01
if cantext = five, strcantext = strcantext + sm52
if cantext > five,
[
strtextno = no2str(cantext)
strcantext = strcantext + strm + strtextno
]
When you enter the Canned Text dialog with this altered MPFAN.PST active, you will see a display
similar to the dialog box below. In this picture, canned text #5 (“M52”) has already been selected to
output before.
This is a sample output from the altered MPFAN.PST using the new “M52” (cantext #5) option.
The first “M52” in this NC program was generated by the selection of the cantext option as shown
above on the Canned Text dialog when programmed from the Tool Parameters page of the Contour
path parameters.
The second “M52” in this NC program was generated by the selection of the cantext option as shown
above on the Canned Text dialog when programmed from the Change at Point page accessed from the
Chain Manager.
(This cantext command was “tagged” onto a specific position along the contour toolpath.)
%
O0001
(PROGRAM NAME - CANTEXT_EXAMPLE)
N10G20
N12G0G17G40G49G80G90
( 1" FLAT ENDMILL TOOL - 1 DIA. OFF. - 1 LEN. - 1 DIA. - 1.)
N14M52
N16T1M6
N18G0G90G54X0.Y-.5A0.S1528M3
N20G43H1Z.25
N22Z.1
N24G1Z-1.F6.42
N26Y-1.5F24.45
N28X1.75
N30G3X2.Y-1.25R.25
N32G1Y1.25
N34G3X1.75Y1.5R.25
N36G1X-1.75
N38M52
N40G3X-2.Y1.25R.25
N42G1Y-1.25
N44G3X-1.75Y-1.5R.25
N46G1X0.
N48Y-.5
N50Z-.9F6.42
N52G0Z.25
N54M5
N56G91G28Z0.
N58G28X0.Y0.A0.
N60M30
Volume 1 Chapter 17 File Manipulation
17 File Manipulation
The MP post executable is capable of providing several output file streams and temporary file streams.
These can be used to manipulate, order, and access data to be used for a variety of purposes. The
ability to manipulate files makes the MP language very flexible. This chapter presents the various file
streams and formula functions that can be used with them.
See Volume 2, Buffer Files and Volume 2, Subprograms for related topics.
NC program output files

By default, the MP post executable directs all NC program output to the NC file. It can also direct NC
program output to one or more alternate output files:
sub file
auxiliary file
external file
This ability is controlled by setting the numeric variable subout. By setting this variable to the
appropriate value, you can switch the output stream the post processor writes data to.
Note: Be aware that when you set the automatic use of subprograms with the numeric variable
sub_level, switching is done for you based on the predetermined nested level of the subprogram.
When using automatic subprograms, you cannot use the alternate files.
Controlling alternate file defaults

The path, name and extension of the alternate files (and the extension of the standard NC output file as
an initial setting) can be controlled by the post customization file. This ability allows the reuse of a
particular alternate file with a new file name.
Changing default output file extensions

Use the following string variables to redefine the default output file name extension:
string variable output file extension (default)
sextnc default output file (.nc)

sextsub sub output file (.sub)
sextaux auxiliary output file (.aux)
sextext external output file (.ext)
Chapter 17 File Manipulation Volume 1
The extensions are assigned the default character strings as shown above. This default can be
overwritten by initializing the string variables or by reassigning them on a postline. The new file name
is not used until the procedure to changing the output file is used. The NC file extension cannot be
reassigned, but when initialized in the post, it is read into Mastercam when the post is loaded. For
example:
sextnc “ABC” # Mastercam now uses “ABC” as the NC file extension
See Volume 1, String Variables for more information on strings.
Changing default output file names

Use the following string variables to redefine the default output file name:
string variable output file name
snamesub sub output file name

snameaux auxiliary output file name
snameext external output file name
The file names are assigned the NCI file name by default. This default can be overwritten by
initializing the string variables or by reassigning them on a postline. The new file name is not used
until the procedure to changing the output file is used.
Note: The NC file name is defined in Mastercam.
Setting output file paths

Use the following string variables to set the default output file path from within the post:
string variable output file paths
spathsub sub output path

spathsaux auxiliary output path
spathext external output file path
The paths are the current directory (that is, no path is assigned) by default. This default can be
overwritten by initializing the string variables or by reassigning them on a postline. The new path is
not used until the procedure of changing the output file is used.
Managing output files

Selecting an output file
You can control where the NC output is written from within the post customization file by using
numeric variables related to the subout variable and the subout variable itself.
The subout variable acts as a switch to direct the NC code output to one of the following alternate files:
subout value alternate file (and default extension)
0 default output file (.NC)

1 sub output file (.SUB)
2 auxiliary output file (.AUX)
3 external output file (.EXT)
Set the subout variable to the desired value in the post customization file either by initializing it or
setting it on a postline at the point the stream is to be switched. The NC output is then directed to the
alternate file selected by the subout value. For example:
subout : 0 # Direct the output to the NC file
subout = 1 # Re-direct the output to the sub alternate file
Opening output files

The alternate output file must be recognized as a valid stream before it can be opened and accessed
with the subout variable. The file is actually opened on the first attempt to output to the file. The
following numeric variables are used to recognize the alternate files:
numeric variable output file
subprg sub output file

auxprg auxiliary output file
extprg external output file
Note: The NC output file is always open.
The subprg, auxprg and extprg numeric variables have three possible states. Set the appropriate variable
to one of the following values:
variable value action
0 Disable writing to the alternate file.

1 If the alternate file already exists, erase the contents of the file and open the file, or
create the new file.
2 If the alternate file already exists, open the file and append output to the existing
contents of the file, or open a new file.
Set the appropriate variable value by initializing it or by using it in a formula statement, although
returning to the standard NC output file (subout = 0) requires no additional coding. This is required the
first time output is directed to the alternate file only. For example, the sub file can be recognized either
way:
subprg : 1 # Allow access to the sub file by initializing subprg = 1 (open and clear)
subprg = 1 # Allowing access to the sub file as a formula statement (alternate method to subprg : 1)
subout = 1 # Re-direct the output to the sub file
The above code snippet displays the value set for erasing the contents of the .SUB alternate file when
the file exists. The following code displays the setting to append the NC output to the contents of the
file if it exists.
subprg : 2 # Allow access to the sub file by initializing subprg = 2 (open and append)
pblock # A postblock with the numeric variable
subprg = 2 # Allow access to the sub file as a formula statement (alternate method to subprg : 2)
subout = 1 # Re-direct the output to the sub file
Note: Automatic subprograms enable the alternate files, so it is not necessary to set these variables in
posts supporting the subprograms.
Merging output files

You can append (merge) an alternate file into another output file (including the standard NC output
file) by using one of the merge commands:
command variable file to be merged
mergesub Merge sub output file.

mergeaux Merge auxiliary output file.
mergeext Merge external output file.
To merge an alternate file, enter the command variable for the appropriate alternate file into the post
customization file as a postline at the point where you want to merge the file. The alternate file can be
merged at any time and will be appended to the target file (as defined by the current subout setting). By
merging before all posting is completed, the contents of the merged file are inserted into the target file.
You cannot merge a file into itself, so the subout variable cannot be set to write to the same alternate file
as being merged. For example, if subout were set to 1, attempting to mergesub would generate an error
because a file cannot be merged into itself. The following is not valid:
subout = 1 # Direct the output to the sub alternate file
mergesub # Append the sub file to the NC file
The following is a legal use of the merge function:

subout = 0 # Direct the output to the NC file
mergesub # Append the sub file to the NC file
Clearing output files

You can clear or empty alternate files of their current contents by using the appropriate command
variable for the alternate file:
command variable file to be emptied
clearsub Empty sub output file.

clearaux Empty auxiliary output file.
clearext Empty external output file.
To clear an alternate file, enter the command variable for the appropriate alternate file into the post
customization file as a postline at the point where you want to clear the file. For example:
subout = 0 # Direct the output to the NC file
clearsub # Empty the sub alternate file
Changing the output file

Use the following command variables to close the alternate file and reopen it with a new file path,
name or extension. The file opening method can also be modified before the command variable is
encountered on the postline. If the file name is not changed and the file opening method numeric
variables (subprg, auxprg and extprg) are 1, the file is emptied.
command variable file to be closed and reopened
newsub Close then open a new sub output file.

newaux Close then open a new auxiliary output file.
newext Close then open a new external output file.
For example, the name is changed for the alternate file “sub file”. In the following code example, the
alternate sub file is closed with the contents intact and reopened with the new file name as a new file by
the command variable newsub:
psubname # Rename the ISO name
subout = 0
sisoend = no2asc(isono)
snamesub = snamenc + sisoend
subout = 1
subprg = 1
newsub
Note: To close a specified file rather than the current file, change the output file path, name, and or
extension before using these command variables in a postline.
Closing output files

You can close the NC output file and the alternate files (.sub, .aux, .ext) with the file function fclose. If
the argument passed in the function is a string variable that is the file name and extension of the NC file
or one of the alternate files, the file with the matching name is closed. See Volume 1, Formulas for
more information.
string1 "file.sub"
real_result = fclose (string1) # Close the matching file name
General file manipulation formulas

The following formula functions can be used to manipulate any files including the alternate files:
Formula Use
fexist Determine if a file exists.

fclose Close a file.
remove Remove a file from the disk.
rename Rename a file on the disk.
These tools can be used in conjunction with other MP features, such as buffer files, to perform a high
level of file manipulation.
See Volume 3, Formulas and Volume 2, Buffer Files for more information.
General file manipulation techniques

Following are examples of techniques that can be used to manipulate files using the MP language.
Because MP is a language, there are many possible applications. These examples provide a general
idea of what is possible.
Closing and reopening an alternate file with subprograms

With automatic subprograms, it is sometimes desirable to have separate files generated for each
subprogram. To do this, you must rename the alternate output file for each new subprogram written.
Because a subprogram is called to be written at the postblocks psub_st_m and psub_st_s, a call to the
example postblocks psubname_m and psubname_s can be made from the appropriate postblock. You
must filter the calls so that the call is made only on the initial subprogram.
See Volume 2, How subprograms work for more information.
For example:
psub_st_m # Header in main level
if sub_sec_no = zero, psubname_m
*main_prg_no, "(PROGRAM - ", progname, ")", e
psub_st_s # Header in sub level
if sub_sec_no = one, psubname_s
*sub_prg_no, "(PROGRAM - ", progname, ")", e
This example creates a unique file name for each subprogram by appending a letter to the NC file
name. Initialize the following user-defined variables for use in the code snippet.
snameend # String for character to append
ascii_no : 65 # Ascii equivalent of character to append (ASCII value 65 = the letter ‘A’)
The postblocks and the postlines in them assign a new subprogram name (alternate file name) when
they are called. Notice that the main subprogram is automatically assigned the sub file and the sub
subprogram was assigned the auxiliary file.
psubname_m # Name the main subprogram
snameend = no2asc(ascii_no)
snamesub = snamenc + snameend
newsub
ascii_no = ascii_no + 1
psubname_s # Name the sub subprogram

snameend = no2asc(ascii_no)
snamesub = snamenc + snameend
newaux
ascii_no = ascii_no + 1
The postlines first convert the ascii_no value to a character (initially to A). The character in the
resulting alternate file name is appended to the NC file name. Next, the command variable is
encountered, which closes the currently open file and reopens the stream with the new file name. The
last action is to index the numeric variable ascii_no to get the next character when either postblock is
called again.
Renaming the NC file after posting

When a job is posted from Mastercam, the NC file name is passed as an argument to the post
executable and cannot be changed until after posting is complete. You can change the NC output
filename after posting completes by using the formula functions in the MP language. It is assumed that
either the user or the post has assigned the new file name to the sting variable snewfame.
snewname # User defined string to hold the new file name
sncfilename # User defined string to hold the NC program file name
For example:
ppost # This predefined postblock is called after all files are closed at the end of posting
sncfileame = spathnc + snamenc + sextnc # path + name + extension
result = remove(snewname) # in case this filename already exists
result = rename(sncfilename, snewname) #rename the NC file just created to the name specified in ‘snewname’
The above code snippet first builds the complete NC filename, with the path, file name, and filename
extension. Next, the file specified in the string variable snewname is removed from the disk. (This is a
precaution. If the file already exists on the disk, you cannot rename another to have that name.) Finally,
the NC file is renamed with the new file name.
Opening an alternate file as a buffer file

You can reopen an alternate file (NC output) as a buffer file to further process the resulting NC code.
This might be required, for example, for renumbering or adding additional code based on the resulting
output.
The following example demonstrates the MP code required to reopen an alternate file as a buffer. First,
define some variables and the buffer file to be used:
result : 0 #A variable for a return value
rc1 :1 # A variable for the buffer read count
sz1 :1 #A variable for the size of the buffer
s_extname #A string variable for the entire ext file name
stringbuf #A string variable for the buffer read
fbuf 1 0 80 1 #Define buffer 1, initialize flag set to open a file
In the postblock pheader, set the output to the external alternate file:
pheader # Predefined postblock at file header
extprg = 1 # Open (and clear) the .EXT file
subout = 3 # Direct post output into this file
In the postblock peof, switch the output stream to the NC output and build the external file name. Next,
close the external file and the name is assigned to the first buffer file. The buffer file (formerly the
external file) is checked for the size and then the file is read and written to the NC output. This
continues until all the records are read because of the variables used in the “while” loop. The rc1
variable used for the read counter is automatically incremented by the rbuf command each time a
record is read. (Normally you would have code in the “while” loop to manipulate the read record.).
peof #End of file postblock
n, "M30", e
s_extname = "C:\MCAM9\MILL\NC\" # Assign the path for the EXT file
s_extname = s_extname + snameext + sextext # Build up the complete file name
result = fclose(s_extname) # Close the EXT file
sbufname1 = s_extname # Now, open this file as a Buffer
subout = 0 # Set output stream to (main) NC file
size1 = rbuf(1, 0) # Get the size (# of records) in the buffer file by reading record ZERO
while rc1 <= size1, # Loop through the entire buffer file
[
stringbuf = rbuf(1, rc1) # Read a record (line) from the buffer file (rc1 auto increments)
stringbuf, e #This writes the record to the NC output file
]
See Volume 3, Formulas and Volume 2, Buffer Files for more information.
Volume 1 Chapter 18 How Prompt Questions Work
18 How Prompt Questions Work

Overview
You can allow the operator to set or change variable values or strings during the posting operation by
using prompt questions. Prompt questions are post questions that cause the post processor to display a
screen prompt during the posting process. The questions may be used to prompt the user to enter in
data, and can store that data into a variable in the post for use in post calculations or output.
Defining a prompt question is a two-step process:
1. Define up to 20 prompt questions using the fq function. Each question can contain a maximum
of 80 characters, including the question number, and may also contain variables.
2. Insert a call to a specific question (that is, ask the question) in the post by inserting the question
name (q1, q2, q3, etc.) on a postline at the point where you would like the question to be asked.
When the post is run and a question is encountered, the question is output to the screen and the post
waits for a numeric or string reply. The reply will then be stored in a variable.
Note: The result numeric variable or string variable must be defined before the question is defined.
Format of a prompt question in the post

fq 1 seqno Enter starting sequence number.
Where:
fq 1 = Question number (FQ [space] number)

seqno = Variable that holds the response to the question
Enter starting sequence number = Question string
A post variable can be used in the question itself if the variable is enclosed in double slashes
(//variable//).
For example:
fq 1 ofs Enter tool //t// offset:
If t = 3, the above code would display on the Mastercam prompt area when post processing:
“Enter tool 3 offset:”
and pass the response entered in the user-defined variable ofs.

Note: The variable in the question is formatted according to the assigned format statement.
Chapter 18 How Prompt Questions Work Volume 1
Question definition for a numeric response

thdtype : 0 # Declare a numeric variable to hold response to question 1
fq 1 thdtype Thread Type (0=simple G32, 1=complex G76, 3=box G92)
Question definition for string response

sextaux # Declare a string variable to hold response to question 1
fq 1 sextaux Aux file name extension = # Override Aux file extension
Note: The result target variable must be defined before the question.
Inserting a question into a postline

fq 1 seqno Enter starting sequence number # Define the prompt question
psof # Start of file for postblock
pinit
!opcode, !coolant
q1 # Ask the question defined by the ‘fq 1’ statement
if tcnt = 1, stagetool = 2
"%”, e
The q1 command calls the question defined by fq 1.
Example
The following example shows adding a prompt question to a post. This example prompts the user to
enter a part number, and then outputs the part number at the start of the NC output file.
1. Define a string variable (spartno) to store the part number retrieved through the post question.
spartno #Define empty string
2. Add the question definition to the post processor. The fq function must begin in column 1.
fq 1 spartno Enter the part number
3. Add the question call to post. (This depends on where you wish the question to be asked.)
In this example, it is added to the pheader postblock
pheader #Header postblock
“%”, e
q1 # Question ‘Enter the part number’ is asked here…
4. Add a postline to output part number information to the NC output file.
psof #Start of file
pinit
progno
spartno = ucase (spartno) # Make it all UPPERCASE (optional)
“(Part Number: “, spartno, “)” # Output the part number that was entered at the question
prompt
Volume 1 Chapter 18 How Prompt Questions Work
Merging files through prompt questions

You can also use prompt questions to merge external ASCII files identified by the user into the NC
program. In this example, the user will be prompted to enter the name of a file to merge into the NC
output file. The predefined string scopyfile is provided to hold the contents of an external file. The
mergeext function performs the merge operation by writing that external file’s contents to the NC file.
For example:
# Definition using ‘scopyfile’ as the target variable
fq 2 scopyfile Enter name of file to merge # Define prompt question 2
pheader # Header postblock
q2 # Display “Enter external file name” and read contents of response file into scopyfile.
mergeext # Merge contents of file ‘scopyfile’ to NC file.
Volume 1 Chapter 19 Posting Comments into the NC File
19 Posting Comments into the NC File

Comments can be inserted into the NC toolpath file using Mastercam. They can be inserted using the
manual entry toolpath type or the change at point option accessed from the Chain Manager, and from
the comment box on the tool parameters page. The comments will appear in the NCI file with the
following Gcodes:
1005 - Write comment at current position with sequence number
1006 - Write comment at current position without sequence number
1007 - Write comment at the end of the next linear or arc move
When a comment is entered in the Comment box on the Tool Parameters dialog box of a toolpath
operation, it is written to the NCI file as a Gcode 1008.
Using pcomment to format comments

When the post executable processes the NCI file, comments are read into the predefined string variable
scomm. The post executable then calls the predefined postblock pcomment, where the comment is
formatted.
If the comment is a Gcode 1005, 1006 or 1008, the comment is output immediately.
If the comment is Gcode 1007, it is saved and output at the end of the next NC line.
You can set the pcomment postblock to output comments with different formats by checking the Gcode
numbers. In the NCI file:
Gcode 1005 outputs the comment before the current NC block.
Gcode 1006 outputs the comment after the current NC block.
Gcode 1007 outputs the comment with the same line as the next arc or linear move.
Gcode 1008 is a comment from the Comment box on the current toolpath operation. It is handled
internally like a Gcode 1005 comment.
Manual entry postblock example

A standard manual entry setup may look like the following:
pcomment #Comment from manual entry (must call pcomment2)
pcomment2 # Required if doing ‘if’ logic testing!
pcomment2 #Post to output Comment from manual entry
if gcode = 1005, "(", scomm, ")", e # Before
if gcode = 1006, "(", scomm, ")", e # After
if gcode = 1007, "(", scomm, ")" # With
if gcode = 1008, "(", scomm, ")", e # Operation comment
Chapter 19 Posting Comments into the NC File Volume 1
Using scomm to capture comments

Comments in the NCI file are captured in the string variable scomm. scomm is output from the
postblock pcomment and is then cleared. When using the scomm variable in a Boolean (logic)
statement, the pcomment postblock must first call a user-defined postblock where the logic tests are
performed to avoid clearing the contents of scomm.
pcomment #Comment from manual entry (must call pcomment2 if using Boolean logic tests)
pcomment2
if gcode = 1007, "(", scomm, ")"
Using the commlng variable

The numeric variable commlng is automatically set to the length of the scomm text string. This is the
number of characters in the scomm comment string.
Note that commlng is only valid in the call to the pcomment0 postblock !
pcomment0 #Comment (pre-call postblock)
"commlng = ", ~commlng, e # If scomm contains something, this is the string length
pcomment #Comment from manual entry (must call pcomment2 if using Boolean logic tests)
"commlng = ", ~commlng, e # commlng will always be ZERO here in the pcomment postblock!
pcomment2
if gcode = 1007, "(", scomm, ")"
Using the commvar variable

The numeric variable commvar is a special comment case. If the scomm comment string is composed
entirely of numbers (0-9) and optionally the symbols “.”, “+”, or “-“, it will automatically be converted
from the text string into a numeric value and placed into the commvar variable.
Note: If commvar is used, the scomm string will be cleared.
If you do not want a numeric value, but a string that contains the “numbers”, you must capture the
value in commvar and convert it to a string. Note that this is done in the pcomment0 postblock!
sblank # Declare a string variable that contains “nothing”
scomm_tmp sblank # Declare a string variable to hold the "comment" from COMMVAR
pcomment0 #Comment from manual entry (pre-call postblock)
# If a comment (the SCOMM string variable) contains ONLY digits
# (and possibly "+-." characters) is encountered, it is automatically converted to a
# NUMERIC value and stored in predefined numeric variable COMMVAR
# Note that SCOMM is "blanked out" when this happens!
# So, if you want that special numeric value in COMMVAR as a string variable,
# you must capture and convert it.
# FYI, COMMLNG holds the length of the string in SCOMM
if (commvar <> zero) & (commlng = zero),
scomm_tmp = no2str(commvar) # Convert COMMAR into a string
else,
scomm_tmp = sblank # nothing in commvar this time, blank out scomm_tmp

pcomment #Comment from manual entry (must call pcomment2 if booleans)
pcomment2 # call pcomment2 for output

if (scomm <> sblank),
[
if gcode = 1007, "(", scomm, ")"
]
if (scomm_tmp <> sblank), "(***-> ", scomm_tmp, " <-***)" # The comment converted from commvar
Comments and the tool change block

One of the main uses of comments is to give the machine operator instructions, and one of the primary
times instructions are needed is at a tool change.
To get comments into the NCI file with a tool change block:
1. Choose manual entry when making a tool path.
2. Select the first point of the toolpath after the tool change.
3. Enter the comment.
4. Choose before to output the comment immediately before the tool change.
Note: If you choose with, the comment will be output to the NCI file with a 1007 Gcode, but not until
the first move of the toolpath (after the tool change). If you choose after, the comment will be output
after the first move in the toolpath (also after the tool change).
Using the comment command with tool changes

By default, comments appear immediately before the tool change. However, because you might wish
to process the tool change block before outputting the comments, you must save the comments until
after the tool change block has been read. This can be done with the special command comment.
If the comment command appears in any postblock when a comment with a Gcode 1005, 1006 or 1008
is read, it is automatically saved in an array. When the postline with the comment command is
executed, the array of saved comment strings is output, one comment string at a time. Each string from
the saved list is copied into the string variable scomm, and a call is made to the postblock pcomment. In
this way, each comment can be formatted before it is output to the NC file.
The comment command is usually used in the psof, ptlchg, ptlchg0, peof (and lsof, ltlchg, ltlchg0,leof, msof,
mtlchg, mtlchg0, and meof) postblocks to output the comments at a particular location in the NC
program. To output comments at a specific location, use the command comment. Never call the
postblock pcomment directly from other postblocks.
Chapter 19 Posting Comments into the NC File Volume 1
Example using the comment command

The following is an example of correct usage of the comment command.
ptlchg # Tool Change postblock
n, pcooloff # Coolant off at end to tool
n, "G28 Z0" # End of previous operation
comment # Output the comment(s) here
n, t, "M6" # Tool change / start of new operation
The preceding code would generate NC output similar to:

M09
G28 Z0
(THIS IS THE COMMENT FOR TOOL#4)
T4M6
The rules for using the comment command can be complicated, but keep in mind that the main purpose
of the comment command is to save comments that appear before a tool change until after the tool
change block has been read.
How the post processes comments

When a comment is found, it is saved in an array until an NCI line is read that is not a comment. If the
next line read is anything but the start of a tool change block or the NCI line for the end of file, the
array comments will be output before that NCI line is processed. If the next line read is the start of a
tool change block or the NCI line for the end of file, the comments will not be output until the
command comment is found in one of the following postblocks:
psof
ptlchg
ptlchg0
peof
lsof
ltlchg
ltlchg0
leof
msof
mtlchg
mtlchg0
meof
If the comment command does not appear in one of these postblocks, the array of comments will not be
output. In this case, the array of comments can be output by the comment command in a postblock
other than one of the postblocks mentioned above. For example, to delay outputting the comments
until after the first rapid move after the tool change, the command comment would appear in the
postblock prapid.
The one exception to the rules above is when comments appear before the start-of-file block, with
Gcode 1005, 1006 or 1008. These comments are always saved in an array whether the command
comment is used or not.
If the comment command is not used, the array of comments will be output when the start-of-file
postblock (psof, lsof, msof) is executed but before it is processed.
If the comment command is used, the comments will be output at the location of the comment
command when the start-of-file postblock is executed and not before.
Using the pscomm0 postblock

An alternative method of handling comments is to use the pre-defined postblock pscomm0 and the pre-
defined variable scomm0. When the post customization file (.PST) reads a comment from the NCI file,
it copies the comment string into the pre-defined variable scomm0 and calls the postblock pscomm0.
This allows immediate access to any start-of-file comments. After executing postblock pscomm0, the
post executable does not automatically reset the scomm0 variable to an empty string. The post writer
must do this in the post customization file with a postline at the end of the pscomm0 postblock:
scomm0 = sblank # sblank must be initialized as blank string
Note: The function of the postblock pscomm0 is rarely needed. If you use the pscomm0 method, you
would not usually also use the comment command method.
ADDENDA
Post header line components

The post header line was most recently modified in Mastercam X6. A typical header line
Quick Start
from an X6 or newer post reads as follows:
[POST_VERSION] #DO NOT MOVE OR ALTER THIS LINE# V15.00 P0 E1 W15.00
T1305895880 M15.00 I0 O0
The W and O parameters were added in X6. A complete directory of header parameters is:
 V—Post update/edit version.
 P—Mastercam product: 0=Mill, 1=Router, 2=Lathe, 3=Wire, 4=Mill/Turn.
 E—Product used to edit post: 0=unknown, 1=UpdatePost (value 2 is reserved for
future use).
 W—Version number of the product used to update the post (parameter E). So in
the example above, E1 indicates that the post was updated with UpdatePost;
W15.00 indicates UpdatePost Version 15 (for X6).
 T—Date/time stamp from UpdatePost (do not enter this manually!)
 M—Mastercam version required to run the post (X8 = 17).
 I—Not currently used; reserved for future use.
 O—Support for optional products or prototypes. This is a “license plate” value in
which each decimal place indicates support for a different product. Two values
are currently supported:
 O1 indicates support for Renishaw probing.
 O10 indicates support for the Pickoff/Cutoff utility.
Therefore, O11 indicates support for both products.
Volume 1 Appendix A Glossary
A Glossary
This appendix defines terms used in the MP Post Processor Reference Guide. The definitions are grouped
as follows:
General terms
Post areas
Postblocks
Postline types
Postline statement types
Variables
Math
General terms
Alternate file Used to describe subprogram files or files that have been created
because the output stream has been redirected by the subout variable
(sub, aux, ext).
ASCII decimal equivalent A numerical value for a character as defined by the American
Standard Code for Information Interchange.
Buffer file function The function used to declare a buffer file in the post.
Format assignment A post function that assigns or links a format statement to a numeric
variable.
Format statement A post function that defines the format of a numeric variable.
Global formula An assignment to a variable that is automatically updated each time
the variable is encountered in a postblock.
Intermediate file A file that describes the cutter location and toolpath parameter
information.
Label The name given to a postblock or variable.
Lookup table A table of values to be referenced by the math functions; flook, frange,
and finc.
Lookup table function The function (flktbl) used to define a lookup table.
Modal, modality The property of a variable that determines how the post handles its
value.
MP language A specific code format that is acceptable to be interpreted by the MP
Post Executable.
NC output file The final output code produced by the post processor, which can be
read by a machine tool (G codes, M codes, etc.).
NCI file An ASCII text file containing the cutter location and toolpath
October 2003 Mastercam Version 9.1 MP Post Processor Reference Guide A-1
Appendix A Glossary Volume 1
parameter information.
NCI Gcode A numeric value that tells the MP post executable how to interpret the
next line of data from an NCI file.
Numeric variable An initial value assigned to a numeric variable using the colon ( : )
initialization operator.
Operation parameter file An external (.OPS) file containing toolpath parameter information.
Parameter table function A table of values to be referenced by the post function fprm.
Post customization file An ASCII text file that contains the instructions that are customized
by the post writer.
Post executable file The file responsible for reading the NCI data and interpreting the
instructions in the post customization file.
Post function A call to an internal routine in the post executable (for example, fs2).
Post text file An ASCII text file containing strings used to customize the text
messages and prompts in Mastercam.
Post writer A person who customizes a post.
Postblock Blocks of MP language code that perform a function or call another
postblock.
Postblock declaration The statement that declares a postblock. A postblock must be
declared before it can be used. Traditional postblocks are declared by
placing a label beginning with “p”, “l”, or “m” in the first column. A
bracketed postblock is declared by using the open and close brackets
([,]) as postline statements surrounding the postlines to be included in
the postblock.
Postline Individual lines of MP language code with a postblock.
Postline entries The individual elements or terms contained within a postline.
String select function A function used by the MP Language to link a numeric variable to a
list of strings. This allows the post writer to create groups of
commands and maintain modality within the group based on the value
of a numeric variable used to index through the list.
String variable initialization A string can be initialized by adding a space after the variable name
and following with a literal.
System numbered questions Questions in the post customization file read by Mastercam and used
to control aspects of Mastercam and post operation.
User prompt function A prompt that can be customized by the post writer to ask the user to
enter information that can be returned to the post in either a variable
or string.
Post areas
Definition area A section of the post that usually contains all of the variable
A-2 Mastercam Version 9.1 MP Post Processor Reference Guide October 2003
initializations, format assignments, global formulas, lookup tables,

parameter tables, prompt definitions.
Postblock area The section of the post that contains the logic of the customization
file. Also the area responsible for all output.
System numbered question Typically located at the end of the Post customization file, this section
area contains numbered questions that can be read by Mastercam.
Postblocks
Bracketed postblocks Bracketed code nested within a postblock using the square brackets ( [
) and ( ] ). These blocks of code are interpreted as user-defined
postblocks by the MP language.
Command postblock A pre-defined postblock called by a command word rather than a
standard postblock call.
Post-process postblock Postblocks called after processing the NCI file.
Predefined postblocks Postblocks defined internally within the MP executable.
Pre-output postblocks Postblocks called prior to the output standard output postblocks.
These postblocks provide access to NCI variables prior to the
calculation of the post calculated variables as in plin0 and pcir0.
Preparatory postblocks Postblocks called either prior to the actual NCI read or during the pre-
read scanning of the NCI as in ptooltable and pwrtt.
Pre-process postblocks Postblocks called prior the NCI read.
Standard postblocks Pre-defined postblocks typically used for output (for example, plin,
pcir, prapid).
User-defined postblocks Postblock definitions not automatically recognized by the MP
language, that is, whose definitions are not built into the MP language.
Postline types
Boolean postline A conditional test using the symbols “&” and “|” to represent AND
and OR.
Formula postline A variable assignment within a postblock.
Output postline Variables, strings and literals within a postblock that are not part of a
Boolean or formula that are to be considered for output.
Postline statement types

ASCII literal An ASCII decimal value appearing on a postline is defined as a
unique literal string within the MP language.
Command variable A single word appearing on a postline that triggers a pre-defined chain
of events usually including a call to a pre-defined postblock.
Conditional branching A true / false test that controls flow when calling of postblocks based
statement on the result of the conditional (“if” statement).
Debug numeric variable A numeric variable used for debugging.
Debug string variable A string variable used during debugging.
Dependent numeric variable A numeric variable prefixed with the grave accent character ( ` ),
which will be output only if there is other output on the current line of
NC code.
Dependent string literal A literal string enclosed in single quotes (‘ ’), which will be output
only if there is other output on the current line of NC code.
Dependent string variable A string variable prefixed with the grave accent character ( ` ), which
will be output only if there is other output on the current line of NC
code.
Forced numeric variable A variable used to store a floating point value prefixed by a special
character (typically the asterisk character ( * )) to force output
(making it non-modal).
Forced string variable A string variable that appears on a postline prefixed by the asterisk ( *
) character to force output (making it non-modal).
Format numeric variable The action of defining how the numeric portion of a variable will
appear in the output (decimal precision, leading / trailing zeros, etc.).
Formula statement A formula appearing in a variable initialization or in a conditional;
different from a global formula or postline formula.
Global formula Global formulas are evaluated any time the target numeric variable is
used as a postline statement or in a postline Boolean or formula. The
equal sign (=) makes the formula a global formula.
Numeric variable A variable used to store a floating point value.
Output line variables The physical line number in an NC output file (not necessarily equal
to the “sequence number”).
Output statement A variable, string or literal appearing in a postline.
Postblock call A branch or CALL SUB-like statement created by entering the name
of the postblock you wish to call on a postline.
Postline formula When the assignment formula is used in the postblock area of the post
customization file, the assignment formula can be used as a formula
postline where it is evaluated when the postblock is executed, or as the
action in a Boolean formula. The equal sign (=) is the only valid
assignment operator in this scenario.
Previous numeric variable A variable (prv_[variable name]) that stores the previous value of
another variable. All numeric variables have an associated variable
previous variable.
Selector debug string A call to a string select function prefixed with the tilde character ( ~ )
variable to control output. Will be output only if there is other output on the
current line of NC code.
Selector dependent string A call to a string select function prefixed with the accent grave
variable character (`) to control output. Output will be suppressed if it is the
only output to occur in a line of NC code.
Selector forced string A string select function call that is prefixed by a special character to
variable force non-modal output.
Selector string variable A string variable used in a list of strings linked by the post function
fstrsel.
String literal A string of characters enclosed by single or double quotes (for
example, “Text Message”).
String select function call A call to the internal routine in MP that will access a table of strings
defined by the fstrsel function and return a string based on the value of
the associated selector variable. Also referred to as the target string.
String variable A variable that holds character data rather than a numeric value.
Update numeric variable Prefixing a numeric variable with the exclamation mark ( ! ) to force
the update of its previous value (prv_); used to control modality.
User prompt function call A call to execute a user prompt as defined by the fq function.
User-defined numeric A variable used to store a floating point value not pre-defined
variable internally by the MP executable.
Variables
Boolean result The TRUE or FALSE return that controls whether or not to execute
the statements to the right of a conditional statement.
Command variable A variable used to trigger a pre-defined chain of events usually
involving a call to a pre-defined postblock.
Constant A variable that does not change in the post.
File name variable A string variable containing the name of a file.
Helper variable A variable calculated by a function to help make a logical decision,
such as the “T parameters” used with the intersection math routines.
NCI variable A variable read directly from the ASCII NCI file.
Output line variables Numeric variables typically used to format positional information
(that is, X, Y, Z, I, J, K).
Predefined variable Variables defined as part of the MP language.

Post switch variable A variable that can be assigned different values to control a certain
feature or function.
Tolerance variable A numeric variable used to control the tolerance of a post function
like the breakup of motion.
User-defined variable A variable that is not part of the MP language; must be declared in the
post customization file
Variable modifier A special character used to update or control output (~, *, !, etc.).
Math
2D vector math Math functions that work with two-dimensional (X and Y)
components.
3D vector math Math functions that work with three-dimensional data (X, Y and Z).
Advanced math functions Arithmetic operators for math operations other than addition,
subtraction multiplication and division (that is, log(), frac(), int(), etc.).
Assignment formula A formula that is evaluated by the MP language with the result
returned to the variable on the left side of the equation, for example, .
Basic math functions Basic arithmetic operators for addition, subtraction multiplication and
division.
Binary functions Mathematical operators that work on two numeric variables.
Boolean formula A formula that is evaluated by MP language with the result
determining a TRUE or FALSE return.
Conversion functions Functions that convert one type of data into another, for example,
no2str, which converts a number to a string.
Equation An expression that states the equivalence of mathematical or logical
expressions.
File formula Formula functions that perform actions such as renaming an output
file to that of an existing disk file. File formulas can be used in
conjunction with other MP features, such as buffer files, to perform a
high level of file manipulation.
File functions Function calls within the MP executable that work on disk files such
as fclose and rename.
Formula Math operators and math formulas as applied to the two MP language
statement types:
the formula statement
the conditional branching statement
Both of these statement types use the same syntax in the argument
portion of the statement. The formula statement makes an assignment
to a variable that is the target of the formula. The conditional
branching statement is a Boolean statement that evaluates for zero or

non-zero in the result of the formula.
Formula assignment The result of a formula function. Similar to an operator assignment,
which assigns a value calculated using the math operators, except that
formula functions pass parameters enclosed in the parentheses
following the function label.
Formula function A defined routine using one or two passed arguments that returns a
result, which is applied or assigned to the variable on the left of the
equation, for example, gear = frange (one, speed) or string2 = lcase
(string). Formula functions are part of the MP language; you cannot
define your own functions.
Function Unique mechanisms in the MP language that support the string select
feature, lookup table features, buffer files, and user prompt feature.
Functions rely on a declaration in the post customization file for the
feature and a formula as the calling method.
Function argument Data used within the MP executable to execute a function call. The
arguments provided to a function call on a postline are typically
enclosed within parentheses, with arguments separated by commas ( ,
). Note: Pre-process function definitions often use spaces as a
delimiter and no parentheses.
Implied array An ordered list of variables that can be used as an array for post
functions that require more than one value (that is, vector math
functions and buffer read / write functions).
Intersection formula A formula that determines the intersection point between two entities.
Intersection function A function that returns the intersection of two entities.
Logic operators The symbols &, |, and, ior, xor, not.
Math formula A formula that performs a basic math function and contains a math
operator.
Math operator Characters recognized by the MP language that perform arithmetic
operations. Basic math operators include operators for assignment
(=), addition, subtraction, multiplication, division, etc.
Matrix math Math functions that typically operate on a 9-dimensional implied
array (3x3 matrix).
Numeric value A value that can be expressed as a real number.
Operator argument The variable that the operator is working with.
Operator assignment Assignment of a value calculated using the math operators. The result
of the equation is assigned to the variable on the left side of the
equation.
Precedence functions Open and close parentheses ( ) that control the precedence of
operation, that is, the order in which operations are performed.
Result assignment The variable on the left side of an equation.
Simple assignment The act of assigning a value to a variable without the need for a
complex formula or other math operator besides the equal sign ( = ).
Special MP functions Unique mechanisms in the MP language that support the string select
feature, lookup table features, buffer files and user prompt feature.
String formula A formula that alters a character string.
String functions Functions that operate on character strings rather than numeric data.
Trigonometric functions Standard trigonometric functions for sine, cosine and tangent of an
angle. The atan2 function returns the solution of the arc tangent within
the 360 degree range.
Unary functions Mathematical operators that work on a single numeric variable.

MP Ref Guide - Vol 1 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MP Ref Guide - Vol 1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

LEGACY DOC -- VERSION 9.

Volume 1 Chapter 1 How to Use the MP Post Processor Reference Guide

1 How to Use the MP Post Processor Reference

The MP Post Processor Reference Guide consists of three volumes:

Volume 1 contains a Glossary.

How to contact CNC Software

Chapter 1 How to Use the MP Post Processor Reference Guide Volume 1

Volume 1 Chapter 2 Introduction to MP Post Processors

2 Introduction to MP Post Processors

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-1

Chapter 2 Introduction to MP Post Processors Volume 1

How does an MP post work?

2-2 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

Post processing in greater detail

Reading the NCI file

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-3

Chapter 2 Introduction to MP Post Processors Volume 1

Mastercam reads numbered system questions in .PST

Mastercam sets values and modifies menus and

User prepares Mastercam job.

User posts Mastercam job (one or more operations).

2-4 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

Mastercam writes ASCII NCI file.

Mastercam launches MP.DLL, MPL.DLL, or

Post .DLL reads and parses active PST file.

Post executes pre-process and preparatory functions

A Post reads the ASCII NCI file, two lines at a time.

Based on first line Gcode, passes parameters as

Based on first line Gcode, calls a predefined entry

Post interprets postline statements and writes NC

Post returns to A to continue reading NCI line sets

What files do I need for the posting process?

The post text file (*.TXT)

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-5

Chapter 2 Introduction to MP Post Processors Volume 1

The post ‘bin file (*.PSB)

The post executable file (*.DLL)

What are the components of the MP language?

2-6 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

Formula functions for intersecting geometry

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-7

Chapter 2 Introduction to MP Post Processors Volume 1

2-8 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

For example, this is a formula postline and a formula statement:

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-9

Chapter 2 Introduction to MP Post Processors Volume 1

2-10 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

String select function

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-11

Chapter 2 Introduction to MP Post Processors Volume 1

Support for subprograms and canned cycles

System numbered questions

How is an MP post organized?

2-12 Mastercam Version 9.1 MP Post Reference Guide February 2004

Volume 1 Chapter 2 Introduction to MP Post Processors

February 2004 Mastercam Version 9.1 MP Post Reference Guide 2-13

Chapter 2 Introduction to MP Post Processors Volume 1

System numbered question area