Working With Tool and Operation Parameters: MP Application Guides

MP APPLICATION GUIDES
Working with tool and

operation parameters
revision date: May 15, 2016
Contents
1. Introduction ...........................................................................................................................1
2. Using the opinfo function to get toolpath data ......................................................3
A. Capturing values for 10000s parameters .................................................................5
B. Capturing values from 20000s lines and other NCI gcodes .................................8
Capturing a string from a 20000s line ................................................................10
Capturing numeric values from a 20000s line ..................................................11
Getting enhanced tool table values ....................................................................14
C. Selecting the operation to query .............................................................................15
Testing if an operation has a tool table record .................................................16
3. Building parameter tables with fprm .........................................................................17

4. Working with machine definition, control definition, and machine group
parameters ..........................................................................................................................22
A. Capturing machine definition parameters .............................................................22
B. Getting the entity ID and querying the axis combination ...................................25
Understanding component IDs ...........................................................................25
Using the acomboinfo function ...........................................................................27
Using the uidinfo function ....................................................................................35
C. Capturing control definition parameters ................................................................39
D. Capturing machine group parameters ...................................................................40
5. Direct access to machine definition data.................................................................42
A. Rotary axis settings ....................................................................................................43
B. Machine matrix ...........................................................................................................46
C. Feed rate settings ......................................................................................................47
6. Advanced techniques for working with operation parameters ......................48
A. Dumping all the parameters: outputting all the parameter values ...................48
B. Using pnci20000$ to access buffered comments ...............................................53
C. Setting options for transform operation parameters ...........................................54
D. Getting the operation number from Mastercam ..................................................54
Displaying the op_id$ value in Mastercam........................................................55
E. Validating parameters with UpdatePost................................................................56
F. Lathe tool inspection comments ............................................................................57
7. Changes from X9 to 2017 ..............................................................................................61
A. Migrating a post from X9-style to 2017-style ........................................................61
MP Application Guide—Working with tool and operation parameters
Copyright © 2016 CNC Software, Inc.—All rights reserved
Terms of Use—Use of this document is subject to the Mastercam End User License Agreement.
A copy of the Mastercam End User License Agreement is included with the Mastercam product package.
The Mastercam End User License Agreement can also be found at: http://www.mastercam.com/en-us/Company-Info/Legal/LicenseAgreement/
rev. May 15, 2016 INTRODUCTION  1
1. Introduction Contents
Most of the information about your part file is transmitted to your post in the form of
NCI Gcodes. Your post reads these from the NCI file and converts them into NC code for
your machine control. These codes are numbered from 0–1056. Each code is associated
with one or more values that are read by your post and automatically assigned to
predefined variables. For example:
Because these values are automatically stored in predefined variables, you don’t need to
do anything special in your post to get them; all you need to do is use the proper variable.
However, your post also has access to other sets of information about your toolpath that
supplement the NCI Gcodes.
 Tool parameters are numbered beginning with 20000. These are output in the
NCI together with the NCI Gcodes as described above. The difference is that
these values are not automatically assigned to predefined variables; you need to
get them yourself.
The Operation  Operation parameters are numbered individually beginning with 10000. These
Parameter are not output in the NCI file at all. You need to create logic in your post to get
Reference lists all the values you want. Different procedures are required depending on whether
of these the parameter belongs to the toolpath, machine definition, control definition, or
parameters. machine group.
Learning how to get each type of value is the subject of this book.
A note about terminology—For purposes of this book, “operation parameters” are
numbered from 10000–19999 and above 30000. Operation parameters contain all the
original data associated with each toolpath operation in Mastercam, such as the values
that the Mastercam user entered in the dialog boxes. Values can be integers, real values,
or strings. They consist of the following main groups:
 Parameters from 10000–16999 are toolpath and related operation settings.
 17000–17999 and 60000–64999 are machine definition settings.
 18000–18999 are control definition settings (65000–69999 are reserved for future
control definition settings).
Working with tool and operation parameters

rev. May 15, 2016 INTRODUCTION  2
 19000–19999 are machine group settings (70000–74999 are reserved for future
machine group settings).
 30000–39999 are typically used by C-Hook developers.
 40000–59999 and above are similar to 10000–16999 settings; as Mastercam has Contents
grown, we simply needed more numbers (as of Mastercam 2017, no numbers in
the 50000s have been assigned).
Despite these differences, the term “10000s parameters” is still understood by many post
developers to refer to all of them, including 30000 and 40000 parameters.
“Tool parameters” and “20000s lines” mean the same thing: these are the lines in the NCI
file that are numbered above 20000.
This guide is divided into the following sections:
 Using the opinfo function to get toolpath data . . . . . . . . . . . . . . . . . . . . . page 3
 Building parameter tables with fprm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 17
 Working with machine definition, control definition, and machine group
parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 22
 Direct access to machine definition data. . . . . . . . . . . . . . . . . . . . . . . . . . . page 42

 Advanced techniques for working with operation parameters . . . . . . . page 48
 Migrating from X9 to 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . page 61
IMPORTANT: It is important to understand that many, many new features related to

tool and operation parameters were introduced in Mastercam 2017. Most existing
posts will continue to use the older techniques from X9 and earlier Mastercam
versions.
To accomodate those existing posts, the X9 version of this application guide is still
available. Please see the “Working with tool and operation parameters—X9 and
earlier posts” application guide to support posts that use these techniques.

rev. May 15, 2016 USING THE OPINFO FUNCTION TO GET TOOLPATH DATA  3
2. Using the opinfo function to get Contents
toolpath data
The most important tool for accessing toolpath or operation data is the opinfo( )
function. It has three features that make it especially powerful and useful:
 You can use this one single function to get information from any of three
different sources:
a. Operation parameters (in other words, parameters numbered from 10000–
16999 and above 30000).
b. NCI data. This includes not only the tool parameter lines numbered above
20000, but any other NCI line.
c. Enhanced tool table data. (This is new for Mastercam 2017.)
 You can access information from any operation, not just the current one. You
can navigate forwards or backwards in the operation sequence to get
information about, say, the next operation, the last operation, etc.
 You can use it in any postblock.
The opinfo( ) function was introduced in Mastercam 2017, replacing earlier
techniques that relied on the pparameter$, pwrtt$, and pwrttparam$ postblocks.
Those techniques relied on repeatedly looping through parameter and NCI structures
until the requested parameters were encountered—or worse, continue to loop until all
data was exhausted. The opinfo( ) function, in contrast, simply goes and gets the
requested data—and only the requested data. This makes it much more efficient. While
those older techniques still work in Mastercam 2017 to maintain compatibility with posts
that have been migrated from older versions, newer posts for Mastercam 2017 and later
should typically be written to use the opinfo( ) function.
IMPORTANT: The pparameter$, pwrtt$, and pwrttparam$ postblocks should not be

present in your post if you use the opinfo function in your post. If any of these post-
blocks are present, Mastercam will still loop repeatedly through all of the parameter/
NCI structures. See section Migrating a post from X9-style to 2017-style on page 61
for more information about implementing opinfo in an existing post.
The general form of the function is:

return = opinfo(param, source_op, mode)
where:
return = a numeric or string variable to store the return value. Use a string or
numeric variable depending on what type of value you are expecting. It is your
responsibility to determine the proper type.
param = a number that specifies the data that you are querying. You can query three
types of data, depending on the range of this number:

 Values from 10000–16999 and from 40000+ (“10000s parameters”) will return
the value of the specified operation parameter. This can be either a string or
numeric value, depending on the specific parameter queried. This is
described in Capturing values for 10000s parameters on page 5.
Contents
 Values from 950–1056, and from 20000–29999, will return a string that
contains all the values from the specified NCI line. Parse the string to extract
the desired value. This is described in Capturing values from 20000s lines and
other NCI gcodes on page 8.
 Values from 1–106 let you directly access enhanced tool table data. This is
described in Getting enhanced tool table values on page 14. Note that the
ability to access this data was introduced in Mastercam 2017 and does not
apply to earlier versions of Mastercam.
source_op = a number that identifies the operation whose parameters are being
queried. For example, you can get the value of parameter 14752 from the current
operation, or the next operation. You can specify the operation in a number of
different ways—the current operation, an offset from the current operation, or an
absolute op_id$ value. See Selecting the operation to query on page 15 to learn
more.
mode = is an optional four-digit “license plate” value that provides the context for
the source_op value. Selecting the operation to query on page 15 describes in
detail how the mode value is used.
The param and source_op values are required; mode is optional. If mode is not included,
a value of 0 is assumed.
While the second and third arguments let you configure opinfo for lots of different
applications, it is important to realize that for the most common use—getting a single
parameter from the current operation—the function is quite simple:
return = opinfo(param_number, 0)
See the next sections for specific examples.

Note that the opinfo( ) function is not designed to access machine definition, control
definition, or machine group parameters—in other words, parameters numbered from
17000–19999. Separate mdinfo( ), cdinfo( ), and groupinfo( ) functions are
provided to access those parameters. See Working with machine definition, control
definition, and machine group parameters on page 22 to learn about those functions.

A. Capturing values for 10000s parameters

This section shows you how to use opinfo to get 10000s operation parameters. These are Contents
parameters numbered from 10000–16999, and above 30000.
NOTE: The techniques in this section replace the techniques from X9 and earlier
that relied on pparameter$, pwrtt$/pwrttparam$, and rd_params$. None of those are
required any longer. They should not be present in your post if you are using the
opinfo function.
The techniques in this section are useful for retrieving one value at a time. See Build a
table of parameter values on page 18 to learn about using tables to efficiently return
several parameter values at once.
How do I...?
Capture a value from a 10000s parameter for the current
operation
1. Use the Operation Parameter Reference to find the number of the desired
parameter.
2. Define a variable to store the value. Make sure that the variable is of the proper
type for the expected return value; a numeric variable will not store a string
value, if that is what is returned.
s_my_string : "" # Stores a string
my_var : 0 # Stores a number
3. Go to the desired postblock where you want to get the value, and add a line like
this:
my_var = opinfo(1xxxxx, 0)
where 1xxxx is the actual number of the parameter and my_var is the variable
that you defined in step 2.
In this case, using 0 as the value of the second argument tells MP to get the value
from the current operation, meaning the operation that MP is currently
processing.
Because you are accessing the current operation, the third argument is not
required.
4. Repeat steps 1–3 for each individual parameter that you wish to capture.

How do I...?
Capture a value from a 10000s parameter from a nesting or
Contents
transform operation
parameter.
type for the expected return value:
this:
my_var = opinfo(1xxxxx, 0, 10)
or
my_var = opinfo(1xxxxx, 0, 20)
In this case, use the third argument to tell Mastercam that you want to get the
parameter from a nesting or transform operation.
 Use 10 to get a transform parameter.
 Use 20 to get a nesting parameter.
Selecting the operation to query on page 15 fully describes how MP uses the third
argument to query operations.
How do I...?
Capture a value from a 10000s parameter from the next
operation or previous operation
parameter.
type for the expected return value:
this:
my_var = opinfo(1xxxxx, 1)
or
my_var = opinfo(1xxxxx, –1)
In this case, set the second argument to a non-zero value to search forward or
backward in the operation sequence.

 Use 1 to search the next operation. Use any positive number to look ahead
that number of operations, relative to the current operation; 1 gets the next
operation. Do not use a “+” sign.
 Use –1 to search the previous operation. Use any number to look back that Contents
number of operations, relative to the current operation; –1 gets the previous
operation.
If no operation exists at that offset from the current operation—for example, you are
looking ahead one operation, but the current operation is already the last one—
opinfo will return either a string –99999 or numeric value –99999, depending on
your return type.
Selecting the operation to query on page 15 fully describes the different techniques
for searching operations; this is just a simple example of the most common use.
Example
Using opinfo to directly query a specific parameter
This example gets some values for a nesting application. First, it gets the value of the
clearance plane parameter (parameter number 10020) from the current and next
operation so you can compare them. Then it gets the value of parameter 41756,
which indicates if the user has selected the option to automatically use the smallest
tool.
For the first parameter, the post is querying the source operations; for the second, it
will query the nested operation. (For this example to make any sense, the source
operation should be in a nesting operation.)
clearance : 0 # clearance height for current op
clearance_next : 0 # clearance height for next op
tool_dia_flag : 0 # use smallest tool?
p_getparams # can read parameters from any postblock

clearance = opinfo(10020, 0)
clearance_next = opinfo(10020, 1)
tool_dia_flag = opinfo(41756, 0, 20)

B. Capturing values from 20000s lines and other NCI

gcodes Contents
The 20000s parameters are similar to the 10000-series parameters, except that they are
written directly to the NCI file. The information is written just prior to the actual tool
change NCI Gcodes (1000, 1001 and 1002) as two-line sets of NCI lines. The first line is
the parameter number, and the second line is its value. For example:
20001
1/4 FLAT ENDMILL
20002
20003
20004
1 10 1 0 0.25 0. 0. 180. 1 1 6.4176 6.4176 6.4176 2139 1 4
20006
0 50. 50. 25. 25. 0. 0. 0.
20007
0. 2. 3. 2.5 0.25 2. 1. 0 100. 25. 0
20008
0. 0. 1. 0 0. 0. 0 0. 0.
Traditionally, these are called “tool information parameters” because that was their
original purpose, but in modern versions of Mastercam their use has been expanded to
include other types of data. In general, they are now used for any information about an
operation that MP needs to read from the NCI file, instead of retrieved from the MCAM
file like other operation parameters.
The 20000 lines include integers, real values, or strings. In the example above, the 20001
parameter contains only a single value, a string that is the tool name. However, the 20004
parameter, which encodes the tool definition, contains a series of 16 values. Each value
represents a different tool definition parameter. The NCI Reference volume lists each
20000-series parameter and the type of value(s) it contains.
Previous versions of Mastercam relied on sparameter$, prmcode$, and pparameter$ to
read the 20000s lines. Beginning in Mastercam 2017, you can replace these with the
opinfo function. However, 20000s lines that have multiple parameters are still returned
as a single string of values that you need to parse with rpar, rparsprm or rparsngl. The
following sections give you step-by-step procedures and examples for capturing each
type of parameter:
 Capturing a string from a 20000s line
 Capturing numeric values from a 20000s line
Parameter ranges—20000s parameters are organized in the following groups:
20000–20099 Mill, plus parameters that are common to all products

20100–20199 Lathe
20200–20299 Wire
20300–20399 Router
20400–20499 Reserved for future use
20500–20599 Nesting
20600–20699 Machine definition

20700–20799 Stream/NCI Information

20800–20999 5 Axis Mill
Contents
22000–28999 Custom interface parameters (typically used for Wire).
 22001–22050 used for generic parameters (reused in
multiple interfaces).
 22051–28999 reserved in blocks for each interface (i.e.
Agievision is 22051–22100)
29999 Tool inspection comment (see special instructions in Lathe
tool inspection comments on page 57)
Direct access to NCI lines—Not only can you use the opinfo function to read the 20000s
lines from your NCI file, but you can also use it to access other NCI lines as well.
Beginning in Mastercam 2017, you can use opinfo to read any NCI line numbered 950 or
higher.
On the surface, this might not seem to have much value, since all of these values are—by
definition—stored in predefined variables, and can be directly accessed that way.
However, the opinfo function lets you easily access those values for other operations
besides the current one. This lets you, for example, directly compare the value from the
current operation to the previous or next operation without having to store or buffer the
value from operation to operation.
The example Getting a single number from a 20000s line or an NCI line (rparsngl) on page
13 shows how to do this, but you should understand that in any of the examples in this
section, you can substitute any NCI line 950 or higher anywhere that you see a 20000s
line used.
NOTE: This use of the opinfo function is limited to the tool change block of NCI lines.
Typically, this is the block of NCI lines from the 999 line to the first tool change line
(1000/1001/1002).
Accessing buffered comments—MP maintains a separate buffer of comments from the

20000s lines. Traditionally, the pparameter$ postblock has been used to read comments
from this buffer. Since pparameter$ is no longer otherwise necessary for accessing
parameters, Mastercam 2017 includes a new postblock—pnci20000$—that can be used
for this purpose. See Using pnci20000$ to access buffered comments on page 53.

Capturing a string from a 20000s line

Use the opinfo function to capture strings that are written out to the NCI file on 20000s
lines. See also Using pnci20000$ to access buffered comments on page 53 to for more
information about accessing 20000s lines. Contents
How do I...?
Capture a string from a 20000s line
1. Go to the NCI Reference volume to find the number of the 20000s line with the
desired string.
2. Define a string variable to store the value.
s_my_string : "" # Stores the string
this:
s_my_string = opinfo(2xxxxx, 0)
where 2xxxx is the actual NCI line number and s_my_string is the variable that
you defined in step 2.
Using 0 as the value of the second argument tells MP to get the value from the
current operation, but you can configure this value to search other operations.
See for Selecting the operation to query on page 15 for details.
4. Repeat steps 1–3 for each individual string that you wish to capture.
Example
Getting a string from a 20000s line
This example shows how to get the name of the tool plane from the 20012 line for
the current and next operation.
stool_plane # Define a string for current operation
stool_plane_next # Tool plane for next operation
p_get_my_parameter # Any postblock where you need the value

stool_plane = opinfo(20012, 0)
stool_plane_next = opinfo(20012, 1)

Capturing numeric values from a 20000s line

Recall that 20000s lines can contain a series of values, which can be either integer or real
values. In this case, the value returned by opinfo will be a string that contains a series of
values separated by spaces. For example, this is what is written to the NCI file for a 20004 Contents
line (20004 contains tool definition parameters):
20004
1 10 0 0 0.2 0. 0. 45. 1 1 0. 0. 0. 0 8 4
To use these values, you must capture the string and pull out the desired values. There
are separate functions for each of the following tasks:
 capturing all of the values from the string
 capturing a single value from the string
 capturing a range of values from the string
Each is described in the following examples.
NOTE: The functions to capture a single parameter and a range of parameters were
introduced in Mastercam X3 and do not apply to older posts.
How do I...?
Store all the parameters from a 20000s line in an array
Use the rpar function to retrieve all the parameters from a 20000s line. It will store
them in an array of user-defined variables.
1. Go to the NCI Reference volume to find the desired 20000s line.
a. Look up the desired 20000s line number.
b. See how many values are included in the output string.
2. Create a series of unique, user-defined numeric variables to store the results—

one variable for each value in the string.
# User-defined numeric variables
# (This creates an implied array)
var1 : 0
var2 : 0
var3 : 0
var4 : 0
var5 : 0
3. Go to the postblock where you want to retrieve the values, and nest the opinfo
function inside the rpar function to retrieve the values, pointing it to the first
variable in the list:
var1 = rpar(opinfo(2xxxxx, 0), 5)
where:
 2xxxx is the actual number of the 20000s line
 var1 is the first variable in your array
 5 is the number of variables in the array

Example
Capturing all the values from a 20000s line (rpar)
Contents
This example uses rpar to get the aggregate head parameters from the 20008 line.
There are 9 values output with this particular line.
# Numeric variables to hold '20008' agg head parameters
# Do NOT change the order of these (9) variable definitions !
hd_ax_x : 0 # Head axis in X

hd_ax_y : 0 # Head axis in Y
hd_ax_z : 0 # Head axis in Z
hd_body_typ : 0 # Head body type
hd_body_dia : 0 # Head body diameter
hd_body_len : 0 # Head body length
stat_body_typ : 0 # Station body type
stat_body_dia : 0 # Station body diameter
stat_body_len : 0 # Station body length
p_get_my_parameter # Any postblock where you need the values

hd_ax_x = rpar(opinfo(20008, 0), 9)
How do I...?
Capture a single parameter from a 20000s line
Use the rparsngl function to retrieve a single parameter from a 20000s line. It will
be stored in a user-defined variable.
NOTE: This procedure is used for retrieving a numeric value. To capture a string, see
Capture a string from a 20000s line on page 10.
b. Identify which parameter in the string contains the desired value.
2. Create a numeric variables to store the value.

# User-defined numeric variable
var1 : 0 # parameter value
3. Go to the postblock where you want to retrieve the values, and nest the opinfo
function inside the rparsngl function, pointing it to the variable you defined in
step 2:
var1 = rparsngl(opinfo(2xxxxx, 0), 5)
where:
 2xxxx is the actual number of the 20000s line, or any NCI gcode
numbered 950 or higher.
 5 is the location of the value in the parameter string

Example
Getting a single number from a 20000s line or an NCI line
Contents
(rparsngl)
This example uses rparsngl to get the station body length from the 20008 line
(aggregate head parameters) for both the current and previous operations.
This example also gets the head number from both operations. The head number of
the current operation is available as parameter 14 on the 1016 line, which is stored
in the lstation$ predefined variable. To get the value for the previous operation,
you can use opinfo to directly query that operation’s 1016 line.
gauge_length : 0 #Station body length
gauge_length_old : 0 #Value from previous operation
lstation_old : 0 #Value from previous operation

gauge_length = rparsngl(opinfo(20008, 0), 9)
gauge_length_old = rparsngl(opinfo(20008, –1), 9)
lstation_old = rparsngl(opinfo(1016, –1), 14)
How do I...?
Capture a range of parameters from a 20000s line
Use the rparsprm function to retrieve a range of parameters from a 20000s line. For
example, if there are 9 parameters in a 20000s line, you can use this function to
capture parameters 3–7. The values will be stored in an array of user-defined
variables.
Note that the rparsprm function depends on sparameter$ as a helper variable, so
to use rparsprm successfully, you will need to use opinfo to set sparameter$.
Follow these steps:
b. Identify which parameters in the string contain the desired values. These
should be a continuous block of values.
2. Create a series of unique, user-defined numeric variables to store the results—
one variable for each value in the range that you are capturing.
var1 : 0
var2 : 0
var3 : 0
var4 : 0
var5 : 0
3. Go to the postblock where you want to retrieve the values, and use the opinfo
function to set sparameter$.
sparameter$ = opinfo(2xxxxx, 0)
where 2xxxx is the actual number of the 20000s line.

4. Use the rparsprm function to retrieve the values, pointing it to the first variable
in the list:
var1 = rparsprm(x, y)
where: Contents
 x is the index position of the first parameter in sparameter$ that you
want to retrieve.
 y is the total number of parameters to retrieve. This should equal the
number of variables that are defined in your array.
Example
Getting a range of numbers from a 20000s line (rparsprm)
This example uses rparsprm to get the fourth through seventh values from the
20007 line. Using rpar, you would have needed to define seven variables to store all
seven values. Using rparsprm, you only need to define variables for just the four
values that you want to retrieve.
tl_shoulder_length : #Shoulder length
tl_arbor_diam : #Arbor diameter
tl_holder_diam : #Holder diameter
tl_holder_length : #Holder length

sparameter$ = opinfo(20007, 0)
tl_shoulder_length = rparsprm(4, 4)
Getting enhanced tool table values

In addition to the operation parameters and NCI data that have been available in past
versions of Mastercam, you can use the opinfo function directly access the new data
objects that have been created to support the enhanced tool table routines in Mastercam
2017.
You can use the opinfo if you need to access this data anywhere in your post outside of
ptooltable$ (or a postblock called from it). Use a statement of the following form
var = opinfo(n, 0)
where var is the name of a numeric variable to store the value, and n is a number from
1—106 that represents an enhanced tool table parameter.
See the Working with enhanced tool tables application guide for complete information
about using these variables.

C. Selecting the operation to query

Most of the opinfo examples in the preceding sections have targeted the current Contents
operation. These are simplest form of the function:
return = opinfo(param, 0)
where param is the number of the parameter that you are looking for; the second
argument is 0; and the third argument is omitted, because it is not necessary.
However, recall that the full form of the opinfo function is:
return = opinfo(param, source_op, mode)
You can configure the source_op and mode values so that you can query almost any
operation in your part file—even operations that do not have a tool change—no matter
what operation is currently being processed. You can even query operations that have
not been output in the NCI file—see mode nnn1 in the table below.
The mode value is a four-digit “license plate” value that tells MP what the the source_op
value is pointing to. The following tables explain in detail how the mode value is used. If
the mode value is omitted, it has the same effect as effect as mode = 0000.
Table 1: opinfo “mode” selection: 1s digit

Value of “mode” How it affects “source_op” argument
nnn0 In this mode, the value of “source_op” is an offset from current operation.
 0 = query current operation
 1 = query next operation
 –1 = query previous operation
 other positive value = look ahead by that many operations
 other negative value = look backward that many previous operations
The sequence of operations = those operations for which a 1000/1001/1002
line exists in NCI file.
nnn1 In this mode, the value of “source_op” is the operation ID (op_id$ value).
Note that you can use this mode to query operations that have not actually
been output to the NCI file—for example, stock model operations, or
operations that have not been selected for posting.
nnn2 In this mode, the value of “source_op” is the stream sequence. The sequence
of operations = those operations for which a 999 line exists in NCI file. This
lets you query operations for which no tool change exists, such as probing,
manual entry, or POCO operations.

Value of “mode” How it affects “source_op” argument
nn0n In case of nested or transform operations, query the source operation. Note
that you can query enhanced tool table parameter 2 or 105 for a non-zero value
to see if the transform or nesting parameters exist.
nn1n In case of transform operations, query the transform parameters.
nn2n In case of nested operations, query the nesting parameters.

Value of “mode” Effect
n0nn Do not populate the tt_ enhanced tool table variables.


n1nn Populate the tt_ enhanced tool table variables.
Contents
0nnn Normal processing.
1nnn Enable multiple processing for multiple instances of the specified “param”
value. Helper variable t1$ stores the count of which instance is being
processed. Use this in a “while” loop that is linked to t1$ value.
This is only effective when 1s digit = 1 (“mode” = nnn1).
Note that in any of the query modes, if you are querying an operation that does not
exist—for example, you are looking ahead one operation, but the current operation is
already the last one—opinfo will return either a string –99999 or numeric value –99999,
depending on your return type.
See the Working with enhanced tool tables application guide for more information about
using the tt_ variables.
Testing if an operation has a tool table record

The opinfo function include a special mode that you can use to query whether an
operation has a NCI 1000/1001/1002 line. To do this, set the param value (the first
argument) to 0. For example,
return = opinfo(0, op_id$, 1)
This only works when the mode value (argument 3) is 1 or 2. In other words, you need to
identify the operation by either its operation ID or stream sequence.
The return value will be 1 if a tool table record (NCI 1000/1001/1002) is found, otherwise
0.

rev. May 15, 2016 BUILDING PARAMETER TABLES WITH FPRM  17
3. Building parameter tables with Contents
fprm
MP includes a parameter table function that lets you efficiently extract several
parameters and store them in a table. Use the fprm command to retrieve values for all of
the parameters in a single statement. The fprm command is used together with the
fprmtabl statement. They work together like this:
 Use the fprmtabl statement to create and name the table where the parameter
values will be stored.
 Use the fprm command to get the actual parameter values from your part file
and place them in the table.
In addition to accessing operation parameters, you can also use this technique to build
tables of machine definition, control definition, or machine group parameters.
The general form of the fprm command is:
return = fprm(table_num, param_type, mode)
where:
return = 0 if the parameter table is not found, otherwise 1.
table_num = the number of the parameter table whose values you are populating.
This is always required.
param_type indicates the type of parameter you are searching for:
 0 = operation parameters (10000–16999, 40000+)

 1 = machine definition parameters (17000–17999)
 2 = control definition parameters (18000–18999)
 3 = machine group parameters (19000–19999)
mode = is an optional value that can be used when getting operation or machine
definition parameters.
 For operation parameters, (param_type = 0), use the mode value to specify
the type of source operation:
 0 (or omitted) = regular operation.
 1 = get values from a transform operation.
 2 = get values from a nesting operation.
 For machine definition parameters, (param_type = 1), set the mode= 0 to
query general or overall machine properties. Otherwise, set the mode to the
entity ID of the specific axis combo or component whose parameters you
want to query.

NOTE: It is your responsibility to make sure that the parameter numbers in your
fprmtbl table make sense for the param_type value in the fprm statement. For
example, if the fprmtbl table contains the numbers of 17000-series machine
definition parameters, but param_type = 2 (for control definition), your parameter Contents
table will not be populated with any values.
In Mastercam 2017, you can use the fprm command in any postblock. Note that
operation parameters for the first operation are available in the pprep$ postblock;
parameters for subsequent operations are available when the tool change gcodes have
been read from the NCI file. When you are using tlchng_aft$ = 2, operation parameters
are available in ptlchg1002$.
You can also use fprm during enhanced tool table processing. When calling the tool
table, as MP iterates through the list, it increments the operation so that calls to fprm will
refer to that specific operation.
Please be aware that if you call fprm during any of the following postblocks, it will
automatically trigger “X9-style” processing.
 pparameter$
 pmachineinfo$
 pwrtt$
 pwrttparam$
 any postblock that is called from one of these
Typically there is no reason for you to include these postblocks in your Mastercam 2017
post except for backwards compatibility. If that is the case, please see the Working with
tool and operation parameters—X9 and earlier posts application guide for how to support
older posts.
The param_type and mode arguments were introduced in Mastercam 2017 to support
the ability to use fprm in any postblock. If your post still uses the X9-style processing—
meaning that fprm is only used in the traditional postblocks—these arguments can be
omitted. In this case, you only need to include the table_num argument.
How do I...?
Build a table of parameter values
Follow these steps to build a table of parameter values with a single function call.
1. Define a set of variables to hold the desired parameter values. These can be
strings, numeric variables, or any combination.
2. Define an additional numeric variable to hold the result of the fprm command.
Note that this is only a success or fail value, not the value of any specific
parameter.
Your set of variables should look something like this:
string1 : "" # User-defined string variables
var1 : 0 # User-defined numeric variables
var2 : 0
var3 : 0
result : 0 # Variable to hold fprm return value

3. Use the fprmtbl command to define the table.

a. On the first line, place the fprmtbl command followed by a number that
identifies the table, and another number that indicates how many
parameters are in the table. Contents
b. On the next lines, list the parameter numbers you want to capture, followed
by the name of the variable where the value will be stored. Indent each line.
For example:
fprmtbl 101 4 # Table of operation parameters
10094 string1 # Tool description
10002 var1 # Tool Number
10003 var2 # Tool Dia. Offset Number
10004 var3 # Tool Length Number
NOTE: Each type of parameter—operation, machine definition, control defintion,

and machine group—needs to be its own table, with a separate fprmtbl declaration.
For example, you cannot combine machine definition and control defintion
parameters in the same table.
TIP: If you will be getting parameters for different machine components, the best
practice is to create a separate table for each component or axis combination.
4. In the postblock where you want to access the parameter values, place the fprm
command. Include the following:
 The number of the table, as defined in the fprmtbl statement.
 The code that indicates the type of parameter you are retrieving (0–3). This
example retrieves operation parameters (type 0) and places them in table
number 101:
p_mypostblock
result = fprm(101, 0)
 If you need to access machine definition parameters, you will typically need
to include the third argument as described above. The next section shows an
example.
Storing parameters by tool_op$ value—A common technique is to define tables of
parameters for different operation types, numbering each table with the tool_op$ of the
operation it refers to. You can then use a statement like this:
p_mypostblock # Any postblock
result = fprm(tool_op$, 0)
to automatically load parameters in the proper table for the current operation.

Example
Building a table of parameter values with fprmtbl & fprm
Contents
The following example builds several parameter tables:
 a table of operation parameters.
 a table of machine definition parameters for a specific component; in this case,
the primary rotary axis component.
 a table of machine definition parameters for settings that apply to the whole
machine.
In this example, entid_pri is the entity ID of the rotary axis component for the
primary rotary axis.
# Operation Parameters
fprmtbl 101 5 # Operation - tool table
1013 sparameter$
10010 xy_stock
10068 z_stock
15346 comp_type
20001 strtool$
# Machine Definition Parameters

fprmtbl 17000 3 # Machine definition - general settings
17022 brk_rot_motion # Break rot motion at combined angle?
17023 brk_rot_angle # Angle for breaking rotary motion
17101 all_cool_off # First coolant off command
# shuts off ALL coolant options
fprmtbl 102 4 # Machine definition - rotary component

17402 rot_ccw_pos # Rotary direction
17408 rot_index # Index or continuous
17409 rot_angle # Index step
17410 rot_type # Rotary type
result : 0 # return value for fprm function
pset_mach #Set post switches by reading machine def parameters

result = fprm (17000, one, zero) # Get general machine params
result = fprm (102, one, entid_pri) # Get rotary axis info
ptooltable$ #Tool table output

if tool_info > one & tt_count$ = one,
result = fprm (101, zero, zero) # Get parameter data
The first fprm call reads general machine definition parameters (in other words,
parameters that are not from a specific component). This is why the third argument
is zero.
The second fprm call needs to read the parameters from a specific component, so
the third argument (entid_pri) is the entity ID of that component. Typically, you
would use the acomboinfo( ) function to get the entity ID; see Getting the entity
ID and querying the axis combination on page 25 to learn more.

The final fprm call gets the operation parameters about a toolpath. This has been
placed in the ptooltable$ postblock so that the data can be written out to the tool
table as ptooltable$ continues.
(The rest of the ptooltable$ postblock has been omitted from this example so you Contents
can focus on the parameter function. An actual ptooltable$ postblock would
have much more code.)

rev. May 15, 2016 WORKING WITH MACHINE DEFINITION, CONTROL DEFINITION, AND MACHINE GROUP PARAMETERS  22
4. Working with machine definition, Contents
control definition, and machine

group parameters
Mastercam includes a group of functions that are designed to let you get parameter
values from your machine definition, control definition, or machine group. For each type
of parameter, there is a specific query function. These functions are similar to the opinfo
function described earlier, which lets you get parameter values from toolpaths and other
operations.
The following sections tell you how to get each type of parameter:
A. Capturing machine definition parameters
B. Getting the entity ID and querying the axis combination
C. Capturing control definition parameters
D. Capturing machine group parameters
A. Capturing machine definition parameters

Use the mdinfo() function get parameter values from the machine defintion. The
general form is:
return = mdinfo(param, component)
where:
return = a numeric or string variable to store the return value. Choose a string or
param = the number of the parameter that you are querying. These will be the
17xxx group of parameters. They are listed in the Operation Parameter Reference.
component = the entity ID or string ID of the specific component or axis

combination in the machine definition: for example, the X-axis component, instead
of the Y-axis or Z-axis component.
 For most uses of the mdinfo function, you can provide either the string ID or
entity ID. See Understanding component IDs on page 25 to learn more.
 Typically, you will use the axiscomboinfo() function to get the ID. See
Getting the entity ID and querying the axis combination on page 25.

 Some parameters—like the General Machine Parameters— apply to the

entire machine, not a specific component. Use a component value of 0 to
query these parameters.
Contents
More specifically, if you look at the Operation Parameter Reference volume, the
parameters in the CNC_MACHINE_TYPE group can be accessed when component
= 0.
The mdinfo function can be used in any postblock.
The mdinfo function was introduced in Mastercam 2017, replacing earlier techniques
that relied on the pmachineinfo$ postblock, rd_md$ command, and rd_mch_ent_no$
helper variable. While those older techniques still work in Mastercam 2017 to maintain
compatibility with older posts, newer posts for Mastercam 2017 and later should
typically be written to use the mdinfo function. See Migrating a post from X9-style to
2017-style on page 61 for more information about implementing mdinfo in an existing
post.
In addition to basic parameter queries, the mdinfo function has two special modes:
 You can use it to query whether a specific type of component—for example, a B-
axis—is included in an axis combination. See Using mdinfo to query for specific
types of components on page 34 to learn more about this application.
 Modes –1 and –2 are parameter dump modes. See Dumping all the parameters:
outputting all the parameter values on page 48 to learn more.
How do I...?
Get a machine definition parameter
Follow these steps to get single machine definition parameters. If you want to get
many parameters, consider building a table; see Build a table of parameter values
on page 18.
1. Go to the Operation Parameter Reference volume to look up the desired
parameter number.
Use the Machine definition: visual reference section to see pictures of all the
dialog boxes with the parameter numbers noted. This is typically the easiest way
to find the parameter you need.
2. Create a user-defined variable to store the parameter value.
3. Figure out if the parameter that you want to get belongs to a specific
component; if so, you will need to get the entity ID or UID of the component. See
Getting the entity ID and querying the axis combination on page 25.

this:
my_var = mdinfo(17xxx, component)
where 17xxx is the actual parameter number. Use a component value of 0 to Contents
query the general machine parameters, otherwise set this to the entity ID or
UID of the desired component or axis combination.
Example
Getting a general machine definition parameter
The following example gets the state of the First coolant off… option. Since this is
part of the General Machine Parameters, set the component value to 0.
all_cool_off : 0 # First coolant off command shuts off

# ALL coolant options
p_my_postblock # Any postblock where you need this data

all_cool_off = mdinfo(17101, 0)
Example
Getting a parameter from a specific machine definition
component
The following example gets minimum Z-axis travel limits (inch and metric values)
for the current axis combination. These are parameters 17719 (inch) and 17721
(metric) for a linear axis.
To get the entity ID of the Z-axis component, first use acomboinfo in mode 1. This
returns the entity IDs for X-Y-Z-A-B-C axes in that order and stores them as an array.
Note that you should define variables for all six axes as shown; because acomboinfo
will return an array of six values, this will prevent one of the values from
unexpectedly overwriting another variable.
entid_x : 0 # entity ID of X axis for current axis combo
entid_y : 0 # entity ID of Y axis for current axis combo
entid_z : 0 # entity ID of Z axis for current axis combo
entid_a : 0 # entity ID of A axis for current axis combo
entid_b : 0 # entity ID of B axis for current axis combo
entid_c : 0 # entity ID of C axis for current axis combo
z_min_inch : 0 # inch travel limit

z_min_mm : 0 # metric travel limit

entid_x = acomboinfo (1, syncaxis$) # Get array of entity IDs
z_min_inch = mdinfo(17719, entid_z) Contents
z_min_mm = mdinfo(17721, entid_z)
Note that the ID for the current axis combination is typically available as the
syncaxis$ value, but only after the NCI 950 has been read. If you need it before that
line is read—for example, if you are calling the postblock from pprep$—you can use
the opinfo function to query the enhanced tool table value 8:
syncaxis$ = opinfo(8, 0, 0)
When you do this, MP interprets the “current operation” as the first operation in the
NCI file, but you can use the opinfo function to access other operations as well. See
Selecting the operation to query on page 15 to learn more.
B. Getting the entity ID and querying the axis combination

Unless you are querying the general machine parameters:
most likely you will need to target a specific component and include its ID in your
parameter query.
Specifically, if you look at the Operation Parameter Reference volume, the parameters in
the CNC_MACHINE_TYPE group can be accessed when component = 0. Any other
parameter query will need to include the entity ID.
Use the axiscombo() function to query the machine definition and find out the entity
IDs for individual components.
Understanding component IDs

Every component and every axis combination in your Mastercam machine definition
has two IDs:
 a number, called the entity ID
 a string, called the UID (or sometimes just “the string ID”)

You can see these IDs in the NCI file. The IDs for each component are written out on the
20600 lines. The IDs for each axis combination are written out on the 20601 line. The first
parameter is the numeric entity ID, and the second is the string ID.
Contents
You can use either ID in the axiscombo function to specify the component. Which one
you use depends on your circumstances:
 The entity ID will change if you add, remove, or rearrange components in your
machine definition.
 The string ID does not change.
Typically the entity ID will be the easiest to use, and is used in most of the examples in
this book, but if you really want to be sure that you are referring to a specific
component—in other words, this specific A-axis component, and not some other A-axis
component—the string ID gives you this capability.
In the above picture, the A-axis component has entity ID 160. However, it is important to
understand that the entity ID of a component will not only be different from machine to
machine, but might also vary within a Mastercam session. If a component with entity ID
160 does exist at all, it could be an X-axis component, a chuck, a tool, or any other
component.
IMPORTANT: If you are using the entity ID to access machine components, never
“hard-code” the entity ID in your post. Always retrieve it from the machine definition,
then pass it to the desired function.
The axiscombo function can return either the numeric entity IDs or the string IDs: MP
will automatically select which ID to return based on the type of your return variable. You
can also use the uidinfo function to query the 20600 lines based on the entity ID, and
return either the string ID or any of the other parameters on the 20600 line. The general
workflow is, first use the axiscombo function to get information about which
components are present and their entity IDs, then use the uidinfo function to query the
proper 20600 line.

Using the acomboinfo function

Use the acomboinfo() function to:
 get information about the current axis combination.
Contents
 query the NCI 20601 lines (similar to the way uidinfo queries the 20600 lines).
 build arrays of information about the axes on your machine tool and how they’re
laid out.
The most common use of this function is to get the entity IDs of the linear and rotary axis
components in the axis combination. This lets you learn which components are present
in the machine definition and lets you identify the specific components whose
parameters you want to query.
The acomboinfo function has several different function states. Each state is designed to
answer a specific type of question. Whenever you call the acomboinfo function, you
need to specify the function state and the axis combination you are querying.
General form:
return = acomboinfo(function_state, axis_combo)
where:
return = numeric or string variable to store the return value. For most function
states, this will be an entity or string ID. Mastercam will automatically return either
the numeric entity ID or the string UID depending on the type of variable you use
for return.
function_state = a number that tells MP what information you are looking for.
See Using function states to build specific queries on page 30 for a reference listing
of all the options.
axis_combo = the ID of the axis combo that you are querying. You can use either
the numeric entity ID or the string ID.
In most cases, the process of using acomboinfo to drill down to specific components
begins with the entity ID of the current axis combo. This is output on the NCI 950 line
(parameter 4) and is available as the syncaxis$ variable. This variable stores the
numeric entity ID of the axis combo for the current operation. Many times you will
simply use syncaxis$ as the second argument in the acomboinfo function call,
particularly when using function states 5–9.
Note that the syncaxis$ value is only available after the NCI 950 has been read. If you
need it before that line is read—for example, if you are calling the postblock from
pprep$—you can use the opinfo function to query the enhanced tool table value 8:
syncaxis$ = opinfo(8, 0, 0)
See Using acomboinfo before the NCI is read on page 30 for an example of this technique.

Returning arrays of component information

Probably the most important and common use of the acomboinfo function is using it to
return an array of the six axis components in the current axis combination: X, Y, Z, A, B, C.
You can choose to return the array in either of two forms: Contents
 An array where the entity IDs are presented in a fixed order X-Y-Z-A-B-C. For
example:
If a component is present in the axis combination, its entity ID is stored in the

array; if a component is not present in the axis combination, Mastercam returns
the default entity ID for that component type:
 X axis: –1
 Y axis: –2
 Z axis: –3
 A axis: –4
 B axis: –5
 C axis: –6
 An array where the entity IDs are arranged in the order in which they are
“stacked” in the machine definition component tree. For example:
If there are fewer than six axis components, the end of the array is padded with
zeros.
In either case, the return argument for the acomboinfo function should be the first
variable in the array.
Component stacking order—The second array deserves some more explanation. If you
look at the component tree in the Machine Definition Manager, “stacking order” is
interpreted as the sequence of components that you encounter as you move in a circuit

from the part (in this case, the Stock or Machine Table components) to the tool (in this
case, the Tool Spindle component).
Contents
Follow this general workflow:

 First, define an array of six variables.
 Then, when you use the acomboinfo function, use the first variable in the array
as the return variable.
 Use function state 1 to return the axis components in X-Y-Z-A-B-C order:
var_1 = acomboinfo(1, axis_combo)
 Use function state 2 to return the axis components in the order in which
they are laid out in the machine component tree:
var_1 = acomboinfo(2, axis_combo)
Remember that you can use the acomboinfo function in any postblock.
See also Using function states to build specific queries on page 30 for more uses of the
acomboinfo function.
Example
Retrieving an array of component information
This example builds an array to store the entity IDs for all the axis components. It
then uses acomboinfo with function state 1 to populate the array. Finally, it uses
one of the stored entity IDs to get some specific parameter values—in this case, min
and max Z-axis travel limits.
# Define array for acomboinfo return values
ent_id_x : 0 # Entity ID of X-axis component
ent_id_y : 0 # Entity ID of Y-axis component
ent_id_z : 0 # Entity ID of Z-axis component
ent_id_a : 0 # Entity ID of A-axis component
ent_id_b : 0 # Entity ID of B-axis component
ent_id_c : 0 # Entity ID of C-axis component
# Define variables to store parameter values

z_lim_min : 0 # Z-axis travel limit (min)
z_lim_max : 0 # Z-axis travel limit (max)


ent_id_x = acomboinfo(1, syncaxis$) # populate array
z_lim_min = mdinfo(17723, ent_id_z) # get min limit
z_lim_max = mdinfo(17724, ent_id_z) # get max limit Contents
If you wish, you could modify this logic to test if ent_id_z was not equal to –3 (the
default entity ID) before using calling mdinfo.
Example
Using acomboinfo before the NCI is read
This example reads the axis combo information from the pprep$ postblock, before
the NCI is read. Because the NCI 950 line has not yet been read, syncaxis$ has not
been set, so the value is read directly from the enhanced tool table data using the
opinfo function.
The final line sets a switch to indicate if a Y-axis component is present. For any
component, all you need to do is check the array to see if that value is greater than 0;
if it is, that means that acomboinfo returned an actual entity ID instead of the
default entity ID for that component.
pprep$ #Pre-process postblock

pset_mach
pset_mach # User-defined postblock to set machine switches

syncaxis$ = opinfo (8, 0, 0) # Get the axis combo ID
acombo_x = acomboinfo (1, syncaxis$) # Build axis array
# Test if a Y-axis component was read
y_axis_mch = fsg((acombo_y > 0), yes$, no$)
Using function states to build specific queries

The acomboinfo function supports many different types of queries. Recall the general
form of the function:
return = acomboinfo(function_state, argument)
The table below describes how to use each function state.
Table 5: Function states for acomboinfo
Function Return value

Purpose of query Value for argument 2
state # (success / failure)
Get the numeric entity ID of the axis combination, 0 Number. String ID of axis combo.
based on the string ID. Failure value = –999999.0


Contents
Build X-Y-Z-A-B-C array of axis component IDs 1 Value of first variable in array. Entity ID or string ID of axis
(numeric values) given the ID of the axis combo. On failure, the array is populated combo.
with default entity IDs.
Build array of axis component IDs as stacked on 2 Value of first variable in array. Entity ID or string ID of axis
machine, given the ID of the axis combo. See On failure, the array is populated combo.
Component stacking order on page 28. with default entity IDs.
Get the string for the user-defined description of the 3 String. Failure makes no change. Entity ID or string ID of axis
axis combination. This is parameter 4 from the combo.
20601 line.
Indicates if the direction of the axis combination 4 Returns the first variable in a Entity ID or string ID of axis
matrix vector is reversed relative to the world three-variable array (X-Y-Z). combo.
coordinate matrix. Value is 0 if the direction is same
as world coordinates, or 1 if
reversed.
Find out the axis of rotation for the primary, 5 Returns the first variable in a Entity ID or string ID of axis
secondary, tertiary rotary axes; in other words, find three-variable array, in which the combo.
out the linear axis about which each rotary axis first variable indicates the axis of
rotates, in terms of the axis combination matrix. rotation for the primary rotary
axis; the second and third
variables indicate this for the
secondary and tertiary axes.
Value is 0=X, 1=Y, 2=Z
Find out if each rotation axis is head-type. 6 Returns the first variable in a Entity ID or string ID of axis
three-variable array, in which the combo.
first variable indicates the type
of A axis, second is B, and third
is C. Value = 1 for head-type
rotation, otherwise 0.
Find out which rotary axis is the primary, 7 Returns the first variable in a Entity ID or string ID of axis
secondary, and tertiary rotary axis. three-variable array, in which the combo.
first variable indicates the
primary rotation axis; the second
and third variables indicate the
secondary and tertiary axes:
0=A, 1=B, 2=C
The number of linear axes in the axis combination. 8 Number. Entity ID or string ID of axis
combo.
The number of rotary axes in the axis combination. 9 Number. Entity ID or string ID of axis
combo.
The string ID of the axis combination, given the 10 String. Entity ID of axis combo.
entity ID.
The number of axis combinations in the NCI file (in 11 Number. Entity ID or string ID of axis
other words, how many 20601 lines there are). combo.


Contents
Get entity ID of component in axis combination. 17683 to Number for 17683–17695; Entity ID or string ID of axis
17696 string for 17696. combo.
This function state is a special case: the first
argument is the number of the parameter that is
linked to a pre-built array of axis combination
components. See Getting entity IDs for any
axis combo component on page 33.

Getting entity IDs for any axis combo component

Machine definition parameters 17683–17694 constitute a pre-built array of entity IDs for
each component in the axis combination. Querying one of these parameter numbers
returns the entity ID of that component. This is an alternative to using Array 2 from Contents
Returning arrays of component information on page 28. The difference is that this
function returns any component in the axis combination, not just linear/rotary axes.
To use this function state, simply specify the parameter number from Table 6 as the first
argument in the acomboinfo function.
For example:
my_component_id = acomboinfo(17687, syncaxis$)
would return the entity ID of the 4th component in the current axis combination.
Table 6: Parameter values for function state 10
Parameter value Parameter description
17683 Axis combo ID
17684 Component entity ID of first component in axis combo
17685 Component entity ID of second component in axis combo
17686 Component entity ID of next component
17694 Axis combination user description
The following output shows typical values from this function.

17683 50
17684 5
17685 4
17686 12
17687 13
17688 14
17689 15
17690 17
17691 0
17692 0
17693 0
17694 0
17695 0
17696 Right/Lower

If the component does not exist, the parameter will have a value of 0.
Using mdinfo to query for specific types of components

The mdinfo() function has a special mode that lets you query whether a component of a Contents
specific type—for example, a B-axis component—is present in an axis combination. If
the component is present, Mastercam will return its entity ID. Use a statement of this
form:
return = mdinfo(0, axis_combo, component_type)
where:
return = a numeric or string variable to store the return value. Use a string variable
if you want to get the string UID, or a numeric variable to get the numeric entity ID.
 If no component of that type is present, the function returns –99999. (If you
are using a string variable for a return, it will return “–99999” as a string.)
axis_combo = the ID of the axis combo that you are querying. You can use either
the string UID or numeric entity ID.
component_type = the component type code from the table below.
Table 7: Component type codes for mdinfo
Code Component type
–6 X axis
–5 Y axis
–4 Z axis
–3 A axis
–2 B axis
–1 C axis
100 Rectangular table
101 Round table
102 Wire table
103 Fixture
104 Vise
105 Vise jaws
106 Chuck
107 Chuck jaws
108 Collet
200 Tool locator
201 Tool
202 Drill block station

Table 7: Component type codes for mdinfo
Code Component type
203 Multi-head component Contents
204 Piggyback multi-head
205 Wire upper guide
206 Wire lower guide
207 MD tool locator
301 Tool spindle
302 Multi-tool component
303 Turret
304 Aggregate head
305 Drill block
306 Gang tool block
400 ATC
401 Tailstock
402 Lathe center
403 Steadyrest
Using the uidinfo function

Use the uidinfo function to get information about specific components from the NCI
20600 lines as well as other properties.
The most common use of this function is to get the axis label and selected other
properties of the component. For properties that are available with this function, using
the uidinfo function can be easier and more straightforward than querying the
parameter number. See Figure 1-1 on page 36 and Figure 1-2 on page 37 to see which axis
properties can be queried with the uidinfo function. You can use the uidinfo function
in any postblock where you need the information.
return = uidinfo(function_state, component_ID)
where:
return = numeric or string variable to store the return value. Select a string or
numeric variable depending on what type of return data you are expecting.
function_state = a number that tells MP what information you are looking for.
Table 8 on page 36 lists all of the function states.
component_ID = the ID of the component that you are querying.

The table below describes how to use each function state.
Table 8: Function states for uidinfo
Function Return value Contents

Purpose of query Expected for argument 2
Get the numeric entity ID of the component, based 0 Number. String ID of component.
on the string ID. Failure value = –999999.0
Get the string for the component’s absolute axis 1 String with axis label. String ID or numeric entity ID
label. On failure, there is no change in of component.
the value of the return variable.
Get the string for the component’s incremental axis 2 String with axis label. String ID or numeric entity ID
label. On failure, there is no change in of component.
the value of the return variable.
Get the string for the user-defined component 3 String. On failure, there is no String ID or numeric entity ID
name. change in the value of the return of component.
variable.
Get the state of the diameter output option. 4 1 if diameter option is selected. String ID or numeric entity ID
of component.
Get the positioning type for a rotary axis 5 0 if not a rotary axis; String ID or numeric entity ID
component. 1= signed continuous; of component.
2 = 0–360, shortest distance;
3 = 0–360, signed direction.
Negative value for reversed
Get the string ID of the component, based on the 6 String. On failure, there is no Numeric entity ID of the
numeric entity ID. change in the value of the return component.
variable.
Figure 1-1: Linear axis properties available with uidinfo

Figure 1-2: Rotary axis properties available with uidinfo
Contents

Example
Using the uidinfo function to get axis labels
Contents
This example uses the uidinfo function to query the absolute and incremental axis
labels for the X-Y-Z-C axes in the current axis combination. First, the acomboinfo
function is used to retrieve the entity IDs for all the axes. These are stored in an array
beginning with ent_id_x. Then the uidinfo function reads the axis labels for each
component. If no entity ID is actually stored in the array for that axis, a default
string is assigned.

# Get the entity IDs for current axis combo
ent_id_x = acomboinfo(1, syncaxis$)
# Get the abs & inc labels for each axis

# If no entity ID is stored in the array, assign default value.
if ent_id_x > 0,
[
str_x_out_abs = uidinfo(1, ent_id_x)
str_x_out_inc = uidinfo(2, ent_id_x)
]
else, str_x_out_abs = "X", str_x_out_inc = "U"
if ent_id_y > 0,
[
str_y_out_abs = uidinfo(1, ent_id_y)
str_y_out_inc = uidinfo(2, ent_id_y)
]
else, str_y_out_abs = "Y", str_y_out_inc = "V"
if ent_id_z > 0,
[
str_z_out_abs = uidinfo(1, ent_id_z)
str_z_out_inc = uidinfo(2, ent_id_z)
]
else, str_z_out_abs = "Z", str_z_out_inc = "W"
if ent_id_c > 0,
[
str_c_abs = uidinfo(1, ent_id_c)
str_c_inc = uidinfo(2, ent_id_c)
]
else, str_c_abs = "C", str_c_inc = "H" #Use defaults

C. Capturing control definition parameters

Capturing control definition parameters is typically easier than machine definition Contents
parameters, since you do not have to worry about individual components. Use the
cdinfo() function to get the parameter values. The general form of the function is:
return = cdinfo(param)
where:
 param = –1 triggers parameter dump mode. See Dumping all the parameters:
The cdinfo function can be used in any postblock.
The cdinfo function was introduced in Mastercam 2017, replacing earlier techniques
that relied on the pmachineinfo$ postblock and rd_cd$ command. While those older
techniques still work in Mastercam 2017 to maintain compatibility with older posts,
newer posts for Mastercam 2017 and later should typically be written to use the cdinfo
function. See Migrating a post from X9-style to 2017-style on page 61 for more
information about implementing mdinfo in an existing post.
How do I...?
Get a control definition parameter
Follow these steps to get a single control definition parameter. If you want to get
many parameters, consider building a table; see Build a table of parameter values
on page 18.
parameter number.
Use the Control definition: visual reference section to see pictures of all the
dialog boxes with the parameter numbers noted. This is typically the easiest way
to find the parameter you need.
this:
my_var = cdinfo(18xxx)
where 18xxx is the actual parameter number.

Example
Capturing control definition parameters
Contents
This example gets several parameters from the control definition. Some are strings
and some are numbers.
ssetup_sheet : "" # String variable for setup sheet string
wear_support : 0 # Does control support wear comp?
rev_wear_support : 0 # Does control support reverse wear comp?

ssetup_sheet = cdinfo(18160)
wear_support = cdinfo(18706)
rev_wear_support = cdinfo(18707)
D. Capturing machine group parameters

Use the groupinfo() function to get parameter values from the machine group settings.
return = groupinfo(param)
where:
 param = –1 triggers parameter dump mode. See Dumping all the parameters:
The groupinfo function can be used in any postblock.
If you are interested in getting parameters for the stock model, remember that stock
models are considered components in the machine definition. This means that
depending on how the stock model is defined—particularly lathe stock models, along
with chuck jaws and tailstock centers—some of the parameters that you are interested in
might need to be accessed as machine definition component properties, instead of
machine group properties.
NOTE: You can only get parameters for stock models that are defined in machine
group properties or as machine definition components. You cannot access
parameters or values from a stock model operation.
The groupinfo function was introduced in Mastercam 2017, replacing earlier

techniques that relied on the pmachineinfo$ postblock and rd_tlpathgrp$ command.
While those older techniques still work in Mastercam 2017 to maintain compatibility
with older posts, newer posts for Mastercam 2017 and later should typically be written to
use the groupinfo function. See Migrating a post from X9-style to 2017-style on page 61
for more information about implementing mdinfo in an existing post.

How do I...?
Get a machine group parameter
Contents
Follow these steps to get a single machine group parameter. If you want to get many
parameters, consider building a table; see Build a table of parameter values on page
18.
parameter number.
Use the Machine group properties: visual reference section to see pictures of all
the dialog boxes with the parameter numbers noted. This is typically the easiest
way to find the parameter you need.
this:
my_var = groupinfo(19xxx)
where 19xxx is the actual parameter number.
Example
Capturing machine group parameters
This example finds the file name of the current machine definition, together with
the name of the machine group and its number.
smd_file_name : "" # Define string variable for name of
# the machine definition file
stp_grp_name : "" # Define string variable for name of
# the machine group
tp_grp_number : 0 # Define numeric variable for the
# machine group number

tp_grp_number = groupinfo(19247)
stp_grp_name = groupinfo(19248)
smd_file_name = groupinfo(19105)

rev. May 15, 2016 DIRECT ACCESS TO MACHINE DEFINITION DATA  42
5. Direct access to machine Contents
definition data
Mastercam 2017 includes a routine that allows MP to set a number of predefined

variables directly from the machine definition. These settings are used for multiaxis or 5-
axis posts. This affects the following variables:
rotaxis1$ pri_limtyp$ matb1$ fr_max_ipm$

rotaxis2$ sec_limtyp$ matb2$ fr_max_mpm$
rotdir1$ pri_limlo$ matb3$ fr_max_ipr$
rotdir2$ pri_limhi$ matb4$ fr_max_mpr$
nut_ang_pri$ pri_intlo$ matb5$ fr_max_ideg$
pri_inthi$ matb6$ fr_max_mdeg$
sec_limlo$ matb7$ fr_max_iinv$
sec_limhi$ matb8$ fr_max_minv$
sec_intlo$ matb9$ fr_min_ipm$
sec_inthi$ fr_min_mpm$
fr_min_ipr$
fr_min_mpr$
fr_min_ideg$
fr_min_mdeg$
fr_min_iinv$
fr_min_minv$
Before Mastercam 2017, variables in the first three columns were typically initialized
manually in the post. The variables in the last column are new for Mastercam 2017;
before Mastercam 2017, post writers typically got these values by capturing machine
definition parameters.
Configuring your post to support these variables—The routine that allows MP to
automatically set these variables needs to be explicitly enabled in your post. This has
been done to support backward compatibility with the many existing posts that explicitly
initialize them. A new predefined variable has been added for this purpose:
x_mp_adv_func$. Simply initialize it to 1 to automatically read the values from the
machine definition:
x_mp_adv_func$ : 1 #Set the 5 axis variables
Typically when you enable x_mp_adv_func$, you will want to remove any lines in your
post that explicitly initialize the above variables. Any initializations that do occur in your
post will override the value that MP calculates from your machine definition.
Note that if a post initialization overrides the machine definition–derived value, MP will
not display a warning or other message. It is your responsiblity to maintain your post
code properly.
Depending on how an existing post is currently written, you may wish to read some
values from the machine definition, and explicitly initialize others. This is allowed.

A. Rotary axis settings

When x_mp_adv_func$ is enabled, the values for rotaxis1$, rotdir1$, rotaxis2$, Contents
and rotdir2$ are calculated from the rotary axis settings that are highlighted in the
following picture.
 rotaxis1$ and rotdir1$ are for the primary rotary axis
 rotaxis2$ and rotdir2$ for the secondary rotary axis.
MP uses the Tilt angle settings for the primary rotary axis to calculate nut_ang_pri$:

MP calculates values for the travel limit variables from the following settings:
Contents
The following variables are calculated from these settings:
pri_limhi$ Positive travel limit
pri_limlo$ Negative travel limit Primary rotary axis
pri_limtyp$ Basic angle range of rotation
sec_limhi$ Positive travel limit
sec_limlo$ Negative travel limit Secondary rotary axis
sec_limtyp$ Basic angle range of rotation

The intersection angles for each rotary axis are read directly from the following settings:
Contents
This applies to the following variables:
pri_inthi$ Intersection angle (max)

Primary rotary axis
pri_intlo$ Intersection angle (min)
sec_inthi$ Intersection angle (max)

Secondary rotary axis
sec_intlo$ Intersection angle (min)

B. Machine matrix
Contents
When x_mp_adv_func$ is enabled, the machine matrix matb1$–matb9$ is read from the
Positive axis direction vector for each linear axis. This is the vector in the picture,
adjusted by the Tilt Angle (if any):
 matb1$–matb3$ are the vector from the X-axis properties page.

 matb4$–matb6$ are the vector from the Y-axis properties page.
 matb7$–matb9$ are the vector from the Z-axis properties page.
In the picture above, (matb1$, matb2$, matb3$) would equal (1, 0, 0). If the –X
orientation was selected, the vector would be (–1, 0, 0).

C. Feed rate settings

Contents
When x_mp_adv_func$ is enabled, MP will read the minimum and maximum feed rate
settings from the machine definition and store them in the following predefined
variables:
Note that the option to use inches/mm per minute or degrees/minute is set in the
control definition.
These variables are new to Mastercam 2017; in previous versions of Mastercam, these
values were typically accessed via the parameter capture routines, as parameter
numbers 17054–17067.

rev. May 15, 2016 ADVANCED TECHNIQUES FOR WORKING WITH OPERATION PARAMETERS  48
6. Advanced techniques for working Contents
with operation parameters
This section discusses several specialized topics and techniques related to reading
parameters.
 A. Dumping all the parameters: outputting all the parameter values
 B. Using pnci20000$ to access buffered comments
 C. Setting options for transform operation parameters
 D. Getting the operation number from Mastercam
 E. Validating parameters with UpdatePost
 F. Lathe tool inspection comments
A. Dumping all the parameters: outputting all the

parameter values
Sometimes it can be difficult to determine exactly which parameter contains the value
that you need for a specific application. Use the techniques described in this section as a
“brute force” approach to isolating the parameter code.
The new query functions introduced in Mastercam 2017 have special “parameter dump”
modes or function states that you can use for this purpose. Mastercam also includes a
special predefined postblock called pdump$ that is automatically called when MP
encounters a parameter dump function call. So to dump the parameters you need to do
two things:
 Insert a line that calls one of the query functions in parameter dump mode.
 Implement pdump$ to output the parameter values.

The following table describes the parameter dump format for each of the query
functions. You need to invoke separate functions to dump each type of parameter
(operation, machine definition, control definition, and machine group):
Table 9: Parameter-dump modes for query functions Contents
Type of query Function format

Dump parameters for a specific operation. return = opinfo( –1, source_op, mode )
See Selecting the operation to query on page 15 to learn
more about using source_op and mode to target the desired
operation.
Dump all operation parameters for all return = opinfo( –2 )
operations.
This will dump parameters for all operations that are selected or
output to NCI.
Note that you can use –1 mode to target any operation, even
operations that are not output to NCI (for example, a stock model
operation, or an operation that has been “ghosted”).
Dump parameters for a specific machine return = mdinfo( –1, component_ID )
definition component.
See Getting the entity ID and querying the axis
combination on page 25 to learn more about using
component_ID to identify the desired component.
Dump all machine definition parameters. return = mdinfo( –2 )
Dump control definition parameters. return = cdinfo( –1 )

Dump machine group parameters. return = groupinfo( –1 )
To implement the pdump$ postblock, all you need to do is insert a line like this:
~prmcode$, ~sparameter$, e$
The prmcode$ variable outputs the parameter number, and sparameter$ outputs the
value of the parameter.
Follow these steps to work through an example.
How do I...?
Dump all the parameters
1. Define a numeric variable that you can use as the return variable for the query
function.
2. Add the pdump$ postblock to your post and include the following line:
pdump$ #Information from parameters
~prmcode$, ~sparameter$, e$
3. Go to the postblock where you want to begin outputting the parameter values
and insert the query functions for the desired parameter type. A typical location
is in pheader$. Use any or all of the following:
 opinfo for operation/toolpath parameters.
 mdinfo for machine definition parameters.
 cdinfo for control definition parameters.
 groupinfo for machine group parameters.

See Parameter-dump modes for query functions on page 49 for details on the
exact form of the function.
4. Create a toolpath of the type that has the parameter you are looking for.
Contents
For example, if you are interested in the parameters for the Stock to leave on
walls and Stock to leave on floors settings for a contour toolpath, create a 2D
contour toolpath with the following settings:
5. For the fields that you are interested in, enter distinctive values that are not likely
to be used anywhere else.
When you look at the NC file created by your parameter-dump .PST file, the
distinctive values that were entered for the two fields should make them easy to
find.
6. Open the NC output file into a text editor and search for the unique values.
Searching for 0.01234 finds this line in the NC file:
prmcode$ 10010. 0.01234
Searching for 0.09876 finds this line in the NC file:

prmcode$ 10068. 0.09876
These are most likely the desired prmcode$ values. These should match the
parameter numbers from the Operation Parameter Reference volume in your
MP_documentation.pdf.
7. To verify that these are the desired values, go back to the Contour parameters
tab in Mastercam and change one of them to a new value. Re-post the operation
and search the NC file for the new value.
If you find the new value with the same prmcode$, you can be confident that you
have found the correct parameter number and that it is being output correctly.
Example
A simple parameter dump post
Contents
The following code sample illustrates a complete parameter dump post for
Mastercam Mill. No other code is required.
[POST_VERSION] #DO NOT MOVE OR ALTER THIS LINE# V19.00 P0 E1 W19.00
T1453128035 M19.00 I0 O0
return : 0
pheader$ # Call query functions
"----- Machine definition parameters -----", e$
return = mdinfo(-2)
" ", e$
"----- Control definition parameters -----", e$
return = cdinfo(-1)
" ", e$
"----- Machine group parameters -----", e$
return = groupinfo(-1)
" ", e$
"----- Operation parameters -----", e$
return = opinfo(-2)
" ", e$
"----- End param dump -----", e$
pdump$ # Output parameter values
~prmcode$ ~sparameter$ e$
Note the product code in the header line (P0). This identifies the post as a Mill post.
Change this code to create a post that will work with other Mastercam products:
 P1: Router
 P2: Lathe
 P3: Wire
 P4: MP-based mill-turn posts (in other words, mill-turn posts for Mastercam
Lathe, not the Mill-Turn product).

Example
Dumping all the rotary axis parameters
Contents
The following example dumps all of the parameters for each rotary axis in the
machine definition. Before dumping the parameters for each axis, the post checks
that a non-default value for the entity ID exists, to make sure that the rotary axis is
present.
# Define array for axis entity IDs
return : 0
pheader
ent_id_x = acomboinfo (1, syncaxis$) # Build axis array
# Get parameters for A axis if it is present
if ent_id_a > 0,
[
"----- A-axis parameters -----", e$
return = mdinfo(-1, ent_id_a)
" ", e$
]
# Get parameters for B axis if it is present
if ent_id_b > 0,
[
"----- B-axis parameters -----", e$
return = mdinfo(-1, ent_id_b)
" ", e$
]
# Get parameters for C axis if it is present
if ent_id_c > 0,
[
"----- C-axis parameters -----", e$
return = mdinfo(-1, ent_id_c)
" ", e$
]
pdump$ # Output parameter values
~prmcode$ ~sparameter$ e$

B. Using pnci20000$ to access buffered comments

For reading comments from the 20000s lines, Mastercam 2017 includes a new predefined Contents
postblock called pnci20000$ as an alternative to the opinfo() function. This is
intended to be a direct replacement for the pparameter$ postblock. This means that—
just like pparameter$—pnci2000$ will be automatically executed by MP for each
operation if it is implemented in your post.
The difference between opinfo() and pnci20000$ is that pnci20000$ will access the
comments as they are buffered by MP instead of trying to read them directly from the
NCI file. While, technically, you can use pnci20000$ to get any other operation
parameter (just like pparameter$ is used in pre-2017 posts), this doesn’t make any sense
for any other parameter except the 20000s-line comments; the opinfo() function is still
the best and most efficient technique for getting any other value.
To use this postblock to get NCI comments, implement it exactly like pparameter$
would have been implemented in an X9 or earlier post. The following code is a typical
example:
stp_name : "" # Define a string for name of toolplane
pnci20000$ # Implement postblock
if prmcode$ = 20013, stp_name = sparameter$

C. Setting options for transform operation parameters

The control definition includes an option that lets you specify which parameters to make Contents
available when you create transform operations:
 parameters for the transform operation
 parameters for the source operation
 both sets of parameters
You can find this setting on the Files page in the Control Definition Manager:
The setting itself is available as parameter 18157.
D. Getting the operation number from Mastercam

Many post writers don’t realize that they have access to the toolpath numbers that are
displayed in Mastercam's Toolpath Manager:
One way to use this information is to output this number as a comment in the NC file.
The following procedure outlines the logic.

How do I...?
Get the operation number from Mastercam
Contents
1. Create and format a variable to hold the number:
op_num : 0 # operation number listed in the tp manager
fmt "" 4 op_num # operation number listed in the tp manager
2. Go to the postblock where you need the information, and get the value of
parameter 15240.
# get operation number listed in the tp manager
op_num = opinfo(15240, 0)
3. Output the comment in your toolchange postblocks—psof$, ptlchg0$, lsof$,

etc.
pbld, n$, `sopen_prn, 'Operation:', no_spc$, op_num, `sclose_prn, e$
This way, if there is a problem in the code, you can immediately identify the source
operation in Mastercam.
Displaying the op_id$ value in Mastercam

Most post developers routinely need to work with the op_id$ value in their posts.
However, it is difficult to know which op_id$ value goes with which operation because
the Operations Manager in Mastercam only displays a sequence number, which is
different than the op_id$:
However, you can use the Display options dialog to “trick” Mastercam into displaying
the op_id$.
Follow these steps:
1. Right-click in the Toolpath Manager and choose Display options.

2. Clear the highlighted settings:
Contents
3. Click OK to return to Mastercam. The op_id$ values will be displayed as shown:
In the Display options dialog box, the List numbers option toggles the type of number
that is displayed. For example, if you go back to Display options and select the List
numbers option, the operations will again be displayed with sequential numbers:
E. Validating parameters with UpdatePost

The UpdatePost C-Hook included with Mastercam typically includes routines that search
for references to specific parameter numbers and validates them against known changes.
If your original post tries to read a parameter with a number that has changed, the
following line will be written to the updatepost.log file:
PARAMETER DATA - - Possibly incorrect parameter number detected:
17665. Please check the parameter number.
When you see this message, look up the parameter number in the Operation Parameter
Reference and make sure that your post is actually referencing the parameter that you
want.

IMPORTANT: UpdatePost only looks at parameter numbers in fprm tables.

Postlines that are inside postblocks—for example:
Contents
pparameter$
if prmcode$ = 10068, z_stock = rpar(sparameter$, 1)
are not validated. If either pparameter$ or pwrttparam$ is used, you will be alerted
so that you can manually check these postblocks.
F. Lathe tool inspection comments

Mastercam X4 introduced a tool inspection feature for lathe grooves. This lets you retract
the tool between depth cuts or between grooves to inspect or change the tool. For
example, in this toolpath, the tool inspection has been programmed between grooves:
The NCI output for this feature has two components.

 The retract move to the inspection position. This is indicated by the same 70000
cur_cflag$ (rpd_typ$ = 7) used for the Mill tool inspection feature in the
surface high-speed toolpaths.
 A comment that is written to the NCI just before the 70000 move. The 29999 NCI
code has been created for this comment.
To implement this feature in your post, therefore, you need to process both elements.
Unlike other 20000s lines, which are written to the NCI before the tool change line, the
29999 is written in the middle of the toolpath, at the point where the tool inspection is to
take place. Importantly, this means that you cannot read this line with the opinfo
function like the other 2xxxx lines. See the Example: Tool inspection postblock for an
example of how to read it.

The following picture shows the NCI for a lathe groove toolpath, with and without the
tool inspection. You can see how the retract move and new codes are implemented.
Contents
The first step in processing the tool inspection move is to trap the 70000 value. This
needs to be done in the entry postblocks for both linear and rapid moves. For posts based
on Mastercam’s generic posts, these are typically prapidout and plinout. The following
example shows how this can be done.
Example
Modifying plinout/prapidout to trap a tool inspection move
The highlighted lines show the new lines that were added to process the flag for a
tool inspection. These lines will trap both mill and lathe tool inspection codes. The
tool inspection code triggers a call to a new postblock, ptool_insp, that will
actually process the move.
prapidout #Output to NC, linear movement - rapid
pcan1, pbld, n$, psgplane, pexct, psgcode, psccomp, pwcs,
pxout, pyout, pzout, pcout, pscool, strcantext, e$
if rpd_typ$ = 7, ptool_insp #Tool inspection point
plinout #Output to NC, linear movement - feed

pcan1, pbld, n$, psgplane, sgfeed, pexct, psgcode, psccomp,
pwcs, pxout, pyout, pzout, pcout, pfr, pscool, strcantext, e$
if rpd_typ$ = 7, ptool_insp #Tool inspection point
It is a good practice to create a new postblock to hold the processing logic for the
tool inspection. In this example, the new postblock is ptool_insp.
The tool inspection postblock needs to do the following:
 Since the lathe tool inspection uses the same 70000 flag as the mill/HST tool
inspection, mill-turn posts need to be able to distinguish between a mill and
lathe tool inspection.
 Handle the 29999 comment.
 When the tool returns to the part, restore the machine operation mode that was
in effect before the inspection. At a minimum, this will include the motion mode
and feed rate; coolant state; and work offset.
Example: Tool inspection postblock shows how this postblock was implemented in
the MPLFAN.PST generic post.

Example
Tool inspection postblock
Contents
This example outputs:
 An M00 at the inspection point.
 A comment (with some default text), in addition to the comment entered
with the tool inspection toolpath.
The comment text in the example is only a place holder indicating that this
postblock is a generic solution that has not been customized for a specific machine.
Remove this comment when you customize this for your customers’ machines and
replace it with whatever code, if any, is appropriate for your application.
NOTE: Make you also customize this example so it outputs the proper stop or wait
code for your machine.
ptool_insp #Tool inspection point

#Modify following lines to customize output for tool inspection
if posttype$ = 2, #Lathe tool inspection point
[
"(TOOL INSPECTION POINT - POST CUSTOMIZATION
MAY BE REQUIRED)", e$
if prmcode$ = 29999, #Only output tool insp comment if one
was entered with this insp point
[
sparameter$ = ucase(sparameter$)
pbld, n$, *sm00, "(", sparameter$, ")", e$
]
else, pbld, n$, *sm00, e$ #Output just the stop
if no comment
pbld, n$, *sgcode, *toolno, e$ #Restate tool number
pbld, n$, pfsgplane, e$ #Restate plane code
prpm # Output programmed RPM #Restate spindle
prv_feed = c9k #Set prv_values to c9k to force them out
with next moves
prv_gcode$ = c9k
prv_workofs$ = c9k
if coolant$, prv_coolant$ = c9k
]
else, #Mill tool inspection point
pbld, n$, *sm00, "(TOOL INSPECTION POINT - POST CUSTOMIZATION
REQUIRED)", e$

The following picture shows the before-and-after NC output generated by the post
logic in the preceding examples:
Contents

rev. May 15, 2016 MIGRATING FROM X9 TO 2017  61
7. Migrating from X9 to 2017 Contents
Use this section as a guide for migrating an existing post written for X9 or earlier to the
new parameter processing techniques. Typically, you will do this to realize one or more of
the following benefits:
 Faster and more efficient post processing.
 Simpler and more maintainable code.
 Code that is more generic and can be more easily re-used among different posts.
For most posts, you will need to address the following areas:
 Tool table parameters
 pparameter$ postblock
 Parameter tables
 MD, CD, and group parameters
 Optimizing parameter usage
IMPORTANT: Always make a backup copy of your post before making edits!
A. Tool table parameters

Typically, when you migrate a post to use the new parameter read functions, you will also
implement the new enhanced tool table processing routines. This involves removing the
pwrtt$ and pwrttparam$ postblocks. Typically, the parameters that are currently read
in pwrttparam$ in your X9 post will be read in ptooltable$ in the new post.
This is an example of how pwrttparam$ might be implemented in an X9 post:
pwrttparam$ #Pre-read parameter data
#Cutter compensation type
if prmcode$ = 15346, comp_type = rpar(sparameter$, 1)
#Capture stock to leave (XY)
if prmcode$ = 10010, xy_stock = rpar(sparameter$, 1)
#Capture stock to leave (Z)
if prmcode$ = 10068, z_stock = rpar(sparameter$, 1)

In the Mastercam 2017 post, these parameters can be moved to a parameter table, which
is populated during ptooltable$.
fprmtbl 101 3 # Operation - tool table
10010 xy_stock Contents
10068 z_stock
15346 comp_type
ptooltable$ #Tooltable output
result = fprm (101,0, 0)
The Working with enhanced tool tables application guide covers the new tool table
routines in much more detail.
B. pparameter$ postblock
The key element in migrating your post to the new techniques is removing the
pparameter$ postblock. Look through your pparameter$ postblock and identify the
parameters that it is retrieving. Typically these can be replaced by opinfo() function
calls that are placed directly in the postblock where the information is needed. For
example, in this post, pparameter$ is used to read the inch/metric flag from the 20007
line:
pparameter$ #Read operation parameters
# See if tool is metric
if prmcode$ = 20007, toolismetric = rparsngl(sparameter$, 11)
In the Mastercam 2017 post, this is set directly in a user-defined postblock called ppitch
where it is needed:
ppitch # Adjust pitch for inch/metric tool in inch/metric machine
toolismetric = rparsngl(opinfo (20007, 0, 0), 11)
(rest of postblock omitted...)
Also, search your post for references to rd_params$. Recall that this command calls
pparameter$ so you can perform parameter reads from any postblock. Typically,
instances of rd_params$ can be replaced by individual opinfo() function calls for the
desired parameter. You should also remove any related references to rd_prm_op_no$.
Once you are done, the pparameter$ postblock should be completely removed from
your post. For best efficiency, the pparameter$, pwrtt$, and pwrttparam$ postblocks
must each be removed or commented out.

C. Parameter tables
You will most likely be able to reuse existing parameter tables; the fprmtbl statement Contents
hasn’t changed from X9.
However, the fprm() calls will need to be edited.
 In X9 and earlier posts, these needed to be in pparameter$, pwrttparam$, or
pmachineinfo$.
 Since these postblocks are not used in 2017–style posts, the fprm() calls should
be moved to more appropriate locations.
 In Mastercam 2017, fprm() can be used in any postblock.
For example, many of our generic posts include a user-defined postblock called
pset_mach that is used for machine definition settings. This is an ideal location to move
fprm() calls from pmachineinfo$.
In addition, note that for Mastercam 2017, two new arguments have been added to the
fprm() statement. Edit each fprm() call as required to include the new arguments.
Building parameter tables with fprm on page 17 describes them.
Finally, you should review tables of machine definition parameters. You will most likely
need to restructure these.
 In the first place, review the tables for parameters that might no longer be
needed—in particular, look for settings that are part of the new
x_mp_adv_func$ routines. These will automatically be placed in predefined
variables, and this will typically be the preferred way to access these values. See
Direct access to machine definition data on page 42 to learn more.
 You will want to break out the parameters for each component type into
separate tables, distinct from the general machine parameters. For example, use
separate tables to group parameters for linear axis components, rotary axis
components, general machine parameters, etc.
 Once you complete these two steps, you might find that you have single
parameters for specific components. For these, you might prefer to not create a
table for that component type, and can simply use an mdinfo() function call
wherever you need the information.
The following sample code of an X9 parameter table shows examples of each of these
conditions.

 The yellow parameters above are broken out into a new table for rotary axis
parameters. A separate table includes the coolant parameters (17101 and 17102),
which are general machine parameters.
Contents
 The green parameters are no longer needed; they are set directly from the
machine definition by the new x_mp_adv_func$ routines.
 The remaining parameter, 17605, is a linear axis parameter. There is no need to
create a separate table for it; instead, it is read directly by mdinfo() in the user-
defined postblock where it is needed:
D. MD, CD, and group parameters

Recall that X9 and earlier posts relied on a group of three related commands for
retrieving machine definition, control definition, and machine group parameters:
 rd_md$ for machine definitions
 rd_cd$ for control definitions
 rd_tlpathgrp$ for machine groups
Each of these commands resulted in the pmachineinfo$ postblock being executed. The
pmachineinfo$ postblock contains the references to the individual parameters that are
being retrieved.
For 2017, these commands should be replaced by the new query functions:
 mdinfo()
 cdinfo()
 groupinfo()
In addition, use acomboinfo() in place of the helper variables like rd_mch_ent_no$ to
support mdinfo().

A typical use of the X9-style commands is to place them in pprep$:

pprep$ #Pre-process postblock
rd_cd$ #Read CD Parameters
rd_mch_ent_no$ = 0 #Read machine base parameters Contents
rd_md$ #Read machine definition parameters
In 2017, you will do either of the following—most likely, a combination of both:

 Create a user-defined postblock that is called from pprep$. This can collect the
mdinfo(), cdinfo(), and groupinfo() function calls that will replace the
parameter references in pmachineinfo$.
 Place individual mdinfo(), cdinfo(), and groupinfo() function calls directly
in whichever postblock needs the information.
The recommended practice in 2017 is to begin by defining one or more arrays to store
key component information. Then, early in your post, call acomboinfo() to populate
them. This way, any future uses of mdinfo() will always be able to easily access the
desired component.
The following sample code does the following:
 First it defines three arrays to store information about the machine’s
components.
 Then pprep$ calls a user-defined machine set-up postblock, pset_mach.
 Finally, pset_mach populates information about the machine.
 fprm() retrieves tables of parameters from the machine definition and
control definition.
 acomboinfo() populates the arrays of component information.
# Arrays for machine definition component information

entid_pri : 0 # Entity ID of primary rotary axis
acombo_x : c9k # Implied array X,Y,Z,A,B,C entity IDs
acombo_y : c9k
acombo_z : c9k
acombo_a : c9k
acombo_b : c9k
acombo_c : c9k
acombo_pri : c9k # Implied array for entity IDs of primary,
acombo_sec : c9k # secondary, tertiary rotary axes
acombo_ter : c9k
acombo_prirt : c9k # Implied array for axis of rotation for
acombo_secrt : c9k # each rotary axis
acombo_terrt : c9k
pprep$ # Pre-process postblock
pset_mach
pset_mach # Get machine definition data
result = fprm (17000, 1, 0) # Get MD base parameters
result = fprm (18000, 2) # Get CD parameters
syncaxis$ = opinfo (8, 0, 0) # Get the axis combo entity ID
acombo_x = acomboinfo (1, syncaxis$) # Collect the X,Y,Z,
# A,B,C axis order

acombo_pri = acomboinfo (7, syncaxis$) # Get map for primary/

# secondary/tertiary
# rotary axes
# Get the entity ID of the primary rotation axis Contents
entid_pri = vlout ((acombo_pri + three), acombo_x, zero)
# Get axes of rotation for each rotary axis
acombo_prirt = acomboinfo (5, syncaxis$)
E. Optimizing parameter usage

Between the mdinfo() function and the x_mp_adv_func$ routines, your ability to
access information from the machine definition is greatly expanded, simplified, and far
more efficient. Examine your post and look for more opportunities where you can
simplify your logic by directly accessing the machine definition.
For example, many of our generic posts implement logic to determine the axis label for
the primary rotary axis (srot_label). The following code from our MPFAN.PST is
typical:
pset_rot_label #Set rotary axis label
if not(use_md_rot_label),
[
if rot_on_x = 1, srot_label = srot_x #Rotating about X axis
if rot_on_x = 2, srot_label = srot_y #Rotating about Y axis
if rot_on_x = 3,
[
if vmc, srot_label = srot_z #Rotating about Z (VMC)
else, srot_label = srot_y #Rotating about Y (HMC)
]
]
result = nwadrs(srot_label, cabs)
result = nwadrs(srot_label, cinc)
result = nwadrs(srot_label, indx_out)
pset_rot_label_sign #Set rot axis label for signed output dir
if use_md_rot_label,
[
if not(use_rotmcode),
[
if indx_mc = zero, srot_label = srot_label + sminus
else, srot_label = sav_srot_label
]
]
else,
[
if not(use_rotmcode),
[
if rot_on_x = 1, srot_label = srot_x #Rotating about X axis
if rot_on_x = 2, srot_label = srot_y #Rotating about Y axis
if rot_on_x = 3, srot_label = srot_z #Rotating about Z axis
]
]

result = nwadrs(srot_label, cabs)

result = nwadrs(srot_label, cinc)
result = nwadrs(srot_label, indx_out)
In a post that has been written for Mastercam 2017, you can simply use the mdinfo() Contents
function to read the axis label directly from the primary rotary axis component. Much of
the logic from the X9 post can therefore be simply eliminated:
pset_rot_label #Set rotary axis label for signed direction
if rot_type = 1 & not(use_rotmcode),
[
srot_label = mdinfo (17397, entid_pri)
]
Another opportunity to optimize your code are places where you use buffers so that you
can compare information from different operations. Because you can easily configure
opinfo() to directly access parameters from any operation, you might be able to replace
these buffers and related logic with direct opinfo() function calls.
And, remember to initialize x_mp_adv_func$ in the initialization area at the top of your
post as described in Direct access to machine definition data on page 42. In most cases,
this will allow you to eliminate a number of parameter calls from your post and most
likely other code as well.
x_mp_adv_func$ : 1 #Set the 5 axis variables

Working With Tool and Operation Parameters: MP Application Guides

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Working With Tool and Operation Parameters: MP Application Guides

Încărcat de

Drepturi de autor:

Formate disponibile

MP APPLICATION GUIDES

Working with tool and

3. Building parameter tables with fprm .........................................................................17

Working with tool and operation parameters

 Direct access to machine definition data. . . . . . . . . . . . . . . . . . . . . . . . . . . page 42

IMPORTANT: It is important to understand that many, many new features related to

Working with tool and operation parameters

2. Using the opinfo function to get Contents

IMPORTANT: The pparameter$, pwrtt$, and pwrttparam$ postblocks should not be

The general form of the function is:

Working with tool and operation parameters

See the next sections for specific examples.

Working with tool and operation parameters

A. Capturing values for 10000s parameters

Working with tool and operation parameters

Working with tool and operation parameters

p_getparams # can read parameters from any postblock

Working with tool and operation parameters

B. Capturing values from 20000s lines and other NCI

Parameter ranges—20000s parameters are organized in the following groups:

20000–20099 Mill, plus parameters that are common to all products

Working with tool and operation parameters

20700–20799 Stream/NCI Information

Accessing buffered comments—MP maintains a separate buffer of comments from the

Working with tool and operation parameters

Capturing a string from a 20000s line

p_get_my_parameter # Any postblock where you need the value

Working with tool and operation parameters

Capturing numeric values from a 20000s line

a. Look up the desired 20000s line number.

b. See how many values are included in the output string.

2. Create a series of unique, user-defined numeric variables to store the results—

Working with tool and operation parameters

hd_ax_x : 0 # Head axis in X

p_get_my_parameter # Any postblock where you need the values

1. Go to the NCI Reference volume to find the desired 20000s line.

a. Look up the desired 20000s line number.

b. Identify which parameter in the string contains the desired value.

2. Create a numeric variables to store the value.

Working with tool and operation parameters

p_get_my_parameter # Any postblock where you need the value

a. Look up the desired 20000s line number.

Working with tool and operation parameters

p_get_my_parameter # Any postblock where you need the value

Getting enhanced tool table values

Working with tool and operation parameters

C. Selecting the operation to query

Table 1: opinfo “mode” selection: 1s digit

Table 2: opinfo “mode” selection: 10s digit

Table 3: opinfo “mode” selection: 100s digit

Working with tool and operation parameters

Table 3: opinfo “mode” selection: 100s digit

Testing if an operation has a tool table record

Working with tool and operation parameters

3. Building parameter tables with Contents

 0 = operation parameters (10000–16999, 40000+)

Working with tool and operation parameters

Working with tool and operation parameters

3. Use the fprmtbl command to define the table.

NOTE: Each type of parameter—operation, machine definition, control defintion,

Working with tool and operation parameters

# Machine Definition Parameters

fprmtbl 102 4 # Machine definition - rotary component