GPP2

CimatronE 10.0 User Guide

CimatronE 10.0 GPP2 User Guide ⎪i

Table of Contents

1 Theory of Operation ..........................................................................................................1

1.1 Introduction to GPP2 ..............................................................................................................1
1.2 GPP2 Input Files ....................................................................................................................2
1.3 GPP2 Coordinate Systems ....................................................................................................3
1.3.1 Reference UCS..........................................................................................................................3
1.3.2 Toolpath UCS ............................................................................................................................3
1.3.3 Current Procedure ORIGIN UCS...............................................................................................4
1.3.4 Output UCS................................................................................................................................5
1.3.5 Legacy Coordinate Systems......................................................................................................5
1.3.5.1 MACSYS UCS..........................................................................................................5
1.3.5.2 MODEL UCS ............................................................................................................5
1.3.6 Multiple Part Setups (Multiple REF)...........................................................................................5
1.4 GPP2 Toolpath Points............................................................................................................8
1.5 Blocks and Qualifiers..............................................................................................................8
1.5.1 List of Blocks and Qualifiers ................................................................................................... 10
1.5.1.1 Non-Supported Old Blocks.................................................................................... 10
1.6 Procedure Header Blocks ....................................................................................................11
1.6.1 Multi-Tool Procedures............................................................................................................. 12
1.7 GPP2 Connections...............................................................................................................12
1.7.1 The Connection Process ........................................................................................................ 13
1.7.1.1 Starting the Connection......................................................................................... 13
1.7.1.2 Choosing the Default Connection Scenario .......................................................... 14
1.7.1.3 Procedure Connection Point ................................................................................. 15
1.7.2 Connection Scenarios............................................................................................................. 16
1.7.3 The Default Scenarios ............................................................................................................ 16
1.7.3.1 Short Connection (Short Scenario) ....................................................................... 16
1.7.3.2 Long Connection (Long Scenario)......................................................................... 17
1.7.3.3 Connection after Tool Change (Tool-Change Scenario)....................................... 17
1.7.3.4 Safe Connection (Through-Safe Scenario) ........................................................... 18
1.7.4 Breaking Sideways Moves to Multiple Motions ...................................................................... 18
1.8 Subroutines ..........................................................................................................................20
1.8.1 Dealing with Machine Capability............................................................................................. 20
1.8.2 Subroutine Numbers ............................................................................................................... 20
1.9 Subroutine Blocks ................................................................................................................21
1.9.1 Post-time vs. Runtime............................................................................................................. 22
1.9.2 Location of Subroutine Body G-Code ..................................................................................... 23
1.10 Linear Motion........................................................................................................................24
1.10.1 Qualifiers................................................................................................................................. 24
1.10.2 Process Rapid as Feed .......................................................................................................... 25
CimatronE 10.0 GPP2 User Guide ⎪ii

1.11 Circular Motion .....................................................................................................................25

1.11.1 Dealing with Machine Capability............................................................................................. 26
1.11.2 Planes, Axes and Angles........................................................................................................ 26
1.11.3 CimatronE Arc Planes............................................................................................................. 30
1.11.4 Limiting Arcs to Quadrants ..................................................................................................... 30
1.11.5 Limiting Arc Angles ................................................................................................................. 31
1.11.6 Breaking Arcs to Linear Motions............................................................................................. 31
1.12 Converting Linear Motions to Arcs .......................................................................................34
1.13 Drill Cycles ...........................................................................................................................35
1.13.1 Cycle Qualifiers....................................................................................................................... 35
1.13.2 Dealing with Machine Capability............................................................................................. 36
1.13.3 Inter-Cycle Connections ......................................................................................................... 37
1.13.4 Tool Position after Cycle......................................................................................................... 38
1.13.4.1 Default Tool Height after the Cycle ....................................................................... 39
1.13.5 Information on the Next Cycle ................................................................................................ 40
1.14 GPP2 Variable Initialization..................................................................................................40
1.15 Running a Post-Script from GPP2........................................................................................41
1.16 Licensing Post-Processors with GPP2.................................................................................42
1.16.1 Protection of the GPP2 Development Environment ............................................................... 42
1.17 Post Processing with Transformations (GPP & GPP2) ........................................................43
1.17.1 GPP Output............................................................................................................................. 43
1.17.1.1 Fully Exploded Mode............................................................................................. 43
1.17.1.2 Non-Exploded Transformations............................................................................. 43
1.17.2 Processing in GPP2................................................................................................................ 44
1.17.2.1 DF2 Additions ........................................................................................................ 44
1.17.2.2 Processing Transformations.................................................................................. 44
1.17.2.2.1 Simple Transformations......................................................................................44
1.17.2.2.2 Exploding Transformations.................................................................................45
1.17.2.2.3 Multi-Cutter Procedures......................................................................................45
1.17.2.2.4 When a Subroutine Cannot be Used ..................................................................45

2 GPP2 Editors ...................................................................................................................47

2.1 EX2 Editor ............................................................................................................................48
2.1.1 Toolbar Buttons....................................................................................................................... 49
2.1.2 Editor Pane ............................................................................................................................. 51
2.1.2.1 Jump to Line # ....................................................................................................... 51
2.1.2.2 Assisted Editing ..................................................................................................... 53
2.1.2.3 Comment Block ..................................................................................................... 54
2.1.2.4 Toggle Comment................................................................................................... 54
2.1.2.5 Bookmarks............................................................................................................. 55
2.1.3 Marks Pane............................................................................................................................. 56
2.1.4 Console Log............................................................................................................................ 57
CimatronE 10.0 GPP2 User Guide ⎪iii

2.2 DF2 Editor ............................................................................................................................58

2.2.1 GPP2 DF2 Editor Dialog – Post Tab ...................................................................................... 60
2.2.2 GPP2 DF2 Editor Dialog – Linear Tab.................................................................................... 61
2.2.3 GPP2 DF2 Editor Dialog – Circular Tab ................................................................................. 62
2.2.4 GPP2 DF2 Editor Dialog – Connection Tab ........................................................................... 63
2.2.5 GPP2 DF2 Editor Dialog – Formats Tab ................................................................................ 64
2.2.6 GPP2 DF2 Editor Dialog – Machine Code Tab ...................................................................... 65
2.2.7 GPP2 DF2 Editor Dialog – Output Files Tab .......................................................................... 66
2.2.8 GPP2 DF2 Editor Dialog – Miscellaneous Tab....................................................................... 67

3 Language Reference Manual..........................................................................................68

3.1 Introduction and Conventions...............................................................................................68
3.1.1 Structure of this Document ..................................................................................................... 68
3.1.2 GPP Users .............................................................................................................................. 68
3.1.3 GPP Conventions ................................................................................................................... 69
3.2 GPP Variables......................................................................................................................69
3.2.1 System Variables .................................................................................................................... 69
3.2.2 User-Defined Variables........................................................................................................... 70
3.2.3 User-Defined Interaction Variables......................................................................................... 70
3.2.4 User-Defined GPP-Procedure Variables ................................................................................ 71
3.2.5 Array Variables – Not Recommended .................................................................................... 71
3.2.6 Variable Formats and Types................................................................................................... 71
3.2.7 Formatting Variables for Output.............................................................................................. 73
3.2.8 Variable Modality and Set Status............................................................................................ 75
3.2.9 Identical Variables – Not Recommended ............................................................................... 77
3.2.10 Variable Initialization ............................................................................................................... 78
3.2.11 Tool/cycle User-Defined Variables – Not Supported .............................................................. 78
3.3 GPP Expressions .................................................................................................................79
3.3.1 Expression Types ................................................................................................................... 79
3.3.2 Constants................................................................................................................................ 80
3.3.3 Variable References ............................................................................................................... 81
3.3.4 Standard Mathematical Operators.......................................................................................... 81
3.3.5 Trigonometric Functions ......................................................................................................... 82
3.3.6 Other Numeric Functions........................................................................................................ 83
3.3.6.1 FORMATTED_NUM Function ............................................................................... 83
3.3.6.2 FRAC_DIGITS Function........................................................................................ 84
3.3.6.3 INT_ and FRAC_ Functions .................................................................................. 85
3.3.7 String Functions ...................................................................................................................... 85
3.3.7.1 String Concatenation............................................................................................. 85
3.3.7.2 String Length ......................................................................................................... 86
3.3.7.3 String to Number ................................................................................................... 86
3.3.7.4 Numeric Variable to String .................................................................................... 86
CimatronE 10.0 GPP2 User Guide ⎪iv

3.3.7.5 Sub-Strings............................................................................................................ 87
3.3.7.6 Other String Functions .......................................................................................... 88
3.3.7.7 Splitting Strings to Sub-strings .............................................................................. 88
3.3.7.8 Replacing-strings................................................................................................... 89
3.3.8 Tool Parameter Functions ...................................................................................................... 90
3.3.9 Boolean Expressions .............................................................................................................. 91
3.3.9.1 Comparisons ......................................................................................................... 91
3.3.9.2 Comparing Numeric Expressions.......................................................................... 91
3.3.9.3 Comparing String Expressions.............................................................................. 92
3.3.9.4 Comparing Mixed Expressions – Not Recommended .......................................... 93
3.3.9.5 Testing Variable Set Status................................................................................... 93
3.3.9.6 Complex Boolean Expressions ............................................................................. 94
3.4 Program Structure ................................................................................................................95
3.4.1 Declaration Part ...................................................................................................................... 95
3.4.2 New-Line-Is Section................................................................................................................ 95
3.4.3 Regular Execution Blocks....................................................................................................... 96
3.4.4 System-Defined Blocks and Qualifiers ................................................................................... 96
3.5 Declaration Statements ........................................................................................................97
3.5.1 Post Processor Title................................................................................................................ 97
3.5.2 Post Processor Protection ...................................................................................................... 97
3.5.3 FORMAT................................................................................................................................. 98
3.5.4 INTERACTION........................................................................................................................ 98
3.5.4.1 System Interaction Variables................................................................................. 99
3.5.4.2 Multi-Choice Interaction Variables......................................................................... 99
3.5.4.3 Boolean Interaction Variables ............................................................................. 100
3.5.5 IDENTICAL – Not Recommended ........................................................................................ 101
3.5.6 MODAL ................................................................................................................................. 101
3.5.7 SET_TABS............................................................................................................................ 102
3.5.8 ALWAYS_FORMATTED ...................................................................................................... 102
3.5.9 CONNECTION_SCENARIO................................................................................................. 103
3.5.10 Scenario Actions ................................................................................................................... 103
3.5.10.1 Move.................................................................................................................... 103
3.5.10.2 Move Up .............................................................................................................. 104
3.5.10.3 Move Down.......................................................................................................... 105
3.5.10.4 Move to Safe Position ......................................................................................... 105
3.5.10.5 Machine Control .................................................................................................. 106
3.5.10.6 Set UCS............................................................................................................... 107
3.5.10.7 Forcing a Scenario Action ................................................................................... 108
3.5.10.8 Scenario Examples ............................................................................................. 108
3.5.11 INIT_FILE.............................................................................................................................. 110
3.5.12 REPORT_VARS ................................................................................................................... 111
3.5.13 REPORT_TOOL_VARS ....................................................................................................... 111
3.6 Execution Statements ........................................................................................................112
3.6.1 Assignment ........................................................................................................................... 112
CimatronE 10.0 GPP2 User Guide ⎪v

3.6.2 IF ........................................................................................................................................... 113

3.6.3 IF_SET.................................................................................................................................. 114
3.6.4 IF_EXISTS ............................................................................................................................ 114
3.6.5 REPEAT UNTIL .................................................................................................................... 115
3.6.6 OUTPUT ............................................................................................................................... 115
3.6.6.1 Using Expressions in Output ............................................................................... 118
3.6.7 PRINT, PRINT0, PRINT1 to PRINT10.................................................................................. 118
3.6.8 OUTPUT Redirection ............................................................................................................ 119
3.6.9 LOAD_FILE........................................................................................................................... 121
3.6.10 SET_ON and SET_OFF ....................................................................................................... 122
3.6.11 Sequencing ........................................................................................................................... 123
3.6.12 System Calls ......................................................................................................................... 124
3.6.13 GPP_STOP........................................................................................................................... 126
3.6.14 Advanced Statements for 5-Axis Machines.......................................................................... 126
3.6.15 KEEP .................................................................................................................................... 126
3.7 GPP Procedures ................................................................................................................127
3.7.1 Procedure Definition ............................................................................................................. 127
3.7.1.1 Parameter and Variable Name Scope ................................................................ 128
3.7.2 Procedure Calls .................................................................................................................... 128
3.8 GPP Debugging and Tracing .............................................................................................129
3.8.1 Trace Execution .................................................................................................................... 129
3.8.2 Single-Step Execution .......................................................................................................... 131
3.8.3 Trace G-Code Output ........................................................................................................... 131

4 Blocks, Constants and System Variables ...................................................................132

4.1 GPP2 Blocks ......................................................................................................................132
4.2 GPP2 Constants.................................................................................................................137
4.2.1 General Purpose Constants ................................................................................................. 137
4.2.2 Constants for GPP2 Connections......................................................................................... 137
4.2.3 Other Numeric Constants ..................................................................................................... 138
4.2.4 Constants for 5 Axis Machines ............................................................................................. 139
4.2.5 Constants for 5 Axis Post Processing................................................................................... 140
4.2.6 Transformation Constants .................................................................................................... 141
4.3 GPP2 Variable Formats .....................................................................................................142
4.4 DF2-Related Variables .......................................................................................................143
4.4.1 Machine Codes ..................................................................................................................... 144
4.4.2 Sequencing ........................................................................................................................... 145
4.4.3 Circular Motions .................................................................................................................... 146
4.4.4 Converting Linear Motions to Arcs........................................................................................ 147
4.4.5 GPP2 Connections ............................................................................................................... 148
4.4.5.1 5 Axis Connections.............................................................................................. 149
CimatronE 10.0 GPP2 User Guide ⎪vi

4.4.5.2 Inter-Cycle Connections ...................................................................................... 150

4.4.6 5 Axis Motions....................................................................................................................... 151
4.4.7 Miscellaneous ....................................................................................................................... 152
4.5 GPP2 System Flags ...........................................................................................................153
4.6 Global System Variables ....................................................................................................157
4.7 Advanced System Variables ..............................................................................................158
4.8 Machine Definition Variables..............................................................................................160
4.8.1 5-Axis Machine Definition ..................................................................................................... 160
4.8.2 5-Axis Machine – Primary (A) Axis ....................................................................................... 162
4.8.3 5-Axis Machine – Secondary (B) Axis .................................................................................. 164
4.8.4 Machine Simulation............................................................................................................... 166
4.8.5 Miscellaneous ....................................................................................................................... 169
4.9 XML and Report Variables .................................................................................................171
4.10 Toolpath Variables .............................................................................................................173
4.10.1.1 Block: BEGINNING OF CONNECT..................................................................... 173
4.10.1.2 Block: BEGINNING OF PROC ............................................................................ 174
4.10.1.3 Block: BEGINNING OF SUB ............................................................................... 178
4.10.1.4 Block: BEGINNING OF TAPE ............................................................................. 179
4.10.1.5 Block: BEGINNING OF TLPATH......................................................................... 180
4.10.1.6 Block: CIRCULAR MOTION................................................................................ 181
4.10.1.7 Block: CUTTER COMPENSATION..................................................................... 182
4.10.1.8 Block: CYCLE...................................................................................................... 183
4.10.1.9 Block: END OF CONNECT ................................................................................. 188
4.10.1.10 Block: END OF FILE ........................................................................................... 188
4.10.1.11 Block: END OF PROC......................................................................................... 189
4.10.1.12 Block: END OF SUB............................................................................................ 189
4.10.1.13 Block: END OF TAPE.......................................................................................... 190
4.10.1.14 Block: END OF TOOLPATH................................................................................ 191
4.10.1.15 Block: HOME SHIFT ........................................................................................... 191
4.10.1.16 Block: INSERT WITH (SEQUENCING) .............................................................. 191
4.10.1.17 Block: INSERT WITHOUT (SEQUENCING)....................................................... 191
4.10.1.18 Block: LINEAR MOTION ..................................................................................... 191
4.10.1.19 Block: MACHINE CONTROL .............................................................................. 192
4.10.1.20 Block: MESSAGE ................................................................................................ 192
4.10.1.21 Block: MOVE TO SAFE....................................................................................... 192
4.10.1.22 Block: ORIGIN CHANGE .................................................................................... 192
4.10.1.23 Block: POST SCRIPT.......................................................................................... 193
4.10.1.24 Block: PROC FIRST POINT................................................................................ 193
4.10.1.25 Block: PROC TRANS .......................................................................................... 194
4.10.1.26 Block: RECONFIG MACHINE ............................................................................. 195
4.10.1.27 Block: RESET AXIS ............................................................................................ 195
4.10.1.28 Block: SET UCS .................................................................................................. 195
4.10.1.29 Block: START PROC .......................................................................................... 195
4.10.1.30 Block: STARTUP................................................................................................. 195
CimatronE 10.0 GPP2 User Guide ⎪vii

4.10.1.31 Block: SUBROUTINE CALL ................................................................................ 196

4.10.2 Block: TOOL CHANGE......................................................................................................... 197

5 4/5 Axes Post-Processors ............................................................................................200

5.1 Introduction to 5 Axis Post-Processing...............................................................................200
5.2 Machine Definition..............................................................................................................200
5.2.1 Machine Types...................................................................................................................... 201
5.2.1.1 5-Axis Table-Table (TT) ...................................................................................... 201
5.2.1.2 5-Axis Table-Head (TH) ...................................................................................... 203
5.2.1.3 5-Axis Head-Head (HH) ...................................................................................... 204
5.2.1.4 4-Axis Table......................................................................................................... 204
5.2.1.5 4-Axis Head ......................................................................................................... 206
5.2.2 Defining Machine Axes ......................................................................................................... 206
5.2.2.1 Manually-Defined Axes ....................................................................................... 208
5.2.3 Machine Definition Command............................................................................................... 209
5.2.4 Machine Geometry................................................................................................................ 210
5.2.4.1 A and B Vectors .................................................................................................. 210
5.2.4.2 Tool Direction Vector........................................................................................... 214
5.2.4.3 Tool Length Correction........................................................................................ 215
5.2.5 RTCP Settings ...................................................................................................................... 215
5.2.5.1 Head RTCP ......................................................................................................... 216
5.2.5.2 Table RTCP......................................................................................................... 216
5.2.5.3 Full RTCP (M128) ............................................................................................... 217
5.2.6 Axis Rotation Types .............................................................................................................. 220
5.2.6.1 Continuous Cyclic Axes....................................................................................... 220
5.2.6.2 Continuous Resettable Axes ............................................................................... 220
5.2.6.3 Limited Range Axes ............................................................................................ 222
5.2.7 Axis Angle Limits................................................................................................................... 222
5.2.8 Miscellaneous Settings ......................................................................................................... 222
5.2.8.1 Axis Preference ................................................................................................... 222
5.2.8.2 Axis Angle Reversal ............................................................................................ 222
5.2.8.3 Axis Letter............................................................................................................ 223
5.2.9 Machine XYZ Limits .............................................................................................................. 224
5.3 Placing the Part on the Machine ........................................................................................225
5.4 5-Axis Toolpath Optimization .............................................................................................226
5.4.1 Toolpath Segments............................................................................................................... 226
5.4.2 Axis Angle Optimization........................................................................................................ 227
5.4.2.1 Any Angles .......................................................................................................... 227
5.5 5-Axis Linear Motions.........................................................................................................228
5.6 5-Axis Connections ............................................................................................................229
5.6.1 The 5-Axis Connection Shape .............................................................................................. 230
5.6.2 In-Place 5-Axis Connection .................................................................................................. 232
5.6.3 Controlling the 5-Axis Connection Point ............................................................................... 234
CimatronE 10.0 GPP2 User Guide ⎪viii

5.6.4 In-Place Connection.............................................................................................................. 236

5.6.5 Force Regular Connection in an “In-Place Connection” situation ........................................ 236
5.7 5-Axis Drill ..........................................................................................................................237
5.8 Thread Mill Cycle................................................................................................................237
5.9 Inverse Time Feed Rate.....................................................................................................239
5.10 Managing Advanced 5-Axis Machines ...............................................................................239
5.10.1 Set Output UCS .................................................................................................................... 239
5.10.1.1 SET_OUTPUT_UCS Improvement ..................................................................... 243
5.10.2 Calculating the Work Plane UCS.......................................................................................... 244
5.10.3 Virtual Axes Rotation Angles ................................................................................................ 246
5.10.3.1 Incremental Rotations ......................................................................................... 248
5.10.4 Setting the Axes Zero Points ................................................................................................ 248
5.11 Indexed Machine Axes .......................................................................................................249
5.12 6 Axes Machines – Reconfiguration...................................................................................250
5.12.1 Re-configuration Process ..................................................................................................... 250
5.12.2 When and How to Request Reconfiguration ........................................................................ 250
5.12.2.1 In the START PROC Block ................................................................................. 250
5.12.2.2 In the BEGINNING OF CONNECT Block ........................................................... 250
5.12.2.3 In the LINEAR MOTION Block ............................................................................ 251
5.12.2.4 Between CYCLE Block........................................................................................ 251
5.12.3 The RECONFIG MACHINE Block ........................................................................................ 251
5.12.4 Scenario Connections in 6-Axis Machines ........................................................................... 252
5.12.5 Example 1 – Vertical and Horizontal Head........................................................................... 253
5.12.6 Example 2 – Full 6-Axis Machine ......................................................................................... 254
5.13 Machine Simulation ............................................................................................................255
5.13.1 Machine Simulation Output................................................................................................... 255
5.13.2 Safe Position......................................................................................................................... 255
5.13.3 Move to Safe Request .......................................................................................................... 256
5.13.4 Part Position on the Table .................................................................................................... 257
5.13.5 Simulation Data Order .......................................................................................................... 257
5.13.6 Tool Compensation............................................................................................................... 257
5.13.7 Toolpath Representation ...................................................................................................... 257
5.13.8 Using 6 (or More) Axis Machines.......................................................................................... 258
5.13.9 Machine Simulation Output as G-Code ................................................................................ 259
5.13.9.1 Formatting the ‘Move List’ Display ...................................................................... 260
5.13.10 Adding Comments in the Simulator File ............................................................................... 261
5.13.11 Machine Simulator – In-Motion Collision Checks ................................................................. 261
5.13.12 Additional Spindles in the Machine Simulator ...................................................................... 263

6 Report Customization ...................................................................................................264

6.1 GPP2 Reports ....................................................................................................................264
CimatronE 10.0 GPP2 User Guide ⎪ix

6.1.1 Using GPP2 and XML Variables........................................................................................... 264

6.2 Selecting the Report Template...........................................................................................265
6.3 Creating Report Templates ................................................................................................265
6.3.1 Report Header ...................................................................................................................... 267
6.3.2 Report Body .......................................................................................................................... 268
6.3.3 Report Trailer ........................................................................................................................ 269
6.3.4 Report Pictures ..................................................................................................................... 270
6.3.5 Debugging Report Templates............................................................................................... 272
6.4 XML File Configuration.......................................................................................................273
6.4.1 Many-to-One Mapping .......................................................................................................... 274
6.4.2 GPP2 Processing of XML Data ............................................................................................ 275
CimatronE 10.0 GPP2 User Guide ⎪1

1 Theory of Operation

1.1 Introduction to GPP2

A CimatronE GPP2 post processor translates CimatronE NC (Numerical Control) data (toolpaths and
procedures) into specific CNC (Computer Numerical Control) machine tool commands (machine
code). These commands are known as a G-Code program.
This document describes the theory of operation of GPP2 – the second generation of the General
Post Processor.
GPP2 is essentially a programming environment that allows the development of post-processors for
CimatronE NC. A GPP2 post processor is composed of the following:

.EX2 A program file, also known as the EX2 program file (after its extension). This program
tells GPP2 how to process each toolpath block it encounters. EX2 programs are written,
using the EX2 Editor, in a special dedicated programming language, which is described
in the GPP2 Language Reference Manual. The language is tailored and well suited to
the task of writing post processors.

.DX2 The EX2 program file is compiled, using the EX2 Editor, to create a DX2 file, which is
executed by GPP2.

.DF2 A definitions file, also known as the DF2 file. This file is edited using the DF2 Editor and
contains many definitions that affect how GPP2 interprets and executes the EX2 program
file. It allows fine tuning of the output machine code (generally referred to as “G-Code”),
the formatting of numbers, the way GPP2 handles various motions, etc.

GPP2 is similar but not 100% backward-compatible to the legacy GPP. This was done in order to fix
some of the elements in the legacy GPP, mostly related to the reference coordinate system used for
post-processing. Trying to maintain backward compatibility would have caused more confusion than
bring benefits. The document highlights these differences where applicable.
CimatronE 10.0 GPP2 User Guide ⎪2

1.2 GPP2 Input Files

GPP2 is a separate stand-alone program from CimatronE. In order to get the CimatronE NC toolpath
for processing, it works on an intermediary toolpath file (extension .GPP2), which is essentially a dump
of the toolpath.
The GPP2 toolpath file is created using old GPP, with a special post-processor (called GPP2) that
creates the file according to the format expected by GPP2. The process is shown in the diagram
below.

Post
Run
Cimatron

GPP2.exe G-
Old GPP Code

TP
(.GPP2) Machine
Simulation
FILE
Rev. Post
GPP2.DEX <POST>.DX2

GPP2.DEF <POST>.DF2
NC
Doc.

The process of post-processing with GPP2 involves the following steps:

• Creating the toolpath file from within the CimatronE post dialog (selecting the special GPP2 post-
processor).
• Running GPP2.
• Loading the toolpath file (created by old GPP) into the GPP2 application.
• Loading a GPP2 post-processor (DX2 and DF2 files) into the GPP2 application.
• Executing the post-processor on the loaded toolpath file.
CimatronE 10.0 GPP2 User Guide ⎪3

1.3 GPP2 Coordinate Systems

There are several coordinate systems being used in GPP2 and in CimatronE NC. Every tool point is
always defined relative to a given UCS. It is important to understand the relationship between the
UCSs and how the various points relate to each one.

1.3.1 Reference UCS

The reference UCS (REF) defines the reference point and reference axes direction for the whole
posting process. All other UCS’s and tool points are defined relative to REF.
The REF UCS must correspond to the “zero” UCS for the machine. The operation of GPP2 assumes
that zeroing all machine axes will result in the tooltip positioned at the REF UCS origin, with the tool
aligned with the REF UCS Z axis.
The REF UCS is determined by the user at post-time, in the CimatronE PP interaction. Currently,
there are several ways to define the REF UCS:
• NC document setup UCS – this is the simplest way, but is also very rigid, since that UCS cannot
be modified in an NC document after it is created.
• The first procedure UCS.
• Any UCS selected by the user. This option is available starting with CimatronE version 7.2 patch 4.
It should become the major method of specifying the REF UCS.
Note that inside GPP2, there are no EX2 system variables that specify REF. It is simply not required.
The REF zero point is, by definition, (0,0,0), and its orientation axes are similarly known: X is (1,0,0),
Y is (0,1,0) and Z is (0,0,1). Everything else is measured in reference to this UCS.

1.3.2 Toolpath UCS

The Toolpath UCS (TP UCS) is actually not used in GPP2. It is mentioned here for completeness only.
The only use of the TP UCS is when defining the HOME point. With GPP2, the HOME point is always
specified relative to the TP UCS (that takes place in the CimatronE PP interaction). However, the
HOME point is immediately translated to the REF coordinate system. For that reason, the TP UCS is
not truly relevant inside GPP2.
Note: the TP UCS was also not fully available in old GPP (orientation was not known).
CimatronE 10.0 GPP2 User Guide ⎪4

1.3.3 Current Procedure ORIGIN UCS

Each procedure has its own UCS, which is fully specified in GPP2, as the ORIGIN UCS. The ORIGIN
UCS is defined relative to REF, both in terms of position, and in terms of orientation.
The following system variables describe the procedure Origin UCS:

System Variable Meaning

X_ORIGIN X, Y and Z or the ORIGIN UCS zero point,
Y_ORIGIN expressed in the REF coordinate system
Z_ORIGIN
I_ORIGIN Orientation of the ORIGIN UCS Z vector,
J_ORIGIN expressed in the REF coordinate system
K_ORIGIN
IX_ORIGIN Orientation of the ORIGIN UCS X vector,
JX_ORIGIN expressed in the REF coordinate system
KX_ORIGIN

The orientation of the Y unit vector can be obtained from a vector multiplication of the Z and X vectors
(Z * X).
The following diagram shows the REF UCS and an ORIGIN UCS. It shows the ORIGIN zero point, Z
axis and X axis, all expressed in the REF coordinate system.

Y
An ORIGIN UCS,
expressed in REF
UCS coordinates ORIGIN UCS
Z

X
Zero point vector
Z
X_ORIGIN
REF UCS Y
Y_ORIGIN
Z_ORIGIN

Z axis orientation X axis orientation

I_ORIGIN IX_ORIGIN
J_ORIGIN JX_ORIGIN
K_ORIGIN KX_ORIGIN
CimatronE 10.0 GPP2 User Guide ⎪5

1.3.4 Output UCS

The “Output UCS” is the UCS used for outputting all toolpath points to the machine. Typically, data is
output (or “posted”) to the G-code file relative to the REF UCS, which corresponds to the machine
UCS.
In some cases, data needs to be output relative to another UCS. A typical example is when a “work
plane” is defined for a 5X machine. From that point on, the machine is expecting data expressed in a
new work plane UCS. In other words, GPP2 must use a different Output UCS.
GPP2 supports dynamic definition of the Output UCS (from the EX2 program). By default, the Output
UCS is simply identical to the REF UCS.

1.3.5 Legacy Coordinate Systems

1.3.5.1 MACSYS UCS

The MACSYS coordinate system is not used in GPP2, except for the fact that it is the default
reference UCS (REF). Therefore, GPP2 does not include any system variables that define MACSYS
in any way.
• If MACSYS is used as REF, then it’s data if implicitly known (0,0,0,…)
• If another UCS is used as REF, then MACSYS is simply not used in any way.

1.3.5.2 MODEL UCS

The model UCS is not used in GPP2. It was partly used in old GPP, since its zero point was the true
reference position for all tool points.
Since this is not the case in GPP2, and all tool points are fully referred to the REF UCS (orientation
and position), the Model UCS is not used.

1.3.6 Multiple Part Setups (Multiple REF)

Most parts need to be machined from multiple directions. With 4-axis and 5-axis machines, this can
often be implemented by rotating the machine to the required orientation. However, when a part needs
to be machined from different directions using a 3-axis machine, the part has to physically placed on
the machine table multiple times, in different orientations. We refer to that process as “Multiple
Setups”. For each orientation, the part is placed on the table, the machine home is calibrated, and the
relevant procedures are executed.
In GPP2 terminology, the part setup on the machine table is represented by the REF UCS specified by
the user when running the post-processor. The REF UCS defines the base machine coordinate
system (zero, or home position, and most importantly the machine axis orientation) with respect to the
part. Therefore, changing the part setup on the table is equivalent to defining a new REF UCS.
CimatronE 10.0 GPP2 User Guide ⎪6

The user interaction within CimatronE only allows the definition of one REF UCS. It is recommended
that a single posting process be limited to a single setup of the part. If some procedures need to be
executed using a different part setup (i.e., different REF), then a second run of the post-processor is
needed, creating a separate G-Code file.
However, some users prefer to generate a single G-code file covering the entire machining of the part,
including changing the part setup between procedures (at least when an orientation change is
required). Other users like to use “multiple homes” on the machine, each home used for machining at
a specific area or orientation. All these users need to change the REF UCS in the middle of the post-
processor run (between procedures).
In order to achieve this, use the GPP2 system flag SET_REF_BY_ORIGIN. It allows changing the REF
UCS in the middle of the run to be the current procedure ORIGIN UCS. The change can only take
place in the ORIGIN CHANGE block, meaning it can only be done in the first procedure that uses a
given ORIGIN UCS (the block is only invoked when the ORIGIN is changed).
In order to define a new REF UCS, the EX2 program must set the GPP2 system flag,
SET_REF_BY_ORIGIN to TRUE_, inside the ORIGIN CHANGE block. GPP2 only tests this system flag
after the execution of this block. GPP2 will respond by setting the REF UCS to the ORIGIN UCS. All
subsequent motions, including the connection for the current procedure, will take place according to
the new REF UCS.
Another, more advanced, way is to change the REF_UCS at run-time, and support multiple REF
output. By setting the appropriate UCS position and orientation values to the *_REF variables, and
after that setting the SET_REF_BY_VARS system flag to TRUE_, the REF_UCS would change
accordingly.
Note: For standard use there is no need to ever use these variables in the post. They are to be used
ONLY if REF_UCS really needs to be changed.
Usage example: By copying the TP*_ORIG values to the corresponding *_REF variables and
SET_REF_BY_VARS system flag as TRUE_, the current TP UCS would become the new REF_UCS.
Note: All 9 *_REF variables must be set before SET_REF_BY_VARS is used. Do not assume anything
on the previous value of any *_REF variable (for instance, the X/Y/Z_REF variables are not
necessarily at 0,0,0).
Several side effects of the REF change are listed below:
• The next connection (of the current procedure) will use the “tool change” scenario, even if the tool
has not been changed. This is the safest connection scenario (and suitable here, since the
machine head was probably moved aside to allow the new part setup).
• RTCP (M5_RTCP_M128) is turned off (in case it was on). This is only relevant to intelligent 5X
machines.
• The Output UCS is reset (to the new REF) in case it was different. This is only relevant to
intelligent 5X machines.
• All system vectors (like HOME, CURPOS or ORIGIN) are recalculated to conform to the new REF
UCS.
CimatronE 10.0 GPP2 User Guide ⎪7

• The machine simulator does not support multiple part setups. When using multiple setups,
machine simulation cannot be used!
Note: Changing the REF UCS in the middle of the run is a delicate and very advanced action. It is best
used with 3-axis machines only.
CimatronE 10.0 GPP2 User Guide ⎪8

1.4 GPP2 Toolpath Points

Inside CimatronE, the toolpath points are defined relative to each procedure UCS (also known as the
procedure origin). GPP2 converts every tool point to the REF coordinate system.
ROT_MAT and TRANS_MAT are not used in GPP2. All conversions between the original procedure
UCS and the REF UCS are being taken care of by GPP2.
The following diagram shows a tool point in the REF UCS (showing both position and orientation), as
well as the original position vector in the procedure UCS.

Tool point in GPP2

Original point
vector inside
Position CimatronE Toolpath
vector
(X,Y,Z)

Y
Z Procedure
Orientation (origin) UCS
vector Y Z
(I,J,K) X
(0,0,0)
X
REF UCS

1.5 Blocks and Qualifiers

GPP2 is a programming environment based on toolpath blocks and execution of specific code in
response to each block. The code is defined in the post-processor EX2 file, and is executed when
each block is invoked.
Some blocks have optional qualifiers, which may affect the required output. For instance, the “TOOL
CHANGE” block has a qualifier called “first”, which is used on the first time the block is called (first tool
change).
When GPP2 executes a block with a qualifier, it follows the following algorithm:
• It first looks for a block definition in the EX2 program that includes the specific qualifier (for
instance, TOOL CHANGE: first:). If that block is found, the commands listed in it are executed.
• If such a block does not exist in the EX2 program, GPP2 looks for the same block but without the
qualifier (the generic block, for instance, TOOL CHANGE:). If such a block is found, it is executed.
• If no generic block is found, nothing is executed, and GPP2 simply moves on to the next toolpath
block.
CimatronE 10.0 GPP2 User Guide ⎪9

Therefore, it is important to make the distinction between how a block is invoked (with or without a
qualifier) and how it is eventually executed (that depends on the actual structure of the EX2 program).
Note: the order of blocks in the program file has no effect on the logic of execution.
There are some important exceptions in the block execution logic described above.
One of them relates to the LINEAR MOTION block. The LINEAR MOTION block has many qualifiers, 2
of them are used for rapid motions – fast: and fastlencomp:. For these qualifiers, GPP2 defines
a “two-level hierarchy” for selecting the block to be executed.
• In case the block is invoked with the fastlencomp: and the exact block cannot be found in the
program, GPP2 will attempt to execute the block with the fast: qualifier.
• If a block with the fast: qualifier cannot be found either, GPP2 will attempt to execute the block
with no qualifier.
• The two-level hierarchy allows the GPP developer to write a single block LINEAR MOTION:
fast: that handles all the “fast” qualifiers. Without that logic, these blocks (fastlencomp:)
would “fall through” to the standard (feed) LINEAR MOTION block (with no qualifier).
A two-level hierarchy is also used with the CYCLE block. If the toinit: qualifier is invoked, and no
such block exists, GPP2 will attempt to execute the on: qualifier block before defaulting to the “no
qualifier” case.
toinint: Æ on: Æ none
With that logic, the GPP developer can write one CYCLE: on: block that handles both qualifiers,
toinit and on.
Also, the CYCLE: off: block does not fall back to the CYCLE: block, since they really represent
different things. In order for a CYCLE “off” block to be executed, the EX2 program must have a
CYCLE: off: block defined.
Similarly the POST SCRIPT: stopped: block does not fall back to the POST SCRIPT: block, since
they correspond to two very different situations (successful and failed run). In order for the “stopped”
block to be executed, the EX2 program must have a POST SCRIPT: stopped: block defined.
CimatronE 10.0 GPP2 User Guide ⎪10

1.5.1 List of Blocks and Qualifiers

The following table lists all GPP2 blocks. A more complete list, with all the qualifiers and their use, is
provided in the GPP2 Blocks, Constants and Variables manual.

BEGINNING OF CONNECT: END OF SUB: PROC FIRST POINT:

BEGINNING OF PROC: END OF TAPE: RECONFIG MACHINE:
BEGINNING OF SUB: END OF TOOLPATH: RESET AXIS:
BEGINNING OF TAPE: INSERT WITH: SET UCS:
BEGINNING OF TLPATH: INSERT WITHOUT: START PROC:
CIRCULAR MOTION: LINEAR MOTION: STARTUP:
CUTTER COMPENSATION: MACHINE CONTROL: SUBROUTINE CALL:
CYCLE: MESSAGE: SUBROUTINE RETURN:
END OF CONNECT: MOVE TO SAFE: TOOL CHANGE:
END OF FILE: ORIGIN CHANGE:
END OF PROC: POST SCRIPT:

1.5.1.1 Non-Supported Old Blocks

Several blocks that were supported in old GPP are no longer supported in GPP2:
• AXIS CHANGE (the number of axes is available at the Beginning of Proc block)
• CONSTANT SPEED (lathe only)
• COOLANT (the coolant data is available at the Beginning of Proc block)
• DWELL
• FEED (the feed data is available at the relevant motion blocks)
• GROOVE CYCLE (lathe only)
• NIBBLE (punch machining only)
• NURBS (for now, any nurb motion is converted to linear motions)
• SPIN (spindle data is available at the Beginning of Proc block)
• START STRING
• START THREAD (lathe only)
• STOP POINTS (Wire EDM only)
• THREAD CANNED CYCLE (lathe only)
• THREAD CYCLE (lathe only)
• THREAD STEP (lathe only)
CimatronE 10.0 GPP2 User Guide ⎪11

• TOOL CHANGE MESSAGE

• TRANSFORMATION
• WIRE (Wire EDM only)
• Z_SURFACE (instead, full connections are provided between cycles, if needed)
Finally, user-defined blocks are currently not supported in GPP2.

1.6 Procedure Header Blocks

Several blocks are invoked and executed at the beginning of each procedure (the procedure
“header”). It is important to understand their order, as well as the type of information that is available in
each one. This becomes especially critical in 4/5X positioning post-processors.
A procedure starts with the following sequence of blocks (in that order).

Block Comments
BEGINNING OF PROC: Additional variables available with GPP2
ORIGIN CHANGE: Optional (only if origin has changed from last procedure)
TOOL CHANGE Optional (only if tool has changed from last procedure)
START PROC: Last block before the connection motions
Connection Blocks A series of blocks that take the tool to the procedure start
point (tool above the first actual cutting point, and properly
oriented). See discussions about GPP2 connections.
PROC FIRST POINT: A block just before the actual procedure motions start

Note that some of the blocks generated by old GPP are missing here (e.g., FEED, SPIN, COOLANT).
These blocks are not needed in GPP2.
Instead, the complete information regarding the feed rate (MCH_FEED), spindle settings (SPIN_DIR and
SPIN_SPEED), and the procedure coolant (MCH_COOL) are provided as new variables in the
BEGINNING OF PROC block. The data is used later, whenever appropriate for the specific post
processor and machine.
Notes:
1. START PROC is a convenient place to do things just before the motions start. For instance, the
spindle may be turned on. If subroutines are used for each procedure, this may also be a good
place to redirect the output and open a subroutine header (e.g., “O101”).
2. While ORIGIN CHANGE and TOOL CHANGE are optional, START PROC is guaranteed to be
invoked by GPP2.
3. PROC FIRST POINT is the place where the actual procedure motions are about to start. After
that block, GPP2 will perform the final approach to the material. It may be a convenient place
to turn the coolant on.
CimatronE 10.0 GPP2 User Guide ⎪12

1.6.1 Multi-Tool Procedures

CimatronE supports multi-tool procedures, where several tools of different lengths are used within the
same NC procedure.
GPP2 breaks such multi-tool procedures to multiple procedures, each with its own tool. It creates the
complete procedure “structure”, as described above, for each one. This includes the tool change and
connection part. Of course, much of the data is replicated from the original first procedure.
In the TOOL CHANGE block of the additional procedures (all except the first), a new qualifier is used,
multitool:, to indicate that this procedure is actually part of a multi-tool CimatronE procedure.

1.7 GPP2 Connections

This is a new and very large topic. GPP2 connections are series of motions and machine control
operations generated by GPP2 in order to connect between toolpath points in a safe and predictable
way.
Connections are mostly required in 4/5X machines, where small changes in orientation may translate
into large rotations of the table and/or head, and to large displacements that result from them.
However, GPP2 applies some connections in all procedures, including 2.5X and 3X ones.
GPP2 applies connections in the following situations:
• At the beginning of each procedure, bringing the tool to the point and orientation where the actual
procedure starts.
• Between drill cycles, when certain conditions are met (e.g., large shift in Z, large rotation). See a
detailed discussion later in this manual regarding these conditions.
• In 5X milling, moving the tool between adjacent toolpath “segments”. In 5X continuous milling,
GPP2 effectively replaces all the rapid motions generated by CimatronE with GPP2 connections.
See detailed discussion regarding 5X connections in the 5X PP Manual.
• In 5X milling, when work has to be interrupted and the machine rotated because of reaching an
axis limit. GPP2 handles the full process, retracting from the material to safe height, rotating and
coming back to the material at the same point.
Note that the NC “CONNECT” procedure is an exception. Being a connection procedure by itself,
GPP2 does not try to connect to it or replace any of its motions. The CONNECT procedure is kept “as
is” by GPP2.
CimatronE 10.0 GPP2 User Guide ⎪13

1.7.1 The Connection Process

Every GPP2 connection process is enclosed between a BEGINNING OF CONNECT and END OF
CONNECT blocks. The actual connection takes place between these two blocks, and follows a
“scenario” that can be fully customized as described below.

1.7.1.1 Starting the Connection

In the BEGINNING OF CONNECT block, several important system variables provide information about
the connection that is about to take place.
CON_CONTEXT describes the context of the connection, and may receive one of the following
numerical values (predefined GPP2 constants):

Value Meaning

CON_AFTER_TOOL The connection takes place at the beginning of a procedure,

after a tool change.

CON_PROC The connection takes place at the beginning of a procedure (but

there was no tool change).
This value will also be used during 5X procedures for
connections between tool path segments.

CON_CYCLE The connection takes place between two canned drill cycles
(only happens if such a connection is needed).

CON_5X_SWAP The connection takes place during a 5X procedure, when the

machine must be rotated to swap between two solutions (due to
reaching of machine limits).

CON_SCENARIO is a string variable that contains the name of the scenario selected by GPP2 for this
connection. GPP2 will select one of its default scenarios, based on the context and “size” of the
connection, as well as several DF2 parameters. See more details below.
GPP2 will always select one of the following default scenarios: “short”, “long”, “through-safe” or
“tool-change”.
“Short” connections are quickest, as they take the shortest route between the two points. A “long”
connection takes a “higher” (thus safer) route between the points. A connection through the “safe
point” will first take the machine to a safe position, then move to the connection target point. A “tool-
change” scenario is selected after a tool change, where GPP2 assumes that the machine is already at
a safe point.
CON_ROTATION_A contains the magnitude (absolute value) of the rotation in the alpha axis, in
degrees. Similarly, CON_ROTATION_B contains the magnitude of the rotation in the beta axis. Both are
only applicable in 4/5X machines.
CimatronE 10.0 GPP2 User Guide ⎪14

CON_DISTANCE contains the distance between the connection start point and connection target point,
expressed in the REF coordinate system. Note that it is meaningless in connections after a tool
change (context is CON_AFTER_TOOL), since GPP2 does not really know where the tool is.
The EX2 program can change the value of the CON_SCENARIO variable to another name, during the
BEGINNING OF CONNECT block. That will instruct GPP2 to execute another connection scenario.

1.7.1.2 Choosing the Default Connection Scenario

GPP2 will choose the proper default scenario based on connection context, the rotary axes rotations,
and the connection distance.
For connections after a tool change (context is CON_AFTER_TOOL), GPP2 always selects the “tool-
change” scenario. This is a special scenario since GPP2 does not know where the tool really is.
With all other connections, the first decision GPP2 has to make is if this is a short or long connection.
All connections are short, unless they meet the criteria for a long connection, as specified by the
following variables:

LONG_CON_X Distance along the X axis, above which a connection is

defined as “long”.
LONG_CON_Y Distance along the Y axis, above which a connection is
defined as “long”.
LONG_CON_Z Distance along the Z axis, above which a connection is
defined as “long”.
LONG_CON_A Difference in the “alpha” angle, in degrees, above which
a connection is defined as “long”.
LONG_CON_B Difference in the “beta” angle, in degrees, above which a
connection is defined as “long”.

It is enough that one of the conditions is met to make a connection “long”.

It is possible to cause GPP2 to use connections through the safe point instead of a “short” or “long”
connection.
This is controlled by the SWITCH_TO_SAFE_CONNECT variable, which may take be assigned one of the
following values:
WHEN_TOOLCHANGE Do not convert short or long connections to through-safe.
WHEN_LONG_CON On every “long” connection
WHEN_EVERY_CON On every connection
If the criterion is met, GPP2 will switch the “short” or “long” scenario to “through-safe”.
CimatronE 10.0 GPP2 User Guide ⎪15

1.7.1.3 Procedure Connection Point

In milling procedures, CimatronE generates several rapid motions before the actual cutting motions.
The last rapid motions are used by GPP2 to determine the connection point as follows:
- The connection point is “above” the first cutting (feed rate) point, where “above” is measured
along the tool axis.
- The point has the same orientation as the first cutting point
An example is shown in the following image.

Rapid
motion

Feed
Connection motions
Point

In drill procedures, CimatronE generates no rapid motions before the actual cycles. The connection
point is defined at the “init” point of the first cycle.
• The connection point is above the first hole point, where “above” is measured along the tool axis.
The height is defined by the CYC_DZINIT variable.
• The point has the same orientation as the first drill cycle.
An example is shown in the following image.

Init Height
CYC_DZINIT

Connection
Point

First drill point

CimatronE 10.0 GPP2 User Guide ⎪16

1.7.2 Connection Scenarios

GPP2 applies connection based on flexible and programmable “scenarios”. That way, it is possible to
build the exact sequence of events per machine type or per user requirements.
A scenario is a sequence of “actions” performed by GPP2. There are two categories of actions: motion
actions, where the machine is actually moved and control actions where other things take place (e.g.,
the coolant can be turned off, or a 5X machine work-plane may be defined).
GPP2 has four built-in default scenarios. The EX2 program can change the behavior of the default
scenarios and/or add additional scenarios (with other names).
Connection scenarios are defined in the declaration part of the EX2 program, with the
CONNECTION_SCENARIO statement. As many scenarios as needed can be defined. Defining a
scenario with one of the default names (e.g., “short”) replaces the built-in definition. See the GPP2
Language Reference Manual for the details of defining scenarios.

1.7.3 The Default Scenarios

The built-in default scenarios are defined as follows:

1.7.3.1 Short Connection (Short Scenario)

The default short connection is composed of two out of the following three steps:
• Move Up, along the Z axis, to the height of the connection target point. This step is skipped if the
tool is already higher than the target point.
• Move sideways, along the XY axes, to the point above the connection target point. In 4/5X
machines, any necessary rotation of the alpha and beta axes also takes place during that step.
Multiple motions are allowed (see below).
• Move down, along the Z axis, to the target connection point. This step is skipped if the tool is
already at the target point after the second step.
All motions are rapid (G00). These steps are illustrated in the following diagram:

Move sideways Move sideways

P2 P1
Move up Move down
P1 P2

Short Connection 1 Short Connection 2

CimatronE 10.0 GPP2 User Guide ⎪17

1.7.3.2 Long Connection (Long Scenario)

The default long scenario is very similar to the short scenario, except that the first step goes up higher,
to the Z_HOME value. Here, we typically see the three steps taking place.
Note that the Z_HOME value is interpreted by GPP2 to be provided in the REF coordinate system.

Move sideways
Z_HOME

P1
Move down
P2

Long Connection

1.7.3.3 Connection after Tool Change (Tool-Change Scenario)

The default connection after tool change is composed of two steps only, since it assumes that the tool
is already in a safe very high position.
• Move sideways, along the XY axes, to the point above the connection target point. In 4/5X
machines, any necessary rotation of the alpha and beta axes also takes place during that step.
This motion cannot be broken to multiple linear motions (see below).
• Move down, along the Z axis, to the target connection point. Perform the linear motion block with a
“cutter length compensation” qualifier.

Unknown Move sideways

“safe” position
Cutter Length
Compensation

Move down
P2

Connection after Tool Change

The linear motions are rapid (G00).

CimatronE 10.0 GPP2 User Guide ⎪18

1.7.3.4 Safe Connection (Through-Safe Scenario)

The default connection through the safe position is composed of the following three steps.
• Move to the safe position, “in all axes” (not just in Z). This is done by invoking the new MOVE TO
SAFE GPP2 block.
• Move sideways, along the XY axes, to the point above the connection target point. In 4/5X
machines, any necessary rotation of the alpha and beta axes also takes place during that step.
This motion cannot be broken to multiple linear motions (see below).
• Move down, along the Z axis, to the target connection point.
Note that the last two steps are very similar to the “tool-change” scenario, except that here cutter
length compensation is not performed. The linear motions are rapid (G00).

Unknown Move sideways

“safe” position
NO Cutter Length
Compensation
Move
to Safe Move down
P2
P1

Connection through Safe Position

1.7.4 Breaking Sideways Moves to Multiple Motions

GPP2 can break the sideways motion shown in the scenarios to multiple motions, in order to limit the
motion or rotation size in each linear motion. This feature is controlled by the following variables:

CON_MAX_ALPHA Maximum change in “alpha”, in angles, allowed in one

connection linear motion
CON_MAX_BETA Maximum change in “beta”, in angles, allowed in one
connection linear motion
CON_MAX_DIST Maximum distance allowed in one connection linear
motion

GPP2 will calculate the number of steps necessary so that all the conditions will be met, and none of
the changes (alpha, beta or distance) will exceed the value specified in the corresponding variable.
For instance, the following diagram shows a sideways motion broken into three parts, to limit the angle
rotation.
CimatronE 10.0 GPP2 User Guide ⎪19

Move sideways, in 3 motions

Move up
P1
Move down
P2

Note that this option cannot be used when moving from the safe position or after a tool-change, since
the start point is not known (hence no intelligent decisions or division can be made). This is
implemented in the various default scenarios.
CimatronE 10.0 GPP2 User Guide ⎪20

1.8 Subroutines
CimatronE NC generates subroutines for several NC procedures, such as Pocket and Profile. GPP2
fully supports these subroutines, as well as “exploding” them (replacing subroutine calls with the actual
commands listed in the subroutine) if necessary.

1.8.1 Dealing with Machine Capability

Not all machines can handle subroutines the same way. Some machines can only handle subroutines
in the XY plane (constant Z value). Other can handle subroutines in all major planes (XY, YZ and ZX),
while others can handle subroutines in any plane.
A new DF2 file parameter, “Output Subroutines by Planes”, allows the GPP2 user to specify how
subroutines are handled. It is a multi-choice parameter, as follows:
• Never: all subroutines are exploded into individual motion commands.
• XY Plane: subroutines are used in the XY plane only. All other are exploded.
• Major Planes: subroutines are used in all major planes. All other are exploded.
• Any Plane: subroutines are used in any plane, and never exploded.
The selected option is copied to a GPP2 system flag, SUBS_CTRL_BYPLANE, which can be changed by
the GPP2 program in order to override the original setting. After the system flag is initialized from the
DF2 parameter, GPP2 will follow the setting of the SUBS_CTRL_BYPLANE variable.
In order to set or check the value of SUBS_CTRL_BYPLANE, it is advised to use the predefined GPP2
constants, DF2_NONE, DF2_XYONLY, DF2_MAJORPLANES and DF2_ANYPLANE. They correspond to the
four options listed above.
Note: GPP2 only checks this system flag at the beginning of each procedure, after the execution of the
PROC FIRST POINT block. Therefore, the right time to set this system flag is in the EX2 program for
that block of before.

1.8.2 Subroutine Numbers

With GPP2, it is possible to define the first subroutine number (in GPP, it is always 1). A new DF2 file
parameter, “First Subroutine Number”, allows the GPP2 user to define any integer number for the first
subroutine. Subsequent subroutine numbers increment by 1 each time a new subroutine is
encountered.
The subroutine number is presented in the SUB_NUMBER system variable. With GPP2, the number is
available both during the definition of the subroutine and during each call to the subroutine.
CimatronE 10.0 GPP2 User Guide ⎪21

1.9 Subroutine Blocks

In case a subroutine is used, the following blocks are being generated, in that order:

Block Use and comments

BEGINNING OF SUB: This block is executed once before any call to the
subroutine takes place. It precedes all the actual
subroutine body motion blocks.
Subroutine body blocks These are the linear and circular motion blocks that define
the subroutine body.
END OF SUB: This block is executed once after all subroutine body
blocks.
SUBROUTINE CALL: One or more subroutine call blocks are generated, one for
each Z level.
SUBROUTINE RETURN: This block is invoked immediately following each
SUBROUTINE CALL block. It is useful for commands that
should be executed after the subroutine is called (and after
it returns).

Notes:
1. The order of execution is different than in old GPP. With GPP2, the subroutine is processed
before any call to it is performed (in GPP, the first subroutine call is invoked before the
subroutine definition). That way, GPP2 can “study” the subroutine and record its affect on the
tool position and its expected execution time (both need to be known when a call to the
subroutine takes place).
2. Unlike old GPP, the SUB_NUMBER parameter is available in the BEGINNING OF SUB block,
and can be used as part of the output. The old practice of defining a user variable that is used
instead of SUB_NUMBER is not necessary. Furthermore, setting such a number in the
subroutine call block is too late, since the subroutine definition takes place before the call.
3. In each SUBROUTINE RETURN block, GPP2 presents the correct tool last position
(X_LASTPOS, etc.). GPP2 calculates the motions that will be executed at runtime when the
subroutine is called, and sets the variables accordingly.
CimatronE 10.0 GPP2 User Guide ⎪22

1.9.1 Post-time vs. Runtime

It is important to note the exact differences between what happens during post-processing time (post-
time) and what happens on the NC machine, at runtime. The following table highlights these
differences.

Block Post-Time Runtime

BEGINNING OF Called once at the beginning of Not relevant
SUB: subroutine definition, used to
output the subroutine “header”
G-code.
Subroutine body Called and processed once, The subroutine body G-
blocks during subroutine definition code is executed each time
only. the subroutine is called
END OF SUB: Called once, at the end of Not relevant
subroutine definition, used for
optional “cleanup” work
SUBROUTINE CALL: Called multiple times, used to The output G-code is
output the G-code that calls the executed multiple times,
subroutine on the machine. The and calls the subroutine on
subroutine body blocks are not the machine
executed here!
SUBROUTINE Called immediately after each In case any G-code was
RETURN: SUBROUTINE CALL block. output in this block, it is
executed after the
subroutine return.
CimatronE 10.0 GPP2 User Guide ⎪23

1.9.2 Location of Subroutine Body G-Code

The subroutine body G-Code output is located in one of two places:
• At the end of the G-Code file. Subroutine body commands are processed early in the posting
process (even before any call to the subroutine is processed), but the output is stored internally
until the end of the run. Then, it is copied to the end of the G-Code file (it may not be the first file, if
a “tape cut” operation took place during the run). This is important to remember – the order of
blocks in the output file does not represent the order of processing in case subroutines are
involved.
Note that the subroutine data is copied to the end of the file before the “END OF FILE” block is
executed. Therefore, any OUTPUT generated in the END OF FILE block (e.g., the “%” character)
will be placed after the subroutine G-Code.
• In separate files, one per subroutine, with extension “._snn”, where nn is a serial number, starting
from 01. In order to direct the subroutine G-code to separate files, the GPP2 user has to check the
DF2 file parameter “Subroutines in Separate Files”.
If separate files are requested, GPP2 will take a decision regarding the file extension, based on
how many subroutines exist in the toolpath being processed.
• If the number of subroutines is up to 99, the extension will be of the form “._snn”, from “._s01”
to “._s99”.
• If the number of subroutines is between 100 and 999, a digit is added to the extension, ranging
from “._s001” to “._s999”. If a 1000 or more subroutines exist, yet another digit is added (from
“._s0001” to “._s9999”).
CimatronE 10.0 GPP2 User Guide ⎪24

1.10 Linear Motion

Linear motion blocks make up most of the toolpath. This section gives more detail on how they are
processed in GPP2

1.10.1 Qualifiers
There are seven potential qualifiers used in GPP2 linear motions.
Basic feed-rate linear motions blocks come with no qualifier. Most of the rapid motions come with the
fast: qualifier (except cutter length compensation, see below).
Four qualifiers are provided for cutter compensation purposes. They should be used to turn cutter
compensation on and off (if relevant to a given procedure).
• normappr: Normal approach to a contour
• normretr: Normal retract from a contour
• ltangappr: Before a tangential approach to a contour
• ltangretr: After a tangential retract from a contour
There are two cutter length compensation (“G43”) qualifiers:
• fastlencomp: Rapid motion where cutter length compensation should be applied
• lencomp: Feed-rate motion, for the same purpose (see rapid to feed)
GPP2 generates the cutter length compensation as part of the connection process from the safe
position (typically takes place after tool change).
Recall the two-level hierarchy regarding linear motions qualifiers:
fastencomp Æ fast Ænone
If a block is invoked with the fastlencomp: and the exact block cannot be found in the program,
GPP2 will attempt to execute the block with the fast: qualifier. Only if that block is missing too,
GPP2 will execute the LINEAR MOTION block with no qualifier.
CimatronE 10.0 GPP2 User Guide ⎪25

1.10.2 Process Rapid as Feed

A DF2 file parameter, “Use Feed Instead of Rapid”, allows the GPP2 user to replace every rapid linear
motion (“G00”) with a feed linear motion (“G01”), using a predefined very fast feed rate (also a DF2 file
parameter).
If that option is checked, the following actions take place in GPP2 when a rapid motion block is
encountered:
• A special FEED block is inserted before the linear motion block, with the new (very fast) feed rate.
• The linear motion machine code parameter (LIN_MOV) is replaced with the appropriate code for
feed operation.
• The “fast” qualifiers are replaced by regular feed qualifiers. Specifically, fastlencomp: is
replaced by lencomp:, and fast: is replaced by no qualifier.
• The linear motion block is executed.
• After the rapid motion block, or after several such blocks (in case they come in a succession),
another FEED block is inserted, restoring the feed rate to its original value before the change to the
very fast rate.

1.11 Circular Motion

GPP2 can handle circular motions at any plane, both perpendicular to the tool axis or in the same
plane as the tool axis.
Most of the circular motion blocks generated in CimatronE are simple “horizontal” arcs, where the arc
takes place in the procedure XY plane. However, each procedure may have its own rotated origin
UCS, and these simple XY arcs may turn out to be in any plane (compared to the REF UCS).
GPP2 handles a circular motion in one of three ways:
• Present it “as is” to the EX2 program, for output.
• Break it into multiple “quadrant-limited” arcs, where each arc is limited to one quadrant of the arc
plane.
• Break it into multiple linear motions, approximating the arc in a given tolerance.
CimatronE 10.0 GPP2 User Guide ⎪26

1.11.1 Dealing with Machine Capability

Not all machines can handle circular motions the same way. Some machines can only handle arcs in
the XY plane (constant Z value). Other can handle arcs in all major planes (XY, YZ and ZX), while
others can handle arcs in any plane.
A new DF2 file parameter, “Output Arcs by Planes”, allows the GPP2 user to specify how circular
motions are handled in GPP2. It is a multi-choice parameter, with the following options:
• Never: all arcs are broken into linear motions.
• XY Plane: arcs are used in the XY plane only. All other are broken into linear motions.
• Major Planes: arcs are used in all major planes. All other are broken into linear motions.
• Any Plane: arcs are used in any plane, and never broken into linear motions.
The selected option is copied to a GPP2 system flag, ARCS_CTRL_BYPLANE, which can be changed by
the GPP2 program in order to override the original setting. After the system flag is initialized from the
DF2 parameter, GPP2 will follow the setting of the ARCS_CTRL_BYPLANE variable.
In order to set or check the value of ARCS_CTRL_BYPLANE, it is advised to use the predefined GPP2
constants, DF2_NONE, DF2_XYONLY, DF2_MAJORPLANES and DF2_ANYPLANE. They correspond to the
four options listed above.
Note that this parameter also affects arcs generated by the Arc Fitting algorithm that converts
sequences of linear motions to arcs. If the arc fitting algorithm creates arcs in the Major Planes (ZX
and YZ), but this parameter only supports arcs in the XY plane, then all these arcs will be broken back
to linear motions (which makes no sense).
Make sure that this parameter is consistent with the arc fitting algorithm!

1.11.2 Planes, Axes and Angles

Circular motion always takes place on a given plane, from a start angle to an end angle. The arc angle
is the difference between these angles. The arc axis is the vector perpendicular to the arc plane. In
addition, the direction of the motion is either Clockwise (CW) or Counter-Clockwise (CCW). CCW
motion is defined by a positive arc angle, while a CW motion is defined by a negative arc angle. For
instance, a CCW from angle 10 to 40 is defined as an arc of 30 degrees (CCW). The reverse motion,
from 40 to 10 is defined as an arc of -30 degrees (CW).
The following diagram illustrates the arc parameters for a CCW motion.
CimatronE 10.0 GPP2 User Guide ⎪27

CCW Arc Arc Axis

Arc Plane Center

Start Angle End Angle

GPP2 defines three major planes. On each plane, it is important to define the axis which serves as the
zero angle, as well as the direction for positive angle motion (CCW).

Major Plane Angle “zero” Direction of Counter-Clockwise Motion

X-Y X axis XÆY
Y-Z Y axis YÆZ
Z-X Z axis ZÆX

Note the Z-X axis. It is defined from Z to X, not the other way around. This is consistent with the way
right-hand coordinate systems are defined.
The three major planes are illustrated in the following diagram.

The X-Y Plane The Y-Z Plane The Z-X Plane

Z X Y
Y (angle 90) Z (angle 90) X (angle 90)

CCW CCW CCW

X (angle 0) Y (angle 0) Z (angle 0)

Note that each major plane may be viewed from both sides. For instance, the X-Y plane is typically
viewed from the Z axis (from the “top”). For circular motions, the arc axis is aligned with the Z axis. But
the same plane could also be viewed from the –Z axis (from “below”), in which case the arc axis is
reversed.
CimatronE 10.0 GPP2 User Guide ⎪28

For the “reverse” major planes, the meaning of CW and CCW motion is reversed. The following
diagram illustrates this duality on the X-Y plane. Consider a motion from the X axis (angle 0) to the Y
axis (angle 90). Two tools are shown, one coming from the top, with its orientation vector aligned with
the Z axis (0,0,1), while the other coming from the bottom, with its orientation vector aligned with the –
Z axis (0,0,-1). It can be clearly seen that the same motion, from 0 to 90, represents a CCW motion for
the first tool, and a CW motion for the second.

Arc Axis = Z (0,0,1)

Tool
CCW
Z
Y (angle 90)

X (angle 0)
Tool CW (!!!)

Arc Axis = -Z (0,0,-1)

Angles on a plane are cyclic by nature. Typically, the angles in GPP2 range from -180 to 180.
However, GPP2 will also use angles ranging up to 360, in order to keep the definition of CW and CCW
motions consistent. Specifically, GPP2 will choose the angles that satisfy the following rules:
• In CCW motion, the end angle is always bigger than the start angle.
• In CW motion, the end angle is always smaller than the start angle.
CimatronE 10.0 GPP2 User Guide ⎪29

The following diagram and table shows the angles used by GPP2, as well as how GPP2 presents CW
and CCW motions in simple and complex cases:

90

Point B

180 0 (360)
Point C Point A

Point D

-90 (270)

Motion From Direction Arc Angle Start Angle End Angle

AÆB CCW 90 0 90
AÆB CW -270 360 90
BÆA CCW 270 90 360
BÆA CW -90 90 0
AÆC CCW 180 0 180
AÆC CW -180 360 180
CÆA CCW 180 180 360
CÆA CW -180 180 0
BÆD CCW 180 90 270
BÆD CW -180 90 -90
DÆB CCW 180 -90 90
DÆB CW -180 270 90

Note that the direction is defined for the “standard” arc axis and the standard major planes. When
viewing the plane from the reverse direction, all directions are reversed (CW becomes CCW, and vice
versa).
CimatronE 10.0 GPP2 User Guide ⎪30

Full 360 degrees are supported. The arc angle will be 360 for CCW arcs, and -360 for CW arcs.
Note that in full 360 degrees circles, the end point is the same as the start point. As most post-
processors define these variables (X/Y/Z_CURPOS) as modal, they will not be set by this circle (as
their value does not change). This will result in no output for the end point.
In order to overcome this, for 360 degree circles GPP2 will force both the center (X/Y/Z_CENTER) and
end point (X/Y/Z_CURPOS) variables to be set “on”.

1.11.3 CimatronE Arc Planes

The circular motion block does not explicitly state the arc axis vector (orientation). It is implied by the
arc plane, as represented in system variable ARC_PLN.
GPP2 receives the arc plane information from the CimatronE toolpath expressed in the procedure
UCS. GPP2 translates it to the REF UCS. GPP2 assumes that the planes defined in CimatronE are
the “normal” planes (coming from “above”) and not the reverse planes. Therefore, the toolpath arc
plane is interpreted as follows:

Toolpath Arc Plane Plane Arc Axis (in Proc UCS)

ARC_PLN = 1 X-Y plane Z axis (0,0,1)
ARC_PLN = 2 Z-X plane Y axis (0,1,0)
ARC_PLN = 3 Y-Z plane Z axis (1,0,0)

The arc axis is rotated to convert it to the REF UCS, and a new ARC_PLN value is calculated and
presented to the EX2 program. The same values are used.
Note that in the EX2 program, the same values are used for both the major plane and the reverse
plane. Only the arc direction is reversed.

1.11.4 Limiting Arcs to Quadrants

In some old controllers, it is necessary to limit arcs to one quadrant of the plane. For instance, an arc
from angle 0 to angle 135 has to be broken into two arcs (each limited to one quadrant) – 0 to 90, and
90 to 135.
GPP2 will limit arcs to quadrants in all major planes, if the DF2 file parameter “Arcs Limited to
Quadrants” is checked. It will break each arc that crosses a quadrant boundary to multiple consecutive
arcs, and generate multiple Circular Motion blocks.
It is not possible to limit an arc to quadrants if the arc is not in one of the major planes. Simply,
quadrants are not well defined if the arc axis is not aligned with one of the major axes. Therefore, if
“Any Plane” arcs are allowed, they will not be limited, even if the DF2 file flag is checked. This is not a
real limitation – the old controllers which need quadrant breakdown do not support arcs in any planes.
CimatronE 10.0 GPP2 User Guide ⎪31

1.11.5 Limiting Arc Angles

GPP2 can limit the angle of a single arc. Larger arcs will be broken into smaller multiple arcs, so that
the angle of each one does not exceed the maximum allowed angle.
This capability is useful, for instance, when the user wants to avoid arcs that extend beyond 180
degrees (in some controllers, such arcs require a negative radius).
The maximum angle is defined by a new DF2 parameter, “maximum angle for single arc”. The DF2
parameter is copied into a system variable, ARCS_MAX_ANGLE, which the EX2 program can access
and modify if needed.
If the maximum value is set to 360 degrees, arcs will never be broken into smaller ones. If the number
is smaller, GPP2 will check each arc and will break larger arcs (CW or CCW) into a set of equal arcs.
For example, if the maximum arc angle is 60 degrees, and GPP2 encounters a CW arc of -150
degrees (CW arcs use negative angles), it will break the arc into three equal arcs of -50 degrees
each.
The “Arcs Limited to Quadrants” parameter overrides the “Maximum Angle” parameter. If arcs are
limited to quadrants, then the maximum angle feature is disabled.

1.11.6 Breaking Arcs to Linear Motions

GPP2 can break any arc to linear motions, in every arc plane. There are several cases where GPP2
will break an arc into linear motions:
• If the arc is in a plane that is not supported by the machine (based on the ARCS_CTRL_BYPLANE
system flag)
• If the arc radius is too large to be handled by the machine. This feature is turned on through a DF2
parameter. The large radius value (above which the arc is broken) is also a DF2 parameter, but
can be later overridden by the GPP2 program through the system flag ARCS_LARGE_RAD.
CimatronE 10.0 GPP2 User Guide ⎪32

• If the arc is too small (based on its radius or its length). Here, the arc is simply replaced by one
linear motion, from its start point to its end point. This feature is turned on through a DF2
parameter.
o The small radius value (below which the arc is replaced by a linear motion) is set
through a DF2 parameter that can be later overridden by the GPP2 program through
the system flag ARCS_SMALL_RAD.
o GPP2 also checks the arc length. The minimum length (below which the arc is replaced
by a linear motion) is set through a DF2 parameter that can be overridden by the GPP2
program through the system flag ARCS_SMALL_LEN.
o The arc will be replaced with a single linear motion if the feature is turned on and either
its radius is too small or its length is too small.
If instructed to replace an arc with multiple linear motions, GPP2 will use the following algorithm:
• The interpolation tolerance is calculated based on a DF2 parameter that defines if the tolerance is
an absolute value or is dependent on the NC procedure tolerance.
o If absolute, GPP2 will use the value of the CIRC_TOL system flag.
o If procedure-dependent, GPP2 will use the part surface tolerance or contour tolerance,
whatever is available. These values are specified at the BEGINNING OF PROC block. If
both are available in a given procedure, GPP2 will use the smaller number.
o Even if procedure-dependent, GPP2 will use CIRC_TOL as an upper limit for the
tolerance (it will never be higher than this value).
• The arc is broken into a number of identical length segments, based on the arc radius, angle and
the calculated tolerance.
• The number of segments may be increased if the DF2 file parameter “Arcs Linear Interpolation,
Minimum Segments” is higher than the calculated number. This number may be overwritten by the
GPP2 program through system flag ARCS_MIN_SEGS.
CimatronE 10.0 GPP2 User Guide ⎪33

• The number of segments may also be increased if the resulting segments are too long. A DF2
parameter defines the maximum length of each segment. The length may be overwritten by the
GPP2 program through system flag ARCS_MAX_SEGLEN.
• Finally, when the number of segments has been set to satisfy all the requirements, intermediary
points are calculated along the arc, and multiple Linear Motion blocks are created, following the
points from the arc start point to the arc end point.

Arc broken to four linear segments Intermediary

points
End

Radius

Center Start
Tolerance
CimatronE 10.0 GPP2 User Guide ⎪34

1.12 Converting Linear Motions to Arcs

GPP2 can convert a series of linear motion points to an arc in one of the major planes. This feature is
used when a smaller G-Code file is required.
The process is controlled through a new section in the DF2 file, which defines the following algorithmic
parameters:
• The planes in which GPP2 searches for arcs. This parameter may be set to “Never” (no arc fitting
is done), “XY Only” (arcs are searched in the XY plane only) or “Major Planes” (arcs are searched
in the three major planes).
• The tolerance used for the algorithm. GPP2 will only convert a set of linear motions to arcs if all of
them fit within the given tolerance. It is possible to use the procedure tolerance for that purpose, or
an absolute value.
• The minimum number of points that “qualify” for an arc. GPP2 will only convert linear motions to
arcs if it can find a set of that size. The minimum number allowed is 6 points. The higher that
number is set, the more difficult it will become to GPP2 to fit arcs to linear motion sets.
Note that this is only the minimum number of points used for arc fitting. Whenever an arc is found,
GPP2 will try to find the longest sequence of points in which an arc can be fitted within tolerance.
So, setting this number low does not mean GPP2 will not generate arcs out of very large
sequences – if the geometry is cylindrical.
• Are helical arcs supported or not. Helical arcs are arcs in the XY plane (only) that also have a
continuous Z slope. They are created by CimatronE in helical plunge motions. CimatronE will
generate a very large number of linear motions to represent these helical motions. If that option is
turned on, GPP2 will look for such arcs as well as regular arcs.
When a helical arc is created, it has the following characteristics:
• The end point Z value is different that the center point Z value. The center Z value is kept the same
as the start Z value, but the end point will be lower.
• The ARC_HELICAL system variable will be set to TRUE_to indicate that this arc is helical. It is
FALSE_ in all other arcs.
In order to ensure tool path continuity, any arc generated by the algorithm must exactly cross the two
end points of the sequence. All other “middle” points must be within tolerance distance to the arc.
The arcs created by the arc fitting mechanism are subject to all the arc processing features described
above. For instance, if arcs are limited to quadrants, these arcs will also be split to quadrants. If arcs
are limited to a given angle, then these arcs will also be split to multiple arcs.
CimatronE 10.0 GPP2 User Guide ⎪35

1.13 Drill Cycles

1.13.1 Cycle Qualifiers

The CYCLE block has the following qualifiers:
The two “start” qualifiers, on: and toinint: are used on the first hole in a series of holes. This is
where the machine cycle is turned on.
The difference between the two qualifiers is the retract point, as identified by the CYC_RETR code.
• If the retract is to the “clear” height, the on: qualifier is used.
• If the retract is to the “init” height (usually higher), then the toinit: qualifier is used.
Many times, the same commands are used in both cases. For that reason, GPP2 uses a two-level
hierarchy regarding the cycle qualifiers.
toinint: Æ on: Æ none
If the retract code calls for a toinint: block, but that specific qualifier does not exist in the EX2
program, GPP2 will attempt to use the block with the on: qualifier. Only if that one does not exist
either, it will default to the block with no qualifier. That way, a single on: block can handle both cases
when a sequence of holes has to start.
All the cycles that follow the first one come with no qualifier.
At the end of each series of holes, GPP2 generates a cycle off: block. No meaningful coordinates
are provided in that block – it is meant to turn the machine cycle off.
Note: the cycle off: block must be explicitly matched in the EX2 program. If that block is not found,
GPP2 will not invoke the “no qualifier” cycle block.
The tree special qualifiers (specialon, special and specialoff) are used for special cycles such
as thread cycle (when the CYCLE_SUB is not 1).
The default behavior of these qualifiers is non-standard, as follows:
CYCLE: specialon: will default to execute CYCLE: special: block
CYCLE: special: no default (GPP2 will not invoke the “no qualifier” cycle block)
CYCLE: specialoff: no default
CimatronE 10.0 GPP2 User Guide ⎪36

1.13.2 Dealing with Machine Capability

Not all machines can handle canned drill cycles the same way. Some machines can only handle drill
cycles in the XY plane (constant Z value). Other can handle drill cycles in all major planes (XY, YZ and
ZX), while others can handle them in any plane.

A new DF2 file parameter, “Output Cycles by Planes”, allows the GPP2 user to specify how drill cycles
are handled in GPP2. It is a multi-choice parameter, with the following options:
• Never: canned drill cycles are not supported, in any plane.
• XY Plane: drill cycles are supported in the XY plane only.
• Major Planes: drill cycles are supported in all major planes.
• Any Plane: drill cycles are supported in any plane.
The selected option is copied to a GPP2 system flag, CYC_CTRL_BYPLANE, which can be changed by
the GPP2 program in order to override the original setting. After the system flag is initialized from the
DF2 parameter, GPP2 will follow the setting of the CYC_CTRL_BYPLANE variable.
In order to set or check the value of CYC_CTRL_BYPLANE, it is advised to use the predefined GPP2
constants, DF2_NONE, DF2_XYONLY, DF2_MAJORPLANES and DF2_ANYPLANE. They correspond to the
four options listed above.
Unlike subroutines or arcs, where GPP2 can convert them to something else in case they are not
supported on a given plane, there is no such built-in mechanism for cycles. The way to “simulate” a
canned drill cycle may vary from machine to machine, and cannot be easily automated inside GPP2.
The burden of handling non-supported cycles is left to the EX2 programmer.
GPP2 will set “on” a special new system variable, CYC_MANUAL, which indicates that a given cycle
block is not supported by the machine, based on the cycle plane and the DF2 file parameter. In cases
where the cycle is supported, the system variable will be set to “off”. The EX2 program should execute
different commands based on the set status of CYC_MANUAL.
CimatronE 10.0 GPP2 User Guide ⎪37

1.13.3 Inter-Cycle Connections

In simple drill procedures, there is no need for any special connection between successive cycles. All
that GPP2 has to do is provide the next hole coordinates, and the machine moves there and drills the
hole.
In some case, a more elaborate and careful connection may be required:
• When there is a big height difference between the two holes (where height is measured along the
tool axis)
• When there is a change in orientation between the two holes (5X drill)
• When the distance between the two holes is very large
GPP2 supports several variables that control if a connection will take place between two successive
holes.

CYC_CON_MINZ Inter-cycle connection is created if the delta in “Z” between

the holes is equal to or less than this value.
The “Z” values are measured along the tool axis.
CYC_CON_MAXZ Inter-cycle connection is created if the delta in “Z” between
the holes is equal to or greater than this value.
The “Z” values are measured along the tool axis.
CYC_CON_DIST Inter-cycle connection is created if the distance between the
last and next cycle is equal to or greater than this value.
CYC_CON_ALPHA Inter-cycle connection is created if the delta in “alpha”
between the holes is greater than (not equal) this value.
CYC_CON_BETA Inter-cycle connection is created if the delta in “beta” between
the holes is greater than (not equal) this value.
CimatronE 10.0 GPP2 User Guide ⎪38

An inter-cycle connection will be created if at least one of the conditions will be met.
Note that the angle thresholds will trigger a connection only if the angle difference is greater than the
threshold. That way, setting both angle variables to zero will ensure that an inter-cycle connection will
take place if the two holes really differ by orientation.
If GPP2 decides that an inter-cycle connection is required, it sets the CYC_NEXT_CONNECT variable to
TRUE_. The EX2 program may override the value of this variable. For instance, it can force a
connection after each hole if the machine requires it (e.g., a Heidenhain controller). The final decision
regarding a connection is taken after the CYCLE block is executed, according to the value of
CYC_NEXT_CONNECT.

If GPP2 decides that an inter-cycle connection is required, it will conduct a standard (short or long)
connection between two points. See detailed discussion about GPP2 connections earlier in this
document.

1.13.4 Tool Position after Cycle

After a cycle block, the tool retracts back along the tool axis. The retract height depends on the actual
machine and controller used. It is important for GPP2 to know the tool position after the cycle, in case
it needs to conduct a connection from that point (to the next hole or to the next procedure).
GPP2 calculates a default retract height, as explained below, and sets it in the variable ZCYC_END (the
Z value of the tool after the hole). In order to support other types of machines with a different behavior,
the EX2 program may override this value during the cycle block.
With some controllers, the tool height after the hole is determined by the first cycle (the “on” cycle) init
height or by the next cycle (look-ahead). In order for the EX2 program to be able to determine the
actual tool height after the cycle, several variables have been added to assist the EX2 program in the
calculation:
• ZCYC_NEXT_INIT: the ZINIT point of the next cycle. This variable is only meaningful if the next
cycle block is not an “off” block, and the next is of the same orientation as this cycle (otherwise, the
“height” notion is basically flawed).
• ZCYC_NEXT_CLEAR: the CLEAR point of the next cycle. This variable is only meaningful if the next
cycle block is not an “off” block, and the next is of the same orientation as this cycle (otherwise, the
“height” notion is basically flawed).
• ZCYC_INIT_FIRST: the ZINIT point of the first cycle (the “on” cycle). This variable is only
meaningful if the first cycle is of the same orientation as this cycle (otherwise, the “height” notion is
basically flawed).
GPP2 will read the value of the ZCYC_END variable after the CYCLE block is executed, and will assume
that the tool height is according to that value. Note that in case of an inter-cycle connection process,
the connection will start at that height.
CimatronE 10.0 GPP2 User Guide ⎪39

1.13.4.1 Default Tool Height after the Cycle

The default height after the hole is determined by the CYC_RETR code, and may be one of the
following:
• The “Clear” height (usually, just above the drill point itself
• The “Init” height (usually much higher above the drill plane)
The height value above the drill point for both cases is taken from the CYC_CLEAR or CYC_DZINIT,
respectively.
GPP2 calculates the default tool position after the cycle is finished by applying the correct retract
length along the tool axis (not necessarily the machine Z axis).
The following diagram explains the process and the tool position after the drill cycle.

Tool

Init Height
Default CYC_DZINIT
Position after Tool
drill cycle or
Clear Height orientation
CYC_CLEAR vector
Drill point
X_CURPOS Z
Y_CURPOS I_CCORD Y
Z_CURPOS J_COORD
K_COORD X
CimatronE 10.0 GPP2 User Guide ⎪40

1.13.5 Information on the Next Cycle

In order to make the bets decisions regarding connections after the cycle and regarding the tool
position after the cycle, the EX2 program needs to know about the next cycle.
This information is provided with a new variable, CYC_NEXT, which can get one of the following values
(predefined GPP2 constants):
• CYC_OFF: there is no “next cycle”. The next cycle block has the “off” qualifier.

• CYC_SAME: there is a next cycle, and it is of the same orientation as the current one.

• CYC_ROTATED: there is a next cycle, but it has a different orientation than the current one (so some
rotation will be needed between the holes).

1.14 GPP2 Variable Initialization

GPP2 includes many variables of several types (system variables, user variables and interaction
variables). Some of these variables are initialized before each run (e.g., SEQ_START is initialized from
the relevant DF2 parameter). Interaction variables are initialized with the last values used by the user
for that post-processor.
It is common practice to use the STARTUP block in order to initialize other variables (mostly user-
defined variables). However, this requires that the initial values are included inside the EX2 program.
Any change requires re-compilation of the post-processor.
In order to allow GPP developers to customize post-processors without re-compilation, GPP2 has
introduced the concept of INIT files. These files are simply text files that are read and “executed” by
GPP2 before each run. They can be used to initialize any GPP2 variable. See the INIT_FILE
command for more details on how to write INIT files and how to use them.
The order of initialization is important to understand, since the same variables may be initialized using
more than one method.
When the post-processor is first loaded, the DF2 file is read, as well as all INIT files. The last values of
the interaction variables are also read from a special file, overriding the original values specified in the
EX2 file.
Before each run (execution of a toolpath) of GPP2, the following process takes place.
• Specific system variables are initialized from DF2 data.
• All INIT files are “executed”, assigning values to any variable listed in them.
• Interaction variables are re-assigned the values on the screen (overriding any EX2 or INIT file
values).
GPP2 also allows the user to restore the default values for interaction variables. Pressing the Restore
Defaults button loads the original values specified in the EX2 file and then executes the INIT file
statements (potentially modifying the variables).
CimatronE 10.0 GPP2 User Guide ⎪41

1.15 Running a Post-Script from GPP2

Often, it is required to copy, move or rename the files generated in the posting process, in order to
complete the job. Sometimes, several files should be merged to one file, and so on.
With GPP2, it is possible to execute such file manipulation system commands from inside the EX2
program, without the need to execute a separate script (batch) file.
A new block, POST SCRIPT, was added in GPP2. It is executed after all other blocks have been
executed (including END OF FILE) and after GPP2 closes all the output files.
In the new block, it is possible to use a special new command, SYSTEM_CALL, which causes the
execution of any system command, such as copy or rename. The SYSTEM_CALL is similar to the
OUTPUT command in its format. It allows combining strings and variable names to form any system
command affecting the files associated with this specific run.
Note that some commands are not allowed in the POST SCRIPT block, since they attempt to write to
the output files which are already closed. The following commands are not allowed:
• OUTPUT, PRINT, PRINT1, etc.

• OUTPUT_REDIRECT and OUTPUT_BACK

• GPP_CALLPROC (since the procedure may contain output commands)

Other GPP2 commands can be freely used, including IF and other program control statements.
One advantage of using SYSTEM_CALL instead of running an external batch file is debugging. By using
step-by-step debugging, it is possible to pause and check the results of each individual command.
The POST SCRIPT block is also invoked in the case of runtime errors and in case the run was stopped
using the GPP_STOP command. In such a case, it is invoked with the “stopped:” qualifier, allowing the
EX2 program to clean up after the non-successful run (typically, delete all the files that were created
during the run).
Unlike most blocks, the “stopped” POST SCRIPT block does not fall back to the regular block (with no
qualifier). In cases of failure, GPP2 will only execute the POST SCRIPT block with the explicit
stopped: qualifier.

More detail on the use of SYSTEM_CALL is given in the GPP2 Language Reference Manual.
CimatronE 10.0 GPP2 User Guide ⎪42

1.16 Licensing Post-Processors with GPP2

GPP2 uses the standard Cimatron licensing mechanism to protect the use of GPP2 and the use of
specific post-processors.
Protection is done at post-time. GPP2 tries to grab one or more licensed modules at the beginning of
the execution, and releases them at the end of the execution. If the required module cannot be found,
execution stops with an error.
In order to run any post-processor, GPP2 requires the “GPP2_3X” licensed module. This license is
required for any run. For a continuous 4/5X toolpath (number of axes > 3), an additional license is
required “GPP2_5X”.
Finally, it is possible to protect a specific PP developed by a Cimatron Provider, with a new command
GPP_PROTECT. The command is optional and can be used in the EX2 program declaration part. It
allows the EX2 programmer to specify the name of the module that protects the post-processor.
When GPP2 runs the post-processor and encounters the GPP_PROTECT command, it tries to grab the
specified module. If that module is not available, the execution stops with an error.
Multiple protection modules may be specified by using multiple GPP_PROTECT statements in the EX2
program. GPP2 only needs one of these modules in order to run. It will search them according to the
order of the statements, and will stop searching once one of the modules is found. If no module is
available, the execution stops with an error.
This capability can be used for defining a special “technical support” protection module that is listed in
all the provider post processors in addition to the specific PP protection module. That way, technical
support personnel can easily use any PP developed by the provider.
Cimatron provides a mechanism for Providers to define their own PP-protection modules and create
licenses for them. Contact Cimatron for further details.
Using the standard Cimatron licensing mechanism has several advantages:
• It is possible to use either permanent or temporary licenses, and use hardware protection devices
(plugs) or Ethernet addresses.
• An evaluation license can be extended if required without the need to modify or re-compile the
post-processor.
• There is no need to indicate a specific plug number inside the EX2 program (the same way it is not
necessary for licensing any other module, such as MILL-3X).

1.16.1 Protection of the GPP2 Development Environment

GPP2 also protects the development environment, namely the EX2 editor and the DF2 editor. These
editors are protected by the GPP2_DEV_EX2 and GPP2_DEV_DF2 modules, respectively.
Typically, these licenses are only given to Cimatron providers who need to develop GPP2 post-
processors. Contact Cimatron for details.
CimatronE 10.0 GPP2 User Guide ⎪43

1.17 Post Processing with Transformations (GPP & GPP2)

In order to support Transformations, the following modes are available for post-processing:
• Exploded; where the transformed procedures simply appear as additional regular procedures to
GPP. The G-Code is longest, since it contains the full set of motions repeated again for each
transformed procedure.
• With subroutines; where the procedure motions are placed inside a machine subroutine, and each
transformed location is executed as a call to that subroutine. The G-Code is much shorter. The
main program includes a separate call (and home relocation) per transformed procedure.
The requirements from GPP and GPP2 in order to support all these options in GPP2 are detailed
below. For GPP, the “exploded” method is available.

1.17.1 GPP Output

The following options are available to output transformations in GPP, selectable in the Post
Processing Dialog.
• Fully exploded, to maintain backward compatibility with legacy GPP post-processors.
• As Transformations, for newly modified post-processors and for GPP2.

1.17.1.1 Fully Exploded Mode

When selecting this option, all transformed motions are exploded and posted as a standard toolpath
output. There are no traces of any transformations (as if the procedures were actually copied and re-
executed in all transformed positions).
This option is important to support GPP post-processors.

1.17.1.2 Non-Exploded Transformations

In this mode, GPP outputs the transformation procedures in a way that is very similar to the way they
are represented inside CimatronE. That data and structure are used by GPP2 to present the
transformed procedures.
GPP users are able to use that information in a “manual” way in the EXF file.
CimatronE 10.0 GPP2 User Guide ⎪44

Each transformation procedure is output as a series of blocks:

BEGINNING OF PROC: Used for several name parameters, such as

transformation procedure name, comment and unique
name.
ORIGIN CHANGE: Defines the transformation procedure UCS.
PROC TRANS: The “header” block defining the transformation type,
etc.
END OF PROC: For completeness.

1.17.2 Processing in GPP2

The following information relates to how GPP2 processes Transformations.

1.17.2.1 DF2 Additions

In the DF2 file and editor, the following definitions relate to Transformations:
- Transformations. This multi-choice parameter has the following options:
o Exploded: all transformations are exploded into regular motions.
o Subroutines: whenever possible, machine subroutines are used for transformed
procedures. Arrays are broken into multiple individual transformations (using
subroutines).
- Transformation Subroutine Number. A numeric value, telling GPP2 the number of the first
machine subroutine to be used for transformations. Only active and relevant if transformations
are not exploded. This number is also controllable by the EX2 program.
- Output transformation subroutines as separate files (Yes / No). Only active and relevant if
transformations are not exploded. If true, transformation subroutines are output to separate
files with the extension “.t01”, “.t02”, etc. (like 2.5X subroutines in “.s01” files).

1.17.2.2 Processing Transformations

Transformation procedures are processed in a “recursive” way, starting from the last transformation
and working backwards to the original procedures.

1.17.2.2.1 Simple Transformations

Whenever a simple transformation is processed, GPP2 first decides if all the referred procedures can
be executed as subroutines. Otherwise, the transformation is exploded to individual motions.
If a subroutine can be used, a simple (non-array) transformation is processed as follows:
- HOME SHIFT shift home position (incremental)
- Execute the referred procedures (recursion)
- HOME SHIFT restore the original home position (incremental)
CimatronE 10.0 GPP2 User Guide ⎪45

If the reference tree contains two simple transformations one pointing to the other, the two
transformations may be combined to one home shift.
Original Æ Transform1 Æ Transform2 is actually equivalent to
Original Æ (Transform1* Transform2)

1.17.2.2.2 Exploding Transformations

A transformed procedure may need to be exploded in two cases:

- The DF2 parameter requires that all transformations are exploded.
- A specific transformation UCS includes such orientation changes that a subroutine cannot be
used.
If a given transformation must be exploded, GPP2 performs the following logic:
- Execute the original procedure “as is”, except that the ORIGIN of the procedure is modified to
reflect the transformed position.
o New origin = Transformation UCS * Old Origin
- Everything else stays the same – connections, tool change, etc.

1.17.2.2.3 Multi-Cutter Procedures

In GPP2, multi-cutter procedures are broken into multiple single-cutter procedures in the execution list.
Consequently, when a multi-cutter procedure is referred to in a transformation procedure, GPP2 must
process all the individual single-cutter procedures.

1.17.2.2.4 When a Subroutine Cannot be Used

A transformation procedure can use subroutines only if every one of the transformed procedures can
use a subroutine in the final orientation.
In 5X processing, the transformed position may be rotated vs. the original position. In such a case, the
machine needs to be rotated for the transformed orientation. With 5X machines, it is usually possible
to align the procedure Z axis with the tool (unless machine limits are reached). However, it is not
always possible to control the orientation of the X and Y axes.
In order to use the same subroutine in the original and transformed positions, the transformed Origin
UCS must be perfectly aligned with the original Origin UCS. The original and transformed origin UCS
must be the same when measured in the REF UCS.
This cannot always be guaranteed in 5X machines. It depends on the nature of the rotation.
If the rotated origin UCS cannot be perfectly aligned with the original origin UCS, then this specific
position must be exploded into individual motions. The subroutine saved in the original orientation
cannot be used.
It may happen that for the same procedure, some transformation instances can use a subroutine while
others cannot. It all depends on the individual transformation UCS and the machine structure. GPP2
will use the subroutine whenever possible, and explode other instances where necessary (while giving
CimatronE 10.0 GPP2 User Guide ⎪46

a warning message).
Note: In some cases, the GPP2 generates a “don’t care” solution for a given Z axis orientation. This
means that one of the axes can be positioned in any angle. In such cases, it is likely that one unique
solution allows the use of subroutines (aligning also the X and Y axes) while all others do not. GPP2
will attempt to find that unique solution and apply it for the transformed position.
CimatronE 10.0 GPP2 User Guide ⎪47

2 GPP2 Editors
The following editors are used by GPP2 developers:

EX2 Editor This tool is used by GPP2 developers to write EX2 programs in a special
dedicated programming language, which is described in the GPP2
Language Reference Manual. This EX2 program file is compiled, using
the EX2 Editor, to create a DX2 file, which is executed by GPP2.

DF2 Editor This tool is used by GPP2 developers to edit a definitions file, also known
as the DF2 file. This file contains many definitions that affect how GPP2
interprets and executes the EX2 program file. It allows fine tuning of the
output machine code (generally referred to as “G-Code”), the formatting of
numbers, the way GPP2 handles various motions, etc..
CimatronE 10.0 GPP2 User Guide ⎪48

2.1 EX2 Editor

This tool is used by GPP2 developers to write EX2 programs in a special dedicated programming
language, which is described in the GPP2 Language Reference Manual. This EX2 program file is
compiled, using the EX2 Editor, to create a DX2 file, which is executed by GPP2.
The EX2 Editor dialog is displayed:

Interaction

1. Create a new file (File / New) or open an existing .ex2 file (File / Open or double-click the file)
in the Cimatron\CimatronE\Program\IT\var\post2 folder.
2. Write/edit the EX2 post program file.
If required, see the explanations on the following sections of the EX2 Editor:
Toolbar Buttons
Editor Pane
Marks Pane
Console Log
3. Compile ( ) the EX2 file to create a DX2 file, which is executed by GPP2.
CimatronE 10.0 GPP2 User Guide ⎪49

2.1.1 Toolbar Buttons

The following toolbar buttons appear in the EX2 Editor:

Standard file toolbar buttons:

Open a new EX2 document.

Open an existing EX2 document.

Save the currently opened EX2 document.

Standard edit toolbar buttons:

Cut.

Copy.

Paste.

Delete.

Standard undo / redo toolbar buttons:

Undo the last operation.

Redo the last undo operation.

Find.

Compile EXF. This saves the EX2 program file and compiles it to
create a DX2 file, which is executed by GPP2.

Hide / Show the Console Log pane.

Open the DEF Editor.

CimatronE 10.0 GPP2 User Guide ⎪50

Bookmark buttons:

Toggle bookmark.

Next bookmark.

Previous bookmark.

Clear all bookmarks.

Hide / Show the Marks Pane.

Toggle a comment. This toggles the currently highlighted line

between a comment and non-comment status.

Comment Block. Convert a block of highlighted text into comments.

Remove the comment status of a block of highlighted comments.

Jump to line number. Enter a line number and press Enter. If the line
number exists in the currently open program, the appropriate line is
displayed and highlighted.

Display the Cimatron Corporate web page.

CimatronE 10.0 GPP2 User Guide ⎪51

2.1.2 Editor Pane

The Editor Pane displays the EX2 post program file and is used to edit the program.
Below are some editing examples to demonstrate the use of the editor.
Jump to Line #
Assisted Editing
Comment Block
Toggle Comment
Bookmarks

2.1.2.1 Jump to Line #

An example of using the Jump To Line # button. Enter the required line number and press Enter.

The appropriate line, if it exists, is displayed and highlighted.

Whenever any change is done to the post program, [***** Not Compiled *****] is displayed in the title
bar to inform you that the post needs to be compiled. In this case, the semicolon (;) at the end of the
line has been deleted.
CimatronE 10.0 GPP2 User Guide ⎪52

Note: If you attempt to compile the post ( ) when it contains grammatical errors, [ Not Compiled ] is
displayed in the title bar and an appropriate message is displayed in the Console Log enabling you to correct
the problem.
CimatronE 10.0 GPP2 User Guide ⎪53

2.1.2.2 Assisted Editing

When editing a post program, the EX2 Editor automatically recognizes commands and variable names
and assists you by converting commands to upper case and displaying appropriate variable options.
Commands
Place the cursor at the beginning of an empty line and type the word “output”.

Notice that before you complete Once the word is completed it changes to
the word, the letters are in lower uppercase and its color turns dark blue.
case. GPP2 automatically recognizes commands
and variable names (if typed correctly!) and
changes their appearance. This is a nice
way to make sure you have no typing errors.

Variable Options
Continuing the above example - after a space, type the letter “X”. Press the CTRL + SPACE
BAR keys.

A popup window is displayed, containing a Select any of the variables in the list and it
list of all the variables. The cursor is replaces the letter you typed with the
placed on the first variable that starts with selected variable. This ensures that the
the letter (or string) you typed. correct variable name is entered, without
you having to remember all the variables.
CimatronE 10.0 GPP2 User Guide ⎪54

2.1.2.3 Comment Block

Convert a block of highlighted text into comments.

Select a block of text to be converted into All the selected lines (including the highlighted
comments and press the toolbar button. line where the cursor is currently positioned)
are converted to comments with one single
command.

Note: To remove the comment status from a block of comments, select the appropriate block press the
toolbar button.

2.1.2.4 Toggle Comment

Toggle a comment. This toggles the currently highlighted line between a comment and non-comment
status.

Highlight the appropriate line and press the The highlighted line where the cursor is
toolbar button. currently positioned is toggled. In this case,
notice the following:
1. the line is already a comment, and the
toggle removes the comment status.
2. even though the block of text is
highlighted, only the line where the
cursor is currently positioned is
toggled.
CimatronE 10.0 GPP2 User Guide ⎪55

2.1.2.5 Bookmarks

The Bookmarks buttons are used to create, navigate through and clear all bookmarks in the post
program.

Highlight the appropriate line and press the Use the Next and Previous bookmark
toolbar button. A bookmark flag is buttons to navigate sequentially through all
displayed next to the line number. the bookmarks.
The bookmark button deletes all
bookmarks from the post program.
CimatronE 10.0 GPP2 User Guide ⎪56

2.1.3 Marks Pane

Hide / Show the Marks Pane by toggling the toolbar button.

The Marks Pane lists all the pre-defined sections of an EX2 program file in alphabetical order. These
include, the header, GPP procedure names, debug flags, block titles, etc..
The Marks Pane is used to navigate the EX2 program file. Select an item in the Marks Panes, and if it
appears in the current EX2 program file, it is highlighted in the Editor Pane.

Example Use:

Select an item in the Marks Pane.

The first occurrence of the relevant string (if it exists) in the program is highlighted in the Editor Pane.

Repeated selections of the same item in the Marks Pane, will highlighted subsequent occurrences of
the same string (if they exist) in the program. After the last occurrence, the first occurrence is
highlighted again.

If the item selected in the Marks Pane does not exist in the program, nothing happens.

Note: The Marks Pane list is composed of the entries in the following files from the
Cimatron\CimatronE\Program\gpp2 folder:

• gpp2-blocks.txt
• gpp2-marks.txt
CimatronE 10.0 GPP2 User Guide ⎪57

2.1.4 Console Log

Hide / Show the Console Log pane by toggling the toolbar button.
The Console Log displays messages informing you of successful or unsuccessful compilation results.

Successful Compile

Successful compilations are displayed in green and inform you that the dx2 file has been created
successfully:

Failed Compile

Unsuccessful compilations are displayed in red. In this case the following occur:

In unsuccessful compilations, the following occurs:

1. The Console Log displays the problematic line in the program file and also the nature of the
problem, to help you to correct it.
In this example, line 535 is displayed in the Console Log. The second line states the specific
cause of the failed compilation - the semi-colon at the end of the line is missing.
2. The problematic line is highlighted in the Editor Pane for correction.
3. The title bar informs you that the compile failed.
CimatronE 10.0 GPP2 User Guide ⎪58

2.2 DF2 Editor

This tool is used by GPP2 developers to edit a definitions file, also known as the DF2 file. This file
contains many definitions that affect how GPP2 interprets and executes the EX2 program file. It allows
fine tuning of the output machine code (generally referred to as “G-Code”), the formatting of numbers,
the way GPP2 handles various motions, etc..
The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
The DF2 Editor dialog is displayed.
CimatronE 10.0 GPP2 User Guide ⎪59

Interaction

1. Open an existing .df2 file (File / Open or double-click the file) in the
Cimatron\CimatronE\Program\IT\var\post2 folder.
2. Set the appropriate parameters in each of the following tabs:

Post
Linear
Circular
Connection
Formats
Machine Code
Output Files
Miscellaneous

3. Save the DF2 file using File / Save or File / Save As.
CimatronE 10.0 GPP2 User Guide ⎪60

2.2.1 GPP2 DF2 Editor Dialog – Post Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪61

2.2.2 GPP2 DF2 Editor Dialog – Linear Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪62

2.2.3 GPP2 DF2 Editor Dialog – Circular Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪63

2.2.4 GPP2 DF2 Editor Dialog – Connection Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪64

2.2.5 GPP2 DF2 Editor Dialog – Formats Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪65

2.2.6 GPP2 DF2 Editor Dialog – Machine Code Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪66

2.2.7 GPP2 DF2 Editor Dialog – Output Files Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪67

2.2.8 GPP2 DF2 Editor Dialog – Miscellaneous Tab

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in Chapter 4: DF2-Related Variables.
CimatronE 10.0 GPP2 User Guide ⎪68

3 Language Reference Manual

3.1 Introduction and Conventions

3.1.1 Structure of this Document

This document is essentially a programming language reference manual. It describes the GPP “EX2”
language in detail, as implemented in GPP2.
The document is mostly structured “bottom-up”, defining basic concepts first, and building on top of
them.
The document is built as follows:
• Basic concepts
• GPP variables of all types
• GPP expressions (numeric, string, Boolean)
• The structure of a GPP program and its “blocks”
• Declaration Statements
• Execution Statements
• GPP Procedure
• GPP Debugging

3.1.2 GPP Users

This document discusses two types of users involved with GPP:
GPP Developer: the NC expert who develops a post-processor using GPP. He or she writes the GPP
program, edits the definition file (.DF2), and compiles the GPP program to create the runtime post-
processor.
GPP User: the NC operator or programmer who uses the post-processor developed with GPP. He or
she uses the compiled program to create G-Code files. We also refer to this process as runtime.
CimatronE 10.0 GPP2 User Guide ⎪69

3.1.3 GPP Conventions

GPP is not case-sensitive, meaning every keyword or variable name may use uppercase or
lowercase letter (or any combination of them). For instance, a variable named OLDX may also be
referred to as oldx or oldX.
String Boolean operations are case sensitive. You may use String Functions (namely, STR_LOWER,
STR_UPPER) to overcome the case-sensitive nature.
Spaces and line-breaks are ignored. Several statements may be placed in a single line, or a single
statement may span several lines.
With GPP2, there are two ways to write comments inside the GPP program:
• A line starting with the * character is ignored (the traditional GPP way)
• Any text following the // characters to the end of the line is ignored (C++ way).
Examples:
* This whole line is a comment, from start to end
X = 12; // an assignment statement, followed by a comment
All calculations in GPP are done using double precision. In case there is a need to make the
calculation in the “output format”, the numbers should be first converted (see FORMATTED_NUM
function). See later, a detailed discussion on output formats and how it affects calculations and
Boolean operations.

3.2 GPP Variables

3.2.1 System Variables

System variables are predefined in GPP. Many of them represent data from the NC toolpath, such as
the current X position, or the procedure name. GPP assigns values to system variables, based on the
specific toolpath block being processed.
Other system variables do not represent toolpath data. Rather, they are used to control the post
processor execution and behavior or to provide non-toolpath information. Examples include 5X
machine definition variables.
All system variable names include one or more underscores, as in X_CURPOS or SPIN_SPPED.
The full list of system variables and the blocks in which they are assigned values is given in the “GPP2
Theory of Operation” document.
CimatronE 10.0 GPP2 User Guide ⎪70

3.2.2 User-Defined Variables

User-defined variables are actually defined by the GPP developer (not the runtime user) in the
program declaration part (see below), and can be used for any purpose. They are usually used for
program control, and to hold temporary values and calculated results.
User-defined variable names are made of letters and digits only, and must start with a letter. User-
defined variable names must not contain an underscore. For instance, valid names are OldX or
MaxVal.
A variable name cannot be a reserved GPP keyword, such as OUTPUT or TAN. Variable names can
be no longer than 31 characters.
The number of user-defined variables in each GPP program is limited to 25,000. That number includes
all Interaction variables and array members (see below). As long as that limit is concerned, each array
member counts as one variable. Trying to define more user-defined variables will result in a
compilation error.

3.2.3 User-Defined Interaction Variables

Interaction variables are a special type of user-defined variables. They must also be defined in the
program declaration part. Interaction variables are used to give the GPP user control over specific
behavior of the post-processor during each run.
Interaction variables are assigned a default value, specified when the variable is declared. The GPP
user can modify the values of Interaction variables before each run.
Within the same GPP session, Interaction variables maintain their values from run to run. The values
presented to the GPP user in each run are the last values assigned to these variables in the previous
run. However, each time GPP is started, the default values will be presented to the user.
With GPP2, it is also possible to define system variables for user interaction. In particular, it is useful
for system variables that are initialized from DF2 parameters. This allows the end user to override DF2
parameter values at runtime. See more details in the INTERACTION statement section.
Up to 50 Interaction variables can be defined in each GPP program (both user-defined and system
variables).
CimatronE 10.0 GPP2 User Guide ⎪71

3.2.4 User-Defined GPP-Procedure Variables

GPP-Procedure Variables are local variables, defined and used only inside a GPP procedure. GPP-
Procedure variable names and formats are the same as other user-defined variables.
Although the scope of GPP-Procedure Variables is limited to the procedure itself, it is recommended
to use unique names for all variables in the GPP program.

3.2.5 Array Variables – Not Recommended

User-defined variables can also be defined as arrays. Array members are referred to with square
brackets (e.g., A[2]).
Array indexes start at 1. For instance, in A is defined as a 100-entry array, then valid members are
from A[1] to A[100]. Any index number outside this range results in a runtime error.
No system variable is an array. Interaction variables cannot be defined as arrays.

3.2.6 Variable Formats and Types

Each GPP variable has a format. The format defined how a variable is formatted for output, specifying
things like the number of digits used after the decimal point, and whether leading zeros are used or
not.
Variable format has no effect on the internal value of the variable. All numeric variables are stored as
double-precision floating point numbers. In most cases, when variables are used in expressions, the
internal value is used regardless of the format. There are several specific cases when the format is
considered (e.g., when comparing variables), and these cases will be explicitly identified and
explained in this document.
CimatronE 10.0 GPP2 User Guide ⎪72

There are 19 predefined GPP formats, as listed below. Their names suggest their intended use, but
any variable can be assigned any format.
CHARACTER
COORDINATES
ANGLES
FEED
SPINDLE
DWELL
SEQUENCING
TOOL
USER_1
USER_2
USER_3
USER_4
USER_5
USER_6
USER_7
USER_8
USER_9
USER_10
REAL
There are 2 predefined GPP formats that are used only in the INTERACTION statement (refer to
INTERACTION section)
BOOLEAN
MULTI_CHOICE
Variable formats also define the variable type, which may be numeric or string. Numeric variables
contain floating point values (double precision), whereas string variables contain text character strings.
The maximum length of strings that can be held in variables is 256 characters. Attempting to store a
longer string will result in a runtime error.
Note – there are no pure integer variables in GPP. While a format may be defined to print no decimal
point and no fractions (so the printed output is rounded to an integer value), the internal representation
cannot be limited to integer values only.
The variable format uniquely defines the variable type. The CHARACTER format is the only format for
string variables. All other formats define numeric variables.
Each system variables has a default format, suitable for its use (e.g., the X_CURPOS variable uses
the COORDINATES format, while TOOL_ANGLE uses the ANGLES format). However, the GPP
developer can assign a different format for each system variable. The full list of system variables and
their default formats is given in the “GPP Theory of Operation” document.
User-defined variables, including Interaction variables and arrays, are assigned a format when they
are defined in the GPP program declaration part. Note that it is not possible to define a separate
format to an individual array member – all members of an array share the same format.
CimatronE 10.0 GPP2 User Guide ⎪73

3.2.7 Formatting Variables for Output

Variables of the CHARACTER format (string variables) are printed “as is”, with no special formatting.
All characters stored in the variable (including spaces) are printed. Note that some DEF parameters
also control the output format. For instance, there is a parameter to force all output to be upper-case.
Variables of all other formats (numeric variables) are formatted for output according to the following
options:

Format Option Comment

Max. digits for integer part Up to 9 digits. Values that cannot fit within that
number of digits generate a runtime error.
Max. digits for fractional part Up to 9 digits. The number is rounded to that
number of fractional digits. Note: setting to zero
will result in integer-only output.
Min. digits for integer part If the integer part does not need that number of
digits, leading zeros or spaces will be used. Must
be less than or equal to the maximum digits.
Min. digits for fractional part If the fractional part does not need that number of
digits, trailing zeros or spaces will be used. Must
be less than or equal to the maximum digits.
Leading zeros (Yes / No) Choose between zeros (if Yes) and spaces (if
No), if the minimum number of integer digits is
not met.
Trailing zeros (Yes / No) Choose between zeros (if Yes) and spaces (if
No), if the minimum number of fractional digits is
not met.
Character for the plus (+) sign If left blank or set to ~, no sign character will be
printed for positive numbers. Otherwise, a sign
character will be used (e.g., +3.2).
CimatronE 10.0 GPP2 User Guide ⎪74

Format Option Comment

Character for the minus (–) sign If left blank or set to ~, no sign character will be
printed for negative numbers. Otherwise, a sign
character will be used (e.g., -3.2).
Character for the decimal point Any character except space (usually a dot)
Use decimal point for integer If set to Yes, a decimal point will be printed even
numbers (Yes / No) for integer values (e.g., 2. instead of 2)
Representation of the value 0 Exact string to be used (e.g., 0.0) when value is
0 (all other formatting options are ignored).

The following examples assume the following:

• The standard characters are used for the decimal point (.) and the minus sign (-).
• No character is used for the plus sign (so positive numbers are printed without a preceding + sign).
• Decimal point is not used for integer values.
• In the examples, trailing spaces are shown as underscores (_) for clarity, they are actually
spaces.

Variable Max. int. Max frac. Min. int. Min frac. Leading Trailing Output
Value digits digits digits Digits zeros zeros

6.6666… 4 3 0 0 No No 6.667

6.6666… 4 1 0 0 No No 6.7

6.6666… 4 3 2 0 No No 6.667

6.6666… 4 3 2 0 Yes No 06.667

25.0 5 0 1 0 Yes Yes 25

24.9 5 0 1 0 Yes Yes 25

25.1 5 4 3 2 Yes Yes 025.10

25.1 5 4 3 2 No No 25.1_

2000.0 3 2 1 0 No No Error!

-0.333... 4 3 0 0 No No -0.333
CimatronE 10.0 GPP2 User Guide ⎪75

Notes:
1. A runtime error occurs when the number to be formatted exceeds the maximum number of
digits allowed for the integer part.
2. In an “integer-only” format (when the maximum number of fractional digits is zero), non-integer
numbers are rounded. It does not affect their internal value, only the formatted output string.
3. Although it is theoretically possible to define an 18 digit number (setting both maximum digits
to 9), this is beyond the actual accuracy of double precision numbers. Practically, no more than
14 significant digits can be formatted.
4. The REAL format is internally defined with 14 maximum digits for the integer part and 14
maximum digits for the fractional part. The minimum number of digits for the integer and
fraction parts is set to 1. The numbers set in the DF2 file for these options have no effect on
the REAL format. Other options (like leading or trailing spaces) do affect the REAL format.
However, it is advised to leave the REAL default definition as is.
5. A comma (“,”) can be used for the decimal point character, instead of the standard dot (“.”).
This is common in Germany (ex: 0,5 means 1/2).
6. If the decimal point character is omitted (i.e. “”), the output may be erroneous. For instance, if
max fraction digits is 1, than 6.6666… will be formatted as 67 instead of 6.7 – as if multiplied
by 10!

GPP Compatibility Notes:

In old GPP, the formats also defined the default modality for variables of this format. In GPP2, formats
do not define modality at all (this parameter was removed from the format) and all variables are non-
modal by default.

3.2.8 Variable Modality and Set Status

Every GPP variable can be defined as “modal” or “non-modal”. In GPP2, the default modality is
“non-modal” for all variables. The variable modality can be modified by statements in the GPP
program declaration part.
Variables are typically defined as modal when they need to be output to the G-code file, but only if
they are set “on”. The perfect example is X_CURPOS, which only needs to be output it is assigned a
new value (and hence set on). With GPP2, only a few variables need to be defined as modal.
CimatronE 10.0 GPP2 User Guide ⎪76

All Array members share the same modality, which is defined for the whole array.
The only difference between modal and non-modal variables is how they are affected by OUTPUT and
PRINT commands. More specifically, the difference relates to their “set” status – that needs some
explanation.
In GPP, each variable has a special status flag, signaling of the variable is set “on” or “off”. It is
primarily used to identify system variables that are actually assigned new values by GPP when a
block is processed. However, user-defined variables also have the same status set flag, and behave
the same way.
In arrays, each array member has a separate “set” flag. Therefore, some array members may be “on”,
while others may be “off”.
The “set” status flag can be tested in program control statements (such as IF, IF_SET and REPEAT
UNTIL), so that different actions can be taken based on any variable status.
In GPP2, the “set” status flag dose not affect how variables are printed in OUTPUT & PRINT
statements. A variable will be printed even if it is in “set off” status.
A variable is set “on” in one of the following cases:
• The first time it is assigned a value.
• It is set “on” by GPP2 when it needs to be output as part of the G-Code. The exact condition
depends on the variable, the toolpath block, and internal GPP2 logic.
o Some variables, such as X_CURPOS, are set on when they are assigned a new value,
different than the previous value it had before. Note that for numeric variables,
“different” takes into consideration the variable format – values are considered different
only if they appear different when sent to OUTPUT.
o Other variables, such as PART_TOL, are set on when they are included in the toolpath
(e.g., in a given procedure) and off when they are not – regardless of their previous
value (being equal to the new value or not).
• It is explicitly turned on with the SET_ON command (see later).
• An identical variable is turned on (identical variables always have the same set status). See below
regarding identical variables.
CimatronE 10.0 GPP2 User Guide ⎪77

A variable is turned “off” in one of the following cases:

• A modal variable is printed with an OUTPUT or PRINT statement. Non-modal variables are not
affected by these statements (and will remain “on”).
• The variable is explicitly turned off with the SET_OFF command (see later).
• An identical variable is turned off (identical variables always have the same set status).
Once again, the only difference between modal and non-modal variables is how they react to
OUTPUT statements. Modal variables are turned “off”, while non-modal variables are not.

GPP Compatibility Notes:

In the old GPP manual, it is stated that non-modal variables are never turned off. This is not accurate
– they are not turned off by the OUTPUT statement, but they can be turned off in other ways (e.g.,
with the SET_OFF command).
In old GPP, members of modal arrays do not respond to the OUTPUT statement. They remain set
“on”. In GPP2, they are turned “off”, like any modal variable.
In old GPP, the default modality for each variable was taken from its format. In GPP2, formats do not
have modality anymore, and all variables are non-modal by default, unless explicitly declared as
modal.

3.2.9 Identical Variables – Not Recommended

GPP supports the notion of identical variables. It is possible to declare two or more variable to be
“identical”, which has the following results:
• They will always have the same value. Whenever the value of one variable changes, all other
identical variables get the same value.
• They share the same “set” status flag value. Each time a variable is turned on or off (for whatever
reason), all other identical variables are also turned on or off.
Note that identical variables do not have to share the same format. They can use different formats, as
long as they are of the same type (numeric or string). It is not possible to declare variables of different
types as identical – a compilation error will result.
Identical variables of different formats always share the same internal value. When used in OUTOUT
statements, the printed results may be different depending on the formats, but the internal values are
always the same.
Declaring two or more system variables as identical is not recommended, since GPP may try to assign
different values to these system variables. The result is unpredictable (the variables will end up having
the same value, but it is not possible to know which value prevailed). A compilation warning will be
issued if two or more system variables are declared as identical.
Arrays and array members cannot be declared identical to any other variable.
CimatronE 10.0 GPP2 User Guide ⎪78

3.2.10 Variable Initialization

At the beginning of each GPP run, all variables are in a special “un-initialized” state. Variables are only
initialized when assigned a value for the first time, either by GPP or in the GPP program (the first
assignment also turns them “on”).
Each array member needs to be initialized (assigned a value) separately. Consequently, some array
members may be initialized while other may stay unused (and hence un-initialized) for the whole
duration of the GPP run.
Note that Interaction variables are always initialized, since they are assigned values before the
program execution. Consequently, any variable declared as identical to an Interaction variable is also
initialized (and assigned the same value). Interaction variables are also set “on” at the beginning of
the program.
Some other variables are initialized with data from the DF2 file. Finally, variables may be initialized
through the use of INIT files and the INIT_FILE statement.
Variables should not be used in the GPP program before they are initialized, since the result may
seem unpredictable. A runtime warning will be issued in case an un-initialized variable is referred to
during the program execution. No compilation-time warning is possible.
If (carelessly!) used in the GPP program, un-initialized variables exhibit the following behavior:
• They are ignored (not printed) by OUTPUT and PRINT statements.
• Their “set” status flags are initially turned “off”.
• They can be turned “on” and “off” using the explicit SET_ON and SET_OFF statements. This does
not make them initialized – they remain un-initialized. It only changes their “set” status flag.
• When used in expressions, a runtime warning is issued. The value returned from any un-initialized
variable is 0.0 for numeric variables and an empty string for string variables.
If another variable is assigned the value of an un-initialized variable, then the second variable is
considered to be initialized (with the value 0.0). For instance, assume A and B are both un-initialized.
Executing the statement B = A; will issue a runtime warning (about A) and will make B initialized (A
will stay un-initialized).

GPP Compatibility Notes:

In old GPP, variables seem to start as being “on”, even if they are not yet initialized. In GPP2, they
always start in the “off” state.
In old GPP, assigning a value of an un-initialized variable to another variable does not make the
second variable initialized.

3.2.11 Tool/cycle User-Defined Variables – Not Supported

Tool/Cycle user-defined variables of the form $NAME are not supported in CimatronE or in GPP2.
Using them in a GPP program will result in a compilation error.
CimatronE 10.0 GPP2 User Guide ⎪79

3.3 GPP Expressions

Expressions make a significant part in any programming language, and GPP is no exception.
Expressions are used in assignment statements, in function arguments, and in program control
statements.
For instance, a simple expression is shown in the statement below:
A = B + 3;
The “B + 3” part is a numeric expression.
This section describes all the legal expressions in the GPP language, and how they are assigned
values at runtime. Later sections in this document will describe the various GPP commands and what
expressions may be used in each.
Note: the OUTPUT and PRINT statements do NOT use standard GPP expressions. They use a
unique set of output entities, which will be described separately. This section only deals with
standard GPP expressions (i.e., expressions that can be used in assignment statements).

3.3.1 Expression Types

GPP supports three types of expressions:
Numeric: floating point (or integer) numbers. Numeric expressions are always calculated with double
precision floating point mathematics. Numeric expressions can be assigned to numeric variables.
String: character strings, up to 256 characters long. String expressions can be assigned to string
variables.
Boolean: True or False expressions, which are only used in program control statements, such as IF or
REPEAT UNTIL. Boolean expressions cannot be assigned to any variable or used as function
arguments.
In the coming sections, the following conventions will be used to refer to expressions of various types:
<expr> An expression of any type
<num-expr> Numeric expression
<str-expr> String expression
<bool-expr> Boolean expression
The following variable names will be used in the expression examples:
X, Y Numeric user-defined variables
S1, S2 String user-defined variables
AR A user-defined array variable
CimatronE 10.0 GPP2 User Guide ⎪80

3.3.2 Constants
The simplest expression is a constant, of numeric or string type. String constants are enclosed in
double quotes, and can be up to 256 characters long.
Examples:
10
12.5
“This is a constant string”
Constant strings cannot be broken across lines. The whole string must be entered in the same line.
There are several special predefined named constants in GPP, as follows:
Numeric:
PI (numeric constant, 3.14…)
INCH (numeric constant, 25.4)
TRUE_ or YES_ or ON_ (numeric constant, 1)
FALSE_ or NO_ or OFF_ (numeric constant, 0)
String:
DBL_QUOTE (string with one double-quote (“) character)
Note that DBL_QUOTE is the only way to use a double-quote character in expressions.
DBL_QUOTE is not truly a constant – it is a system variable, which is initialized with a single
double-quote sign, and never changed by GPP.
Special Numeric Constants
GPP contains a large number of predefined numeric constants that can be used instead of numbers
for the purpose of improved clarity of the GPP program.
Consider the following two statements:
ARCS_CTRL_BYPLANE = 2 ;
ARCS_CTRL_BYPLANE = DEF_XYONLY ;
Both statements have the same result, since the DEF_XYONLY predefined constant has the value of 2.
However, the second statement is clearer – it tells us that arcs in this post-processor are only
supported in the XY plane. If the same variable was assigned the value DEF_NONE (1), it would mean
that arcs are not supported in any plane (and are broken to linear motions). That way, these constants
help make the GPP program easier to read and debug.
The special numeric constants are used in conjunction with specific GPP2 system variables
(ARCS_CTRL_BYPLANE was shown here in the example) and commands. The constants provide a
convenient way of setting and testing these variables, without having to remember the numeric value
of each option.
These constants are best explained in conjunction with their applicative use
CimatronE 10.0 GPP2 User Guide ⎪81

within GPP2. The full list of special constants, their meaning, values and associated variables is given
in the GPP Theory of Operation manual.
Output Constants
Special Control Characters, new-line characters and the special TAB_ keyword, are not mentioned
here since they can only be used in OUTPUT statements. They will be described when the OUTPUT
statement is discussed.

3.3.3 Variable References

Variable references are also simple expressions. Any GPP variable (system, user-defined, Interaction)
can be used as an expression. The expression type is the same as the variable type (numeric or
string).
Examples:
X_CURPOS
S1
AR[12]
AR[<num-expr>]
For arrays, only single array members can be used as expressions. The array index is enclosed in
square brackets. The full array name (AR) is not a valid expression and will generate a compilation
error.
Array indexes can be any numerical expression (e.g., X * 3). If the value of the index expression is not
an integer number, GPP will round it to the nearest integer number (no error or warning will be
flagged).
Valid array indexes range from 1 to the number of array entries. If an array index expression gives an
illegal value (e.g., -3), a runtime error is created.

3.3.4 Standard Mathematical Operators

All the standard mathematical operators, such as + or -, are supported in GPP. The standard
precedence order is kept (power is highest priority, multiply, divide and modulus come next, plus and
minus are lowest).
The following standard operators and constructs are supported:
(<num-expr>) Parenthesis
- <num-expr> Single expression negation (like –X)
<num-expr> ** <num-expr> Exponent (X to the power of Y)
<num-expr> * <num-expr> Multiplication
<num-expr> / <num-expr> Division
<num-expr> _MOD_ <num-expr> Modulus
CimatronE 10.0 GPP2 User Guide ⎪82

<num-expr> + <num-expr> Addition

<num-expr> - <num-expr> Subtraction
The modulus operator gives the remainder of the division of the first operand by the second. For
instance, if X is equal 372.5, then X _MOD_ 360 gives 12.5.
Note that the order of execution of operators is always left to right. Therefore, 16 / 4 / 2 will yield the
value 2.
In division and modulus, if the second operand is equal to zero, a runtime error is generated (divide-
by-zero).

3.3.5 Trigonometric Functions

GPP supports a wide array of numeric trigonometric functions. They take one or two arguments, and
return a numerical value.
In trigonometric functions, all angles are expressed in degrees. This is true for function arguments
(e.g., for SIN), as well as function return values (e.g., for ASIN).
Function arguments are enclosed in parentheses. When two arguments are required, they must be
separated by a comma.
SIN(<num-expr>) Sine
ASIN(<num-expr>) Arc sine (return angle, in degrees)
COS(<num-expr>) Cosine
ACOS(<num-expr>) Arc cosine (return angle, in degrees)
TAN(<num-expr>) Tangent
ATAN(<num-expr>) Arc tangent (return angle, in degrees)
SINH(<num-expr>) Hyperbolic Sine
COSH(<num-expr>) Hyperbolic Cosine
TANH(<num-expr>) Hyperbolic Tangent
ATAN2(<num-expr>, <num-expr>) New - two-argument Arc tangent (Y, X)
Note the order of arguments to the ATAN2 function – the Y value comes before the X value. ATAN2
allows users to get an accurate angle (including the quadrant) if the X and Y components are known
(unlike ATAN that cannot identify the right quadrant).
CimatronE 10.0 GPP2 User Guide ⎪83

3.3.6 Other Numeric Functions

The following numerical functions are also supported by GPP:
DEGREE(<num-expr>) Convert number from radians to degrees
RADIAN(<num-expr>) Convert number from degrees to radians
SQRT(<num-expr>) Find the square root of the expression
ABS_(<num-expr>) Find the absolute value of the expression
FORMATTED_NUM(<variable>) Return the “formatted” value of a variable
FRAC_DIGITS(<variable>) Number of digits in the variable format
INT_(<num-expr>) Return the integer part of the expression
FRAC_(<num-expr>) Return the fraction part of the expression
DEGREE simply returns its argument multiplied by 180 / PI. The RADIAN function does the reverse
operation.
SQRT always returns a positive number. It will generate a runtime error if its argument has a negative
value.
ABS_ is a new GPP2 function, returning the absolute value of its argument.

3.3.6.1 FORMATTED_NUM Function

As explained earlier in this document, GPP2 variables have unique “format” characteristics that define
how they are printed in the GPP2 output. The format also affects how variables are compared to each
other inside GPP2 expressions. The format does not affect the internal value of variables.
The FORMATTED_NUM function returns a numeric value that is equal to the formatted form of a given
variable. Unlike most other numeric functions, it only accepts variables as arguments (and not any
numeric expression).
For instance, assume variable VAR has the value 5.2299, and its format defines the maximum number
of fraction digits as 2. Therefore, sending VAR to the output will print the string “5.23”.
FORMATTED_NUM(VAR) will return the number 5.23000
Note that use of this function does not change the internal value of the variable. In our example, VAR
will remain at 5.2299.
The following statement will set VAR to its formatted value (similar to the old CONVERT statement):
VAR = FORMATTED_NUM (VAR); Set VAR to 5.23000
The following example demonstrates the effect of FORMATTED_NUM and its importance. Assume all
variables below are formatted with 3 digits after the decimal point.
CimatronE 10.0 GPP2 User Guide ⎪84

Variable Toolpath Internal Formatted

Coordinate representation Output (G-
code)

Xold 100.0004 100.00040.... 100.000

Xnew 109.9996 109.99960.... 110.000

Delta1 = 9.9992 9.99920.... 9.999

(should be
Xnew - Xold
10.000 !)

DELTA2 = 10.000 10.000 10.000

FORMATTED_NUM(Xnew) -
FORMATTED_NUM(Xold)

While the internal representation of Delta1 seems OK, the formatted output of Delta1 is not the
excepted result. DELTA2 gets the correct result (both internal and output).
Note that the FORMATTED_NUM function can also be used to convert Xold and Xnew:
Xold = FORMATTED_NUM (Xold); // Xold gets 100.00000
Xnew = FORMATTED_NUM (Xnew); // Xnew gets 110.00000
Delta1 = Xnew - Xold; // Delta1 gets 10.0000
FORMATTED_NUM must use a single variable argument. We cannot write:
Delta1 = FORMATTED_NUM (Xnew - Xold); // illegal expression!!!

3.3.6.2 FRAC_DIGITS Function

This function is also related to the format of variable. It returns the maximum number of digits in the
fraction part of the variable. In other words, it gives the level of precision that is used to output
variables of that format.
Note that the returned value does not depend at all on the variable value. It is derived directly from the
variable format (which is fixed for the duration of the run).
The FRAC_DIGITS function in GPP2 comes to substitute a similar capability that was part of the old
GPP CONVERT statement that is not supported in GPP2.
The following examples assume VAR has a format with maximum 2 decimal digits for the fraction part.
VAR = 2.9999; Set internal value to 2.9999
N = FRAC_DIGITS(VAR); N gets 2
VAR = 3;
N = FRAC_DIGITS(VAR); N stays 2 (not dependent on VAR’s value)
CimatronE 10.0 GPP2 User Guide ⎪85

3.3.6.3 INT_ and FRAC_ Functions

These functions return the integer and the fraction parts of a variable value, respectively.
It is important to note the relationship between these two functions and the special GPP2 variable
“formats”. INT_ and FRAC_ work on the actual value of numeric expressions, ignoring any variable
format information. This may lead to confusion in some cases, if variable formats are ignored.
For instance, assume the variable VAR has the value 2.9999, but its format only allows 2 decimal
digits for the fraction part. Sending VAR to output will print the string “3.00”. When compared to other
variables, VAR will behave as if it has the value 3.00 (see discussion on numeric expression
comparison later in this document).
However, INT_ and FRAC_ ignore the variable format. INT_(VAR) will return 2, and FRAC_(VAR)
will return 0.9999. In most cases, this is indeed the desired result.
If the GPP2 developer needs to integer and fractional values of a variable while taking into account the
variable format, then the following methods can be used:
• Use of the FORMATTED_NUM function. INT_(FORMATTED_NUM(VAR)) will return 3, while
FRAC_(FORMATTED_NUM(VAR)) will return 0.0. This method does not change the internal value
of VAR – it will remain 2.9999.
• Actually change the value of VAR to its formatted value before using the INT_ and FRAC_
functions. This can be achieved with the FORMATTED_NUM function (see above). Note that this
method changes the internal value of VAR to 3.0000.
Examples
VAR = 2.9999;
IPART = INT_(VAR); Set IPART to 2
FPART = FRAC_(VAR); Set FPART to 0.9999
IPART = INT_(FORMATTED_NUM(VAR)); Set IPART to 3, VAR stays 2.9999
FPART = FRAC_(FORMATTED_NUM(VAR)); Set FPART to 0, VAR stays 2.9999
VAR = FORMATTED_NUM (VAR); Change VAR to 3.0000
IPART = INT_(VAR); Set IPART to 3
FPART = FRAC_(VAR); Set FPART to 0

3.3.7 String Functions

String functions are supported to manipulate strings, concatenate them and split them, look for sub-
strings, etc.

3.3.7.1 String Concatenation

<str-expr> + <str-expr> Concatenate (“add”) strings
The + operator is used to concatenate (add) two or more strings. For instance, if S1 has “abc” and S2
has “def”, then S1 + S2 produces the string “abcdef”. Any two or more
CimatronE 10.0 GPP2 User Guide ⎪86

string expressions can be concatenated, as long as the total length of the resulting string is limited to
256 characters.
Example: the expression DBL_QUOTE + “title” + DBL_QUOTE returns a value of “”title”” (the word
title enclosed in double quotes).
Unlike the OUTPUT command, string concatenation can handle string expressions, but not numeric
expressions. In order to include numbers in string concatenation, they must be first converted into
string, using the STR_FORMAT function. Example:

MSG = MyString + STR_FORMAT(MyNumber);

3.3.7.2 String Length

STR_LEN(<str-expr>) Get string length
This function actually returns a numeric value – the length of the string argument, in characters. An
empty string returns 0.

3.3.7.3 String to Number

STR_NUM(<str-expr>) Convert string to number
This function also returns a numeric value, converting its string argument to a number. It is the GPP
developer responsibility to ensure that the string can be properly converted to a number.
For instance STR_NUM(“0.5”) returns the number 0.5. However, STR_NUM(“xyz”) returns an
unpredictable number. No runtime warning or error is generated, even if the string does not translate
to a valid number.

3.3.7.4 Numeric Variable to String

STR_FORMAT (<variable>) Convert numeric variable to string
This function returns a string value, formatting its numeric variable as a string. The conversion takes
place according to the variable format. The variable must be of a numeric format.
The resulting string is the same as would be generated if the variable would be sent to output.
The function is especially useful when the user wishes to build a string made up of constants and
variables, some of which are numeric.
Examples: Assume the format of NUM allows 3 digits for the fraction part.
NUM = 5/3; // NUM gets 1.666666...
S = STR_FORMAT (NUM); // S gets “1.667”
S = STR_FORMAT (NUM) + “ mm”; // S gets “1.667 mm”
The STR_FORMAT function may also be used in conjunction with the tool parameter functions, namely
TOOL_FIRST, TOOL_LAST and TOOL_NEXT (see below), since they actually represent variables with
a well-defined format.
S = STR_FORMAT(NEXT_TOOL(DIAMETER_)); // valid
CimatronE 10.0 GPP2 User Guide ⎪87

3.3.7.5 Sub-Strings

STR_LEFT(<str-expr>, <num-expr>) Left N characters

This function returns a string value, equal to the left N characters of the first function operand, where
N is the value of the second function operand (rounded to an integer).
For example, STR_LEFT(“abcdef”, 3) returns the string “abc”.

STR_RIGHT(<str-expr>, <num-expr>) Right N characters

This function returns a string value, equal to the right N characters of the first function operand, where
N is the value of the second function operand (rounded to an integer).
For example, STR_RIGHT(“abcdef”, 4) returns the string “cdef”.
Note that STR_LEFT and STR_RIGHT can be combined in order to obtain any sub-string from a given
string. For instance, STR_RIGHT(STR_LEFT(“abcdef”, 4), 2) returns the string “cd”.
Both functions will generate runtime errors if the numeric argument is invalid (e.g., if it is negative).

STR_SEARCH(<str-expr>, <str-expr>) Search sub-string

This function returns a numeric value, defined as follows:
• The first argument is the source string, where a sub-string is searched.
• The second argument is a sub-string to search inside the source string.
• If the sub-string is found, the returned number is the position in the source string of the first
occurrence of the sub-string (the first character is position 1).
• If the sub-string is not found, the function returns 0.
The two function arguments must be separated by a comma.
Examples:
STR_SEARCH(“abcdef”, “a”) returns 1.
STR_SEARCH(“123123123”, “31”) returns 3.
STR_SEARCH(“123123123”, “ab”) returns 0.
CimatronE 10.0 GPP2 User Guide ⎪88

3.3.7.6 Other String Functions

STR_LOWER(<str-expr>) Convert string to lowercase
STR_UPPER(<str-expr>) Convert string to uppercase
These two functions return a string value, which is the same as the input string, except that all letters
are converted to lowercase or uppercase.
For instance, STR_LOWER(“ABC123def”) returns the string “abc123def”.

STR_CLEAN(<str-expr>) Remove spaces from string

This function returns a string value, which is the same as the input string except that all space
characters are removed from the input string.
For example, STR_CLEAN(“ abc def “) returns “abcdef”.

3.3.7.7 Splitting Strings to Sub-strings

GPP2 contains a new statement that allows splitting a string into sub-strings. Note – this is not a
function and cannot be used in expressions. However, it is described here because it is part of the
GPP2 string manipulation package.

STR_SPLIT <str-expr1> <str-expr2> var1, var2 ...;

The first string expression is the string to be split. It can be any string expression.
The second string expression is the delimiter sub-string. That delimiter will be used to break the first
string into sub-strings. It may be any string expression and contain any number of characters
(although one character is the typical delimiter).
After these two expressions comes a list of string variables, where the resulting sub-strings will be
stored. At least two variables must be provided. Array members may be used (but not full arrays).
STR_SPLIT will break the source string into smaller sub-strings (based on the delimiter) and will store
them in the target variables. It will use the following rules:
• Delimiter characters that are used to separate sub-strings are removed and not copied to any
target variable.
• If the delimiter is not found at all in the source string, the entire string will be copied to the first
target variable.
• If not enough target variables are provided (too many delimiters found), the “rest” of the source
string will be copied to the last target variable (including “unused” delimiters).
• If too many target variables are provided, the rest of them will be assigned empty strings.
CimatronE 10.0 GPP2 User Guide ⎪89

Examples:

STR_SPLIT “abc/def” “/” var1 var2; // var1 = “abc”, var2 = “def”

STR_SPLIT “abcdef” “/” var1 var2; // var1 = “abcdef”, var2 = “”

STR_SPLIT “ab/cd/ef” “/” var1 var2; // var1 = “ab”, var2 = “cd/ef”

STR_SPLIT “abc/def” “/” v1 v2 v3; // v1 = “abc”, v2 = “def”, v3 = “”

STR_SPLIT “abc||def” “||” var1 var2; // var1 = “abc”, var2 = “def”

3.3.7.8 Replacing-strings

<str-expr2> = STR_REPLACE (<str-expr1>, CH1, CH2)

Replace all characters of type ch1 by character of type ch2 in the original string and return the result in
the modified string.
Example:
<str-expr1> = "This is the original string”;
OUTPUT "**** original string = " <str-expr1> ;
<str-expr2> = STR_REPLACE (<str-expr1>, "i", "1");
OUTPUT "**** replaced string = " <New string>;
Output result:
**** ORIGINAL STRING = THIS IS THE ORIGINAL STRING
**** REPLACED STRING = TH1S 1S THE OR1G1NAL STR1NG
CimatronE 10.0 GPP2 User Guide ⎪90

3.3.8 Tool Parameter Functions

GPP2 supports three special new functions that return the value of any “tool” variable, of the first, last
or next tool.
FIRST_TOOL (<tool-variable>) // first tool in run
LAST_TOOL (<tool-variable>) // last tool in run
NEXT_TOOL (<tool-variable>) // next tool
NEXT_PROC_TOOL (<tool-variable>) // tool of next procedure
The tool variable may be any of the system variables used in the CHANGE TOOL block (e.g.,
TOOL_NUM or TOOL_NAME).
The functions do not have a fixed return type. They return a value that is either numeric or string,
depending on the type of the requested tool variable. The GPP developer must be familiar with the
tool variable types in order to use them correctly.
FIRST_TOOL (TOOL_NUM) Returns a numeric value
FIRST_TOOL (TOOL_NAME) Returns a string value
The variable argument must be one of the TOOL CHANGE variables. An attempt to use another
variable (e.g., X_CURPOS) will result in a compilation error.
A more detailed discussion on these functions and the subtle differences between NEXT_TOOL and
NEXT_PROC_TOOL is provided in the GPP Theory of Operation document.
Note: the tool parameter functions cannot be used directly in OUTPUT and PRINT statements (these
functions do not accept any expressions). In order to output NEXT_TOOL(TOOL_NUM) together with
NEXT_TOOL(TOOL_NAME) the following code should be used (assume Str is a string variable):
Str = STR_FORMAT(NEXT_TOOL(TOOL_NUM) + “ “ + NEXT_TOOL(TOOL_NAME);
OUTPUT Str;
CimatronE 10.0 GPP2 User Guide ⎪91

3.3.9 Boolean Expressions

Boolean expressions are used in program control statements, such as IF and REPEAT UNTIL. They
return a TRUE or FALSE result, which is used by GPP to decide the correct course of action (e.g.,
break the REPEAT loop when the UNTIL condition returns TRUE).

3.3.9.1 Comparisons

The basic Boolean expressions compare between two expressions:

<expr1> _EQ_ <expr2> Equal
<expr1> == <expr2> Equal
<expr1> _NE_ <expr2> Not Equal
<expr1> != <expr2> Not Equal
<expr1> _LT_ <expr2> Less Than
<expr1> < <expr2> Less Than
<expr1> _LE_ <expr2> Less than or Equal
<expr1> <= <expr2> Less than or Equal
<expr1> _GT_ <expr2> Greater Than
<expr1> > <expr2> Greater Than
<expr1> _GE_ <expr2> Greater than or Equal
<expr1> >= <expr2> Greater than or Equal
Notes:
1. It is possible to compare expressions of different types (that is, one numeric expression and
one string expression). However, this is not recommended, and may lead to unexpected
results.
2. In old GPP, only the _XX_ comparison operators were supported. In GPP2, new “standard”
operators were added (after the operators used in the C Programming Language). Both forms
are supported, and can be used freely.
3. See sections below on exactly how expressions are compared.

3.3.9.2 Comparing Numeric Expressions

GPP compares numeric expressions in a non-standard way. Instead of simply comparing the numeric
values (double precision floating point), it takes into account the formatting of values as they are sent
to output.
If an operand of the comparison is a variable, it is temporarily “printed” using the variable format, and
the resulting string is converted back into a number before it is used in the comparison.
CimatronE 10.0 GPP2 User Guide ⎪92

For instance, suppose two variables, X and Y, both have a value of 11/3 (3.666666…). However, they
have different formats. When formatted, X uses 3 fractional digits, so it is formatted as 3.667, while Y
uses 1 fractional digit and is formatted as 3.7. When compared by GPP, these two numbers will come
out as non-equal (although internally, they have the same value)! It is therefore not recommended to
compare variables of different formats, as results are difficult to predict.
GPP will ignore “minor” formatting issues, such as leading or trailing zeros. For instance, suppose now
X and Y both have the value of 2.5. But Y is formatted with at least 3 fractional digits, with trailing
zeros. Once formatted, X will result in 2.5, while Y will give 2.500. In such a case, GPP will treat them
as equal. GPP2 also ignores other minor formatting options, such as the characters used for the plus
or minus sign or whether a decimal point is used for integer values. So, GPP2 will treat “2”, “+2”, “2.”
and “2.000” as equal.
When a non-variable expression is compared to a variable, the non-variable expression is also
formatted using the variable format, to ensure proper comparison.
When none of the two operands is a simple variable (e.g., X + 3 <= Y ** 2), both expressions are
formatted using the REAL format, before being compared.

3.3.9.3 Comparing String Expressions

GPP compares two string expressions in the following way:

• Strings are compared one character at a time, in a case-sensitive way (so ‘A’ is not equal to ‘a’).
• As soon as one different character is found, comparison stops. GPP determines which string has
the “smaller” character based on the ASCII table, and that string is considered “smaller” than the
other.
• If no different character is found, and one string ends before the other – that string is considered to
be “smaller” than the other.
• If all characters are the same, and the strings end together, they are considered equal.
It is possible to use all the comparison operators for strings, such as ‘==’, ‘<’, etc. They work in the
intuitive way under the definition of string comparison listed above.
Examples:
“abcd” is smaller than “abx” (since c < x)
“abcd” is larger than “abc” (since the first string is longer)
“abc” is larger than “ABC” (since in ASCII ‘a’ comes after ‘A’)
Note: if case-insensitive comparison is wanted, the STR_LOWER (or STR_UPPER) function can be used
to convert both expressions to lowercase (or uppercase) before using them in the comparison
expression.
STR_LOWER(“abc”) is equal to STR_LOWER(“ABC”)
CimatronE 10.0 GPP2 User Guide ⎪93

GPP Compatibility Notes:

In old GPP, string comparison was done in a non-standard way. It ignored any trailing spaces, so that
“abc “ and “abc” were found to be equal. This behavior was not kept in GPP2, which uses standard
string comparison.
In old GPP, it was only possible to compare a string variable with a string constant. Also, it was only
possible to check if the string is equal or not equal to the constant. In GPP2, any two string
expressions can be compared, using any of the comparison operators.

3.3.9.4 Comparing Mixed Expressions – Not Recommended

It is possible, but highly not recommended, to compare one numeric expression and one string
expression. The expressions are compared as numeric entities:
• The numeric argument is formatted as a string using the appropriate format (as explained above,
in comparing two numeric expressions), and that string is converted to a numeric value again.
• The string argument is converted to a floating point number.
• The two numbers are compared.
It is the GPP developer’s responsibility to ensure that the string can be properly converted to a
number. If not, results are unpredictable.

3.3.9.5 Testing Variable Set Status

A major GPP capability is to decide whether a variable is set “on” or “off”, and to take action
accordingly. The following Boolean functions are available to support this:
VAR_SET(<var>) TRUE if <var> is set, FALSE if not
VAR_NOTSET(<var>) TRUE if <var> is not set, FALSE if it is
The variable argument for the function may be a simple variable or an array member. Full array
variables cannot be used (each member has its own “set” flag).
Examples: VAR_SET(X), VAR_NOTSET(AR[12]), VAR_SET(AR[Y+1])
CimatronE 10.0 GPP2 User Guide ⎪94

GPP2 will issue a compilation warning if the VAR_SET or VAR_NOTSET functions are used with non-
modal variables (since this test is mostly useful for modal variables).

GPP Compatibility Notes:

In old GPP, testing that a variable is set “on” was done without such functions. It was enough to
specify the name of that variable in the IF_SET condition, and GPP knew that the meaning was to the
set status flag, not to the variable value. This is equivalent to using the VAR_SET function.
This backward-compatibility option is maintained in GPP2, and is further discussed in the relevant
statement sections.
In the GPP2 programming language, a variable name is not a Boolean expression – it is a numeric or
string expression (depending on the variable type). Proper use of the language requires the use of the
VAR_SET and VAR_NOTSET functions. Building complex Boolean expressions is only possible with
these functions.

3.3.9.6 Complex Boolean Expressions

It is possible to combine Boolean expressions with logical OR & AND operations, to form more
complex Boolean expressions.
<bool-expr1> _AN_ <bool-expr2> Logical AND operation
<bool-expr1> && <bool-expr2> Logical AND operation
<bool-expr1> _OR_ <bool-expr2> Logical OR operation
<bool-expr1> || <bool-expr2> Logical OR operation
An AND Boolean expression gives a TRUE value if both of its operands are TRUE.
An OR Boolean expression gives a TRUE value if at least one of its operands is TRUE.
These logical operations did not exist in old GPP. However, in order to support developers who prefer
the traditional operator style (_XX_), both styles have been implemented (traditional and C-like) and
can be used.
Only Boolean expressions can be used as operands for these logical operations.
Examples:
X >= 10 && S1 = “abc”
(X > 0 && Y > 0) || (X < 0 && Y < 0)
Note that the logical AND operator takes precedence over the logical OR operator (like multiply takes
precedence over plus). Therefore, the second example could have been written without the
parentheses. However, it is always advised to use parentheses in such expressions, in order to make
them clearer and to avoid programming errors.
CimatronE 10.0 GPP2 User Guide ⎪95

3.4 Program Structure

A GPP program is made up of a declaration part and several execution blocks. The declaration part
must precede the execution blocks.

3.4.1 Declaration Part

The declaration part is defined from the beginning of the program file to the first execution block. This
is where the following types of declarations can be done:
• A post-processor title string can be defined
• License protection can be defined for the post-processor
• User-defined variables are declared
• Interaction variables are declared (user-defined and system variables)
• Format of system variables can be modified from the default formats
• Variables can be defined as “identical”
• Variables can be defined as modal
• Variables can be defined as “always formatted”, which means their internal value is always set to
be equal to their formatted value.
• The output file “tab” positions can be defined
• Connection scenarios can be defined.
All declaration statements must be placed inside the declaration part, before any execution block. If a
declaration statement is found later in the program (inside one of the execution blocks), it is rejected
by GPP with a compilation error.

3.4.2 New-Line-Is Section

GPP allows the developer to define a special new-line symbol (character), which can be used in
OUTPUT statements throughout the program. Each time this new-line character is encountered as an
OUTPUT argument, the new-line-is block is executed.
The new-line-is block is not mandatory in a GPP program. However, it must be defined if a new-line
character is used in any OUTPUT statement. No more than one such block is allowed in a GPP
program file. It is recommended to locate it immediately after the declaration part.
The format of the new-line block is as follows:
NEW_LINE_IS <char>;
Sequence of execution statements
The new-line character must be a non-alphanumeric character, but not one that is used inside the
GPP language (e.g., +, *, =, > or < are not allowed). It can be one of the following characters:
CimatronE 10.0 GPP2 User Guide ⎪96

$ ! @ # % ^ & { } | ~ ?
Example:
NEW_LINE_IS $ ; // new-line character is $
OUTPUT \J “N” SEQ; // output new-line and sequence number
SEQ = SEQ + SEQINCR; // increment sequence number

3.4.3 Regular Execution Blocks

Most of the GPP program is defined in execution blocks. GPP operates by reading toolpath blocks one
after the other, and then executing the corresponding program block. In GPP2, only System-defined
Blocks are used. User-defined blocks are not supported.
Each execution block is defined by the block name immediately followed by a colon and an optional
qualifier, also followed by a colon. The block name must start at the first character of a line. The block
body consists of a sequence of execution statements, following the block name line.
Example 1:
<Block Name>:
Sequence of Execution Statements
Example 2:
<Block Name>: <qualifier>:
Sequence of Execution Statements

3.4.4 System-Defined Blocks and Qualifiers

The full list of system-defined blocks and their qualifiers in given in the “GPP2 Theory of Operation”
document.
CimatronE 10.0 GPP2 User Guide ⎪97

3.5 Declaration Statements

These are the declarations that appear in the GPP Program declaration part. All of them are optional.
Every statement ends with a semi-colon (;).

3.5.1 Post Processor Title

This feature allows the GPP developer to define a title string for the specific post-processor being
developed. That title string will be presented to the GPP user at runtime, giving additional information
about the post-processor (e.g., the target machine and controller, customer name, etc.). The use of
this statement is optional.
GPP_TITLE <string> ;
The string may contain the “\J” combination, which indicates a new-line character. Once a “\J” is
encountered, the GPP2 application will display the title over multiple lines. The total length of the title
string is limited to 256 characters.
Only one title string can be used in each post-processor. If multiple GPP_TITLE statements are used,
GPP2 will only “remember” the last one.
Examples:
GPP_TITLE “Post XYZ, developed for ABC”; // single line
GPP_TITLE “Line one \JLine two \JLine three”; // multi-line
Note: the string must be written in one line in the GPP program, even if it is very long and contains
multiple “\J” controls.

3.5.2 Post Processor Protection

This feature allows the GPP developer to protect the post-processor with a specific license module.
GPP_PROTECT <string> ;
GPP2 uses the standard Cimatron licensing mechanism. It uses standard modules, namely GPP2_3X
and GPP2_5X. In addition a PP-specific module can be defined with the GPP_PROTECT statement.
This way, each Cimatron Provider can protect its own post-processors, and give evaluation and
permanent licenses.
The use of this statement in a post-processor is optional. If used, GPP2 will try and grab the specified
license. If not available, execution will stop and a runtime error message will be generated.
Multiple provider-specific license modules can be used in each post-processor. If multiple
GPP_PROTECT statements are used, GPP2 only requires one of them to be available in the user
license. It will search for them, one after the other, according to the order of their appearance in the
EX2 program.
Examples:
GPP_PROTECT “PP_XXX_V2” ; // defines the controller
GPP_PROTECT “TechSupport” ; // For the provider personnel
CimatronE 10.0 GPP2 User Guide ⎪98

3.5.3 FORMAT
The FORMAT statement is used to declare user-defined variables and to override the default format of
system variables.
FORMAT (<format-name>) variable1 variable2 ... ;
The format name must be one of the available 19 GPP formats, defined earlier in this document (e.g.,
CHARACTER, COORDINATES, etc.). It must be enclosed in parenthesis. Any number of variables may
be specified in one statement, separated by spaces. As with any statement, it is terminated with a
semi-colon (;).
If the statement specifies a new user-defined variable, it is created by GPP. If the statement specifies
an existing system or user-defined variable, it only changes the format of this variable.
Each time a FORMAT statement is executed, it also sets the variable type – string for CHARACTER
format and numeric for all other formats.
Arrays may also be defined with the FORMAT statement by specifying the number of members in the
array (a constant integer number must be used).
Examples:
FORMAT (USER_1) X Y Z; // creates 3 variables with USER_1 format
FORMAT (COORDINATES) X_CURPOS; // redefine format of system variable
FORMAT (REAL) Queue1[100]; // create an array with 100 members

3.5.4 INTERACTION
The INTERACTION statement defined a user-define or system Interaction variable, to be used by the
GPP user to enter information at runtime.
INTERACTION (<format-name>) “prompt” variable = init-value ;
INTERACTION (<format-name>) “prompt” system-variable;
Only one Interaction variable may be defined in each INTERACTION statement, and it cannot be an
array.
The format name must be one of the available 19 GPP formats, or the special keywords
MULTI_CHOICE and BOOLEAN_, and must be enclosed in parenthesis.
The MULTI_CHOICE pseudo “format” is used for interaction variables that should be displayed to the
user as a List-Box with multiple choices (e.g., “Flat” and “Nested”). See more details below.
The BOOLEAN_ pseudo “format” is used for Yes/No interaction variables. See more details below.
The “prompt” string will be displayed to the GPP user at runtime, typically explaining the nature of the
Interaction variable and asking for input. Like any GPP string, it may be up to 256 characters long.
For user-defined interaction variables, a default initial value for the variable must also be specified (the
= sign is mandatory). This is the value GPP will use if the user does not make any changes to this
CimatronE 10.0 GPP2 User Guide ⎪99

variable. For system interaction variables, initial values are not allowed – the initial values for system
variables can only be set from the DF2 file.
For numerical variables, any data entered by the GPP user at runtime is used “as is”, and never
multiplied by the unit factor, even if the interaction variable uses the COORDINATES format.
GPP2 maintains the value of Interaction variables between toolpath runs (but not between sessions).
For instance, suppose an Interaction variable STARTNUM has the default initial value of 0. Now
suppose the user changes this value to 100 and runs the post-processor to generate an output file.
Now he runs the same post-processor again on a different toolpath - the Interaction variable will show
a value of 100. Re-loading the post-processor or closing GPP and starting it again will reload the
default value defined in the INTERACTION statement. Note, however, that changes made to
interaction variables in the GPP2 program will not have any effect on the next run – only the values
entered by the user are maintained.
No more than 50 Interaction statements can be defined in each GPP program.
Examples:
INTERACTION (CHARACTER) “Enter Name:” Name = “Cimatron”;
INTERACTION (COORDINATES) “Enter Size:” Size = 100;
INTERACTION (SEQUENCING) “Sequencing Start Number:” SEQ_START;

3.5.4.1 System Interaction Variables

The system variables in INTERACTION statements allow the end-user to override values assigned to
system variables in the DF2 file.
For instance, a DF2 parameter specifies the start number for sequencing. That parameter initializes
the system variable SEQ_START. By defining SEQ_START in an INTERACTION statement, the end-
user gets the ability to change the sequencing start value at runtime.
When using system variables in INTERACTION statements, no initialization value is allowed. The
initial value for these system variables only comes from the DF2 file.
When using system variables in INTERACTION statements, the format parameter does not change
the system variable format. It is only used if MULTI_CHOICE or BOOLEAN_ are specified, in which
case the interaction takes a special form (as explained below). The specified format argument must
“match” the system variable format – they must both be of type string (format CHARACTER) or type
numeric (all other formats).

3.5.4.2 Multi-Choice Interaction Variables

MULTI_CHOICE interaction variables allow the GPP developer to define a variable that can get one
value out of a list of allowed values.
MULTI_CHOICE variables are actually numeric integer variables. They use the value 1 to represent
the first choice, 2 for the second choice, and so on. They should never be assigned values smaller
than 1 or larger than the number of options defined for them.
The actual internal format of MULTI_CHOICE variables is SEQUENCING (if used for OUTPUT, the result
CimatronE 10.0 GPP2 User Guide ⎪100

will be a number, with the SEQUENCING format).

In MULTI_CHOICE interaction variables, the prompt string must contain the actual prompt to be used,
followed by all the choices displayed to the user, separated by the ‘/’ character. The total length of the
prompt string is limited to 256 characters.
Examples:
INTERACTION (MULTI_CHOICE) “Tool Change/Auto/Manual” TC = 1;
Note that the initial value is 1, which corresponds to the first choice of “Auto”. A value of 2 represents
“Manual”, and no other values are valid.
INTERACTION (MULTI_CHOICE)
“Support arcs on planes:/None/XY Only/Major Planes/Any Plane”
ARCS_CTRL_BYPLANE; // system variable examples
In this example, the user gets to see and potentially change the way the machine handles arcs. It is a
four-choice system variable, initialized by the corresponding DF2 parameter. The format of
ARCS_CTRL_BYPLANE is not modified.
GPP2 does not enforce the assignment of specific “valid” numbers to MULTI_CHOICE variables. It is
the responsibility of the GPP developer to ensure that the assigned values fall within the valid range.

3.5.4.3 Boolean Interaction Variables

Boolean interaction variables allow the GPP developer to define a simple choice variable that can be
either “Yes” or “No”.
BOOLEAN_ variables are actually numeric integer variables. They use the value 0 for “No” and 1 for
“Yes”.
The actual internal format of BOOLEAN_ variables is SEQUENCING (if used for OUTPUT, the result will
be a number, with the SEQUENCING format).
Unlike MULTI_CHOICE variables, the prompt string for BOOLEAN_ interaction variables does not have
to contain any choices displayed to the user (they are always “Yes” and “No”).
Examples:
INTERACTION (BOOLEAN_) “To Be or Not to Be?” TheQuestion = YES_;
Note that the initial value is YES_ (equal to 1), which corresponds to “Yes”. All the Boolean constants
(TRUE_ and YES_ for 1, FALSE and NO_ for 0) can be used as initial values for Boolean interaction
variables.
GPP2 does not enforce the assignment of values to BOOLEAN_ variables. It is the responsibility of the
GPP developer to ensure that only 0 or 1 are assigned to such variables.
CimatronE 10.0 GPP2 User Guide ⎪101

3.5.5 IDENTICAL – Not Recommended

The IDENTICAL statement declares two or more variables as “identical”, meaning they will always
have the same value and will always be set “on” or “off” together. Changing one of the variables
(either by GPP or through the program) will affect all of them in the same way.
IDENTICAL variable variable2 …;
All variables in one “identical” group must be of the same type (numeric or string). However, they do
not have to be of the same format. Recall that even if their format is different, the internal value of
identical variables will be the same.
Arrays and array members cannot be used in the IDENTICAL statement.
It is not recommended to include more than one system variable in an “identical” group. GPP may
need to assign two different values to these two different system variables, which cannot be done if
they are identical. They will end up having the same value, but it is not possible to predict which value.
GPP will produce a compilation warning in such a case.
Examples:
IDENTICAL A B C;
IDENTICAL XLOCAL X_CURPOS;

3.5.6 MODAL
The MODAL statement can be used to define variables, both system and user-defined, as modal. See
earlier section for a detailed discussion on variable modality.
MODAL variable variable2 ...;
Note that in GPP2 all variables are non-modal by default. This statement allows the GPP developer to
define specific variables as modal.
Arrays can be used as arguments to these statements. However individual array members cannot be
used – the whole array is either modal or non-modal.
Examples:
MODAL X Y X_CURPOS;
MODAL ARRAY;

GPP Compatibility Notes:

In old GPP, there was also a NON_MODAL statement. With GPP2, all variables are non-modal by
default, so there is no need for this statement.
With old GPP, it was possible to use a special ALL_VAR pseudo variable as an argument to the
MODAL statement. ALL_VAR is not supported in GPP2.
CimatronE 10.0 GPP2 User Guide ⎪102

3.5.7 SET_TABS
The SET_TABS statement defines the GPP tab positions. Tab positions can be used when the GPP
developer wishes to align output characters to specific positions (columns) in the output file.
SET_TABS N1 N2 N3 ...;
Up to 20 tab positions can be specified in the SET_TABS statement, and they must be specified in
increasing order. The GPP default tab positions are 8, 16, 24, …, up to 160.
The tab positions are used with the special TAB_ keyword used in an OUTPUT statement. See a more
detailed discussion in the section describing the OUTPUT executable statement.
Example:
SET_TABS 4 8 12 16 24 28 32 40; // 4 column increments
SET_TABS 2 4 8 16 32 64 66 // any sequence is OK

3.5.8 ALWAYS_FORMATTED
This new GPP2 statement can be used to define variables that keep their internal value always equal
to their “formatted” value (the value that will be sent to output).
ALWAYS_FORMATTED variable variable2 ...;
Arrays can be used as arguments to the statement. However individual array members cannot be
used – the whole array is either “always formatted” or not.
The statement should only be applied to numeric variables. It has no effect on string variables.
This behavior is especially convenient in incremental post-processors, where the last position should
be kept exactly as output to the machine. Otherwise, a rounding error will accumulate over the
toolpath points. The obvious target variables for this statement are the “LASTPOS” variables, but it
can be used for any numeric variable.
Examples: ALWAYS_FORMATTED X_LASTPOS Y_LASTPOS Z_LASTPOS;
Following that statement, each time values will be assigned to these variables, GPP2 will format the
value and set the internal value to be equal to the formatted one. This holds true for internal
assignments by GPP2 as well as explicit assignments in the EX2 program.
For instance, assume that all the coordinate variables use 3 digits after the decimal point. Assume
MyVar is a user variable of the coordinate format too. Consider the following statements:
MyVar = 9.9999999; // MyVar gets 9.9999999 (internally)
X_LASTPOS = MyVar; // X_LASTPOS gets 10.0 (internally)
OUTPUT $ MyVar “ “ X_CURPOS; // output is “10.000 10.000”
Note that the output of both variables is “10.000”, whereas the internal values are different because of
the “always formatted” nature of X_CURPOS.
CimatronE 10.0 GPP2 User Guide ⎪103

3.5.9 CONNECTION_SCENARIO
GPP2 connections are series of motions and machine control operations generated by GPP2 in order
to connect between toolpath points in a safe and predictable way. Connections take place in several
points throughout the execution, such as at the beginning of procedures or between 5X segments.
See the GPP2 Theory of Operation Manual for more details about GPP2 connections.
GPP2 connections follow a “scenario”, which is a sequence of actions. GPP2 has four built-in
scenarios, and the EX2 programmer can override them or add any number of additional scenarios.
This is done with the CONNECTION_SCENARIO declaration statement.
CONNECTION_SCENARIO <scenario-name> <list-of-actions> ;
Usually, the statement is very long, since it includes several actions and each action contains several
arguments. Therefore, it is recommended to split the statement over multiple lines.
The <scenario-name> argument must be a string constant. It can be any string, and may include
spaces. The names are not case-sensitive (so “scenario1” and “SCENARIO1” refer to the same
scenario).
GPP2 uses four predefined default scenario names, namely “short”, “long”, “through-safe” and
“tool-change”. The use of any of these names in the statement replaces the default scenario of that
name with the one described in the CONNECTION_SCENARIO statement. Any other name creates a
new scenario.
CONNECTION_SCENARIO “long” <actions> ; // replaces built-in “long” scenario
CONNECTION_SCENARIO “very long” <actions> ; // creates new scenario

3.5.10 Scenario Actions

Each scenario action has an action name and a list or arguments enclosed in parenthesis. The
number of arguments and their type vary by action type.

3.5.10.1 Move

MOVE_ ( <speed> <axes> <target> <multi-Y/N> )

The MOVE_ action is the generic motion action. It uses the following arguments:

Argument Allowed values Effect

<speed> CON_FAST Defines the motion speed.

CON_MAXFEED CON_FAST results in a rapid machine motion.
CON_FEED CON_MAXFEED results in a fast “feed” motion,
using the feed rate from the DF2 parameter for
user-defined maximum feed rate.
CON_FEED moves in the current feed rate.
CimatronE 10.0 GPP2 User Guide ⎪104

<axes> A string made up of Defines the axes along which the motion will
the letters XYZAB take place (in the REF UCS). Any combination
(e.g. “XY” or “AB”) of the 5 letters is allowed, in any order. Other
letters are not allowed and result in a runtime
error.

<target> CON_P2 Defines the target of the motion (only the

CON_HOME relevant axes will move).
CON_P2 represents the final connection target
CON_ZERO
point.
CON_HOME represents the “home” point, as
defined in the X/Y/Z_HOME variables.
CON_ZERO literally represents the value 0.0
(e.g., one can move the B axis to 0.0.).

<multi-Y/N> TRUE_ Defines if the motion can be broken down to

multiple linear motions (if TRUE_) or must be
FALSE_
done in one linear motion (FALSE_).

3.5.10.2 Move Up

MOVE_UP ( <speed> <axis> <target> )

The MOVE_UP action will only create a motion if the target point is “higher” than the current tool point,
where “higher” is measured along the motion axis.
It uses the following arguments:

Argument Allowed values Effect

<speed> Same as in MOVE_ Same as in MOVE_

<axis> A string made up of Defines the one axis along which the motion
one letter X, Y or Z will take place (in the REF UCS).
and an optional ‘-‘
Only one axis may be specified, with an
(e.g. “Z” or “-X”)
optional minus sign to indicate how “high” is
measured.

<target> Same as in MOVE_ Same as in MOVE_

CimatronE 10.0 GPP2 User Guide ⎪105

3.5.10.3 Move Down

MOVE_DOWN ( <speed> <axis> <target> <cutter-length-comp> )

The MOVE_DOWN action will only create a motion if the target point is “lower” than the current tool point,
where “lower” is measured along the motion axis.
It uses the following arguments:

Argument Allowed values Effect

<speed> Same as in MOVE_ Same as in MOVE_

<axis> A string made up of Defines the one axis along which the motion
one letter X, Y or Z will take place (in the REF UCS).
and an optional ‘-‘
Only one axis may be specified, with an
(e.g. “Z” or “-X”)
optional minus sign to indicate how “lower” is
measured.

<target> Same as in MOVE_ Same as in MOVE_

<cutter- TRUE_ Defines if the linear motion will use a “cutter-

length-comp> length-compensation” qualifier (TRUE_) or not
FALSE_
(FALSE_).

3.5.10.4 Move to Safe Position

MOVE_SAFE ( <axes> )
The MOVE_SAFE action invokes the GPP2 “MOVE TO SAFE” block, where the EX2 program is
expected to move the tool to a safe position on the required axes.
It uses the following arguments:

Argument Allowed values Effect

<axes> A string made up of the Defines the axes along which the tool must be taken to
letters XYZAB (e.g. the safe position. Any combination of the 5 letters is
“XYZ” or “Z”) allowed, in any order. Other letters are not allowed.
The value of this argument is copied to the
ACTION_SAFE_AXES variable, to be used by the EX2
program in the MOVE TO SAFE block.
CimatronE 10.0 GPP2 User Guide ⎪106

3.5.10.5 Machine Control

MACHINE_CONTROL ( <qualifier> <num1> <num2> <string> )

This action invokes the new GPP2 “MACHINE CONTROL” block. It is intended for operations that do
not involve tool motion, such as turning the coolant on or off or defining a work plane in a 5X machine.
It uses the following arguments:

Argument Allowed values Effect

<qualifier> Any string constant This argument becomes the qualifier used by GPP2
(e.g., “cool-off” or when invoking the MACHINE CONTROL block. This
“RTCP-ON”) block supports user-defined qualifiers for better
program organization.

<num1> Any numeric The value of this argument is copied to the

constant CONTROL_NUM_1 variable, to be used by the EX2
program in the MACHINE CONTROL block.

<num2> Any numeric The value of this argument is copied to the

constant CONTROL_NUM_2 variable, to be used by the EX2
program in the MACHINE CONTROL block.

<string> Any string constant The value of this argument is copied to the
CONTROL_STRING variable, to be used by the EX2
program in the MACHINE CONTROL block.
CimatronE 10.0 GPP2 User Guide ⎪107

3.5.10.6 Set UCS

SET_UCS ( <qualifier> <position> <rotation> <string> )

This action invokes the new GPP2 “SET UCS” block, specifically intended for defining work planes in
5X machines. It is similar to the MACHINE CONTROL block, except that GPP2 uses a specific logic to
avoid repetitive calls in case the block is not needed (see below).
It uses the following arguments:

Argument Allowed values Effect

<qualifier> Any string constant This argument becomes the qualifier used by
(e.g., “ref” or “proc”) GPP2 when invoking the SET UCS block. This
block supports user-defined qualifiers for better
program organization.

<position> Any numeric The value of this argument is copied to the

constant CONTROL_NUM_1 variable, to be used by the
EX2 program in the SET UCS block.
By convention (only), use the UCS position
definition, such as POS_REF.

<rotation> Any numeric The value of this argument is copied to the

constant CONTROL_NUM_2 variable, to be used by the
EX2 program in the SET UCS block.
By convention (only), use the UCS rotation
definition, such as ROT_RESET.

<string> Any string constant The value of this argument is copied to the
CONTROL_STRING variable, to be used by the
EX2 program in the SET UCS block.

GPP2 keeps track of the SET_UCS actions used. If a SET_UCS action is invoked with the same
qualifier as a previous one, and there was no change in alpha or beta angles between the two calls,
the second SET_UCS action will be skipped (since the work plane did not change between the
actions).
Note that the <position> and <rotation> arguments do not have to be used for this purpose, and
can really be set to anything. GPP2 only looks at the qualifier when it comes to decide if that SET_UCS
action is “the same” as the previous one.
CimatronE 10.0 GPP2 User Guide ⎪108

3.5.10.7 Forcing a Scenario Action

In some cases, scenario actions may be skipped, if GPP2 determines that they are redundant:
• A MOVE_, MOVE_UP or MOVE_DOWN action where no axis is actually set (so there will be no linear
motion block anyway).
• A SET_UCS action where both the qualifier and the machine axis angles are the same as the
previous SET_UCS action.
However, it is sometimes necessary to force GPP2 to execute the action regardless of these rules.
This is especially important when a SET_UCS action must be executed to ensure that the GPP2 output
UCS is not rotated (before a scenario linear motion).
In order to do this, the FORCE_ACTION keyword is used before the action name:
FORCE_ACTION SET_UCS ( ... action variables ... )
This SET_UCS action will be executed regardless of the previous one.

3.5.10.8 Scenario Examples

The GPP2 default “long” scenario is internally defined as follows:

CONNECTION_SCENARIO "long"
MOVE_UP ( CON_FAST "Z" CON_HOME )
MOVE_ ( CON_FAST "XYAB" CON_P2 TRUE_ )
MOVE_DOWN ( CON_FAST "Z" CON_P2 FALSE_ );
It starts with a motion “up” to the home height (Z_HOME). Then, it moves horizontally, in the X, Y, A
and B axes, to a point above the target point (P2). This motion can be broken down to multiple linear
motions (based on DF2 definitions). Finally, it goes down along the Z axis to the target point, with no
special qualifier. All motions are rapid (G01).
Another scenario involving machine control operations may look as follows:
CONNECTION_SCENARIO "my-tool-change"
MOVE_ ( CON_FAST "AB" CON_P2 FALSE_ )
MACHINE_CONTROL ( “coolant-on” 0 0 “” )
MOVE_ ( CON_FAST "XY" CON_P2 FALSE_ )
MOVE_DOWN ( CON_FAST "Z" CON_P2 TRUE_ );
This scenario can be used instead of the default scenario after a tool change.
First it rotates the alpha and beta axes (assume this is a 5X machine). It does not move the X and Y
axes yet.
Next, it invokes the MACHINE CONTROL block with a “coolant-on” qualifier. Presumably, the EX2
statements in that block turn the coolant on.
CimatronE 10.0 GPP2 User Guide ⎪109

Then it moves the tool horizontally, along the X and Y axes to the point above the target point.
Finally it goes down, along the Z axis to the target point – this time with a cutter-length compensation
qualifier (so the G43 code will be generated).
The decision about which connection is used is done at the end of the END OF CONNECT block.
GPP2 will activate the default connection scenarios according to the context. In case a scenario that is
different from the default is defined, GPP2 has to be told under which conditions to activate it. This
should be done in the END OF CONNECT block.
For example:
The following is a user-defined scenario for an advanced control. In the default scenario there must be
some actions to activate and deactivate 'Working Plane' commands. This scenario is meant to be
activated whenever a short connection needs to be performed under RTCP mode.
CONNECTION_SCENARIO "short-rtcp"
MOVE_UP (CON_FAST "Z" CON_P2 )
MOVE_ (CON_FAST "AB" CON_P2 TRUE_)
MOVE_ (CON_FAST "XY" CON_P2 TRUE_)
MOVE_DOWN (CON_FAST "Z" CON_P2 FALSE_);
For that, the following condition needs to be added to the END OF CONNECT block.
IF (M5_RTCP_M128 == TRUE_ && CON_SCENARIO == "short")
CON_SCENARIO = "short-rtcp";
END_IF;
The condition checks if RTCP mode is turned on and if the conditions match those of a short
connection. If TRUE_, then the connection scenario is changed to “short-rtcp”. Note that
CON_SCENARIO is used both for checking the current status and for changing the scenario. Once
this is done GPP2 will follow the actions of the “short-rtcp” scenario instead those of “short”.
CimatronE 10.0 GPP2 User Guide ⎪110

3.5.11 INIT_FILE
This statement specifies the name of a text initialization file to be loaded and executed before each
run of GPP2.
INIT_FILE <string> ;
The file name may include a full path name, or have no path at all. If no path is specified, GPP2 will
look for the file in the same directory as the post-processors files.
Multiple INIT_FILE statements may be specified in one post-processor. The files are read and
executed in the same order of the INIT_FILE statements.
Examples:
INIT_FILE “C:\Cimatron\standard.txt” ;
INIT_FILE “pp.txt” ;
INIT_FILE “*.txt” ; // ‘*’ is replaced with the PP name
If the file specified in the string argument cannot be found – a warning message is printed, but
execution continues.
The “*.txt” string in the last example has a special meaning. If the first character of the string is ‘*’,
GPP2 replaces it with the post-processor name (without any extension). If the PP file is called
demo.ex2, then this statement will load the file “demo.txt”.
This is a way for the PP developer to give users the ability to create multiple post-processors that only
differ by their initialization, without having to recompile the EX2 file.
The INIT files may contain the following:
- Assignment statements, in the standard EX2 format for these statements. The assigned
variable may be any valid GPP2 variable (system, user-defined or interaction). The assigned
values may be simple constants or full expressions.
- Comments (same format as in EX2 files) and empty lines.
Examples to statements inside INIT files:
SEQ_START = 1000; // numeric assignment
MyComment = “this is a comment”; // string assignment
SEQ_START = SEQ_START + SEQ_INC; // expression
Note that all the user variables used in the INIT files must be defined in the EX2 file (with FORMAT or
INTERACTION statements).
Errors encountered in the execution of INIT file statements are reported, and the faulty statements are
ignored. However, execution continues and other (valid) statements will take effect.
Note that this is a declarative statement. It must appear in the declaration part only, before any
execution block. Trying to use it in a regular block (e.g., at STARTUP) will result in a compilation error.
CimatronE 10.0 GPP2 User Guide ⎪111

3.5.12 REPORT_VARS
Starting from CimatronE 10.0, not all user-defined variables are available for the NC reports. If specific
variables need to be available, they need to be declared as such using the REPORT_VARS
statement.
Example: REPORT_VARS MyVar1 MyVar2;

3.5.13 REPORT_TOOL_VARS
Usually only tool variables from the TOOL CHANGE block are available for the “tools” report. If other
variables need to be available as well, they need to be declared as such using the
REPORT_TOOL_VARS statement.
Example: REPORT_TOOL_VARS MyVar1 DOWN_STEP XML_PROC_FEED;
CimatronE 10.0 GPP2 User Guide ⎪112

3.6 Execution Statements

These are the statements that appear in the GPP execution blocks, in GPP procedures, and in the
special new-line-is block. Every statement ends with a semi-colon (;).

3.6.1 Assignment
This is the most basic statement type – the cornerstone of every programming language. It assigns a
value to a variable.
Variable = <expr>;
Any GPP variable may be assigned any type of expression (except Boolean expressions).
Full arrays cannot be assigned a value – only individual array members can. If an array member is
assigned values, the array index can be any numeric expression, not necessarily a constant.
It is highly recommended to ensure that the type of the variable and the assigned expression are
the same (numeric or string). This is proper programming practices. However, GPP accepts type-
mismatched assignments, where a string is assigned into a numeric variable or vice versa. The result
may be unpredictable if the conversion is not straightforward. For instance, assume X is a numeric
variable. The statement X = “3”; will result in X getting the value of 3.0, as expected. But X = “abc”;
will assign an unpredictable number to X.
An assignment type mismatch generates a compilation warning.

GPP Compatibility Notes:

In old GPP, when a string constant was assigned to a string variable, it eliminated any spaces found in
the constant. For instance, assigning the string “one two three “resulted in an assigned value of
“onetwothree”.
This behavior is not maintained in GPP2. Strings are assigned “as is”. If the space characters are not
wanted, they can be eliminated with the STR_CLEAN function.

Examples
X = X_CURPOS + ORIGINX;
Alpha = ACOS (Y / X);
STRAARRY[10] = “Yes”;
STRAARRY[I] = STR_LEFT(NAME, 4);
S1 = “one two three “; // S1 gets “one two three”
CimatronE 10.0 GPP2 User Guide ⎪113

3.6.2 IF
The IF statement allows conditional execution of statements, based on various conditions. It replaces
IF_SET as the generic “if” statement.
IF ( <Bool-expr> )
Sequence of execution statements...
END_IF;
The sequence of statements will only be executed if the Boolean expression is true. Otherwise, they
will be skipped. See earlier section for a detailed discussion of Boolean expressions.
IF ( <Bool-expr> )
Sequence of execution statements for the TRUE case...
ELSE
Sequence of execution statements for the FALSE case...
END_IF;
With the IF / ELSE form, it is possible to define two sequences of statements. One will be executed
if the Boolean expression is true, while the other will be executed if the Boolean expression is false.
IF statements can be nested within each other in any combination and to any depth, as long as each
one is properly terminated with an END_IF clause.

GPP Compatibility Notes:

In old GPP, a major use of the IF_SET statement was to check if a variable is set to “on” or not. This
can be best accomplished with the VAR_SET and VAR_NOTSET functions.
However, old GPP did not have these functions. Instead, it allowed a simple syntax for that purpose,
by simply writing IF_SET(X). While (X) is not really a Boolean expression, when used inside an
IF_SET statement, it was interpreted by GPP to mean the set flag of X.
GPP2 maintains backward compatibility to old GPP, and will also IF_SET(X) to mean
IF(VAR_SET(X)).
Note that complex Boolean conditions must use the proper syntax, not the traditional shortcuts. For
instance, IF_SET(X && Y) or IF(X && Y) is invalid. The GPP developer should use the full form
IF(VAR_SET(X) && VAR_SET(Y)).
CimatronE 10.0 GPP2 User Guide ⎪114

Examples:
IF (X_CENTER != 0)
OUTPUT $ “I” X_CENTER;
END_IF;
IF (VAR_SET(X_CURPOS) && X_CURPOS < 100)
OUTPUT $ “X” X_CURPOS;
OLDX = X_CURPOS;
ELSE
X_CURPOS = X_CURPOS + 1;
END_IF;
Note: indentation of the statements inside an IF structure, as shown in these examples, is not
mandatory. However, it is very useful in making the GPP program easier to read and understand. It is
highly recommended to indent each level of nested IF statement, as follows:
IF (<expr>)
IF (<expr>)
Statements…
ELSE
Statements…
END_IF;
END_IF;

3.6.3 IF_SET
The IF_SET statement is essentially a shortcut for the IF statement, used to check if a given variable
is “on”. In old GPP, it could be used as a generic “if” statement. In GPP2, it is only used to test the “on”
flag of variables.
IF_SET ( <variable> ) // same as IF(VARSET(<variable>))
Sequence of execution statements...
END_IF;
Note that use of IF_SET is identical to using the IF statement with the VAR_SET function. The
IF_SET / ELSE combination is also supported.
GPP2 will issue a runtime warning if the IF_SET statement is used with a non-modal variable (since
this test is mostly useful for modal variables).

3.6.4 IF_EXISTS
The IF_EXISTS statement was used in the past to check the existence of Tools/Cycles user-defined
variables of the form $XXX. Since these variables are no longer supported in GPP2, IF_EXISTS is
not supported in GPP2.
CimatronE 10.0 GPP2 User Guide ⎪115

3.6.5 REPEAT UNTIL

This is the GPP language loop statement. It allows the repeated execution of a sequence of
statements until a condition is met.
REPEAT
Sequence of execution statements
UNTIL ( <Bool-expr> );
GPP will first execute the sequence of statements, then check the Boolean expression in the REPEAT
clause. If true, it will break the loop and continue with the next statement. If false, the loop will be
repeated.
Like with IF, any Boolean expression can be used in the REPEAT clause.

GPP Compatibility Notes:

UNTIL also accepts the old GPP shortcut of specifying a variable name and meaning to check if the
variable is actually set.
UNTIL(X) is interpreted by GPP as UNTIL(VAR_SET(X)).
As in IF, for complex conditions (AND, OR), the full syntax must be used.

3.6.6 OUTPUT
The OUTPUT statement writes text to the output G-code file. This is the way to generate the post-
processor output machine program.
OUTPUT argument1 argument2 ...
The arguments of the OUTPUT statement are special entities in GPP2, and regular expressions
cannot be used. The arguments may be one of the following:
The new-line character (e.g., $): this argument may only be used if the GPP program contains a
NEW_LINE_IS section where the new-line character has been defined. The OUTPUT argument must
match the character used in that earlier definition.
In response to the new-line character in the OUTPUT statement, GPP2 will execute the statements
listed in the NEW_LINE_IS block. The mechanism is similar to a procedure call each time the new-line
character is encountered. All real output is expected to take place in the NEW_LINE_IS block itself.
Strings: any constant string may be used
CimatronE 10.0 GPP2 User Guide ⎪116

Variables: GPP2 will format the variable according to its format, and convert it to a string. For string
variables, the formatted output is simply the variable contents. For numeric variables, the formatted
string depends on the DF2 file definitions, as explained earlier.
Any type of GPP variable may be used (system user or interaction). Array members may also be
used, but not full arrays.
Using non-initialized variables does not generate any output and creates a runtime warning.
With GPP2, it is possible to output a variable regardless of it “set” status. The same result will
be created if the variable is set “on” or “off”.
Many times, the PP program tests the status flag before outputting a variable. For instance, a common
line will be:
IF_SET (X_CURPOS) OUTPUT “ X” X_CURPOS; END_IF;
The IF_SET statement ensures that no output is generated if X_CURPOS is not set. This, of course,
includes the “ X” string.
If, however, the GPP developer wishes to output a variable value regardless of its set status, he or she
can do so easily without using the SET_ON statement first.
For instance, consider the following code after a tool change:
SET_ON SPIN_SPEED SPIN_DIR // Not needed in GPP2!
OUTPUT $ " S" SPIN_SPEED " " SPIN_DIR; // output guaranteed!
The OUTPUT line will turn the spindle on regardless of the set values of the parameters.
Modal variables are set “off” after being output (if they were “on” before).

GPP Compatibility Notes:

In Old GPP, variables that were set “off” did not generate any output when used in the OUTPUT
statement. This behavior was changed in GPP2. A variable is formatted and output regardless of its
set status flag!

The special TAB_ keyword: instructs GPP2 to insert space characters until the next tab position. Tab
positions can be defined with the SET_TABS statement. In case the output file is already positioned on
a tab position, GPP2 will insert spaces until the next tab position.
CimatronE 10.0 GPP2 User Guide ⎪117

Control characters (\A to \Z): GPP2 will output the corresponding ASCII character to the output file
(1 for \A, up to 26 for \Z). Also, \+ may be used to indicate the new-line character (same as \J).
In addition, any ASCII character can be output by using the \ddd format, where ddd is the ASCII
value of the character. That format may be used to output non-standard characters that do not fall
between ASCII 1 to 26 (e.g., \250). The number must be no higher than 255.
GPP2 has a special treatment to the new-line control character (\J or \+). It will only output it if the
current file line already contains some other characters. Otherwise, the new-line character will be
suppressed. That way, no empty lines are ever generated in the output G-code file. At the end of the
file, if the last line is not terminated with a new-line character, GPP2 will automatically add it.
Examples:
OUTPUT “X” X_CURPOS $;
OUTPUT TAB_ “A” TAB_ “B” \J;
OUTPUT $ LIN_MOV $;
Suppose the tabs were set as follows with the SET_TABS statement:
SET_TABS 4 8 12 16; // tabs every 4 positions
Now, suppose the GPP program executes the following statements:
OUTPUT \J "12345678901234567890";
OUTPUT \J TAB_ "A" TAB_ "B" TAB_ "C" TAB_ "D";
OUTPUT \J "*" TAB_ "A";
OUTPUT \J "***" TAB_ "A";
OUTPUT \J TAB_ TAB_ TAB_ TAB_ "D";
The output file will look as follows:
12345678901234567890
A B C D
* A
***A
D
CimatronE 10.0 GPP2 User Guide ⎪118

3.6.6.1 Using Expressions in Output

The OUTPUT command does not support standard expressions. In order to output expressions, they
first need to be assigned to variables, which will be used in the OUTPUT command. It means that all
calculations and string operations must be done in advance. In order to output the value of A + B:
C = A + B;
OUTPUT C; // OUTPUT A + B; is invalid
In order to output a value that is the result of a function (like the number of the next-tool):
A = NEXT_TOOL(TOOL_NUM);
OUTPUT A;
In order to output a manipulated string (like upper-case):
A = STR_UPPER (MyParameter);
OUTPUT A;

3.6.7 PRINT, PRINT0, PRINT1 to PRINT10

These statements are very similar to the OUTPUT statement, except that they send the output text to
other files (not the main G-code file).
PRINT argument1 argument2 ...
PRINT0 argument1 argument2 ...
PRINT10 argument1 argument2 ...
The arguments are exactly the same as in the OUTPUT statement. The output of each statement is
sent to the destination shown in the following table:

Statement Destination File

PRINT <toolpath>.<post>.msg.txt
The text is also printed to the GPP2 application screen.
PRINT0 Print0.txt in the current directory.
PRINT1 to PRINT10 <toolpath>.<post>.<ext>
The extensions <ext> for the 10 files are defined in the DF2
file parameters “PRINT1 File Extension” to “PRINT10 File
Extension”.
Leaving an extension empty inhibits the output to that file.
CimatronE 10.0 GPP2 User Guide ⎪119

Notes:
It is not recommended to use the new-line character (e.g., $) in any of these PRINT statements (since
the block will probably contain OUTPUT statements that will send text to the main G-code file, not to
the expected PRINT destination). The \J control character (new line) should be used instead.
1. The <toolpath> name is the name of the GPP2 input DAT file, without any extension.
2. The <post> name is the name of the current post-processor used, without any extension.
PRINT0 was traditionally used in old GPP to create the script (batch) file that is run after the post-
processor execution. With GPP2, post-run system commands may be created and executed in the
new POST SCRIPT block, essentially making the PRINT0 command mostly redundant.

3.6.8 OUTPUT Redirection

With GPP2, it is possible to “redirect” the output stream to other files, with predefined extensions,
under the program control.
The motivation is to allow the GPP developer to rearrange parts of the output code in a different way
in the final output file. For instance, it may be required to arrange a “main” program followed by the
procedure bodies.
With old GPP, this required using statements like PRINT1, PRINT2, etc. However, during other runs,
the same post-processor may be required to use the standard output and file order as well. GPP
developers often had to write the same “output” commands twice – once with OUTPUT and another
time with PRINTx. GPP2 solves this problem and gives maximum flexibility through output redirection.
OUTPUT_REDIRECT <string> ;
OUTPUT_BACK ;
OUTPUT_CLOSE ;
The OUTPUT_REDIRECT statement has one argument, a constant string with exactly one letter (e.g.,
“p” or “P”). Regular string expressions cannot be used – the string must be a constant string. The
letter “s” (or “S”) cannot be used – it is reserved for subroutine files.
After the first execution of the OUTPUT_REDIRECT statement, all text generated with the OUTPUT
statement will be directed to a new file, sharing the same name as the main G-code output file, but
with an extension “._x01”, where x is the letter used in the redirection statement.
Executing the OUTPUT_BACK statement will restore the output stream back to the main G-code file,
without closing the “._x01” file. If OUTPUT_REDIRECT is used again with the same letter, the data
will be redirected again to the same “._x01” file.
Using the OUTPUT_BACK when no redirection is active (output is currently sent to the main file) has no
effect, and a runtime warning is issued.
The OUTPUT_CLOSE statement closes the currently open redirected output file (“._x01”), so that any
subsequent output will be sent to a new file, with extension “._x02”. This process will repeat with
each use of OUTPUT_CLOSE.
CimatronE 10.0 GPP2 User Guide ⎪120

Using the OUTPUT_CLOSE when no redirection is active (output is currently sent to the main file) has
no effect, and a runtime warning is issued.
The use of OUTPUT_REDIRECT can be nested, by using different letters. For instance, output can be
redirected to “._a01”, then redirected to “._b01”, then redirected to “._c01”. The behavior is like a
“stack” of redirections. The first use of OUTPUT_BACK will restore redirection from “._c01” to “._b01”,
the next use will restore it to “._a01” and another use will restore it to the main file.
GPP2 will support up to 10 levels of nesting. It is only allowed to use any letter once inside a nesting
redirection stack. Therefore, trying to redirect to “a”, then to “b” and then to “a” again (without going
back to the main file) will generate a runtime error.
Examples:
OUTPUT “Main file line 1”;
OUTPUT_REDIRECT “a”; // redirect output to “._a01”
OUTPUT “AAAAA line 1”;
OUTPUT_REDIRECT “b”; // redirect output to “._b01”
OUTPUT “BBBBB line 1”;
OUTPUT_CLOSE; // close file “._b01”
OUTPUT “BBBBB line 1 to file ._b02”; // send to file “._b02”
OUTPUT_REDIRECT “c”; // redirect output to “._c01”
OUTPUT “CCCCC line 1”;
OUTPUT_BACK; // restore output (to “._b02”)
OUTPUT “BBBBB line 2 to file ._b02”;
OUTPUT_BACK; // restore output (to “._a01”)
OUTPUT “AAAAA line 2”;
OUTPUT_BACK; // restore output (to main file)
OUTPUT “Main file line 2”;
CimatronE 10.0 GPP2 User Guide ⎪121

The output files generated will be as follows (assuming the main file is named tp.post):
File tp.post (main):
Main file line 1
Main file line 2
File tp.post._a01:
AAAAA line 1
AAAAA line 2
File tp.post._b01:
BBBBB line 1
File tp.post._b02:
BBBBB line 1 to file ._b02
BBBBB line 2 to file ._b02
File tp.post._c01:
CCCCC line 1

3.6.9 LOAD_FILE
LOAD_FILE is formally a function, not a statement. However, it is described here (and not in the
functions section) since it is actually used as a statement.
LOAD_FILE allows the GPP developer to load an external file and dump it, as is, to the current output
G-Code file.
RESULT = LOAD_FILE (<str-expr>) Load file named in the string
LOAD_FILE will evaluate the string expression and will load the file with the resulting name. The name
is expected to include the full path name.
The function returns a numeric value: 1 if the loading was successful, 0 if not. That way, the GPP2
program can take action in case the loading of the file failed. In case of failure, a runtime warning is
issued as well.
The data from the loaded file will be sent to the “current” output file. In case of output redirection, it will
be sent to the redirected output file.
Note: GPP2 supports a DF2 parameter that can force the output to be all lowercase or all uppercase.
If that parameter is used, it also affects the loaded file data – it will all be converted to lowercase or
uppercase respectively.
Examples:
RESULT = LOAD_FILE (“C:\Cimatron\MyData.txt”);
IF (RESULT == 0) GPP_STOP; END_IF;
LOAD_FILE(“C:\Cimatron\MyData.txt”); // Error! LOAD_FILE is a function.
CimatronE 10.0 GPP2 User Guide ⎪122

3.6.10 SET_ON and SET_OFF

The SET_ON and SET_OFF statements can be used to explicitly set GPP variables “on” and “off”.
See earlier section for a detailed discussion on variable “set” status.
SET_ON variable variable2 ...;
SET_OFF variable variable2 ...;
Full arrays as well as individual array members can be used as arguments to these statements.
Specifying the whole array as an argument will set every member of the array “on” or “off”.
If a variable used as an argument is identical to other variables, then they will also be set “on” or “off”
accordingly.
Examples:
SET_ON X Y X_CURPOS ARRAY[12];
SET_ON ARRAY;

GPP Compatibility Notes:

Old GPP also supported the old RESET statement, which was identical to SET_ON. GPP2 does not
support this statement anymore.
With old GPP, it was possible to use a special ALL_VAR pseudo variable as an argument to SET_ON
and SET_OFF. ALL_VAR is not supported in GPP2.
CimatronE 10.0 GPP2 User Guide ⎪123

3.6.11 Sequencing
GPP2 provides new tools for sequencing of G-code output lines, in several levels of nesting. It allows
sequencing of a main program as well as machine subroutines, at several levels.
The sequencing mechanism works as follows:
• A new numeric global system variable, SEQ_NUM, is used to hold the current sequence number.
SEQ_NUM is “auto-incrementing” – each time it is sent to the output, its value is incremented by a
predefined number (e.g., 1 or 10).
• The auto-increment value is determined by a new DF2 parameter, which can be later overridden
through a GPP2 global system variable, SEQ_INC.
• The sequencing start number is determined by another DF2 parameter, which can be later
overridden through a GPP2 global system variable, SEQ_START.
• The maximum sequencing number is determined by another new DF2 parameter, which can be
later overridden through a GPP2 global system variable, SEQ_MAX. Whenever SEQ_NUM is
incremented above SEQ_MAX, it is automatically reset to the predefined start value (represented in
SEQ_START).
• Typically, SEQ_NUM is sent to the output in the New-Line-Is block, if sequencing is required.
• In case a new series of sequencing is required for a machine subroutine (e.g., for 2.5X
subroutines), the SEQ_LEVEL_NEXT command is used to re-initialize SEQ_NUM with a predefined
start number.
• Once the subroutine is finished, GPP2 is instructed to go back to the previous sequencing series,
with the SEQ_LEVEL_BACK statement. This statement restores the previous value of SEQ_NUM
(the value it had when the SEQ_LEVEL_NEXT statement was executed).
• It is possible to use up to 10 levels of nesting for separate sequencing levels. In practice, no more
than 3 levels are usually needed (main program plus two levels of subroutine nesting).
SEQ_LEVEL_NEXT; // increase nesting, reset SEQ_NUM
SEQ_LEVEL_BACK; // decrease nesting, restore SEQ_NUM
CimatronE 10.0 GPP2 User Guide ⎪124

Examples:
Assume SEQ_NUM happens to be equal to 200, and SEQ_INC is 10.
OUTPUT \J SEQ_NUM; // output 200, SEQ_NUM gets 210
SEQ_START = 1000; // next level will start here
SEQ_LEVEL_NEXT; // SEQ_NUM is set to 1000
OUTPUT \J SEQ_NUM; // output 1000, SEQ_NUM gets 1010
OUTPUT \J SEQ_NUM; // output 1010, SEQ_NUM gets 1020
SEQ_LEVEL_BACK; // SEQ_NUM restored to 210
OUTPUT \J SEQ_NUM; // output 210, SEQ_NUM gets 220

3.6.12 System Calls

This is a new GPP2 feature. It allows the execution of any “system” command to manipulate the files
generated through the post-processing run. It is used to replace the execution of the batch (script) file
of old GPP.
SYSTEM_CALL argument1 argument2 ...
The SYSTEM_CALL may only be used inside the new POST SCRIPT block, which is the last block
executed in the run, after all the output files have been closed.
The argument list is similar to the argument list of the OUTPUT statement. It may contain constant
strings and variable names. New-line characters, control characters and the TAB_ argument are
simply ignored, and should not be used.
GPP2 builds the full system command by formatting and adding up the arguments into one string, and
executing that string with the “shell” operating system function.
GPP2 sets the “working directory” to the directory where all the output files are kept, so the system
commands can use file names without the full path.
CimatronE 10.0 GPP2 User Guide ⎪125

The FILE_NAME system variable is very useful in the SYSTEM_CALL statement, as it contains the
toolpath name and the post name:
Examples:
SYSTEM_CALL “copy ” FILE_NAME “.s* subs.txt”;
This system command will copy all the subroutine files generated through the run to one file called
subs.txt. Assuming the toolpath file is called “TP” and the post being used is called “DEMO”,
FILE_NAME will contain the value “TP.DEMO”. GPP2 will execute the following command: “copy
TP.DEMO.s* subs.txt”.
SYSTEM_CALL “RENAME ” FILE_NAME “ OUTPUT”;
This system command will rename the output G-code file. For the same file and post names, GPP2
will execute the following command: “RENAME TP.DEMO OUTPUT”.
Note: If the output file name is changed using system calls, the EX2 program must “tell” GPP2 about
the new file name, so it will be able to display the G-code file if requested. Simply assign the new
name to FILE_NAME, inside the POST SCRIPT block.
FILE_NAME = “OUTPUT” ;
Similarly, if the output file is copied or moved to another directory, the EX2 program must tell GPP2
about the new directory. The current output directory name is held in the OUTPUT_DIR variable. The
EX2 program must update its value as needed.
For instance, assume that a sub-directory name “SUB” needs to be opened under the current output
directory and the G-code file must be moved to the new sub-directory.
SYSTEM_CALL “MD SUB” ; // create sub-directory
SYSTEM_CALL “MOVE ” FILE_NAME “ SUB” ; // move G-code file
OUTPUT_DIR = OUTPUT_DIR + “SUB\” ; // tell GPP2
CimatronE 10.0 GPP2 User Guide ⎪126

3.6.13 GPP_STOP
This GPP2 statement allows the GPP developer to stop the execution at any point. It is used in cases
where there is no point in carrying on with the process (e.g., reached machine limits or some other
critical condition).
GPP_STOP;
GPP_STOP <str-expr>; // string is optional
In case a string argument is used, it will be displayed to the user. That way, the developer can explain
why the execution had to be stopped (or what needs to be done in order to fix the problem).
Examples:
GPP_STOP “Reached machine X axis limit!”;

3.6.14 Advanced Statements for 5-Axis Machines

GPP2 includes several new advanced statements that are used in conjunction with 4/5 axes post-
processors.
CALC_WORKPLANE <mode> <alpha> <beta>;
SET_OUTPUT_UCS <position> <orientation>;
DEFINE_MACHINE <machine type> <alpha axis> <beta axis>;
MOVE_MANUAL <X> <Y> <Z> <Alpha> <Beta>;
All arguments to these functions are numeric arguments or expressions. They will be described in
detail in the “5 Axes Post Processors” document.

3.6.15 KEEP
The KEEP statement is no longer supported in GPP2 (it had no effect in old GPP either). The values
of system variables are “kept” anyway, until changed in a subsequent toolpath block or explicitly in the
GPP program.
CimatronE 10.0 GPP2 User Guide ⎪127

3.7 GPP Procedures

GPP2 supports procedures inside the GPP program, with or without parameters. Procedures are used
in order to simplify and shorten the GPP program, and avoid typing the same piece of GPP program
again and again.
Procedures must be defined before they can be used. It is advised to locate all the program
procedures before any other executable block (after the declaration part), so they can be later called
from any executable block.
Procedures may be called from within other procedures, However, recursive procedure calling is not
supported in GPP.

3.7.1 Procedure Definition

A procedure is defined with the new GPP_PROCDEF statement, followed by optional
GPP_PROCPARAM statements if procedure parameters are required.
GPP_PROCDEF <proc-name> ;
Sequence of statements to be executed
Like an executable block, the procedure definition comes to an ends when the next procedure or
executable block is encountered. There is no special “procedure end” statement.
The procedure name should follow the standard GPP2 user variable naming conventions (e.g.,
StartOfProc).
GPP_PROCDEF <proc-name> ;
GPP_PROCPARAM (<format-name>) param1 param2 ... ;
Sequence of statements to be executed
The GPP_PROCPARAM statement defines one or more parameters of a given GPP format. The
parameter type (numeric or string) is also derived from the format.
It is possible to use multiple GPP_PROCPARAM statements in order to define parameters of different
formats and types. For instance:
GPP_PROCDEF Myproc1 ;
GPP_PROCPARAM (USER_1) X Y Z; // numeric parameters
GPP_PROCPARAM (CHARACTER) MSG; // string parameter
Sequence of statements to be executed
CimatronE 10.0 GPP2 User Guide ⎪128

3.7.1.1 Parameter and Variable Name Scope

Procedure parameters can be named like any other user-defined parameter (e.g., X, Y). In fact, they
may even use names already used by other “global” user-defined variables. GPP will not be confused
by an X variable defined in the program declaration part and another X parameter defined inside a
procedure.
This behavior, common to many programming language, is known as variable name “scope”.
Normally, GPP works within a global scope, where all variables are recognized and no duplication is
allowed. When a procedure is called, however, GPP enters a local scope, where procedure
parameter names take precedence over any global variable of the same name.
Referring to X inside the procedure will mean the local parameter X, while referring to X outside the
procedure means the global user-defined variable X.
This behavior must be understood by the GPP developer. The advantage of it is the ability to use
simple and short variable names, such as X, I, CNT and TMP, inside procedures, without worrying
about duplication of variable names.
Example:
FORAMT (USER_1) X; // global parameter X
GPP_PROCDEF Proc1;
GPP_PROCPARAM REAL X; // local parameter
OUTPUT X; // this refers to the local variable
more statements...

LINEAR MOTION: // beginning of new block – end of procedure

OUTPUT X; // this refers to the global variable

3.7.2 Procedure Calls

The GPP_CALLPROC statement is used to call a GPP procedure, with or without parameters.
GPP_CALLPROC <proc-name> ();
GPP_CALLPROC <proc-name> (<expr1>, <expr2>…);
The number of arguments and their types must match the parameters defined in the procedure. Any
numeric or string expressions may be used as arguments, as long as they match the expected
procedure parameter.
Multiple procedure arguments must be separated by commas.
When executing a GPP_CALLPROC statement, GPP evaluates the argument expressions, assigns the
resulting values to the local procedure parameters, and executes the sequence of statements inside
the procedure.
CimatronE 10.0 GPP2 User Guide ⎪129

3.8 GPP Debugging and Tracing

GPP2 includes several debugging and tracing tools, which are invoked by special GPP system
variables, as follows:

3.8.1 Trace Execution

The following GPP system variables are used to invoke execution tracing:
TRACE_EXECUTE: Turn tracing on (when TRUE_) and off (when FALSE_).
Once TRACE_EXECUTE is set to TRUE_, GPP starts echoing a detailed log of the program execution
to a log file named gpp2trace.txt (in the output directory). The same trace information is also
displayed on the GPP2 message window, but only in single-step mode (see below).
The execution tracing log file details every statement being executed, including the GPP program line
number, and then shows the result of the execution.
CimatronE 10.0 GPP2 User Guide ⎪130

Examples:
Executing: 0064 X = (X_CURPOS + 20.0)
Result: X = 35.333333 // shows internal value
Executing: 0065 IF(VAR_SET(Arr[2]))
Condition: TRUE value
Executing: 0066 OUTPUT X CONTROL(10) “abc”
Output: “35.333” // the formatted value
Output: Char(10) // new-line character
Output: “abc”
Executing: 0067 GPP_CALLLPROC myproc (1, “abc”)
Parameters myproc.step = 1, myproc.msg = “abc”
Notes:
1. The executed statements are not shown exactly as they were written in the original EXF file.
What is shown is the compiled representation of these statements. In most cases, the printout
will be self-explanatory. Note that expressions will be shown with parentheses, exactly
describing the structure of complex mathematical expressions.
2. In IF_SET statements that use the traditional GPP “short form” to test if a variable is “on” (e.g.,
IF_SET (X_CURPOS), the trace printout will show the implicit VAR_SET function used by GPP:
IF (VAR_SET(X_CURPOS))
3. In assignment statements, the internal value of the assigned variables is shown, with 6 decimal
digits, regardless of their format. The formatted form is clearly shown in OUTPUT statements of
the variables.
4. When an assigned variable has identical variables, all of them will be shown in the result
section. For instance:
Executing: 0064 X = (X_CURPOS + 20.0)
Result: X = Y = 35.333333 // X and Y are identical
5. Control characters (like \J) in Output statements are shown as CONTROL(nn), where nn is
the ASCII value of the character. \A has ASCII value of 1, \J is 10, and \Z is 26. The resulting
output is shown as Char(nn).
6. The execution of each block, including the new-line block, is titled.
7. When a procedure with parameters is called, the trace shows the values assigned to its
parameters as follows: suppose a procedure myproc has a parameter step of type numeric.
The trace will show myproc.step = 1.
CimatronE 10.0 GPP2 User Guide ⎪131

3.8.2 Single-Step Execution

GPP2 allows single-step execution and trace, by setting the TRACE_SINGLESTEP system flag to
TRUE_. This must be done in conjunction with setting the TRACE_EXECUTE system flag. Otherwise, no
output will be shown.
When both TRACE_SINGLESTEP and TRACE_EXECUTE are TRUE_, GPP2 will pause execution after
each GPP2 execution statement. In single-step mode, it will also display the execution trace
information on the GPP2 message window (otherwise, that information is only sent to the trace log
file).
During the pause, the user has three options:
• Step to the next statement (maintain step-by-step mode)
• Continue execution (terminating the step-by-step mode)
• Abort execution

3.8.3 Trace G-Code Output

When debugging a post-processor, it is often required to know which GPP program line generated a
specific G-code output. The TRACE_LINENO system variable is used for that purpose.
When TRACE_LINENO is set to TRUE_, GPP2 will print the program line number before any actual
output characters.
Examples:
[L0050] % // printed by line 50
[L0067] G00 X15. Y36.473 Z0.0 // printed by line 67
It is also possible to trace the toolpath block number where each G-code output was generated. That
can be achieved by setting the TRACE_TPBLOCK variable to TRUE_.
Examples:
[B000100] G00 X15 // printed in TP block 100
Both trace variables may be set simultaneously to trace the line number and the toolpath block for
each G-Code output line. If both are set the following format is used:
[L0085, B000100] G00 X15 // printed in TP block 100 by line 85
CimatronE 10.0 GPP2 User Guide ⎪132

4 Blocks, Constants and System Variables

4.1 GPP2 Blocks

The following table shows the full list of GPP2 blocks and their qualifiers.

Block and Qualifier Use and comments

BEGINNING OF This block is invoked at the beginning of each connection process.
CONNECT: See detailed discussion about GPP2 connections below.
BEGINNING OF PROC: Invoked at the beginning of each procedure. Note that there are
several other blocks invoked at the beginning of each procedure,
see details later.
BEGINNING OF SUB: Invoked at the beginning of the definition of each subroutine. Works
in conjunction with other blocks (e,g, subroutine call).
BEGINNING OF TAPE: Invoked when a new output tape (file) is created.
--- (none) No qualifier indicates the beginning of the first tape, before any
toolpath block is read and processed. The block is always called
once with no qualifier.
aftercut: This qualifier indicates the beginning of a new output tape that
occurred after a previous tape has been cut due to excessive length.
BEGINNING OF TLPATH: Invoked at the beginning of each toolpath, with some basic
information regarding the toolpath (name, type, etc.)
CIRCULAR MOTION: Invoked whenever the toolpath contains an arc. See details on
circular motions in a separate section.
CONNECT IN PLACE: Invoked by GPP2 whenever a regular connection scenario is not
invoked because the machine is already positioned on the target
point. The start and end point of the connection are in the exact
same place.
ctangappr: This qualifier indicates a circular tangential approach to a contour.
ctangretr: This qualifier indicates a circular tangential retract from a contour.
Note that name change from old GPP.
--- (none) No qualifier is used in all other cases.
CUTTER COMPENSATION: Invoked when the Cutter Compensation is turned on or off.
--- (none) No qualifier indicates that the cutter compensation is turned on (left
or right).
coff: This qualifier indicates that the cutter compensation is turned off.
CYCLE: Invoked for each drill cycle.
CimatronE 10.0 GPP2 User Guide ⎪133

Block and Qualifier Use and comments

on: This qualifier is used for the first cycle block in a series (cycle turned
on) where retract is to clearance height.
toinit: This qualifier is used for the first cycle block in a series (cycle turned
on) where retract is to initial height.
--- (none) No qualifier is used for all the cycle blocks in a series, except the
first one (where cycle was turned on).
off: This qualifier is used for an extra cycle block, after all real cycle
blocks in a series were invoked and processed. It is used to turn the
cycle off.
specialon: This qualifier is used for the first special cycle block in a series of
special cycle blocks (same as "on"qualifier for the regular cycle).
special: This qualifier is used for the each special cycle block (for example,
thread cycle) (same as no qualifier for the regular cycle).
specialoff: This qualifier is used for an extra cycle block, after all real special
cycle blocks in a series were invoked and processed (same as "off").
END OF CONNECT: This block is invoked at the end of each connection process. See
detailed discussion about GPP2 connections below.
END OF FILE: Invoked one time at the end of all processing of the toolpath (after
the END OF TAPE block). This is a good time to wrap up the whole
execution.
END OF PROC: Invoked at the end of each procedure.
END OF SUB: Invoked at the end of the definition of each subroutine.
END OF TAPE: Invoked when an output tape (file) is closed.
--- (none) No qualifier indicates the end of the last (or only) tape. The block is
always called once with no qualifier.
beforecut: This qualifier indicates the end of an output tape that is cut due to
excessive length.
END OF TOOLPATH: Invoked at the end of each toolpath.
INSERT WITH: Invoked when encountering an inserted string (with sequencing) in
the toolpath
INSERT WITHOUT: Invoked when encountering an inserted string (with sequencing) in
the toolpath
CimatronE 10.0 GPP2 User Guide ⎪134

Block and Qualifier Use and comments

LINEAR MOTION: Invoked for each linear tool motion.
Note: the first four qualifiers (approach / retract) take precedence
over the other qualifiers.
normappr: This qualifier indicates a normal approach to a contour.
normretr: This qualifier indicates a normal retract from a contour.
ltangappr: This qualifier indicates that the block comes before a tangential
approach to a contour. Note the name change from old GPP.
ltangretr: This qualifier indicates that the block comes after a tangential retract
from a contour.
fastlencomp: This qualifier indicates a rapid linear motion used for tool length
compensation. It is created as part of a connection from the safe
position – the last rapid motion going down (typically in the -Z
direction).
lencomp: This qualifier is a feed-rate equivalent of the fastlencomp qualifier.
Recall that if the DF2 parameter for “rapid to feed” is set, then every
rapid motion, including the tool length compensation is converted to
a feed-rate motion.
fast: This qualifier indicates a rapid motion (maximum speed)
--- (none) No qualifier indicates a regular motion at feed-rate.
MACHINE CONTROL: This block is invoked in response to a “MACHINE_CONTROL”
action processed as part of a connection scenario. See discussion
on connections below.
MESSAGE: Invoked when a message is encountered in the toolpath.
MOVE TO SAFE: This block is invoked in response to a “MOVE_SAFE” action
processed as part of a connection scenario. See discussion on
connections below.
ORIGIN CHANGE: Invoked each time the procedure origin changes.
CimatronE 10.0 GPP2 User Guide ⎪135

Block and Qualifier Use and comments

POST SCRIPT: This s block is invoked at the end of the run, even after END OF
FILE and after all the output files have been closed. The block is
intended to replace the execution of the post-run batch file.
It is the only block where the new SYSTEM_CALL command can be
used to copy, move and rename files after the run.
stopped: This qualifier indicates that the block is invoked after a runtime error
or after the execution of the GPP_STOP command, which aborts the
run.
PROC FIRST POINT: This block is invoked before the first tool point of the procedure, after
the connection. See a detailed description later about all “procedure
blocks”.
RECONFIG MACHINE This s block is invoked as part of the machine reconfiguration
process, mostly used for 6X machines. See a detailed description
later about machine reconfiguration.
RESET AXIS: This block is used in 4/5 axes machines, where an axis has a soft
angle limit and it needs to be “reset” in order to continue. See 5X
manual for more details.
alpha: Reset the “alpha” axis.
beta: Reset the “beta” axis.
SET UCS: This block is invoked in response to a “SET_UCS” action processed
as part of a connection scenario. See discussion on connections
below.
START PROC: This block is invoked after the procedure “header” blocks (beginning
of proc, origin change, tool change), and before any motions of this
procedure (before the connection). See a detailed description later
about all “procedure blocks”.
STARTUP: This block is invoked once before any other program block. This is
the right time to initialize user variables and prepare for the run.
SUBROUTINE CALL: Invoked each time a subroutine is called in the toolpath. This block
should be handled in conjunction with other subroutine-related
blocks, notably BEGINNING OF SUB. See detailed discussion later
regarding the order of invocation (different than in old GPP!).
SUBROUTINE RETURN: Invoked immediately after each SUBROUTINE CALL block. Can be
used for post-subroutine processing and output.
CimatronE 10.0 GPP2 User Guide ⎪136

Block and Qualifier Use and comments

TOOL CHANGE: Invoked with each tool change. The block is invoked at least one
time per procedure, as part of the procedure start process.
first: This qualifier indicates the first (or the only) tool change in the
posting process.
last: This qualifier indicates the last tool change in the posting process. It
is not used if there is only one tool change throughout the execution.
--- (none) No qualifier is used for all other tool changes (neither first not last).
multitool: This qualifier is invoked for tool changes that take place inside multi-
tool procedures. Recall that GPP2 breaks each multi-tool procedure
into separate procedures. This qualifier is used in all the separate
procedures except the first (original) one.
CimatronE 10.0 GPP2 User Guide ⎪137

4.2 GPP2 Constants

GPP2 has several predefined constants used to make the EX2 program clearer and less error-prone.
These constants, their values and their use are shown in the following table.

4.2.1 General Purpose Constants

Constant Value
PI 3.14…
INCH 25.4, inches to millimeters
TRUE_ or YES_ 1
FALSE_ or NO_ 0
DBL_QUOTE String, with single double-quote character (“)

4.2.2 Constants for GPP2 Connections

Constant Value Meaning Relevant Use
CON_AFTER_TOOL 1 After tool change The “context” of the
CON_PROC 2 At beginning of procedure current connection.
CON_CYCLE 3 Between cycles
CON_5X_SWAP 4 When swapping two 5X Variable: CON_CONTEXT
machine solutions
WHEN_TOOLCHANGE 1 After tool change (only) Controls when to apply
WHEN_LONG_CON 2 On each “long” connection a connection through
WHEN_EVERY_CON 3 On every connection “safe” position. Variable:
SWITCH_TO_SAFE_
CONNECT
CON_P2 1 Connection target point Used in conjunction with
CON_HOME 2 HOME point MOVE actions in
CON_ZERO 3 Zero (literally, 0.0) connection scenarios.

CON_FAST 1 Rapid (G00) motion Used in conjunction with

CON_MAXFEED 2 Maximal feed (G01) motion MOVE actions in
CON_FEED 3 Regular feed (G01) motion connection scenarios.
CimatronE 10.0 GPP2 User Guide ⎪138

4.2.3 Other Numeric Constants

Constant Value Meaning Relevant Use
DEF_NONE 1 Not supported on any plane Variables:
DEF_XYONLY 2 XY plane only ARCS_CTRL_BYPLANE
DEF_MAJORPLANES 3 Major planes (XY, XZ, YZ) SUBS_CTRL_BYPLANE
DEF_ANYPLANE 4 Any plane supported CYC_CTRL_BYPLANE
CYC_OFF 1 None (next cycle is “off”) Indicates the type and
CYC_SAME 2 Cycle with same orientation nature of the next cycle.
CYC_ROTATED 3 Cycle with another Variable
orientation CYC_NEXT
PROC_UNKNOWN
0 Unknown procedure type Indicates type of
PROC_MILL procedure.
1 Milling procedure
PROC_DRILL Variable
2 Drilling procedure
PROC_5X_CONNECT PROC_TYPE
3 5x Connection procedure
PROC_AUTODRILL
4 Auto Drill procedure
CimatronE 10.0 GPP2 User Guide ⎪139

4.2.4 Constants for 5 Axis Machines

Constant Value Meaning Relevant Use
AX5_NONE 0 Null axis (4 axes machines) Used in conjunction with
AX5_PX 1 Axis: +X direction the DEFINE_MACHINE
AX5_MX 2 Axis: -X direction statement used for 4/5
axes machines.
AX5_PY 3 Axis: +Y direction
These constants are
AX5_MY 4 Axis: -Y direction
used to define the
AX5_PZ 5 Axis: +Z direction
directions of the machine
AX5_MZ 6 Axis: -Z direction axes.
AX5_PXPY 7 Axis: +X +Y direction
AX5_PXMY 8 Axis: +X -Y direction
AX5_MXPY 9 Axis: -X +Y
AX5_MXMY 10 Axis: -X -Y
AX5_PXPZ 11 Axis: +X +Z
AX5_PXMZ 12 Axis: +X -Z
AX5_MXPZ 13 Axis: -X +Z
AX5_MXMZ 14 Axis: -X -Z
AX5_PYPZ 15 Axis: +Y +Z
AX5_PYMZ 16 Axis: +Y -Z
AX5_MYPZ 17 Axis: -Y +Z
AX5_MYMZ 18 Axis: -Y -Z
AX5_MANUAL_A 19 Axis A – other direction
AX5_MANUAL_B 20 Axis B – other direction
TABLE_TABLE 0 5X machine, table-table Used in conjunction with
HEAD_HEAD 1 5X machine, table-head the DEFINE_MACHINE
TABLE_HEAD 2 5X machine, head-head statement for 4/5 axes
machines
PREF_NONE 0 No angle preference Define angle preference
PREF_POSITIVE 1 Prefer positive angles in 5X machines.
PREF_NEGATIVE 2 Prefer negative angles Variables:
M5_A_PREF
M5_B_PREF
COMP_GPP Correction done by GPP2 Values for variable:
COMP_CONTROLLER 1 Correction by controller M5_RTCP_HEAD
COMP_NONE 2 No head correction
CimatronE 10.0 GPP2 User Guide ⎪140

PROC_ORIENT Use the proc origin Value for variable:

ZERO_ORIENT 1 Use angle 0 ORIENT_PREF
SAME_ORIENT 2 Use same angle as before

4.2.5 Constants for 5 Axis Post Processing

Constant Value Meaning Relevant Use
WP_BETA 1 Rotate around beta only Define the type and data
WP_ALPHA_BETA 2 Rotate around alpha + beta source of work plane
WP_ALPHA 3 Rotate around alpha only calculation. Used in
(not common) conjunction with the
CALC_WORKPLANE
statement.
VA_PROC 1 Current procedure UCS Define the UCS used to
VA_CURPOS 2 Current position “UCS” calculate virtual axes
VA_BY_VARS 3 Use ?_NONROT_UCS rotation angles. Used in
variables conjunction with the
CALC_VIRTUAL_ANGLES
statement
VIRTUAL_AXES_NONE 0 Virtual axes not used Define the type and
EULER_ZYX 1 Euler, Z Æ Y Æ X order of rotations in
EULER_ZXY 2 Euler, Z Æ X Æ Y virtual axis rotation
angles. Used in
EULER_XYZ 3 Euler, X Æ Y Æ Z
conjunction with the
EULER_YXZ 4 Euler, Y Æ X Æ Z
CALC_VIRTUAL_ANGLES
EULER_ZXZ 5 Euler, Z Æ X Æ Z statement.
EULER_ZYZ 6 Euler, Z Æ Y Æ Z
SPATIAL_ZYX 7 Spatial, Z Æ Y Æ X Variable:
SPATIAL_ZXY 8 Spatial, Z Æ X Æ Y VRTUAL_AXES
SPATIAL_XYZ 9 Spatial, X Æ Y Æ Z
SPATIAL_YXZ 10 Spatial, Y Æ X Æ Z
SPATIAL_ZXZ 11 Spatial, Z Æ X Æ Z
SPATIAL_ZYZ 12 Spatial, Z Æ Y Æ Z
POS_RESET 1 Reset position (0,0,0) Used in conjunction with
POS_REF 2 REF zero position the SET_OUTPUT UCS
POS_PROC 3 Current Proc. Position statement (the UCS
position argument).
POS_BY_VARS 4 Use OUTPUT_UCS vars
Note that two constants
POS_NO_CHANGE 4 Use OUTPUT_UCS vars
share the same value.
CimatronE 10.0 GPP2 User Guide ⎪141

ROT_RESET 1 Reset orientation (REF) Used in conjunction with

ROT_PROC 2 Current Proc. orientation the SET_OUTPUT UCS
ROT_WORKPLANE 3 Use WORK_PLANE vars statement (the UCS
orientation argument).
ROT_CURPOS 4 Use current position “UCS”
Note that two constants
ROT_BY_VARS 5 Use OUTPUT_UCS vars
share the same value.
ROT_NO_CHANGE 5 Use OUTPUT_UCS vars

4.2.6 Transformation Constants

Constant Value Meaning Relevant Use
TR_EXPLODE 0 Explode all transformations Transformation mode
TR_USE_SUBS 1 Use subroutines Transformation mode
TR_SIMPLE 0 Simple transformation Transformation type
TR_ARRAY_PRIME_X 1 Array transformation. X is Transformation type
primary.
TR_ARRAY_PRIME_Y 2 Array transformation. Y is Transformation type
primary.
CimatronE 10.0 GPP2 User Guide ⎪142

4.3 GPP2 Variable Formats

Each GPP2 variable has a format, which defines how it is formatted for output if needed in the
machine code. These formats are described in detail in the GPP2 Language Reference Manual.
System variables have a default format (which can be overridden in the EX2 program). This default
format is listed for each block variable listed below. The formats are shown as numbers, from 0 to 18,
according to the following table:
Format Name Format Number Format Name Format Number
CHARACTER 0 USER_3 10
COORDINATES 1 USER_4 11
ANGLES 2 USER_5 12
FEED 3 USER_6 13
SPINDLE 4 USER_7 14
DWELL 5 USER_8 15
SEQUENCING 6 USER_9 16
TOOL 7 USER_10 17
USER_1 8 REAL 18
USER_2 9

Notes:
1. All formats represent double-precision floating point numeric numbers, except format
CHARACTER (0), which represents a string (up to 256 characters).

2. The COORDINATE format (1) has a special meaning in GPP2. Every system variable of that
format is multiplied by the unit factor, as defined in the DF2 file.
3. In GPP2, the FEED format (3) is also multiplied by the unit factor, as defined in the DF2 file.
CimatronE 10.0 GPP2 User Guide ⎪143

4.4 DF2-Related Variables

The DF2 configuration file contains a large set of parameters used to define how GPP2 operates in a
given post-processor. Many of these parameters have associated system variables that can be
accessed or modified in the EX2 program. These variables can also be used in the post-processor
interaction in order to allow the end-user to change some of the values.
These DF2-associated system variables are described in this section.
The data flow is as follows:
1. The DF2 file is loaded into GPP2 (as part of a post-processor load).
2. The relevant system variables are initialized with the DF2 data.
3. If specified as interaction variables, they are shown to the end-user. Any changes made by the
end user take place before the post is executed.
4. The EX2 program may make use the data or make additional changes throughout the
execution.
Note: changes made to DF2-related variables in the STARTUP block take effect before any of
these variables is used in the execution process.
CimatronE 10.0 GPP2 User Guide ⎪144

4.4.1 Machine Codes

The following new variables contain many of the machine codes defined in the DF2 file. They can be
used by the GPP2 developer in order to make his PP more generic whenever these codes have to be
explicitly output to the machine.
Note: these system variables should be regarded as “read-only” by the EX2 program. GPP2 uses the
codes specified in the DF2 file and will not respond to any changes made to these variables.

System Variable Default Use and Comments

format
CODE_DWELL 0 Machine code for machine dwell
CODE_LIN_FEED 0 Machine code for linear motion at feed rate
CODE_LIN_FAST 0 Machine code for linear motion at fast (rapid) rate
CODE_CIRC_CCW 0 Machine code for circular motion at counterclockwise
(CCW) direction
CODE_CIRC_CW 0 Machine code for circular motion at clockwise (CW)
direction
CODE_CUTCOM_LEFT 0 Machine code for cutter compensation LEFT
CODE_CUTCOM_RIGHT 0 Machine code for cutter compensation RIGHT
CODE_CUTCOM_OFF 0 Machine code for cutter compensation OFF
CODE_CUTCOM_LEN 0 Machine code for cutter length compensation
CODE_COOL_OFF 0 Machine code for default coolant OFF
GPP2 will use that code when coolant is off for the
procedure.
CODE_FLOOD_ON 0 Machine code for coolant FLOOD ON
CODE_FLOOD_OFF 0 Machine code for coolant FLOOD OFF.
GPP2 will use that code when coolant is turned off after it
was set on to FLOOD for the procedure.
CODE_MIST_ON 0 Machine code for coolant MIST ON
CODE_MIST_OFF 0 Machine code for coolant MIST OFF.
GPP2 will use that code when coolant is turned off after it
was set on to MIST for the procedure.
CODE_THROUGH_ON 0 Machine code for coolant THROUGH ON
CODE_THROUGH_OFF 0 Machine code for coolant THROUGH OFF.
GPP2 will use that code when coolant is turned off after it
was set on to THROUGH for the procedure.
CODE_AIR_ON 0 Machine code for coolant AIR ON
CimatronE 10.0 GPP2 User Guide ⎪145

CODE_AIR_OFF 0 Machine code for coolant AIR OFF.

GPP2 will use that code when coolant is turned off after it
was set on to AIR for the procedure.
CODE_SPIN_CW 0 Machine code for clockwise spin
CODE_SPIN_CCW 0 Machine code for counter-clockwise spin
CODE_SPIN_OFF 0 Machine code for turning the spindle off
CODE_RETR_INIT 0 Machine code for cycle “return to init”
CODE_RETR_CLEAR 0 Machine code for cycle “return to clearance”

4.4.2 Sequencing
The following new variables control the automatic sequencing process.

System Variable Default Use and Comments

format
SEQ_NUM 6 The sequence number. Each time it is output, it is
automatically incremented by the value of SEQ_INC. Its
value is also controlled by the SEQ_LEVEL_NEXT and
SEQ_LEVEL_BACK commands for nested sequencing.
SEQ_INC 6 The increment value that is added to SEQ_NUM each time
it is sent to output.
SEQ_START 6 The “start” value of new sequencing series. Each time the
SEQ_LEVEL_NEXT statement is executed, the value of
SEQ_START is copied to SEQ_NUM.
SEQ_MAX 6 The maximum allowed value for SEQ_NUM. If SEQ_NUM is
incremented past this number, it is reset to the value of
SEQ_START.
CimatronE 10.0 GPP2 User Guide ⎪146

4.4.3 Circular Motions

The following new variables control the way circular motions are processed in GPP2.

System Variable Default Use and Comments

format
ARCS_CTRL_BYPLANE 6 Determines if arcs are broken into linear motions,
depending on the arc plane.
Use the following predefined values:
DEF_NONE
DEF_XYONLY
DEF_MAJORPLANES
DEF_ANYPLANE
This variable replaces CIR_INTERP
ARCS_MAX_ANGLE 2 Limits the maximum “size” of each arc (measured in
degrees) to the value specified in this variable. Larger
arcs are broken into smaller (equal) arcs.
If the number is 360, no action takes place.
ARCS_LARGE_RAD 1 If very large arcs are broken into linear motions (another
DF2 parameter, with no matching EX2 system variable),
this variable defines the radius above which the arc is
considered very large.
ARCS_SMALL_RAD 1 If very small arcs are replaced by linear motions (another
DF2 parameter, with no matching EX2 system variable),
this system flag defines the radius below which the arc is
considered very small.
ARCS_SMALL_LEN 1 If very small arcs are replaced by linear motions, this
system flag defines the arc length below which the arc is
considered very small.
ARCS_MIN_SEGS 6 When breaking an arc into linear motions, this is the
minimal number of linear segments that must be used.
ARCS_MAX_SEGLEN 1 When breaking an arc into linear motions, this is the
maximal length of each segment. Enough segments will
be used to ensure the length of each one is no larger than
this value.
CIRC_TOL 1 The tolerance used by GPP2 when breaking circular
motions into linear segments. The smaller the tolerance,
the more segments will be created.
The actual tolerance used depends on other DF2
parameters - see detailed discussion on linear
interpolation tolerance.
CimatronE 10.0 GPP2 User Guide ⎪147

4.4.4 Converting Linear Motions to Arcs

The following new variables control the way GPP2 applies the arc-fitting algorithm that converts a
series of linear motion blocks into arcs:

System Variable Default Use and Comments

format
ARCFIT_PLANES 6 Determines the planes where GPP2 looks for arc fitting.
The variable is initialized from the corresponding DF2
parameter, to one of the following predefined values:
DEF_NONE (1)
DEF_XYONLY (2)
DEF_MAJORPLANES (3)
ARCFIT_TOL 1 Tolerance used in the arc fitting process.
Initialized from a DF2 parameter.
The actual tolerance used also depends on the DF2
parameter that defines the tolerance “type” – Procedure
or Absolute.
ARCFIT_MIN_CNT 6 The minimum number of points that can be
approximated by an arc. No arc will be created if a
proper (within tolerance) arc cannot be found with this
number of points.
Initialized from a DF2 parameter.
ARCFIT_HELICAL 6 Determines if helical arcs (for helical plunge) are
supported or not. Initialized from a DF2 parameter.
If set to TRUE_, GPP2 will also search for helical arcs in
the XY plane (only). If set to FALSE_, GPP2 will ignore
helical arcs.
CimatronE 10.0 GPP2 User Guide ⎪148

4.4.5 GPP2 Connections

The following new variables control the way GPP2 handles connections.
System Variable Default Use and Comments
format
ACTION_MOVE_AXES 0 The variable holds a copy of the second argument
defined in the scenario action (MOVE_, MOVE_UP and
MOVE_DOWN), defining the axes used in the motion
(e.g. "Z", "XY" or "XYZ").
CON_ACTION 6 The connection action.
May get one of the following values:
CON_ACTION_NONE = 0,
CON_ACTION_MOVE = 1,
CON_ACTION_MOVEUP = 2,
CON_ACTION_MOVEDOWN = 3,
CON_ACTION_MOVESAFE = 4,
CON_ACTION_CTRL = 5,
CON_ACTION_SETUCS = 6,
CON_MAX_ALPHA 2 Maximum change in “alpha”, in angles, allowed in one
connection step (linear motion). Not relevant in
connections from safe position.
CON_MAX_BETA 2 Maximum change in “beta”, in angles, allowed in one
connection step (linear motion). Not relevant in
connections from safe position.
CON_MAX_DIST 1 Maximum distance allowed in one connection step
(linear motion). Not relevant in connections from safe
position.
CON_SCENARIO 0 The name of the scenario selected by GPP2 for this
connection. The variable is initially set by GPP2, but
can be modified by the EX2 program during the
“BEGINNING OF CONNECT” block, to select any
scenario to be used by GPP2 for the connection.
See the GPP2 default values in the “BEGINNING OF
CONNECT” block.
LONG_CON_X 1 Distance along the X axis, above which a connection is
defined as “long”.
LONG_CON_Y 1 Distance along the Y axis, above which a connection is
defined as “long”.
CimatronE 10.0 GPP2 User Guide ⎪149

System Variable Default Use and Comments

format
LONG_CON_Z 1 Distance along the Z axis, above which a connection is
defined as “long”.
LONG_CON_A 2 Difference in the “alpha” angle, in degrees, above
which a connection is defined as “long”.
LONG_CON_B 2 Difference in the “beta” angle, in degrees, above which
a connection is defined as “long”.
SWITCH_TO_SAFE_ 6 Defines when a connection must be done through the
CONNECT “safe” position. Use the following predefined values:
WHEN_TOOLCHANGE after tool change (only)
WHEN_LONG_CON every “long” connection
WHEN_EVERY_CON every connection

4.4.5.1 5 Axis Connections

During 5 axes (5X) continuous milling, it is sometimes necessary to introduce a connection in the
middle of the cutting process, as the machine reaches a rotary axis limit and needs to be rotated back
or switch to the alternative solution.
The following new variables control the way GPP2 handles 5X connections.
System Variable Default Use and Comments
format
X5_CON_TANGENT 6 5X “change solution” connections: set to TRUE_ (1) to use
tangential retract and approach. Set to FALSE_ (0) to use
normal retract and approach.
X5_CON_RADIUS 1 5X “change solution” connections: radius of tangential
retract and approach.
X5_CON_RETRACT 1 5X “change solution” connections: the length of the feed-
rate retract motion (along tool axis).
X5_CON_CLEARANCE 1 5X “change solution” connections: the height of the solution
swap point above the surface (along tool axis).
M5_SWAP_INPLACE 2 5X “change solution” connections: allows an “in-place”
solution swap (rotate without lifting the tool from the part) in
certain conditions (when one axis has a very small rotation).
See In-Place 5-Axis Connection on page 232 for details.
CimatronE 10.0 GPP2 User Guide ⎪150

4.4.5.2 Inter-Cycle Connections

On some machines and under some conditions, it is necessary to introduce a connection between two
consecutive drill cycles. For instance, a connection may be needed if the drill plane height (the “Z”,
measured along tool axis) changes between the holes. A connection may also be needed in full 5X
drill, where two successive holes may require a different orientation.
The following new variables control the way GPP2 handles inter-cycle connections.

System Variable Default Use and Comments

format
CYC_CON_MINZ 1 Cycle connections: create an inter-cycle connection if
the delta in “Z” between the last and next cycle is equal
to or less than this value.
The “Z” values are measured along the tool axis.
CYC_CON_MAXZ 1 Cycle connections: create an inter-cycle connection if
the delta in “Z” between the last and next cycle is equal
to or greater than this value.
The “Z” values are measured along the tool axis.
CYC_CON_DIST 1 Cycle connections: create an inter-cycle connection if
the distance between the last and next cycle is equal to
or greater than this value.
CYC_CON_ALPHA 2 Cycle connections: create an inter-cycle connection if
the delta in “alpha” between the last and next cycle is
greater than (not equal) this value.
CYC_CON_BETA 2 Cycle connections: create an inter-cycle connection if
the delta in “beta” between the last and next cycle is
greater than (not equal) this value.
CimatronE 10.0 GPP2 User Guide ⎪151

4.4.6 5 Axis Motions

The following new variables control the way GPP2 5 axes linear motions. They are discussed in more
details in the 5X manual.
System Variable Default Use and Comments
Format
X5_FEED_BY_TOL 6 If set to TRUE_ (1), GPP2 will use the procedure tolerance
value for breaking 5X linear motions to smaller motions
(to determine the maximum angle of each step).
The procedure tolerance value is determined by
PART_TOL or by CONT_TOL (the smaller value).
If set to FALSE_ (0), GPP2 will use the tolerance given in
X5_FEED_MAX_ALPHA and X5_FEED_MAX_BETA.
X5_FEED_MAX_ALPHA 2 The maximum change in the “alpha” angle per 5X linear
motion step (in feed rate). The actual step may be
smaller, if the procedure tolerance is used (see
description of X5_FEED_BY_TOL).
X5_FEED_MAX_BETA 2 The maximum change in the “beta” angle per 5X linear
motion step (in feed rate). The actual step may be
smaller, if the procedure tolerance is used (see
description of X5_FEED_BY_TOL).
X5_FEED_MIN_ALPHA 2 The minimum step to be used for the “alpha” angle when
breaking 5X linear motions to smaller steps. This variable
ensures that not too many steps will be created due to
extremely tight tolerances.
Setting the variable to 0 removes any such limitation.
X5_FEED_MIN_BETA 2 The minimum step to be used for the “beta” angle when
breaking 5X linear motions to smaller steps. This variable
ensures that not too many steps will be created due to
extremely tight tolerances.
Setting the variable to 0 removes any such limitation.
INTERNAL_5X_RAPID 6 Use the rapid motions created inside advanced 5X
procedures to connect feed segments. If the flag is set to
TRUE_, GPP2 follows the exact motions generated by the
procedure. If set to FALSE_, GPP2 creates its own
connections between the feed segments.
The flag only applies to 5X advanced (Aerospace)
procedures. It has no effect on legacy 5X procedures.
Note that GPP2 can optimize the rotary axes motions
better if allowed to perform its own connections between
segments of feed motions.
CimatronE 10.0 GPP2 User Guide ⎪152

4.4.7 Miscellaneous
System Variable Default Use and Comments
format
SUBS_CTRL_BYPLANE 6 Determines if 2.5X subroutines are exploded in the G-
Code file, depending on the subroutine plane.
Use the following predefined values:
DEF_NONE (no subroutines)
DEF_XYONLY
DEF_MAJORPLANES
DEF_ANYPLANE
This system flag replaces NO_SUBROUT
CYC_CTRL_BYPLANE 6 Determines if drill cycles can be performed on the
machine, based on the cycle plane.
Use the following predefined values:
DEF_NONE
DEF_XYONLY
DEF_MAJORPLANES
DEF_ANYPLANE
If a drill cycle is not supported, GPP2 will set the
CYC_MANUAL variable. It is the responsibility of the EX2
program to further handle the situation.
SUPPRESS_BLANKS 6 If set to TRUE_ (1), GPP2 will suppress any blank lines, as
well as any spaces at the beginning of each output line. If
set to FALSE_ (0), the output will be “as is”.
TOOLCHANGE_TIME 18 This parameter controls the time required to change a tool
in the machine. This time is added to the air motion time
for each tool.
CimatronE 10.0 GPP2 User Guide ⎪153

4.5 GPP2 System Flags

GPP2 has several system variables, also known as “system flags”, that can be used by the EX2
Program to affect the way GPP2 operates. They are set or modified by the EX2 program, and later
read internally by the GPP2 engine.
Some of these system flags are also dynamically set by the GPP2 engine throughout the execution.
Others are only initialized with the default value and later set by the EX2 application.
The default format for each system flag is shown in parenthesis after the variable name. The format is
quite meaningless, since all that matters is the value (true or false).

System Flag/Variable Default Set by Use and comments

value GPP2
A_RESET_AXIS FALSE_ No If set to TRUE_, GPP2 will reset the
primary axis, A.
B_RESET_AXIS FALSE_ No If set to TRUE_, GPP2 will reset the
secondary axis, B.
CONNECT_FORCED FALSE_ Yes Indicate if a connection is forced or
not.
CUT_FILE FALSE_ Yes If set to TRUE_, GPP2 will cut the
(format 6) output tape (file) and start a new
(for a one. In the process, it will call the
very END OF TAPE and BEGINNING OF
short TAPE blocks with the proper
period qualifiers (beforecut and
until the aftercut, respectively).
file is After the tape cut, the flag is reset
cut) to FALSE_ again.
GPP2 automatically sets the
variable when the tape needs to be
cut because of excessive length, as
defined in the DF2 file.
FORCE_CONNECT_IF_INPLACE FALSE_ No If set to TRUE_, a regular GPP2
connection is forced in an “In-Place
Connection” situation. The
CONNECT IN PLACE block is not
invoked.
CimatronE 10.0 GPP2 User Guide ⎪154

System Flag/Variable Default Set by Use and comments

value GPP2
MINMAX_SPINDLE FALSE No Defines the actual point being
described by all the “min” and
“max” variables (X_MIN, X_MAX,
etc.). When set to TRUE_, all these
variables describe the min and max
values of the spindle center point,
ignoring the tool itself. When set to
FALSE_ (the default!), these
variables describe the tool tip point
min and max locations.
MINMAX_VS_MACH TRUE No Affects the reference point of all the
“min” and “max” variables (X_MIN,
X_MAX, etc.). When set to TRUE_
(the default!), all these variables
refer to the “machine” zero point
(machine table center). When
FALSE_, all these variables refer to
the REF UCS zero point.
MOVE_TO_SAFE - Yes (in Used to instruct GPP2 to move to
response the safe position. This is useful at
to the the end of
EX2 the run, or in conjunction with a tool
program change.
setting it In order to instruct GPP2 to move,
first) the EX2 program has to set the
GPP2 system flag,
MOVE_TO_SAFE, telling GPP2
which axes to move.
MOVE_TO_SAFE must be set to a
string that contains one or more of
the axis letters, X, Y, Z, A and B.
Uppercase or lower case letters
may be used.
CimatronE 10.0 GPP2 User Guide ⎪155

System Flag/Variable Default Set by Use and comments

value GPP2
OFST_TOOL_CENTER FALSE_ No If set to TRUE_, GPP2 will offset the
tool output coordinates from the
tool tip to the tool center, by moving
them along the tool axis. The offset
is defined the tool radius, as
appears in the TOOL_RAD
variable. This works properly for
ball tools, but is risky for other tool
shapes.
The only coordinates affected are
X/Y/Z_CURPOS and
X/Y/Z_CENTER. Other coordinates,
such as the procedure origin, are
not affected.
OUTPUT_SUSPEND FALSE_ No If set to TRUE_, GPP2 will suspend
(format 6) all output statements (OUTPUT,
PRINT1, etc.). When output is
suspended, the new-line-is block is
not executed at all.
REQUEST_RECONFIG FALSE_ No If set to TRUE_, GPP2 will start a
(format 6) machine re-configuration process
and invoke the RECONFIG
MACHINE block. See a detailed
description regarding machine
reconfiguration and 6X machines.
SET_REF_BY_ORIGIN FALSE_ Yes (in When set to TRUE_ in the ORIGIN
(format 6) response CHANGE block, GPP2 will modify
to the the REF UCS to be the origin UCS
EX2 defined in that block. See the
program section on using Multiple Part
setting it Setups. GPP2 will then reset the
first) flag back to FALSE_. This system
flag is only checked in the ORIGIN
CHANGE block.
TEMPLATE_SETUP As No Name of template file for “NC
(format 0) defined Setup” report (not including the
in DF2 .mht extension).
file The EX2 program may override the
default value in the STARTUP block
(only).
CimatronE 10.0 GPP2 User Guide ⎪156

System Flag/Variable Default Set by Use and comments

value GPP2
TEMPLATE_TOOLS As No Name of template file for “Tools”
(format 0) defined report (not including the .mht
in DF2 extension).
file The EX2 program may override the
default value in the STARTUP block
(only).
TOOL_NUM_OFFSET 0 No This offset number is added to
every tool number coming from
CimatronE. It affects the TOOL_NUM
variable in every TOOL CHANGE
block (as well as in the Tools
report).
TRACE_EXECUTE FALSE_ No If set to TRUE_, GPP2 will start a
(format 6) detailed trace of each command
execution. See the GPP2 language
reference manual for details.
TRACE_LINENO FALSE_ No If set to TRUE_, GPP2 will start
(format 6) tracing the G-code output by
preceding each output line with the
line number of the (first) EX2
command that created the line. See
GPP2 Language Reference
Manual for details.
TRACE_SINGLESTEP FALSE_ No If set to “on”, GPP2 will enter step-
(format 6) by-step debugging mode, where
the execution of each command is
shown on the screen, and GPP2
pauses after each command.
TRACE_EXECUTE must also be
TRUE_ in order to use this mode.
See the GPP2 Language
Reference Manual for details.
TRACE_TPBLOCK FALSE_ No If set to TRUE_, GPP2 will start
(format 6) tracing the G-code output by
preceding each output line with the
toolpath block number. See GPP2
Language Reference Manual for
details.
CimatronE 10.0 GPP2 User Guide ⎪157

4.6 Global System Variables

In addition to the System Flags described above, several system variables are available throughout
the post process, and are not specific to any given block.

System Variable Default Use and Comments

format
FILE_NAME 0 Current toolpath file name plus the post-processor name,
separated by a dot: <tp-name>.<pp-name>
OUTPUT_DIR 0 Current output directory (full path)
BLOCK_NUM 6 The current block number, as it appears in the CimatronE
toolpath (in TP List)
BLOCK_NAME 0 This variable holds the name of the current block, in
upper case and without any spaces (e.g.,
“LINEARMOTION”). It is mostly used for debugging
purposes.
QUALIFIER_NAME 0 This variable holds the name of the current block qualifier,
in lower case (e.g., “on”, “3d”, “first”). If no qualifier is
used, it holds an empty string.
Use of QUALIFIER_NAME inside IF commands can save
duplication of EX2 commands, if the differences between
the EX2 programs for various qualifiers are small.
GPP_PROC_NAME 0 This variable holds the name of the currently executed
GPP2 procedure. It is empty if no such procedure is
executed. It is mostly used for debugging purposes.
OUTPUT_EXTENSION 0 This is a string variable that contains a single character
when the output stream is redirected (using the
OUTPUT_REDIRECT command). Otherwise, it is the
empty string.
X_LASTPOS 1 The coordinates of the last tool position, the position just
Y_LASTPOS before the execution of the current block. GPP2 maintains
Z_LASTPOS the last position throughout the program execution.

A_LASTPOS 2 The angles for “alpha” and “beta” rotary axes of the last
B_LASTPOS tool position (4/5 axes machines)
TP_BLOCKS 6 The number of blocks in toolpath.
CimatronE 10.0 GPP2 User Guide ⎪158

4.7 Advanced System Variables

The following system variables are only used in conjunction with advanced 5X machines. They are
also available throughout the post process, and are not specific to any given block.
System Variable Default Use and Comments
format
VIRTUAL_ANGLE_1 2 These angles are calculated by the CALC_WORKPLANE
VIRTUAL_ANGLE_2 statement when virtual axis rotations are used on the
VIRTUAL_ANGLE_3 machine to define work planes. The rotation method (Euler
or Spatial), the axes used and the order of rotations are all
defined by the VIRTUAL_AXES variable.
I_WORKPLANE 18 The Z orientation vector of the work plane rotation matrix
J_WORKPLANE (calculated by the CALC_WORKPLANE statement).
K_WORKPLANE
IX_WORKPLANE 18 The X orientation vector of the work plane rotation matrix
JX_WORKPLANE (calculated by the CALC_WORKPLANE statement).
KX_WORKPLANE
X_OUTPUT_UCS 1 These variables describe the current origin of the “output”
Y_OUTPUT_UCS UCS, relative to the REF UCS. By default, they are set to
Z_OUTPUT_UCS (0,0,0), and can be modified with the SET_OUTPUT_UCS
statement.
I_OUTPUT_UCS 18 These variables describe the current “output” UCS Z
J_OUTPUT_UCS orientation vector, relative to the REF UCS. By default,
K_OUTPUT_UCS they are set to (0,0,1), and can be modified with the
SET_OUTPUT_UCS statement.
IX_OUTPUT_UCS 18 These variables describe the current “output” UCS X
JX_OUTPUT_UCS orientation vector, relative to the REF UCS. By default,
KX_OUTPUT_UCS they are set to (1,0,0), and can be modified with the
SET_OUTPUT_UCS statement.
CimatronE 10.0 GPP2 User Guide ⎪159

System Variable Default Use and Comments

format
X_NONROT_UCS 1 These variables are the same as the output UCS origin
Y_NONROT_UCS relative to the REF UCS, but without considering any
Z_NONROT_UCS table rotation. They are set each time the
SET_OUTPUT_UCS statement is used.
I_NONROT_UCS 18 These variables are the same as the output UCS Z axis
J_NONROT_UCS relative to the REF UCS, but without considering any
K_NONROT_UCS table rotation. They are set each time the
SET_OUTPUT_UCS statement is used.
IX_NONROT_UCS 18 These variables are the same as the output UCS X axis
JX_NONROT_UCS relative to the REF UCS, but without considering any
KX_NONROT_UCS table rotation. They are set each time the
SET_OUTPUT_UCS statement is used.
CON_AFTR_RECONFIG 6 Set to TRUE_ if this connection takes place immediately after
a machine reconfiguration process. It is FALSE_ in all other
cases.
INACCURATE_ORIENT 6 This flag is set by GPP2 to TRUE_ if the tool orientation is
inaccurate because the machine contains one or two
indexed (non-continuous) axes, and the required tool
orientation cannot be achieved.
It is set during the BEGINNING OF CONNECT block if the
connection point orientation is inaccurate, and in all motion
blocks (e.g., LINEAR MOTION). It is always FALSE_ in
machines without indexed axes.
INACCURATE_ERROR 2 This variable is meaningful only if the INACCURATE_ORIENT
flag is set to TRUE_. It indicates the size of the orientation
vector error, in angles (the difference between the required
and the resulting tool orientation).
CimatronE 10.0 GPP2 User Guide ⎪160

4.8 Machine Definition Variables

These variables are used for defining characteristics of the target machine. Most of them are only
used for 4/5 axes machines, but some are relevant to 3 axes machines as well.

4.8.1 5-Axis Machine Definition

The following sections describe variables used for defining 4 and 5 axes machines. Further
explanation of their use is provided in the GPP2 5X Manual.

System Variable Default Use and Comments

format
M5_TOOL_I 18 Direction vector of the tool. By default, the direction is the
M5_TOOL_J Z axis (0,0,1). Horizontal or slanted tools can also be
M5_TOOL_K defined and used by GPP2.

M5_RTCP_HEAD 6 If set to COMP_CONTROLLER (1), indicates that the

machine uses RTCP for the head, and corrects by itself
the translation caused by head rotation. If COMP_GPP (0),
GPP2 will do the corrections itself (old machines).
A new option COMP_NONE (2), will not make any
corrections to the head – not by GPP2 and not by the
controller (and it will be seen in the simulator as is).
M5_RTCP_TAB 6 If set to TRUE_ (1), indicates that the machine uses
RTCP for the table, and corrects by itself the translation
caused by table rotation. If FALSE_ (0), GPP2 will do the
corrections itself (bare machines).
M5_RTCP_M128 6 If set to TRUE_ (1), indicates that the machine uses the
Heidenhain M128 command, and corrects by itself the
translation and rotation caused by table/head rotation. If
FALSE_ (0), GPP2 will do all the calculations itself.
If set, M5_RTCP_M128 overrides the other two RTCP
flags. If not set, GPP2 considers their values.
M5_USE_MACH 6 If set to TRUE_ (1), indicates that GPP2 needs to consider
the X/Y/Z_MACH vector in order to compensate for the
location of the part on the machine table. If set to FALSE_
(0), GPP2 ignores the X/Y/Z_MACH vector.
CimatronE 10.0 GPP2 User Guide ⎪161

System Variable Default Use and Comments

format
M5_CORR_X 1 A correction vector used in extreme cases where the
M5_CORR_Y machine Anchor Point (the “red” point) cannot be located
M5_CORR_Z at the center of table rotation. See the GPP2 5X Manual
for more details.
M5_SWAP_RANGE 2 Works in conjunction with the M5_A_SWAP_MIN/MAX or
M5_B_SWAP_MIN/MAX variables. If a swap point is moved
to a desired angle, the value of M5_SWAP_RANGE is used
to define a random range within which the swap point will
be located.
For instance, if M5_SWAP_RANGE is set to 5, the random
range is ±5 degrees around the desired swap point.
X_MACH_MIN 1 The minimum and maximum allowed X values (for the
X_MACH_MAX machine spindle center point), relative to the X_MACH
point. Only take effect if M5_CHECK_LIMITS is TRUE_.
Y_MACH_MIN 1 The minimum and maximum allowed Y values (for the
Y_MACH_MAX machine spindle center point), relative to the Y_MACH
point. Only take effect if M5_CHECK_LIMITS is TRUE_.
Z_MACH_MIN 1 The minimum and maximum allowed Z values (for the
Z_MACH_MAX machine spindle center point), relative to the Z_MACH
point. Only take effect if M5_CHECK_LIMITS is TRUE_.
M5_CHECK_LIMITS 6 If set to TRUE_, instructs GPP2 to verify every 5X point
and check that the spindle center point is within the limits
defined by the relevant XYZ minimum and maximum
values. GPP2 will stop the run if it cannot find valid
rotation angles that satisfy the position limits.
ORIENT_PREF 6 Set the desired orientation of the machine if the whole
procedure is in position, where the IJK is 0,0,1 and the
machine axis can work in any angle.
If set to PROC_ORIENT, the orientation would fit the UCS
of the procedure. If set to ZERO_ORIENT, the angle
would get the value 0. If set to SAME_ORIENT, the
angles would be the same as in the previous procedure
(the machine would not move).
CimatronE 10.0 GPP2 User Guide ⎪162

4.8.2 5-Axis Machine – Primary (A) Axis

System Variable Default Use and Comments
Format
M5_A_I 18 Alpha axis direction vector. Usually set automatically by use
M5_A_J of predefined axes. Needs manual setting only if
M5_A_K AX5_MANUAL_A is used.

M5_A_00I 18 Alpha axis “zero angle” direction vector. Usually set

M5_A_00J automatically by use of predefined axes. Needs manual
M5_A_00K setting only if AX5_MANUAL_A is used.

M5_A_VECX 1 Alpha axis displacement vector (from center of axis to

M5_A_VECY another predefined point). Should be given in REF UCS,
M5_A_VECZ when the axis is at zero angle.
Not relevant if RTCP is used on the machine.
M5_A_CYCLIC 6 If set to TRUE_ (1), indicates that the alpha axis is totally
cyclic, meaning it can rotate indefinitely, and the controller
handles the “jumps” (e.g., from 359 to 1).
M5_A_RESETABLE 6 If set to TRUE_ (1), indicates that the alpha axis can rotate
indefinitely, but the controller has soft limits on the angle,
beyond which the axis must be “reset” with the RESET AXIS
block.
For such an axis, M5_A_CYCLIC must be set to FALSE_ (0).
M5_A_REVERSED 6 If set to TRUE_ (1), indicates that the alpha axis angle is
reversed (negated) before being presented. All calculations
take place with the standard angle – it is negated just before
it is output.
M5_A_MIN_ANG 2 Alpha axis minimum valid angle (in degrees)
M5_A_MAX_ANG 2 Alpha axis maximum valid angle (in degrees)
M5_A_RESET_FROM 2 Lower end of the axis “reset range” (-360 by default). This is
only applicable for resettable axes (where M5_A_RESETABLE
is TRUE_).
M5_A_RESET_TO 2 Upper end of the axis “reset range” (+360 by default). This is
only applicable for resettable axes (where M5_A_RESETABLE
is TRUE_).
CimatronE 10.0 GPP2 User Guide ⎪163

System Variable Default Use and Comments

Format
M5_A_PREF 6 Axis angle preference, for cases where GPP2 has two
solutions for the same orientation.
Use one of the following values:
PREF_NONE No preference
PREF_POSITIVE Prefer positive angles
PREF_NEGATIVE Prefer negative angles
M5_A_LETTER 0 The letter used for the alpha axis (e.g., “A” or “C”). Used
both for G-code output as well as machine simulator output.
The letter is by default “A”. May be more than one character.
M5_A_ZERO 2 The “zero” point of the alpha axis, compared to the
reference zero. The variable is typically not used when the
machine is defined (its default value is 0 anyway).
It is used dynamically throughout the run if a new “home”
point has to be defined, where the axis logical “zero” is
redefined at a non-zero angle.
M5_A_STEP 2 Used if the alpha axis is “indexed”, meaning it cannot be
placed at any angle but only at specific angles. This variable
defines the rotation “step”, in degrees, between the allowed
angles.
M5_A_SWAP_MIN 2 The desired A axis angle to perform a solution swap if the
swap is necessary because the A axis minimum angle has
been reached. If such a swap must be done, GPP2 will
attempt to make it when the A axis is near that angle.
M5_A_SWAP_MAX 2 The desired A axis angle to perform a solution swap if the
swap is necessary because the A axis maximum angle has
been reached. If such a swap must be done, GPP2 will
attempt to make it when the A axis is near that angle.
CimatronE 10.0 GPP2 User Guide ⎪164

4.8.3 5-Axis Machine – Secondary (B) Axis

System Variable Default Use and Comments
Format
M5_B_I 18 Beta axis direction vector. Usually set automatically by
M5_B_J use of predefined axes. Needs manual setting only if
M5_B_K AX5_MANUAL_B is used.

M5_B_00I 18 Beta axis “zero angle” direction vector. Usually set

M5_B_00J automatically by use of predefined axes. Needs manual
M5_B_00K setting only if AX5_MANUAL_B is used.

M5_B_VECX 1 Beta axis displacement vector (from center of axis to

M5_B_VECY another predefined point). Should be given in REF UCS,
M5_B_VECZ when the axis is at zero angle.
Not relevant if RTCP is used on the machine.
M5_B_CYCLIC 6 If set to TRUE_ (1), indicates that the beta axis is totally
cyclic, meaning it can rotate indefinitely, and the controller
handles the “jumps” (e.g., from 359 to 1).
M5_B_RESETABLE 6 If set to TRUE_ (1), indicates that the beta axis can rotate
indefinitely, but the controller has soft limits on the angle,
beyond which the axis must be “reset” with the RESET
AXIS block.
For such an axis, M5_B_CYCLIC must be set to FALSE_
(0).
M5_B_REVERSED 6 If set to TRUE_ (1), indicates that the beta axis angle is
reversed (negated) before being presented. All
calculations take place with the standard angle – it is
negated just before it is output.
M5_B_MIN_ANG 2 Beta axis minimum valid angle (in degrees)
M5_B_MAX_ANG 2 Beta axis maximum valid angle (in degrees)
M5_B_RESET_FROM 2 Lower end of the axis “reset range” (-360 by default). This
is only applicable for resettable axes (where
M5_B_RESETABLE is TRUE_).
M5_B_RESET_TO 2 Upper end of the axis “reset range” (+360 by default).
This is only applicable for resettable axes (where
M5_B_RESETABLE is TRUE_).
CimatronE 10.0 GPP2 User Guide ⎪165

System Variable Default Use and Comments

Format
M5_B_PREF 6 Axis angle preference, for cases where GPP2 has two
solutions for the same orientation.
Use one of the following values:
PREF_NONE No preference
PREF_POSITIVE Prefer positive angles
PREF_NEGATIVE Prefer negative angles
M5_B_LETTER 0 The letter used for the beta axis (e.g., “A” or “C”). Used
both for G-code output as well as machine simulator
output. The letter is by default “A”. May be more than one
character.
M5_B_ZERO 2 The “zero” point of the beta axis, compared to the
reference zero. The variable is typically not used when
the machine is defined (its default value is 0 anyway).
It is used dynamically throughout the run if a new “home”
point has to be defined, where the axis logical “zero” is
redefined at a non-zero angle.
M5_B_STEP 2 Used if the beta axis is “indexed”, meaning it cannot be
placed at any angle but only at specific angles. This
variable defines the rotation “step”, in degrees, between
the allowed angles.
M5_B_SWAP_MIN 2 The desired B axis angle to perform a solution swap if the
swap is necessary because the B axis minimum angle
has been reached. If such a swap must be done, GPP2
will attempt to make it when the B axis is near that angle.
M5_B_SWAP_MAX 2 The desired B axis angle to perform a solution swap if the
swap is necessary because the B axis maximum angle
has been reached. If such a swap must be done, GPP2
will attempt to make it when the B axis is near that angle.
CimatronE 10.0 GPP2 User Guide ⎪166

4.8.4 Machine Simulation

System Variable Default Use and Comments
Format
X_SAFE_POS 1 The machine “safe” position, which is usually
Y_SAFE_POS considered as unknown. Only used for machine
Z_SAFE_POS simulation output (no G-code is dependent on
these variables).
The position is defined relative to the “machine”
coordinate system, not to the REF UCS. In the
machine simulator, it is defined relative to the
table center.
Unlike other positions, the numbers define the
position of the spindle center point, ignoring the
tool.
A_SAFE_POS 2 The machine “safe” position alpha and beta
B_SAFE_POS angles. Only used for machine simulation output.
X_SIM_OFFSET 1 The offset of the tool from the base location (used
Y_SIM_OFFSET for reconfiguring, when the tool has changed its
Z_SIM_OFFSET position).

X_SIM_PART_POS 1 The position of the part (REF UCS zero point)

Y_SIM_PART_POS relative to the machine simulator table center.
Z_SIM_PART_POS If the M5_USE_MACH variable is set to TRUE_, then
GPP2 automatically loads this vector from the
X/Y/Z_MACH variables (actually, the negative
values).
MACH_SIM_NAME 0 The name of the machine simulator file.
MACH_SIM_ORDER 0 The order of parameters that are sent to the
machine simulator for the specific machine (e.g.,
“XYZBA”). Use the letters X,Y,Z, A (alpha) and B
(beta) only.
MACH_SIM_TOOLCOMP 6 If set to TRUE_, GPP2 will apply tool length
compensation for the simulator (assuming the
simulator does not do so).
ASC_COLOR_FEED 0 RGB color for toolpath representation, feed
motions.
Default color is light blue (“0 255 255”).
CimatronE 10.0 GPP2 User Guide ⎪167

System Variable Default Use and Comments

Format
ASC_COLOR_RAPID 0 RGB color for toolpath representation, rapid
motions.
Default color is yellow (“255 255 0”).
ASC_COLOR_MAXFEED 0 RGB color for toolpath representation, air motions
in max-feed rate.
Default color is green (“0 255 0”).
ASC_COLOR_CYCLE 0 RGB color for toolpath representation, drill cycles.
Default color is dark blue (“0 50 255”).
ASC_COLOR_CONNECT 0 RGB color for toolpath representation, “pseudo
connections” between the toolpath segments.
Default color is red (“255 0 0”). The pseudo
connections are suppressed if set to the empty
string (“”).
SIM_SHOW_GCODE_OUTPUT 6 If set to TRUE_ the SIM file output will be
changed to show part based (Program like)
coordinates in the ‘Move list’ window in the
machine simulator. For additional information, see
Machine Simulation output as G-Code.
SIM_SHOW_GCODE_FORMAT 0 Used to define the SIM file output format using
regular characters and special parameter place
holders. For additional information, see Machine
Simulation output as G-Code.
SIM_SHOW_GCODE_RAPID Empty Used to define the SIM file output. In rapid
string motions, instead of the feed rate, this place holder
is replaced by the text found in
SIM_SHOW_GCODE_RAPID. For additional
information, see Machine Simulation output as G-
Code.
SIM_COMMENT 0 Used to insert textual comments into the output of
the SIM file, to be shown in the ‘Move list’ window.
Syntax example:
SIM_COMMENT <string-expression> ;
SIM_COMMENT %<variable> ;
SUPPRESS_SIM_COMMENTS 6 If set to TRUE_, the SIM_COMMENT commands
are not executed.
CimatronE 10.0 GPP2 User Guide ⎪168

System Variable Default Use and Comments

Format
SIM_IN_MOTION_CHECK 2 Instructs the machine simulator how to test for
collisions in 4/5 axes machines in the middle of
linear motions. See Machine Simulation In-motion
Collision Checks.
SIM_SUPPRESS_DOUBLE_ROW 6 If set to TRUE_, and if the MANUAL_MOVE,
Subroutine call and MACHINE_RECONFIG
commands are used, the second (comment) row
in the 'Move-list' simulator window will be
suppressed.
SIM_SUPPRESS_OUTPUT 6 Temporarily suppress the SIM file output.
CimatronE 10.0 GPP2 User Guide ⎪169

4.8.5 Miscellaneous
System Variable Default Use and Comments
Format
REVERSE_X_AXIS 6 If set to TRUE_ (1), reverse (negate) the X axis output. The
negation takes place after all calculations are done with
the regular X axis direction.
REVERSE_Y_AXIS 6 If set to TRUE_ (1), reverse (negate) the Y axis output. The
negation takes place after all calculations are done with
the regular Y axis direction.
REVERSE_Z_AXIS 6 If set to TRUE_ (1), reverse (negate) the Z axis output. The
negation takes place after all calculations are done with
the regular Z axis direction.
REVERSE_CW_AXIS 6 If set to TRUE_ (1), reverse the circular motion directions
commands (clockwise and counterclockwise). GPP2 will
output the opposite machine code to the CIRC_MOV and
MOTION_CODE variables.
REVERSE_ANG_AXIS 6 If set to TRUE_ (1), reverse (negate) the circular motion
angles. GPP2 will negate the variables ARC_ANG, ST_ANG
and END_ANG.
MACH_MAJOR_AXIS 6 Defines the machine “major” axis (usually axis Z). This
information is used for GPP2 connections, where GPP2
requires that the major axis of output UCS is aligned with
the major axis of the machine.
This variable is set by default to constant AX5_PZ, and
should only be changed for machines where the major
axis is horizontal (valid values are AX5_PX, AX5_PY,
AX5_MX and AX5_MY).
CimatronE 10.0 GPP2 User Guide ⎪170

System Variable Default Use and Comments

Format
VIRTUAL_AXES 6 Defines the use of virtual axes angles by the
CALC_WORKPLANE statement. VIRTUAL_AXES should be set
to one of the predefined constants, such as EULER_ZYX or
SPATIAL_XYZ in order to define the method, axes and
rotation order.
By default, it is set to VIRTUAL_AXES_NONE.
VIRTUAL_AXES_INCR 6 Incremental virtual axes rotation angles. If set to TRUE_,
GPP2 will calculate incremental rotation angles, taking
the last rotation matrix used as the reference UCS.
Affects the calculation of the CALC_WORKPLANE_UCS
statement. By default, the variable is set to FALSE_.
CimatronE 10.0 GPP2 User Guide ⎪171

4.9 XML and Report Variables

GPP2 can read the XML file that is created by CimatronE NC, and convert any procedure-related
parameters from that file into special GPP2 system variables, termed “XML Variables”.
The XML file data and the XML variables are mostly used for the NC Setup Sheet report generated by
GPP2. However, they can be used inside the EX2 program like any other system variable. The values
for each procedure are loaded (and available for use) at the BEGINNING OF PROC block.
There is no predefined list of such XML variables. The list of XML variables and the “mapping”
between the XML file parameters and GPP2 XML variables is defined in a configuration file that
GPP2 reads at runtime.
The location, structure and customization of the configuration file (gpp2-xml.ini) are described in
the GPP2 Report Customization manual.
In addition to the XML variables that are often used in GPP2 reports, there are several other special
system variables that can only be used inside the Tools report. The reason for that limitation is that
they are only assigned valid values when the Tools report is created (specifically, they do not have
valid values in the TOOL CHANGE block).

System Variable Default Use and Comments

Format
TOOL_CNT 6 The tool sequential number (tools are counted in the
order they are first used).
This variable is also available ate the END OF TAPE
block, showing the total number of tools used.
TOOL_FEED_TIME 0 The total cutting time of the tool throughout the job.
This is a string variable, of the form “hh:mm:ss”,
measuring the cutting time in hours, minutes and
seconds.
The variable is updated on every cutting block (linear,
circular, cycle) reflecting the accumulated feed time of
the current tool from the beginning of the job.
The variable is also updated at the end of each
procedure (END OF PROC block).
TOOL_PROCS 6 The number of procedures in which the tool is used
throughout the job.
TOOL_PROCS_LIST 0 A string containing a list of the procedures in which the
tool is used. The procedure unique ID names are
used. If too many procedures exist, the list is truncated
at 253 characters, and is appended with “…”.
CimatronE 10.0 GPP2 User Guide ⎪172

System Variable Default Use and Comments

Format
TOOL_MIN_CLR_LEN 1 Shows the maximum “minimum clear length”
calculated at all the procedures in which the tool is
used. This can be used to decide if a shorter tool may
be used.
A value of -1 indicates that the data is not available.
TOOL_MIN_CLR_LEN_ 0 Set to “Yes” or “No”.
CHECK The variable is set to “Yes” if the minimum clear length
is greater than zero in all the tool procedures. That
means that the minimum clear length was checked in
all the procedures in which the tool is used, and that
value can be trusted for decisions regarding the
needed tool length.
Otherwise, the variable is set to “No”.
TOOL_COMP_2D3D 0 Set to “Yes” or “No”.
The variable is set to “Yes” if the tool is used (at least
once) in a procedure that applies 2D or 3D cutter
compensation. Otherwise, the it is set to “No”.
CimatronE 10.0 GPP2 User Guide ⎪173

4.10 Toolpath Variables

These variables contain the toolpath information. They are set on each toolpath block just before it is
processed by the EX2 program.

4.10.1.1 Block: BEGINNING OF CONNECT

CON_CONTEXT 6 The context of the current connection. May be one of the
following predefined values:
CON_AFTER_TOOL after a tool change
CON_PROC at the beginning of a procedure
CON_CYCLE between drill cycles
CON_5X_SWAP switching 5X solutions
CON_SCENARIO 0 The name of the scenario selected by GPP2 for this
connection. GPP2 sets the variable to one of the
following strings:
“short” for short connections
“long” for long connections
“tool-change” for connections after a tool change
“through-safe” for connections that should go
through the safe position.
The EX2 program may change this variable and select
another scenario name.
CON_ROTATION_A 2 The absolute value, in degrees, of the alpha axis rotation
during the current connection.
CON_ROTATION_B 2 The absolute value, in degrees, of the beta axis rotation
during the current connection.
CON_DISTANCE 1 The distance, in the REF UCS, from the connection start
point to its target point.
This number is not correct in connections after a tool
change, since the start point is not truly known.
CON_TO_CYCLE 6 Set to TRUE_ if the cutting operation after the connection
is a drill cycle, FALSE_ if it is a milling operation.
CON_AFTR_RECONFIG 6 Set to TRUE_ if this connection takes place immediately
after a machine reconfiguration process. It is FALSE_ in
all other cases.
X_CONNECT 1 Target connection point, in the posting UCS coordinate
Y_CONNECT system.
Z_CONNECT
A_CONNECT 2 Connection target angles for “alpha” and “beta” rotary
B_CONNECT axes (4/5 axes machines).
CimatronE 10.0 GPP2 User Guide ⎪174

4.10.1.2 Block: BEGINNING OF PROC

ANGLE_INCR 2 All relevant procedures - Parallel - angle increment.
Procedures: CLEANUP, SRFPKT, ZCUT
AXIS_NUM 6 Number of axes in procedure. This value replaces the AXIS
CHANGE block that used to be generated before each
procedure.
BET_LAYERS 6 Between layers = 1
Not between layers = 0
Procedures: WCUT.
BY_SCALLOP 6 BY SCALLOP = 1
BY 2D SIDE STEP = 0
Procedures: (Parallel cut): CLEANUP, SRFPKT, WCUT
(between layers).
CHECK_OFST 1 Offset of the check surfaces.
Procedures: CLEANUP, 3D_STEP, PLUNGE_MILL,
SRFPKT, SRFPRF, SURCLR, SURMILL, WCUT, ZCUT.
CHECK_OFST2...6 1 Offset for check surface #2 to check surface #6.
CHECK_TOL 1 Tolerance of the check surfaces.
Procedures: CLEANUP, 3D_STEP, PLUNGE_MILL,
SRFPKT, SRFPRF, SURCLR, SURMILL, WCUT, ZCUT.
CLEAR_PLN 1 The clearance height value.
CONT_OFST 1 Offset of the 1st contour.
Procedures: CLEANUP, 3D_STEP, POCKET, PROFILE,
PLUNGE_MILL, SRFPKT, SRFPRF, WCUT, ZCUT.
CONT_TOL 1 Tolerance of the contours.
Procedures: ROUGH_5X, CLEANUP, CURVE_MX,
POCKET, PROFILE, RULED_MX, SRFPKT, SRFPRF,
SURCLR, WCUT, ZCUT.
DEL_Z_UP 1 The DEL Z UP parameter.
Procedures: CLEANUP, CURVE_MX, 3D_STEP,
POCKET, PROFILE, RULED_MX, SRFPKT, SRFPRF,
SURCLR, SURMILL, WCUT, ZCUT.
DIAM_OFFS 1 The value of the Diameter Offset in Pocket and Profile
within Automated Drill.
DOWN_STEP 1 The procedure DOWN STEP value.
Procedures: CLEANUP, CURVE_MX, POCKET,
PROFILE, PLUNGE_MILL, RULED_MX, WCUT, ZCUT.
CimatronE 10.0 GPP2 User Guide ⎪175

END_ANGLE 2 All relevant procedures - Parallel - end angle.

Procedures: CLEANUP, SRFPKT, ZCUT.
LEAD_ANGLE 2 All relevant procedures - leading angle.
Procedures: SURCLR, SURMILL.
MCH_COOL 0 The machine coolant code for this procedure. This value
replaces the COOLANT block that used to be generated at
the beginning of a procedure.
MCH_FEED 3 The initial feed rate for the procedure. This value replaces
the FEED block that used to be generated at the beginning
of a procedure.
MCH_MODE 6 Describes the machining mode of a certain procedure.
0 – Mill, 1 – Drill, 2 – Special (automated drill with thread
milling cycle).
MILL_ANGLE 2 All relevant procedures - Parallel - milling angle.
Procedures: (only when Radial cut is not used):
CLEANUP, PLUNGE_MILL, SRFPKT, WCUT, ZCUT.
MIN_CLRLN 1 <value> = Minimum Clear Length (if relevant)
-1 = Applicable, but not calculated (for any reason). For
example, if the following values are set for the parameter
Limit Machining by Shank / Holder: Yes, No. Ignore
Holder, or No. Calc. Minimum - but the procedure is not
updated (ex: stock).
-2 = Not supported.
Procedures:Rough Parallel, Rough Spiral, ReRough,
Finish Mill All, Finish Mill By Limit Angle, Finish Horiz.
Planar Areas, Cleanup and Pencil.
MOVMNT_NUM 6 Number of movement blocks in the current procedure (not
correct while using subroutines, quadrants and linear
approximation to circles).
NUM_CONT 6 All Relevant Procedures - Number of contours.
NUM_CSRF 6 All Relevant Procedures - Number of Check surfaces. This
considers all groups of check surfaces.
NUM_LAYERS 6 Number of layers in the procedures. Mill motions only. 0 =
no layers.
NUM_P2SRF 6 All Relevant Procedures - Number of Part2 surfaces.
NUM_P3…6SRF 6 All Relevant Procedures - Number of Part3 to Part6
surfaces.
CimatronE 10.0 GPP2 User Guide ⎪176

NUM_PASS 6 Num of passes.

Procedures: ROUGH_5X, CLEANUP, CURVE_MX,
RULED_MX, SURCLR, SURMILL.
NUM_PSRF 6 All Relevant Procedures - Number of Part surfaces.
NUM_SPRING 6 Number of spring passes.
ORBIT_OFS 1 Orbit Offset.
Procedures: WCUT.
OSIDE_STEP 1 Between layers / Side Step.
Procedures: WCUT.
PART_OFST 1 Part Surface Offset.
Procedures: ROUGH_5X, CLEANUP, CURVE_MX,
3D_STEP, PLUNGE_MILL, RULED_MX, SRFPKT,
SRFPRF, SURCLR, SURMILL, WCUT, ZCUT.
PART_OFST2...6 1 Offset for part surface #2 to part surface #6.
PART_TOL 1 Part Surface Tolerance.
Procedures: ROUGH_5X, CLEANUP, 3D_STEP,
PLUNGE_MILL, RULED_MX, SRFPKT, SRFPRF,
SURCLR, SURMILL, WCUT, ZCUT.
PROC_UCSNAME 0 Procedure UCS name.
Note: When posting Transformation Procedures, UCSs are
automatically created when the transformation involves an
orientation change. These UCSs are given system
generated names using the following convention:
U_1, U_2, etc., with each new UCS name incrementing by
one.
PROC_COMMENT 0 Procedure comment.
PROC_IS_SOURCE 6 The variable is TRUE_ if the procedure is used later as a
source to a transformation procedure.
PROC_IS_TRANSF 6 The variable is TRUE_ if the procedure is as a result of a
transformation.
PROC_LONGNAME 0 The procedure “long name” as it appears in CimatronE
PROC_NAME 0 The name of the current procedure (e.g. PROFILE, DRILL).
PROC_NUM 6 The procedure number created by the system when the
procedure was first defined (This number cannot be
modified by the user. In each TOOL PATH the PROC_NUM
is re-initialized).
PROC_SCLP 1 All Relevant Procedures - Scallop.
Procedures: CLEANUP, CURVE_MX, RULED_MX,
SRFPKT, SURCLR, SURMILL, 3D_STEP.
CimatronE 10.0 GPP2 User Guide ⎪177

PROC_TRJ 6 All Relevant Procedures - Parallel/Spiral/Radial.

Procedures: POCKET, CLEANUP, PLUNGE_MILL,
SRFPKT, WCUT, ZCUT.
PROC_TYPE 6 The type of the current procedure. It may get one of the
following values: PROC_UNKNOWN, PROC_MILL,
PROC_DRILL, PROC_5X_CONNECT, PROC_AUTODRILL.
PROC_UID 6 Unique procedure number (unique ID in the whole file).
PUP_BOOL1...6 6 Procedure user-defined parameters of Boolean type
PUP_INT1...6 6 Procedure user-defined parameters of Integer type
PUP_COMBO1...6 6 Procedure user-defined parameters of Combo-box type
PUP_FLOAT1...6 18 Procedure user-defined parameters of Float type. These
parameters have the default REAL format, and hence are
not affected by the unit factor value.
PUP_UDFLT1...6 1 Procedure user-defined parameters of Unit-dependent
Float type. These parameters have the default
COORDINATE format, and hence are multiplied by the unit
factor value.
RGH_FIN 6 Rough Only = 1
Rough + Finish = 2
Finish Only = 3
Procedures: CLEANUP, POCKET, SRFPKT, WCUT.
SHORT_NAME 0 Procedure short name.
SIDE_STEP 1 The procedure SIDE STEP value.
Procedures: CLEANUP, CURVE_MX, POCKET,
PLUNGE_MILL, SRFPKT, SURCLR, SURMILL, WCUT,
ZCUT, PROFILE, SRFPRF, 3D_STEP.
SPIN_DIR 0 Code for spindle rotation (CW, CCW or OFF) for the
procedure. This value replaces the SPIN block that used to
be generated at the beginning of a procedure.
SPIN_SPEED 4 Spindle rotation speed for the procedure. This value
replaces the SPIN block that used to be generated at the
beginning of a procedure.
START_ANGL 2 All relevant procedures - Parallel - start angle.
Procedures: (Radial cut): CLEANUP, SRFPKT, WCUT,
ZCUT.
STK_WIDTH 1 PROFILE - Stock Width.
Procedures: PROFILE, SRFPRF.
TILT_ANGLE 2 All relevant procedures - tilting angle.
Procedures: SURCLR, SURMILL.
CimatronE 10.0 GPP2 User Guide ⎪178

TRANSF_NUM 6 The number of transformations.

USE_CLEAR 6 The variable is TRUE_ if the procedure uses clearance
height for the connections.
UCS_FIRST_USE 6 Set to TRUE_ if this is the first time (procedure) that this
UCS (recognized by its name) is used.
Otherwise, it is set to FALSE_.
UNIBI_DIR 6 Unidir/Bidir.
Procedures: ROUGH_5X, CLEANUP, CURVE_MX,
POCKET, PROFILE, PLUNGE_MILL, RULED_MX,
SRFPKT, SRFPRF, SURCLR, SURMILL, WCUT, ZCUT.
WITH_STOCK 6 With/Without Stock.
Procedures: WCUT.
Z_DOWN 1 The procedure Z DOWN value.
Procedures: POCKET, PROFILE, PLUNGE_MILL, WCUT,
ZCUT.
Z_UP 1 The procedure Z UP value.
Procedures: POCKET, PROFILE, PLUNGE_MILL,
RULED_MX, WCUT, ZCUT.

Backward Compatibility Notes:

1. In GPP2, the PLATFORM_ variable was moved to the BEGINNING OF TAPE block.
2. In GPP2, the set of variables PRC_UCSN1 to PRC_UCSN13 have been replaced by one variable,
PROC_UCSNAME. This is possible since in GPP2 each variable holds up to 256 characters,
compared to 20 in old GPP.
3. In GPP2, the set of variables PRC_CMNT to PRC_CMNT3 have been replaced by one variable,
PROC_COMMENT.

4. In GPP2, the set of variables EL_PRNAME1 to EL_PRNAME1 (E Long name) have been replaced
by one variable, PROC_LONGNAME.
5. In GPP2, the *_START variables (X_START, etc.) are not used.
6. In GPP2, X_INTER, Y_INTER, and Z_INTER are not used.

4.10.1.3 Block: BEGINNING OF SUB

SUB_NUMBER 6 The subroutine serial number (same number that is
presented in SUBROUTINE CALL).
SUB_TRANSFORM 6 The variable is TRUE_ if the subroutine is the result of a
transformation.
CimatronE 10.0 GPP2 User Guide ⎪179

4.10.1.4 Block: BEGINNING OF TAPE

COMP_MODE 6 Compensation mode:
1- tool tip, 2- geometry.
DATE_SDD 6 Current date: day.
DATE_SMM 6 Current date: month.
DATE_SYY 6 Current date: year.
ETERNET_ID 0 Local computer Ethernet ID (the physical address of the
ethernet adapter – can be used for licensing).
EXT_POST 6 Internal / external post. In GPP2, always set “off”
FACTOR_ 18 The FACTOR variable in the DF2 file.
MACSYS_NAM 0 The MACSYS name.
NODE_ID 0 The workstation Node_ID.
NUM_ORIGS 6 Number of origins (coordinate systems) used in all the
toolpaths.
PART_NAME 0 The name of the part (full name, up to 256 characters)
PART_PATH 0 Path name – just the path, without the name itself (full path,
up to 256 characters)
PFM_UNITS 0 The PFM units.
PLATFORM_ 0 The platform in use (in GPP2, this is always “NT”)
POST_NAME 0 Current Post Processor name.
REF_NAME 0 Name of the reference UCS (by default – MACSYS)
TIME_SHH 0 Current time: hour.
TIME_SMM 0 Current time: minute.
TIME_SSS 0 Current time: second.
USER_NAME 0 The logged-in user name
X_HOME 1 Home position, in the reference coordinate system.
Y_HOME
Z_HOME
X_MACH 1 The machine physical zero point as was input during the
Y_MACH CimatronE PP interaction, presented in the reference
Z_MACH coordinate system.
CimatronE 10.0 GPP2 User Guide ⎪180

Backward Compatibility Notes:

1. In GPP2, the IMS_PRJN1 to IMS_PRJN13 variables are not used.
2. In GPP2, the CIRC_APPRX variable is not used.
3. In GPP2, the *_ORIGIN (X_ORIGIN, etc.) variables are not available in the BEGINNING OF
TAPE block. They are only presented in the ORIGIN CHANGE blocks. The same is true for
CURR_ORIG.

4. In GPP2, the variables PART_NAM2 to PART_NAM13 have been deleted. The PART_NAME
variable is used to hold the full part name (up to 256 characters).
5. In GPP2, the variables PART_PATH2 to PART_PAT13 have been deleted. The PART_PATH
variable is used to hold the full path name (up to 256 characters).
6. In GPP2, the variables LAST_TOOL and FIRST_TOOL have been replaced by functions that
provide information about any parameter of the first or last tool. See GPP2 Language
Reference Manual for details.

4.10.1.5 Block: BEGINNING OF TLPATH

TP_COMMENT 0 Toolpath comment
TP_LONG_NAME 0 Full toolpath name. This contains the full (long) name of the
toolpath (256 characters).
TP_NAME 0 Toolpath name.
TP_TYPE 0 Toolpath main type: MILL, LATHE, WIRE, PUNCH.
TP1_TYPE 0 Toolpath sub-type.
TP_UCSNAME 0 Toolpath UCS name.
TP_UCSNUM 6 Number of the Toolpath UCS.
TPX_ORIG 1 Zero point of the TP UCS, in the REF coordinate system.
TPY_ORIG
TPZ_ORIG
TPI_ORIG 18 Orientation (I, J, K vector) of the Z axis of the TP UCS, in
TPJ_ORIG the REF coordinate system.
TPK_ORIG
TPIX_ORIG 18 Orientation (I, J, K vector) of the X axis of the TP UCS, in
TPJX_ORIG the REF coordinate system.
TPKX_ORIG

Backward Compatibility Notes:

1. In GPP2, the TPNM_LOWER variable is not used (and not needed – string functions allow
conversion of strings to lowercase).
CimatronE 10.0 GPP2 User Guide ⎪181

4.10.1.6 Block: CIRCULAR MOTION

ARC_ANG 2 Delta angle in degrees. Positive number indicates Counter-
Clockwise (CCW) motion; negative number indicates
Clockwise (CW) motion.
ARC_PLN 6 Arc plane, presented in the posting UCS (not necessarily
the same as in the procedure UCS).
X-Y Plane = 1
Z-X Plane = 2
Y-Z Plane = 3
Other (non-major) Plane = 0
CIRC_MOV 0 Circular movement code, as set in the DF2 file (Clockwise
or Counter Clockwise)
CIRC_TOL 1 Controls tolerance of linear approximation of arcs. Initial
value is taken from the DF2 file parameter. It can be
modified later in the EX2 program.
END_ANG 2 End angle in degrees, between -180 and 360. (see detailed
discussion on circular motion).
MCH_FEED 3 Machine feed rate – will be set if it needs to be modified in
the circular motion.
MOTION_CODE 0 This variable can be used to replace CIRC_MOV. It is
assigned a value each time LIN_MOV, CIRC_MOV or
CYC_CODE are assigned a value.
RADIUS_ 1 Arc radius
ST_ANG 2 Start angle in degrees, between -180 and 360. (see
detailed discussion on circular motion).
X_CENTER 1 Arc center point in the posting coordinate system.
Y_CENTER
Z_CENTER
X_CURPOS 1 Arc end point in the posting coordinate system. In GPP2,
Y_CURPOS the standard X/Y/Z_CURPOS variables are used instead of
Z_CURPOS X/Y/Z_ENDPT.
I_CURPOS 18 Tool orientation vector for the circular motion, in the posting
J_CURPOS UCS coordinate system. Currently, this is always the tool
K_CURPOS axis direction in all circular motions.
CimatronE 10.0 GPP2 User Guide ⎪182

ARC_HELICAL 6 Set to TRUE_ if the arc is helical (with a variable “Z”

component). Such arcs may be created when linear
motions are converted to arcs (arc fitting) by GPP2.
Otherwise, it is set to FALSE_.
TOOL_FEED_TIME 0 The total cutting time of the current tool until (and including)
this block. This is a string variable, of the form “hh:mm:ss”,
measuring the cutting time in hours, minutes and seconds.
MOTION_LENGTH 1 Real length of motion, as measured along the arc on the
work piece itself – useful for Inverse Time Feed Rate mode.
INVERSE_TIME_FEED 3 The feed rate for the Inverse Time mode. This feed rate is
calculated by dividing the original feed rate (as expressed
in the MCH_FEED variable) by the arc motion length (as
expressed in the MOTION_LENGTH variable).

Backward Compatibility Notes:

1. In GPP2, ABS_ANG is not used. The END_ANG variable is always equal to the sum of ST_ANG
and ARC_ANG.

4.10.1.7 Block: CUTTER COMPENSATION

CUTCOM_OFF 0 Cutter compensation “Off” machine code – set in the DF2
file, “Cutter Compensation” section.
CUTCOM_ON 0 Cutter compensation “Left” or “Right” machine code - set in
the DF2 file, “Cutter Compensation” section.

Notes:
1. Each time this block is called, either CUTCOM_OFF is set “on” and CUTCOM_ON is set “off” or vice
versa. These two parameters work in conjunction with each other – exactly one of them is set
“on” and indicates the nature of the block (off or on) as well as the machine code that should
be output.
CimatronE 10.0 GPP2 User Guide ⎪183

4.10.1.8 Block: CYCLE

CYC_CLEAR 1 Cycle clear – distance of the clearance plane from the drill
point, measured along the tool axis.
CYC_CODE 0 Cycle machine code - set in the DF2 file, “Canned Cycles”
section.
CYC_DEPTH 1 Cycle depth value.
CYC_DWELL 5 Cycle dwell time in hundredths of a second.
CYC_DZINIT 1 The DRILL procedure DEL INIT value – distance of the init
plane from the drill point, measured along the tool axis.
CYC_MANUAL 6 This variable is set “on” if the drill cycle is on a plane that
cannot be handled by the machine, based on the relevant
DF2 file parameter (“Output Cycles by Planes”). If the
canned drill cycle can be handled by the machine, the
variable is set “off”.
CYC_PECK 1 Cycle PECK value.
CYC_REDUC 1 Cycle DECREASE value.
CYC_RETR 0 Cycle retract code – set in the DF2 file, “Canned Cycles”
section. The retract type determines the tool retract point
after the cycle – to Clearance or Init plane.
CYC_TIMES 6 Number of times to peck.
CYC_XSHFT 1 Cycle shift along the X axis.
CYC_YSHFT 1 Cycle shift along the Y axis.
CURRENT_INIT 1 The current height above the drill point, along the tool axis,
to which the tool would retract after the cycle. If
CYC_RETR is "Init", it is equal to the current init height
above this hole. If CYC_RETR is "Clear", it is equal to the
clear height. If the clear height is larger than the init height,
it will be equal to the clear height.
CimatronE 10.0 GPP2 User Guide ⎪184

CYCLE_1...12 6 These 12 variables work in the following way: one (and

only one) of them is set “on” while all other are set “off”.
They correspond to the 12 canned cycle types as follows:
CYCLE_1: High speed peck
CYCLE_2: Left hand tapping
CYCLE_3: Fine boring
CYCLE_4: Spot drill
CYCLE_5: Counter boring
CYCLE_6: Deep hole peck
CYCLE_7: Tapping
CYCLE_8: Boring
CYCLE_9: Boring + spindle stop
CYCLE_10: Back boring
CYCLE_10: Boring + dwell + manual out
CYCLE_12: Code for boring + dwell + feed
Note: in the CYCLE OFF block, all 12 variables are set “off”.
MCH_FEED 3 Machine feed rate – will be set if it needs to be modified in
the cycle block.
MOTION_CODE 0 This variable can be used to replace CYC_CODE. It is
assigned a value each time LIN_MOV, CIRC_MOV or
CYC_CODE are assigned a value.
X_CURPOS 1 The drill cycle point, in the posting UCS coordinate system.
Y_CURPOS
Z_CURPOS
A_CURPOS 2 Target angles for “alpha” and “beta” rotary axes (4/5 axes
B_CURPOS machines)
X_CYC_DZINIT 1 The “init” point, located CYC_DZINIT distance above the
Y_CYC_DZINIT drill point, where “above” is measured along the tool axis.
Z_CYC_DZINIT
X_CYC_CLEAR 1 The “clearance” point, located CYC_CLEAR distance above
Y_CYC_CLEAR the drill point, where “above” is measured along the tool
Z_CYC_CLEAR axis.

X_CYC_DEPTH 1 The “depth” point, located CYC_DEPTH distance below the

Y_CYC_DEPTH drill point, where “below” is measured along the tool axis.
Z_CYC_DEPTH
CimatronE 10.0 GPP2 User Guide ⎪185

CYC_NEXT 6 Indicates the type and nature of the next cycle bloc. It may
get one of the following values:
CYC_OFF: this is the last cycle in a series, and the next
cycle block is a cycle “off”.
CYC_SAME: the next cycle has the same orientation as the
current cycle.
CYC_ROTATED: the next cycle has a different orientation
than the current cycle.
CYC_NEXT_CONNECT 6 Indicates if a connection is needed for the next cycle. GPP2
will set it to TRUE_ or FALSE_ based on the relevant DF2
parameters.
During the CYCLE block, the EX2 program may override the
value of this variable, forcing GPP2 to have or avoid a
connection after the cycle.
ZCYC_NEXT_INIT 1 The “init” Z value of the next cycle. This variable is only
meaningful if the next cycle is in the same orientation as
the current cycle. See CYC_NEXT.
ZCYC_NEXT_CLEAR 1 The “clearance” Z value of the next cycle. This variable is
only meaningful if the next cycle is in the same orientation
as the current cycle. See CYC_NEXT.
ZCYC_INIT_FIRST 1 The “init” Z value of the first cycle in a series (the “on” or
“toinit” cycle.
ZCYC_END 1 The tool Z value after the cycle. GPP2 initializes that
variable according to the retract code (to the init or
clearance height).
During the CYCLE block, the EX2 program can change the
value of the variable, telling GPP2 where the tool really
ended, based on the specific machine behavior.
TOOL_FEED_TIME 0 The total cutting time of the current tool until (and including)
this block. This is a string variable, of the form “hh:mm:ss”,
measuring the cutting time in hours, minutes and seconds.
CYCLE_SUB 6 If the value of this parameter is 14, this means that it is a
thread milling cycle, otherwise it is one if the legacy cycles.
TRD_APRFED 18 Relevant only to thread cycle (CYCLE_SUB is 14).
Approach Feed, expressed as percentage (%) of normal
feed rate.
Real, non-unit-dependent.
CimatronE 10.0 GPP2 User Guide ⎪186

TRD_CLIMB 6 Cut direction, defined as follows:

1 : Bottom-up
2 : Top-down
3 : Top-down with up-cut – this is a special mode only
applicable when “threads-per-step” > 1. While the overall
process is top-down, each 360-degree helix is done from
the bottom up.
TRD_NOMD 1 Relevant only for thread cycle (CYCLE_SUB is 14) Thread
nominal diameter. For tapered threads, this is taken as the
diameter at the drill point Z level.
TRD_PITCH 1 Relevant only for thread cycle (CYCLE_SUB is 14) Thread
pitch (Z difference between threads).
A positive value indicates a right-hand thread.
A negative value indicates a left-hand thread.
TRD_STEP 6 Relevant only for thread cycle (CYCLE_SUB is 14)
Threads per Step.
The number of thread revolutions by which the cutter is
shifted along its axis.
Threads per step is defined as an Integer ≥ 0.
0 = One 360° helical path to the depth of the thread.
1 = a continuous helical path over the entire length of the
thread.
> 1 = several helical paths with approach and departure;
between them, the machine controller shifts the cutter
along its axis by the Thread per Step value, multiplied by
the pitch.
TRD_STRANG 2 Relevant only for thread cycle (CYCLE_SUB is 14)
Thread start angle (where the helical motion starts, after
the approach). Value of 0 indicates the X axis of the GPP2
output UCS.
TRD_INTERNAL 6 Set to TRUE_ for internal threads, FALSE_ for external.
In GPP, this variable is named: TRD_INTERN.
TRD_TAPERED_ANG 2 Tapered thread angle. Angle is always positive, and taper
direction (in or out) is determined by the internal/external
parameter. The nominal diameter is always assumed to be
at the top (at the drill point height).
In GPP, this variable is named: TRD_TPRANG.
CimatronE 10.0 GPP2 User Guide ⎪187

TRD_STOCK_WIDTH 1 Material stock width. GPP2 will make several passes, each
one deeper into the material, and each one closer to the
nominal thread size by the side step.
For internal threads, GPP2 will start with a diameter smaller
than the nominal, and will enlarge it with each pass. For
external threads, it does the opposite.
In GPP, this variable is named: TRD_STKWID.
TRD_SIDE_STEP 1 The side step used between two passes, except possibly
the last pass. Only relevant if the stock width is not zero.
In GPP, this variable is named: TRD_SIDEST.
TRD_APR_RADIUS 1 Thread helix requested approach radius. The actual radius
may be smaller if there is no room between the tool and the
hole (in internal threads only).
Approach radius of 0.0 indicated normal approach.
In GPP, this variable is named: TRD_APRRAD.
TRD_CUTTER_COMP 6 Flag indicating cutter compensation mode:
0 – off.
1 – on, with toolpath created for the tooltip.
2 – on, with toolpath created for the geometry – this mode
is only relevant to CimatronE10 and beyond!
In GPP, this variable is named: TRD_CUTCOM.
TRD_USE_ARCS 6 If TRUE_, GPP2 will use helical (360-degree) arcs for the
thread helix. If FALSE_, all arcs will be broken to linear
motions.
Default is TRUE_ if the PP uses “linear arc fitting” (as
defined in the DF2 file) and helical arcs are allowed there
(see variable ARCFIT_HELICAL). Otherwise, the default of
TRD_USE_ARCS is set to FALSE_.
TRD_LIN_TOL 1 If arcs are broken to linear motions, this variable defines
the tolerance (maximum distance between the perfect arc
and the linear lines).
Default 0.01 mm (0.0004 inch).
In GPP, this variable is named: TRD_LINTOL.
TRD_FASTFED_PERCENT 18 Feed rate of the “fast” motions inside the cycle (like moving
up to do the next pass). Expressed as percentage of
normal feed.
CimatronE 10.0 GPP2 User Guide ⎪188

TRD_HELICAL_APPROACH 6 If TRUE_, GPP2 will apply a helical tangential approach,

meaning the Z value will gradually change as the tool
approaches the first helix point. If FALSE_, the approach is
horizontal only (and will create a small mark, as it coincides
with the helical groove).
Default: TRUE_.
In GPP, this variable is named: TRD_HELAPP.
TRD_HELICAL_RETRACT 6 If TRUE_, GPP2 will apply a helical tangential retract,
meaning the Z value will gradually change as the tool
retracts. If FALSE_, the retract is horizontal only (and will
create a small mark, as it coincides with the helical groove).
Default: TRUE_.
In GPP, this variable is named: TRD_HELRET.
TRD_MAX_TOOL_DIAM 18 Maximum allowed tool diameter, expressed in percents
(%), relative to the thread diameter (taking into account
stock size and tapered threads). If the ratio between the
tool diameter and the thread diameter exceeds this value,
GPP2 stops with an error message.
Default: 90%.
TRD_BREAK_MOTIONS 6 The system flag used by the EX2 program in order to tell
GPP2 that it requests the current cycle to be treated as
thread-mill and broken down to multiple milling motions.
Can only be used from within a CYCLE block.
TRD_BOTTOM_UP_SPECIAL 6 This system flag can be used by the EX2 program to
request the special Bottom-up mode (mode 3 of
TRD_CLIMB). If set to TRUE__, and “Bottom-up” is selected
in the procedure, the special mode is applied.

4.10.1.9 Block: END OF CONNECT

No block-specific system variables.

4.10.1.10 Block: END OF FILE

No block-specific system variables.

CimatronE 10.0 GPP2 User Guide ⎪189

4.10.1.11 Block: END OF PROC

PROC_CNT 6 Procedure counter (1, 2, 3, etc.)
FEED_TIME 0 Procedure feed (cutting) time, formatted in hours, minutes
and seconds (e.g., “00:15:45” means 15 minutes and 45
seconds).
AIR_TIME 0 Procedure air (rapid) motions time, formatted in hours,
minutes and seconds.
TOTAL_TIME 0 Procedure total time, formatted in hours, minutes and
seconds.
TOOL_FEED_TIME 0 The total cutting time of the current tool until (and including)
this block. This is a string variable, of the form “hh:mm:ss”,
measuring the cutting time in hours, minutes and seconds.
TOOL_CNT 6 The sequential number of the tool used in the procedure
(tools are counted in the order they are first used).
X_MIN 1 Procedure minimum and maximum X values, in the REF
X_MAX coordinate system.
Y_MIN 1 Procedure minimum and maximum Y values, in the REF
Y_MAX coordinate system.
Z_MIN 1 Procedure minimum and maximum Z values, in the REF
Z_MAX coordinate system.
A_MIN 1 Procedure minimum and maximum A (alpha) axis values
A_MAX (degrees).
B_MIN 1 Procedure minimum and maximum B (beta) axis values
B_MAX (degrees).
PROC_X_MIN 1 Procedure minimum and maximum X values, in the
PROC_X_MAX PROCEDURE coordinate system.
PROC_Y_MIN 1 Procedure minimum and maximum Y values, in the
PROC_Y_MAX PROCEDURE coordinate system.
PROC_Z_MIN 1 Procedure minimum and maximum Z values, in the
PROC_Z_MAX PROCEDURE coordinate system.

4.10.1.12 Block: END OF SUB

No block-specific system variables.

CimatronE 10.0 GPP2 User Guide ⎪190

4.10.1.13 Block: END OF TAPE

PROC_CNT 6 Total number of procedures in whole run
TOOL_CNT 6 Total number of tools used in whole run (each tool counted
once even if it is used several times).
TOOL_CHANGES 6 Total number of tool changes in whole run.
FEED_TIME 0 Whole run feed (cutting) time, formatted in hours, minutes
and seconds (e.g., “00:15:45” means 15 minutes and 45
seconds).
AIR_TIME 0 Whole run air (rapid) motions time, formatted in hours,
minutes and seconds.
TOTAL_TIME 0 Whole run total time, formatted in hours, minutes and
seconds.
X_MIN 1 Whole run minimum and maximum X values. This can be
X_MAX calculated:
- In the REF coordinate system / relative to the
machine Zero
- For tool tip / spindle tip
based on the setting of the following parameters:
M5_USE_MACH; MINMAX_VS_MACH; MINMAX_SPINDLE.
Y_MIN 1 Whole run minimum and maximum Y values. This can be
Y_MAX calculated:
- In the REF coordinate system / relative to the
machine Zero
- For tool tip / spindle tip
based on the setting of the following parameters:
M5_USE_MACH; MINMAX_VS_MACH; MINMAX_SPINDLE.
Z_MIN 1 Whole run minimum and maximum Z values. This can be
Z_MAX calculated:
- In the REF coordinate system / relative to the
machine Zero
- For tool tip / spindle tip
based on the setting of the following parameters:
M5_USE_MACH; MINMAX_VS_MACH; MINMAX_SPINDLE.
A_MIN 1 Whole run minimum and maximum A (alpha) axis values
A_MAX (degrees).
B_MIN 1 Whole run minimum and maximum B (beta) axis values
B_MAX (degrees).
CimatronE 10.0 GPP2 User Guide ⎪191

4.10.1.14 Block: END OF TOOLPATH

No block-specific system variables.

4.10.1.15 Block: HOME SHIFT

X_SHIFT 1 The relative (incremental) shift from the current home
Y_SHIFT position in the X Y and Z axes.
Z_SHIFT
X_TOTAL_SHIFT 1 The absolute shift from the original home position in the X,
Y_TOTAL_SHIFT Y and Z axes.
Z_TOTAL_SHIFT
TRANSF_SHIFT_BACK 6 The variable is TRUE_ if this is a "shift back" (after the
subroutine call).

4.10.1.16 Block: INSERT WITH (SEQUENCING)

INS_STR 0 Inserted string

4.10.1.17 Block: INSERT WITHOUT (SEQUENCING)

INS_STR 0 Inserted string

4.10.1.18 Block: LINEAR MOTION

COMP_3X 6 3-D cutter compensation.
LIN_MOV 0 Linear movement code – set in the DF2 file, “Linear Motion”
section.
LINE_ANG 2 Linear motion line angle, as projected on the posting UCS
XY plane.
LINE_LENG 1 Length of the linear motion.
MCH_FEED 3 Machine feed rate – will be set if it needs to be modified in
the cycle block.
MOTION_CODE 0 This variable can be used to replace LIN_MOV. It is
assigned a value each time LIN_MOV, CIRC_MOV or
CYC_CODE are assigned a value.
SRF_NORX 18 X, Y, and Z components of the surfaces normal.
SRF_NORY
SRF_NORZ
X_CURPOS 1 Target tool point position (at the end of the motion), in the
Y_CURPOS posting UCS coordinate system.
Z_CURPOS
CimatronE 10.0 GPP2 User Guide ⎪192

A_CURPOS 2 Target angles for “alpha” and “beta” rotary axes (4/5 axes
B_CURPOS machines)
I_CURPOS 18 Target tool axis orientation (at the end of the motion), in the
J_CURPOS posting UCS coordinate system. Note – these variables
K_CURPOS replace the old GPP I/J/K_COORD.
TOOL_FEED_TIME 0 The total cutting time of the current tool until (and including)
this block. This is a string variable, of the form “hh:mm:ss”,
measuring the cutting time in hours, minutes and seconds.
MOTION_LENGTH 1 Real length of motion, as measured on the work piece itself
– useful for Inverse Time Feed Rate mode.
INVERSE_TIME_FEED 3 The feed rate for the Inverse Time mode. This feed rate is
calculated by dividing the original feed rate (as expressed
in the MCH_FEED variable) by the motion length (as
expressed in the MOTION_LENGTH variable).

Backward Compatibility Notes:

1. In GPP2, the MI_COORD, MJ_COORD, and MK_COORD variables are not used.

4.10.1.19 Block: MACHINE CONTROL

CONTROL_NUM_1 6 First argument defined in the scenario action (numeric)
CONTROL_NUM_2 6 Second argument defined in the scenario action (numeric)
CONTROL_STRING 0 Third argument defined in the scenario action (string)

4.10.1.20 Block: MESSAGE

MESS_STR 0 Message string

4.10.1.21 Block: MOVE TO SAFE

ACTION_SAFE_AXES 0 First argument defined in the scenario action, defining the
axes used in the motion (e.g., “Z”, “XY” or “XYZ”).

4.10.1.22 Block: ORIGIN CHANGE

CURR_ORIG 6 Number of origin on NC controller to which the current
origin corresponds.
X_ORIGIN 1 Zero point of the new ORIGIN (procedure) UCS, in the REF
Y_ORIGIN coordinate system
Z_ORIGIN
I_ORIGIN 18 Orientation (I, J, K vector) of the Z axis the new ORIGIN
J_ORIGIN (procedure) UCS, in the REF coordinate system
K_ORIGIN
CimatronE 10.0 GPP2 User Guide ⎪193

IX_ORIG 18 Orientation (I, J, K vector) of the X axis the new ORIGIN

JX_ORIG (procedure) UCS, in the REF coordinate system
KX_ORIG
X_REF Set by Variables to describe the zero point of a new REF_UCS, in
Y_REF GPP2 at the current REF coordinate system.
Z_REF run-time

I_REF Set by Variables to describe the Orientation (I, J, K vector) of the Z

J_REF GPP2 at axis of a new REF_UCS, in the current REF coordinate
K_REF run-time system.

IX_REF Set by Variables to describe the Orientation (I, J, K vector) of the X

JX_REF GPP2 at axis of a new REF_UCS, in the current REF coordinate
KX_REF run-time system.

SET_REF_BY_VARS FALSE_ When set to TRUE_ in the ORIGIN CHANGE block, GPP2
(format 6) Set by will modify the REF UCS to be according to the values set
GPP2 at in the above *_REF variables.
run-time
(in
response
to the
EX2
program
setting it
first)
UCS_COUNT 6 Counts all UCS's, including new ones created by
transformations.

Backward Compatibility Notes:

1. In GPP2, the FRST_XORIG, FRST_YORIG, and FRST_ZORIG variables are not used.
2. In GPP2, the following variables are not used: MX_ORIGIN, MY_ORIGIN, MZ_ORIGIN,
MI_ORIGIN, MJ_ORIGIN, MK_ORIGIN, MIX_ORIG, MJX_ORIG, MKX_ORIG,
X_MSYSORGN, Y_MSYSORGN, Z_MSYSORGN

4.10.1.23 Block: POST SCRIPT

No block-specific system variables.

4.10.1.24 Block: PROC FIRST POINT

No block-specific system variables.

CimatronE 10.0 GPP2 User Guide ⎪194

4.10.1.25 Block: PROC TRANS

PROC_UCSNAME 0 Transformation procedure UCS name.
Note: When posting Transformation Procedures, UCSs are
automatically created when the transformation involves an
orientation change. These UCSs are given system
generated names using the following convention:
U_1, U_2, etc., with each new UCS name incrementing by
one.
PROC_COMMENT 0 Transformation procedure comment.
PROC_LONGNAME 0 The transformation procedure “long name” as it appears in
CimatronE.
PROC_NAME 0 The name of the transformation procedure (e.g.
TRANSFORMATION).
TRANS_TYPE 6 The type of the transformation. May get the values:
TR_SIMPLE, TR_ARRAY_PRIME_X, TR_ARRAY_PRIME_Y.
X_TRANS 1 Offset of the transformation UCS.
Y_TRANS
Z_TRANS
I_TRANS 1 Z axis orientation of the transformation UCS.
J_TRANS
K_TRANS
IX_TRANS 1 X axis orientation of the transformation UCS.
JX_TRANS
KX_TRANS
X_DELTA 1 For array transformations - delta in the X direction (as
entered by the user).
X_CNT 1 The number of reoccurrences in the X direction.
Y_DELTA 1 For array transformations - delta in the Y direction (as
entered by the user).
Y_CNT 1 The number of reoccurrences in the Y direction.

Note: All coordinates and orientation vectors are given in accordance to the GPP orientation definition
(e.g., MACSYS) and with respect to the model UCS zero point (like regular procedure motions).
CimatronE 10.0 GPP2 User Guide ⎪195

4.10.1.26 Block: RECONFIG MACHINE

No block-specific system variables.

4.10.1.27 Block: RESET AXIS

A_CURPOS 2 The last “alpha” angle, which needs to be reset (if this is a
reset of the alpha axis).
B_CURPOS 2 The last “beta” angle, which needs to be reset (if this is a
reset of the beta axis).

4.10.1.28 Block: SET UCS

CONTROL_NUM_1 6 First argument defined in the scenario action (numeric)
CONTROL_NUM_2 6 Second argument defined in the scenario action (numeric)
CONTROL_STRING 0 Third argument defined in the scenario action (string)

4.10.1.29 Block: START PROC

No block-specific system variables.

4.10.1.30 Block: STARTUP

M5_M128_RELOCATED 6 If TRUE then allow use of TABLE PUCS.

MACH_SIM_YN 6 Create machine simulator file. Override DF2 setting.
REPORT_FORMAT 6 The output format for the report (MHT / PDF / Excel (XLS) /
New Excel (XLSX). Override DF2 setting.
May get one of the following values:
REPORT_MHT = 0
REPORT_PDF = 1
REPORT_XLSX = 2
REPORT_XLS = 3
SETUP_REPORT_YN 6 Create NC Setup report. Override DF2 setting.
TOOLS_REPORT_YN 6 Create Tools report. Override DF2 setting.
TRANSF_MODE Mode of operation of the transformation. May get the
values:
TR_EXPLODE, TR_USE_SUBS
TRANSF_SUB_INIT_NUM The initial number of the transformation subroutine
(sub_number).
TRANSF_SUB_SEPARATE_FILES If the variable is TRUE_ then the transformation
subroutines are output in separate files.
CimatronE 10.0 GPP2 User Guide ⎪196

X5_FEED_DIVIDE_BY_ANGLE 6 If TRUE, force linear interpolation on angles (and not IJK) if

one angle is not changed.

4.10.1.31 Block: SUBROUTINE CALL

SUB_NUMBER 6 The subroutine serial number.
In GPP2, the SUB_NUMBER can be set to start at any
number (not necessarily 1), through a DF2 file parameter.
NUM_LAYERS 6 Total number of layers in the procedure, i.e. the number of
times the subroutine will be called.
CimatronE 10.0 GPP2 User Guide ⎪197

4.10.2 Block: TOOL CHANGE

CLEAR_LENG 1 Distance between holder and tool tip.
CON_ANG 2 Tools conic angle.
CUT_LENGTH 1 Length of cutting edge of tool.
DIAMETER_ 1 Tool diameter.
DIA_COMP 1 Used only when cutter compensation is on.
E_LENGTH 1 Distance between tool axis and circle center.
E_TOL_TYPE 6 Outputs the tool type name as a number; different from
TOOL_TYPE_NAME which outputs the same as a string.
E_TOL_TYPE describes the tool shape according to the following
table:
0 – Ball cutter
1 – Bull nose cutter
2 – Flat cutter
3 – Drill
4 – Reamer
5 – Tap
6 – Center drill
7 – Lollypop cutter
8 – Slot mill (full radius)
9 – Slot mill (sharp corner)
10 – Slot mill (corner radius)
11 – Dove mill (full radius)
12 – Dove mill (sharp corner)
13 – Dove mill (corner radius)
14 – Counter sink
FIXT_COMP 1 Fixture compensation index.
FREE_LEN 1 Cutter free length.
GAUGE_LEN 1 Distance between tool tip and pivot point.
GRIP_LEN 1 Cutter grip length.
HOLDER_DIA 1 Mill tool Holder Diameter (-dia = not in use).
HOLDER_COMMENT 0 Holder comment.
HOLDER_NAME 0 Holder name.
HOLDER_YN 0 A string variable used mainly for reports, having “Yes” or “No”
indicating if the tool has a holder or not.
HOLD_BOT01...10 1 Holder Bottom diameter (holders numbered 1 to 10).
HOLD_CON01...10 1 Holder Conic height (holders numbered 1 to 10).
CimatronE 10.0 GPP2 User Guide ⎪198

HOLD_NUM 7 Number of holder stages in the current tool.

HOLD_TOP01...10 1 Holder Top diameter (holders numbered 1 to 10).
HOLD_TOT01...10 1 Holder Total height (holders numbered 1 to 10).
LENG_COMP 1 Length compensation index.
LIFE_LEN 1 Tool life length as set in the Cutter Table (Machining Parameters
tab).
REF_HIGH 1 Reference height for a shaped cutter.
SHANK_ANG 2 Shank Angle.
SHANK_BOT 1 Shank Bottom diameter.
SHANK_CON 1 Shank Conic height.
SHANK_TOP 1 Shank Top diameter.
SHANK_TOT 1 Shank Total height.
SHANK_TYPE 0 A string variable used mainly for reports, describing the shank
shape. It has one of the following values:
“Conic” – for conic shanks
“Narrow” – for a shank narrower than the tool diameter
“Standard” – in all other cases
SHNKANG_ON 6 Use Shank Angle.
SPNDL_BOT 1 Spindle Bottom diameter.
SPNDL_CON 1 Spindle Conic height.
SPNDL_TOP 1 Spindle Top diameter.
SPNDL_TOT 1 Spindle Total height.
TEETH_NUM 6 Number of teeth in tool.
TOOL_ANGLE 2 The tip angle of the tool.
TOOL_CMNT 0 Tools comment.
TOOL_FIRST_USE 6 Indicates if the tool is used for the first time in the current run (value
set to TRUE_) or not the first time (FALSE_).
TOOL_MAT 0 Tools material.
TOOL_NAME 0 Current tool name (replaced CURR_NAME).
TOOL_NUM 7 Current holder number (replaced CURR_TOOL). Note that
TOOL_NUM_OFFSET is added to the tool number value coming from
CimatronE.
TOOL_PID 6 Tool PID (unique ID).
TOOL_RAD 1 Tool corner radius.
CimatronE 10.0 GPP2 User Guide ⎪199

TOOL_TOTAL_LENGTH 1 The calculated total length of the tool (including holder and shank).
Only relevant for 5X machines with a rotated head and no head
RTCP.
Note: This length can be overridden by the EX2 program during
the TOOL CHANGE block (e.g., based on an exact value entered by
the user during the interaction).
GPP2 will only use the variable value to modify the machine
geometry after the block is executed.
TOOL_TYPE_NAME 0 Outputs the tool type name as a string; different from E_TOL_TYPE
which outputs the same as a number.
USE_WHOLEN 6 Use whole length.
WHOL_LEN 1 Cutter whole length.

Backward Compatibility Notes:

1. In GPP2, the NEXT_TOOL and NEXT_NAME variables are not used. Instead, all parameters of
the next tool are available through the next tool function. See GPP2 Language Reference
Manual for details.
CimatronE 10.0 GPP2 User Guide ⎪200

5 4/5 Axes Post-Processors

5.1 Introduction to 5 Axis Post-Processing

Post-processing for 4 and 5 axes machines is a fairly complex task. It requires good understanding of
the machine structure and kinematics, as well as the machine controller. It involves complex
mathematics, which is handled by GPP2.
From the post-processor developer viewpoint, the following aspects must be mastered:
• Definition of the machine (axes, geometry, angle limits, etc.)
• 5X connections, where milling must be paused and the machine rotated between toolpath
segments (or drill cycles).
• Work planes, both in GPP2 and on the machine itself.
• RTCP Settings and their effect
This document provides the complete information necessary for developing 4/5X post-processors with
GPP2. It assumes the reader is familiar with 5X machines and with 4/5 NC programming using
CimatronE.

5.2 Machine Definition

The first step in developing a 4/5X post-processor is defining the machine.
GPP2 contains a powerful “solver” that can handle practically any combination of machine axes and
calculate the proper rotation angles needed to reach any tool orientation.
GPP2 can also handle the machine geometry, correcting any tool point translation caused by the axes
rotations. However, this requires knowledge of the machine geometry (e.g., the distance between the
table rotation axis and the table face).
Finally, GPP2 can optimize the resulting G-code, minimizing the number of breaks in the milling
process (where the tool has to be lifted from the material, and the machine needs to be rotated before
cutting can continue).
In order to achieve all this, GPP2 must have a complete machine definition.
CimatronE 10.0 GPP2 User Guide ⎪201

5.2.1 Machine Types

GPP2 supports the following machine types:

5.2.1.1 5-Axis Table-Table (TT)

These machines have two rotary axes on the table, one mounted on top of the other. The head is
fixed, typically (but not necessarily) at the Z axis orientation. On table-table machines, the part, which
is mounted on the table, rotates and moves with each axis rotation (hence, the procedure origin UCS
rotates and moves as well). The spindle and tool remain stationary, and are not affected by axis
rotation.
We term the first axis (mounted on the floor) the primary (or alpha) axis, and the other axis (mounted
on top of the first) the secondary (or beta) axis. Note that rotation of the alpha axis affects the position
and direction of the beta axis.
The following diagrams illustrate several table-table machines. The alpha axis is shown in green,
whereas the beta axis (the table) is shown in blue.

Figure 1: Alpha axis: X, Beta axis Z, Vertical Tool

CimatronE 10.0 GPP2 User Guide ⎪202

Figure 2: Alpha axis Z, Beta axis X, Horizontal Tool

Figure 3: Alpha axis Z,-Y (45 degrees), Beta axis Z, Vertical Tool
CimatronE 10.0 GPP2 User Guide ⎪203

5.2.1.2 5-Axis Table-Head (TH)

These machines have one rotary axis on the table, and one rotary axis on the head. The axes are
independent – rotation of one axis has no effect on the other.
In GPP2, the table axis is always termed the primary (or alpha) axis, and the head axis is the
secondary (or beta) axis.
The part, which is mounted on the table, rotates and moves with the table axis. The spindle and tool
rotate with the head axis.
The following diagrams illustrate several table-head machines. The table axis is shown in green,
whereas the head axis (the table) is shown in blue.

Figure 1: Alpha axis X, Beta axis –Z,-Y (45 degrees)

Figure 2: Alpha axis Z, Beta axis –Z,-Y (45 degrees)

CimatronE 10.0 GPP2 User Guide ⎪204

5.2.1.3 5-Axis Head-Head (HH)

In these machines, both rotary axes are located on the spindle, and the table does not rotate. As a
consequence, the part (and procedure origin UCS) does not rotate either.
One axis is mounted on top of the other. The “base” axis, mounted on the machine, is called the
primary (alpha) axis, and the second axis, mounted on the first one, is called the secondary (beta)
axis.
The following diagrams illustrate several head-head machines. The alpha axis is shown in green,
whereas the beta axis is shown in blue.

Figure 1: Alpha axis -Y, Beta axis –Z,-Y (45 degrees)

Figure 2: Alpha axis Z, Beta axis X

5.2.1.4 4-Axis Table

These machines have one rotary axis only, mounted on the table. In GPP2, these machines are
defined as table-head (TH), with a “null” head axis (since the head does not really rotate. Hence, the
table axis is the primary (alpha) axis, and the secondary (beta) axis is not used.
CimatronE 10.0 GPP2 User Guide ⎪205

The part rotates with the table, so the procedure origin UCS rotates and moves with each rotation.

Figure 1: Alpha axis X, null Beta axis

CimatronE 10.0 GPP2 User Guide ⎪206

5.2.1.5 4-Axis Head

These machines have one rotary axis only, mounted on the spindle. In GPP2, such machines are
defined as head-head (HH), with a “null” beta axis. The rotating axis is defined as the primary (alpha)
axis.

Figure 1: Alpha axis Y, null Beta axis

5.2.2 Defining Machine Axes

In GPP2, a rotation axis is defined with a direction (I,J,K) vector. For instance, rotation around the
machine X axis is defined by the (1,0,0) vector. In order to simplify programming, GPP2 has many
predefined axes that can be used without having to deal with these direction vectors.
CimatronE 10.0 GPP2 User Guide ⎪207

Note that axis X (1,0,0) is not the same as axis –X (-1,0,0). The difference is in the direction of
rotation. The direction vector also defines a unique direction of positive and negative rotations, as
illustrated in the following figures.

Z Machine Z Machine
Coordinate System Coordinate System
Y Y
Positive
Direction
Positive
Direction X X

-X Rotation Axis +X Rotation Axis

The same
applies to any GPP2 rotation axis. When looking into the arrow head, positive rotation is always
counterclockwise.
Note that GPP2 provides another method to “reverse” the direction of an axis, using the
M5_A_REVERSED or M5_B_REVERSED variables described later. Essentially, using a reversed +X axis
is equivalent to using a –X axis. However, for Z rotation axes, always use the +Z axis, with the angle
reversal flag.
GPP2 supports the following predefined constants to be used when defining 4/5X machine axes:

AX5_NONE Null (4X machines) AX5_PXPZ +X +Z (45 degrees)

AX5_PX +X direction AX5_PXMZ +X -Z (45 degrees)
AX5_MX -X direction AX5_MXPZ -X +Z (45 degrees)
AX5_PY +Y direction AX5_MXMZ -X -Z (45 degrees)
AX5_MY -Y direction AX5_PYPZ +Y +Z (45 degrees)
AX5_PZ +Z direction AX5_PYMZ +Y -Z (45 degrees)
AX5_MZ -Z direction AX5_MYPZ -Y +Z (45 degrees)
AX5_PXPY +X +Y (45 degrees) AX5_MYMZ -Y -Z (45 degrees)
AX5_PXMY +X -Y (45 degrees) AX5_MANUAL_A Axis A – other direction
AX5_MXPY -X +Y (45 degrees) AX5_MANUAL_B Axis B – other direction
AX5_MXMY -X -Y (45 degrees)
CimatronE 10.0 GPP2 User Guide ⎪208

5.2.2.1 Manually-Defined Axes

GPP2 also allows users to manually define machine rotation axes. This allows the definition of any
axis direction vector, where predefined axes are not available. Very few machines will require that
capability.
This is a very advanced and very complex GPP2 capability, and should only be used if absolutely
necessary. In order to use a manually-defined axis, the following steps should be followed:
- Assign the (I,J,K) values of the rotation axis to system variables M5_A_I, M5_A_J and M5_A_K
(for the alpha axis) or M5_B_I, M5_B_J and M5_B_K (for the beta axis).
- Assign a second direction vector, perpendicular to the axis (I,J,K) to represent the “zero” vector
of the rotation axis. This is required because each machine axis is actually represented
internally as a full rotation matrix. This “zero” direction vector should be assigned to variables
M5_A_00I, M5_A_00J and M5_A_00K (for the alpha axis) or M5_B_00I, M5_B_00J and
M5_B_00K (for the beta axis).
- Use the predefined constants AX5_MANUAL_A (for the alpha axis) or AX5_MANUAL_B (for the
beta axis) in the machine definition command.
Notes:
1. It is possible to use one predefined axis and one manually-defined axis in the same machine.
2. The “zero” vector of the alpha axis may be any vector perpendicular to the axis itself. However,
the “zero” vector of the beta axis must reside on the same plane as the alpha axis direction.
This is necessary for the GPP2 solver operation.
3. Confused? Call Cimatron support for help in using this advanced feature.
CimatronE 10.0 GPP2 User Guide ⎪209

5.2.3 Machine Definition Command

In order to define the basic machine type and its axes, the following GPP2 statement is used:
DEFINE_MACHINE <type> <primary-axis> <secondary-axis> ;
The machine <type> should be one of the following predefined types:

TABLE_TABLE Use for 5X machines, table-table

TABLE_HEAD Use for 5X machines, table-head or 4X machines, table
HEAD_HEAD Use for 5X machines, head-head or 4X machines, head

The primary and secondary axes should be one of the predefined axes listed above.
Examples (only the parameters to the command are shown):

TABLE_TABLE A5X_PX A5X_PZ TABLE_TABLE A5X_MYPZ A5X_PZ

TABLE_HEAD A5X_PX A5X_MYMZ TABLE_HEAD A5X_PZ A5X_MYMZ

CimatronE 10.0 GPP2 User Guide ⎪210

HEAD_HEAD A5X_MY A5X_MYMZ HEAD_HEAD A5X_PZ A5X_PX

Note the last head-head machine. The alpha axis is defined as +Z (A5X_PZ) although it looks like –Z
(as it points down). As mentioned before, with Z axes, you should always use the +Z direction (and
reverse the axis if necessary).

5.2.4 Machine Geometry

When machine axes are rotated, they may also cause translation (movement) of the procedure
coordinate system or the tool point. GPP2 can correct for these translations, but it needs to know the
exact machine geometry.
Most of this section is not relevant for machines with RTCP, since they do the correction by
themselves. For such machines, the A and B vectors may be left zeroed.

5.2.4.1 A and B Vectors

This is probably the most complex part in the 5X machine definition – the relation between the axes
and the machine geometry.
GPP2 uses two vectors to define the relationship between the axes and from the table axis to the
Anchor Point (also known as the “red point”). In rotating head machines, the vectors are used to define
the relationship to the spindle center point.
These vectors are only important for machines with no RTCP – so that GPP2 can do the
necessary corrections itself. With RTCP, these vectors are ignored. However, they always affect
the output to the machine simulator, so it is highly recommended that they are set properly to allow the
use of the machine simulator.
CimatronE 10.0 GPP2 User Guide ⎪211

The vectors are used differently based on the machine type:

Machine Type Vector A Vector B

M5_A_VECX M5_B_VECX
M5_A_VECY M5_B_VECY
M5_A_VECZ M5_B_VECZ

Table – Table From the center of the alpha From the end of the A vector to the
rotation axis to the center of the Anchor Point.
beta rotation axis

Table – Head From the center of the alpha From the center of the beta
rotation axis to the Anchor rotation axis to the spindle center
Point point.

Head – Head From the center of the alpha From the end of the A vector to the
rotation axis to the center of the spindle center point.
beta rotation axis

The “center of an axis” is not really a single point – it is a line – the rotation axis itself. So, where
should a vector actually start? Surely, picking different points along the alpha rotation axis as the start
point of the A vector will result in different vectors. So, which start point is the right one? Interestingly,
all of them are equally valid. GPP2 has a mechanism that deals with such vectors regardless of their
start point along the axis. Therefore, the most convenient point should be used as the start point (e.g.,
the point just “under” the beta axis).
In table-table or head-head machines, the B vector must start at the end point of the A vector.
CimatronE 10.0 GPP2 User Guide ⎪212

The following diagram shows a simple case of a table-table machine. The alpha axis is around X, and
the beta axis is around Z.

As can be seen from the side view, the A vector extends from the center of the alpha axis to the top
center of the table. The Anchor Point is at the center of the table, so the B vector is zero.
The following diagrams illustrate the A and B vectors in a more complex table-table machine, with an
alpha Z axis and a beta X axis.

General View and Side (X) View

CimatronE 10.0 GPP2 User Guide ⎪213

Top View and Side (Y) View

Notes:
1. This is a fairly complex situation, since the center of the beta axis (X) is not located above the
center of the alpha axis (Z). It is somewhat shifted on the Y axis. That’s why both vectors are non-
zero in this example.
2. Note the start point of the A vector (along the alpha Z axis). It is chosen at the same height as the
beta axis, for simplicity.
Now consider a Head-head machine, shown below. Here, the A vector is vertical, connecting the alpha
axis center to the beta axis center.
CimatronE 10.0 GPP2 User Guide ⎪214

The B vector connects the beta rotation axis to the spindle center point. Here, we chose a B vector that is
not perpendicular to the rotation axis. As explained before, the vector can start anywhere along the axis
rotation line, as long as it starts where the A vector ends.
Note that when a tool will be later added to this machine, the tool “vector” will actually be added to the B
vector, since it effectively extends the lever of the beta axis.
Finally, consider the Table-head machine shown below.

The A vector connects the center of rotation to the Anchor Point. As shown here, the Anchor Point is not
centered on the table, so the A vector is not zeroed.
The B vector connects the center of rotation to the spindle center point (and can never be zeroed in
machines with rotating heads).

5.2.4.2 Tool Direction Vector

GPP2 supports machines where the tool is not necessarily aligned with the Z axis. For instance, it is
possible to define a machine with a fixed horizontally mounted tool.
In order to do so, the GPP developer has to define the following system variables, and set them with
the tool direction: M5_TOOL_I, M5_TOOL_J and M5_TOOL_K. By default, these variables are set to
(0,0,1) – the Z axis direction.
Note: the direction vector should point into the tool, not away from the tool. In the standard case, the
tool points down, but the tool vector points up (0,0,1), into the tool.
CimatronE 10.0 GPP2 User Guide ⎪215

5.2.4.3 Tool Length Correction

In rotating head machines (table-head or head-head), the length of the tool determines how much the
tool tip is moved with each rotation. In fact, the length of the tool should be added to the B vector (the
tool essentially extends that vector).
In rotating head machines, GPP2 automatically adjusts the B vector length to include the tool and
holder length with each tool change. Usually, no handling is required from the GPP developer.
In some cases, the calculated tool length is not accurate (for instance, if the tool was sharpened and is
shorter than its nominal value). In such cases, the user wishes to enter the accurate (measured)
length during the GPP2 interaction.
For that reason, the calculated tool length value may be overridden by the EX2 program during the
TOOL CHANGE block, through the use of the TOOL_TOTAL_LENGTH system variable.
• GPP2 first calculates the total length and sets the variable before going into the TOOL CHANGE
block execution.
• Then, the EX2 program has a chance to modify the value inside the block.
• Only after the TOOL CHANGE block is processed, GPP2 uses the value of the variable to set the
machine geometry.
Recall that all this is only relevant in machines without head RTCP. If the machine has head RTCP,
then it does the correction itself (for the spindle and the tool alike).

5.2.5 RTCP Settings

RTCP stands for Rotation Tool Center Point. In GPP2, the term is used to describe if and how the
machine controller maintains the proper tool tip position when the machine axes are rotated.
A simple “dumb” machine employs no RTCP. There is no correction for the tool tip position when an
axis is rotated. GPP2 makes all the necessary corrections by itself, in order to position the tool at the
right point at every axis angle.
CimatronE 10.0 GPP2 User Guide ⎪216

5.2.5.1 Head RTCP

Head RTCP applies to machines with a rotating head (one or two axes are in the head). If supported,
the machine controller will adjust the tool position with every rotation of the head, as demonstrated in
the figure below.

Different Spindle
This would positions Without RTCP, GPP2 has to
be the new modify the output position by
Tool Tip Move Diff, when rotating the head.
position
without the With RTCP, the same output
correction position is used – the machine
2 1 3
controller makes the correction

Same Tool Tip

position

Assume the tool is located at position 1, and needs to be rotated at an angle but still remain at the
same tool tip position. Rotating the head without any correction would result in position 2, far away
from the desired tool tip position. The spindle position must be corrected (moved to the right) in order
to reach position 3.
With Head RTCP, it is the controller that handles the position correction. Without Head RTCP it is
GPP2 that does the same.
For machines with Head RTCP, the M5_RTCP_HEAD variable has to be set to TRUE_. For machines
without Head RTCP, it has to be to FALSE_. The variable can be set dynamically during the run –
GPP2 will adjust its output accordingly.

5.2.5.2 Table RTCP

Table RTCP applies to machines with a rotating table (one or two axes). Rotation of the table actually
has a double effect on tool tip positions:
• The part is rotated; hence the whole procedure UCS is rotated with it. This rotates and modifies
every tool tip point.
• If the REF coordinate system is not located at the center of axis rotation, the REF UCS zero point
is also shifted because of the axis rotation. That translation needs to be corrected on every tool tip
point.
CimatronE 10.0 GPP2 User Guide ⎪217

The following diagram illustrates table RTCP.

The Zero Point

Shifted Translation Vector
REF UCS
REF UCS

Table (0,0,0)

Rotation
center

Table RTCP corrects the REF zero point translation (displacement). The controller adjusts the tool
position in order to compensate for the rotation. It does not correct the procedure UCS rotation – that
is handled by GPP2. In machines without table RTCP, GPP2 handles the full correction.
For machines with table RTCP, the M5_RTCP_TAB variable has to be set to TRUE_. For machines
without table RTCP, it has to be to FALSE_.

5.2.5.3 Full RTCP (M128)

Machines using the advanced Heidenhain controllers support a full RTCP correction mechanism,
where the machine controller full corrects the tool tip position for every rotation of the head or the
table.
Full RTCP goes beyond the corrections of head RTCP and table RTCP explained above. It also
corrects for the rotation of the REF UCS (in rotating table machines), so that GPP2 does not have to
make any changes to tool tip coordinates as a result of the axes rotations.
In such machines, it is common to turn this feature on and off on the machine. GPP2 must always stay
in synch with the machine RTCP status. In order to turn on the full RTCP in GPP2, the
M5_RTCP_M128 is set to TRUE_. To turn it off, the variable is set to FALSE_. The variable can be set
dynamically during the run – GPP2 will adjust its output accordingly.
CimatronE 10.0 GPP2 User Guide ⎪218

The following diagrams demonstrate the differences between standard GPP2 output (no RTCP at all),
table RTCP (correction of the zero point) and full RTCP (M128, rotation of the coordinate system
itself).

X=35

Z=30

Figure 1: Tool Position inside CimatronE

X=-9.87

Z=53.8

Figure 2: Standard Output – no RTCP

CimatronE 10.0 GPP2 User Guide ⎪219

X=8.

Z=45.3

Figure 3: Output with Table RTCP

X=30

Z=35

Figure 4: Output with Full RTCP (M128)

CimatronE 10.0 GPP2 User Guide ⎪220

5.2.6 Axis Rotation Types

Rotation axes differ in the way they handle multiple full turns. Some axes can turn indefinitely, while
other axes have hard limits. This section explains how to define the type of axis rotation (for the alpha
or beta axis).

5.2.6.1 Continuous Cyclic Axes

These axes can turn indefinitely to either direction. They are completely cyclic, in terms of the angles
they accept. For instance, they can move from +179 degrees to -179 degrees and properly interpret
this motion as a 2 degree CCW rotation.
Cyclic axes should have the angle range defined as a single 360 degrees interval, such as 0 to 360 or
-180 to 180. GPP2 will ensure that the output angles fall into this range.
An axis is defined as cyclic by setting one of the following variables to TRUE_: M5_A_CYCLIC for the
alpha axis, and M5_B_CYCLIC for the beta axis. Defining an axis as cyclic overrides any other setting
(e.g., resettable).

5.2.6.2 Continuous Resettable Axes

Resettable axes can also rotate indefinitely to either direction. However, unlike cyclic axes, they use a
limited non-cyclic range of angles. For instance, such an axis may use the range of -3000 to +3000
degrees.
Note that the angle limit is a “soft” limit – the axis can rotate on and on in the same direction. However,
when that software limit is reached, the axis must be “reset” to a smaller angle, within a much smaller
range.
Resetting the axis angle has no effect on the axis position or real angle – it is a software reset only.
For instance, the angle 2999 may be reset to 119 (subtracting a number of full 360 cycles) before the
machine can continue its rotation to angle 3001 (which becomes 121 after the reset).
In order to define an axis as resettable, the following variable must be set to TRUE_: M5_A_RESETABLE
for the alpha axis, M5_B_RESETABLE for the beta axis.
Note that these variables are ignored if the axis is defined as cyclic (see above).
The axis reset range must also be defined. The default range is -360 to +360 degrees, but other
ranges are acceptable (e.g., 0 to 360). The reset range is defined with the following variables:
• M5_A_RESET_FROM and M5_A_RESET_TO for the alpha axis

• M5_B_RESET_FROM and M5_B_RESET_TO for the beta axis

Whenever GPP2 reaches one of the axis soft limits, it invokes a RESET AXIS block with one of the
qualifiers alpha: or beta:, indicating the axis that needs to be reset. The angle to be rest is found in
A_LASTPOS or B_LASTPOS respectively.
CimatronE 10.0 GPP2 User Guide ⎪221

The EX2 program is expected to do the following:

• Reset the axis on the machine by outputting the appropriate machine command.
• Modify A_LASTPOS or B_LASTPOS to the new reset value, based on the specific machine
behavior. The new value must match the machine rest value!
GPP2 checks the value of A_LASTPOS (or B_LASTPOS) after the RESET AXIS block is executed. The
new value must meet the following criteria: (a) it must be within the axis reset range; (b) it must be
equivalent to the previous value (the same direction, since no real rotation takes place). If the criteria
are not met, a runtime error is generated.

RESET AXIS by Request

Usually, an axis reset block (RESET AXIS) is invoked by GPP2 when a resettable axis reaches the
lower or upper soft limit. However, it is also possible to request an axis reset from the EX2 program.
This may be useful if the PP developer prefers to reset the axis at the beginning of each procedure or
as part of a connection process.
In order to request an axis reset, the EX2 program has to set one of two request flags to TRUE_. The
A_RESET_AXIS system flag is used for the A (primary) axis, and the B_RESET_AXIS system flag is
used for the B (secondary) axis. The requests are only relevant to resettable axes.
When GPP2 identifies that an axis reset block has been raised, it invokes the RESET AXIS block with
the appropriate quantifier (depending on the axis requested). The EX2 program is expected to do the
reset by setting the A_LASTPOS or B_LASTPOS variables to the new reset value.
GPP2 only checks the request flags at two points:
• After execution of the START PROC block. This block is invoked at the beginning of each
procedure, just before the first connection motion. This is the simple way to request an axis reset.
• After execution of the BEGINNING OF CONNECT block. The process is more complex here. If a
request flag is raised, GPP2 aborts the current connection, invokes the RESET AXIS block and
then restarts a whole new connection process (starting with a re-invocation of the BEGINNING OF
CONNECT block). The EX2 program logic should be aware of this process and only raise the
request flag in certain conditions (e.g., the angle is above or below a certain limit).
CimatronE 10.0 GPP2 User Guide ⎪222

5.2.6.3 Limited Range Axes

These are the simple axes with a hard limitation on their rotation range. For instance, an axis may be
limited to rotate between -70 and +110 degrees, or between -720 and +720 degrees.
In order to define a limited range axis, both the “cyclic” and “resettable” variables should be set to
FALSE_ (this is also the default setting).
Limited range axes must be rewound (turned back) when they reach their limit. This is handled by
GPP2, which always generates valid angles for these axes. See discussion below regarding 5X
connections that result from such limit conditions.

5.2.7 Axis Angle Limits

Every GPP2 machine axis must have its lower and upper angle limit defined. This holds true for any
type of axis, cyclic, resettable or standard. Of course, the meaning of these limits depends on the axis
type as explained above.
The following variables are used to define axis limits:
• M5_A_MIN_ANG and M5_A_MAX_ANG for the alpha axis

• M5_B_MIN_ANG and M5_B_MAX_ANG for the beta axis

Note that for resettable axes, the reset angle range must also be defined, as explained above.

5.2.8 Miscellaneous Settings

5.2.8.1 Axis Preference

With 5X machines, there are often two angle solutions for the same tool orientation. Typically, one is
positive and the other is negative (or else they differ by 180 degrees).
In some machines, one solution is more desirable than the other. For instance, in some table-table
machines, one solution rotates the parts towards the operator, while the other solution rotates the part
away from the operator, where the part is practically hidden by the table. Preferably, the operator
would like to see the part being machined.
GPP2 allows the developer to define the preference for each axis, with the use of the following
variables: M5_A_PREF for the alpha axis, and M5_B_PREF for the beta axis.
Each variable should set assigned one of the following predefined GPP2 constants:
- PREF_NONE No preference
- PREF_POSITIVE Prefer positive angles
- PREF_NEGATIVE Prefer negative angles

5.2.8.2 Axis Angle Reversal

Some 5X machine axes treat positive and negative angles contrary to the GPP2 conventions. For
instance, in GPP2, a counter-clockwise rotation (when viewed from the axis “top” point) is a positive
CimatronE 10.0 GPP2 User Guide ⎪223

change in the angle. In some machines, a positive change may result in clockwise rotation.
In some cases, such angle reversal can also be handled by defining a negative axis direction (e.g., -X
instead of X). In other cases, where the axis in question has a Z component (same as the tool itself),
such an approach will not succeed. For instance, it is not possible to use –Z instead of Z in a table-
table machine.
In order to handle such situations, GPP2 allows the reversal of each axis angle. By setting
M5_A_REVERSED (for the alpha axis) or M5_B_REVERSED (for the beta axis) to TRUE_, all output angles
for the corresponding axis will simply be negated.
Note that internally, GPP2 uses its standard axis and angle definition. The reversal is done just prior to
setting the values in A_CURPOS and B_CURPOS, and invoking the relevant EX2 block.

5.2.8.3 Axis Letter

In 5X machines, each rotary axis has a corresponding letter (just like the X, Y and Z linear axes). It is
possible to specify that letter in GPP2, by setting the following variables: M5_A_LETTER for the alpha
axis, M5_B_LETTER for the beta axis.
Using the letter variables inside the EX2 program makes the post-processor more generic. For
instance, consider the following typical lines:
IF_SET (A_CURPOS) OUTPUT " " M5_A_LETTER A_CURPOS; END_IF;

IF_SET (B_CURPOS) OUTPUT " " M5_B_LETTER B_CURPOS; END_IF;

These lines work for any machine, regardless of the specific axis names (A, B or C).
The same letters are also used in the output for the machine simulator – see later section in this
manual.
Note that these variables may contain more than one letter. For instance, “C1” or “C2” may be used
instead of just “C” – depending on the machine requirements.
CimatronE 10.0 GPP2 User Guide ⎪224

5.2.9 Machine XYZ Limits

Every machine has limitations in the X, Y and Z axes. In most cases, these limits do not interfere with
everyday operation. Users can check the extreme XYZ values calculated by GPP2 (variables X_MIN,
X_MAX, etc.) and verify that the entire run is within limits.
However, some machines have “severe” position limitations (e.g., X cannot go negative). It may
happen that one 5X angle solution is within limits, while the other one violates the XYZ limits. For such
cases, these limits must be pre-defined for GPP2, so that it can select a valid solution whenever
possible.
The minimum and maximum XYZ limits are defined with the following variables:
X_MACH_MIN and X_MACH_MAX X axis range
Y_MACH_MIN and Y_MACH_MAX Y axis range
Z_MACH_MIN and Z_MACH_MAX Z axis range
These variables define the hard limitations of the machine (regardless of where the zero point is
calibrated). Therefore, they must be defined with the following rules:
• They are defined with respect to the MACH point (X_MACH, Y_MACH, Z_MACH) – not relative to the
reference UCS.
• They define the extreme limits for the machine spindle center point, not the tool tip (since
different tools have different lengths).
• All six numbers must be defined, even if the user is interested in a given axis only. One can always
use out-of-range numbers (e.g., set the allowed Z range between -999999 and 999999 if the Z
axis is of no concern).
Note that these numbers do not usually match the “native” machine coordinate system, where the
(0,0,0) point may be anywhere (e.g., on the ceiling or the floor). They are measured and defined with
respect to the MACH point (the “red” point), which gives the relation between the REF coordinate
system and the machine agreed-upon point.
CimatronE 10.0 GPP2 User Guide ⎪225

5.3 Placing the Part on the Machine

All the GPP2 processing takes place relative to REF UCS and its zero point. The machine is also
calibrated so that the (0,0,0) is located at the REF UCS origin.
However, the machine kinematics and the location of rotary axes cannot be calibrated. The machine
Anchor Point (“red point”) is always located at the same physical location.
In order to properly calculate the correct position of points when the table is rotated, it is necessary to
know the relation between the REF UCS and the machine Anchor Point. This can also be considered
as defining the part location on the machine.
GPP2 uses a distance vector, X_MACH, Y_MACH and Z_MACH to define the location of the Anchor Point
relative to the REF UCS.

REF UCS
Part Zero

X/Y/Z_MACH
Machine Vector
Anchor Table
Point

This is only relevant for machines with no table RTCP. If the table or full RTCP (M128) is used, then
the machine controller handles the corrections by itself.
CimatronE 10.0 GPP2 User Guide ⎪226

5.4 5-Axis Toolpath Optimization

GPP2 optimizes the 5X toolpath based on the machine capabilities, in order to minimize the number of
times the tool must be removed from the material because of machine axis limitations.

5.4.1 Toolpath Segments

Each 5X procedure is treated by GPP2 as a set of “segments”, where each segment contains one
continuous cutting (feed speed) motion. A procedure may have one segment or multiple segments.
The segments are separated by rapid motions, where the end of one segment is connected to the
beginning of the next segment.
A 5X toolpath segment is composed of the cutting motions, as well as a (rapid) approach motion and a
(rapid) retract motion. These motions are taken from the CimatronE toolpath.

Rapid
approach
End of
segment

Beginning
of segment
Feed
motions Rapid
retract
5X Segment
GPP2 optimizes the angles used within each segment, trying to avoid the need to break the cutting
motions because of machine limits.
In addition, it creates the connections between the segments. These connections are “standard” GPP2
connections, and are fully described in the GPP2 Theory of Operation manual. The connections to and
from the segment are not shown in the diagram.
With the advanced 5X procedures (also known as 5X Production or 5X Aerospace), there may be
additional approach and retract motions, depending on the way the procedure was programmed.
With the advanced 5X procedures, it is possible to force the entire procedure to behave as a single
long segment, including all internal rapid motions. This is done by setting the INTERNAL_5X_RAPID
system flag to TRUE_. The flag only affects 5X advanced procedures.
Note that in some machines, GPP2 can optimize the rotary axes motions better if allowed to perform
its own connections between contiguous sections of feed motions (e.g., when axes need to be rotated
or solutions swapped). This behavior is achieved when the INTERNAL_5X_RAPID is turned off. The
downside is that the connections between segments are not the same as seen inside CimatronE.
CimatronE 10.0 GPP2 User Guide ⎪227

5.4.2 Axis Angle Optimization

The need to optimize the 5X toolpath angles exists in axes with hard machine limits. Continuous axes,
either cyclic or resettable, do not need that type of optimization, since they can rotate indefinitely in
any direction.
Consider an axis with hard limits, between -1000 to +1000 degrees. And assume that the toolpath
includes 4 full CCW rotations of this axis, starting from zero angle.
A simple toolpath will start at angle 0, and will grow the angle until the +1000 limit is reached (since 4
rotations require 1440 degrees). Then, the cutting will have to be stopped, the tool will have to be lifted
up, and the machine will have to be rotated back in order to continue the toolpath.
An optimized toolpath will start at angle -720 (equivalent to 0), and will freely continue to +720,
achieving a non-interrupted toolpath and better surface quality.
GPP2 will always look for the best angle to start each 5X segment, so that the number of interruptions
will be minimized. The GPP developer does not need to do anything in order to make this happen.
Note that this will only happen on axes with hard angle limits. For a resettable axis with the same -
1000 to +1000 soft limits, the angle will simply be reset (e.g., from 1000 to 280) without any
interruption in the cutting operation.

5.4.2.1 Any Angles

Another area where GPP2 optimizes the generated angles is when an axis can have “any angle” in
order to meet the required orientation. This happens when the tool is parallel to the table beta axis (so
rotation of that axis has no effect on tool orientation compared to the part).
In such cases, GPP2 will select the proper angles for the axis, taking into account the angles at points
that come before and/or after the “any angle” area. These points define boundary conditions for the
“any angle” area. GPP2 will interpolate the angles within the “any angle” zone so that the transition
into and out of the zone will be as smooth as possible.
Again, this is done automatically by GPP2, without any involvement required from the GPP developer.
CimatronE 10.0 GPP2 User Guide ⎪228

5.5 5-Axis Linear Motions

In a 5X toolpath, each linear motion may contain a rotation of one or two axes. That rotary motion may
introduce a small (or large) error in the tool tip motion, based on the “lever” (the rotation radius) and
the rotation angle. The error is simply the difference between a straight line and a small arc – both
connecting the same two points. These errors may lead to small gouges in the part. See image below,
where an exaggerated case is shown.

When moving from

Point 1 to Point 2 by
Required axis rotation, the tool
linear motion Angle makes an arc, and
does not follow the
straight line between
Point 1 Point 2 the points

Actual arc
Rotation error motion

In order to minimize such errors, GPP2 supports control over the largest rotation angle allowed in
each linear motion step. Clearly, the smaller the arc – the smaller is the difference between the arc
and the linear line.
GPP2 supports an adaptive algorithm to determine the maximum allowed angle in each linear motion
step. If the X5_FEED_BY_TOL variable is set to TRUE_, GPP2 will use the procedure tolerance value as
the basis for calculating the maximum allowed angle. The procedure tolerance is defined by the
PART_TOL (surface tolerance) or CONT_TOL (contour tolerance) variables – the smaller of the two.

Using the procedure tolerance and the rotation radius, GPP2 calculates the maximum angle to use
(per axis), so that the resulting error will be limited to half that tolerance.
In addition, the maximum angles are limited by the following variables:
X5_FEED_MAX_ALPHA – maximum delta angle for the alpha axis

X5_FEED_MAX_BETA – maximum delta angle for the beta axis

If the numbers derived from the tolerance are higher than these numbers, the smaller numbers are
used.
Finally, the GPP developer can also define a lower limit for the per-step angle, by setting the
X5_FEED_MIN_ALPHA and X5_FEED_MIN_BETA variables. By default, they are set to zero, and have
no effect. If set to positive non-zero values, they can ensure that GPP2 will not break linear motions to
a huge number of very small steps (in case the procedure tolerance is near zero).
CimatronE 10.0 GPP2 User Guide ⎪229

For cases where the GPP developer chose not to use the procedure tolerance to determine the
maximum angles (X5_FEED_BY_TOL is set to FALSE_), then GPP2 uses the numbers provided in the
X5_FEED_MAX_ALPHA and X5_FEED_MAX_BETA variables.

Example (shown on one axis only):

X5_FEED_MAX_ALPHA = 1.0; // never rotate more than 1.0 degree per step

X5_FEED_MIN_ALPHA = 0.05; // but never use steps smaller than 0.05 degree

Effects of RTCP: Machines with RTCP may be able to do the correction by themselves, even if the
rotated angle is relatively large. However, GPP2 will always consider the X5_FEED_MAX_ALPHA and
X5_FEED_MAX_BETA variables, regardless of RTCP status. No single linear motion will have a larger
axis rotation.
However, the procedure tolerance will only be considered for a given axis if RTCP for that axis is off.

5.6 5-Axis Connections

In some cases, GPP2 has to stop the cutting motions in the middle of a 5X segment, and rotate the
machine to another “equivalent” position before continuing with the toolpath.
GPP2 identifies the need for such connections automatically, and handles them without any help from
the EX2 program. However, the “shape” of the connection may be controlled as explained below.
Note that these connections are only needed for machines with hard limits on their axes. GPP2 will
apply a 5X connection in one of the following cases:
• Switch to “Other” Solution: many times, there are two solutions for a given orientation of the
tool. When the solution used reaches the machine angle limit, it is often possible to switch to the
“other” solution and continue the operation.
• Rewind Axis: sometimes, there is no “other” solution (e.g., on a 4X machine), and the axis must
be rewound one or more full rotations before cutting can continue.
• Find Middle Point: in rare cases, it is not possible to switch to the “other” solution at the current
tool point (that solution is not valid), but it is also not possible to continue to the next point without
doing the switch. In such a case, GPP2 will find a “middle point”, between the current and next
points, where both solutions are valid, and the swap may be done. This is done by GPP2
automatically.
CimatronE 10.0 GPP2 User Guide ⎪230

5.6.1 The 5-Axis Connection Shape

GPP2 supports three types of 5X connections:
• Tangential, where the retract from the material and the approach back to the material are done in
a tangential way, for best surface quality. This method should be used in most cases.
• Normal, where the retract and approach are strictly along the tool axis. This method will leave a
bigger mark on the material, but is “safer” than the tangential. If the connection takes place in a
very tight area (in terms of potential gouges of the tool/holder with the part, then this is the
recommended solution.
• In-Place, where the rotation of the table takes place without lifting the tool at all from the toolpath
point. See below.
The following diagram illustrates the first two types of connection, in the “part” space. Note that the
table is actually rotated when the tool is at the top connection point.

The table rotation point The table rotation point

3 2

4 3
X_CON_CLEARANCE

5 2 X_CON_RETRACT 1
4
6 1

Tangential 5X Connection Normal 5X Connection

CimatronE 10.0 GPP2 User Guide ⎪231

The tangential connection process takes place as follows

Step Motion
1 Tangential retract, feed rate (radius controlled by EX2 variable
2 Normal retract, feed rate, to “retract” height (along tool axis)
3 Normal retract, rapid to “clearance” height (along tool axis)
Perform the rotations at the top point
4 Normal approach, rapid, back to “clearance” height (along tool axis)
5 Normal approach, feed rate, to the arc start point
6 Tangential approach, feed rate, at the same radius.

In tangential 5X connection, the motions 1 and 2 are limited to the distance until the next or previous
point (relative to the connection point). The motion is along the direction to the next point (retract) or
from the last point (approach). That way, GPP2 attempts to make a smooth continuation of the cut
(inside the lane).
If there simply isn’t enough space between the middle point and one of the adjacent points, GPP2 will
revert to normal retract or approach.
The normal connection process is somewhat simpler, and takes place as follows.

1 Normal retract, feed rate, to “retract” height (along tool axis)

2 Normal retract, rapid to “clearance” height (along tool axis)
Perform the rotations at the top point
3 Normal approach, rapid, back to “clearance” height (along tool axis)
4 Normal approach, feed rate, back to the material

The following GPP2 variables control the 5X connection process:

X5_CON_TANGENT Set to TRUE_ (1) to use tangential retract and approach. Set to
FALSE_ (0) to use normal retract and approach.
X5_CON_RADIUS In tangential connections, this is the radius of the retract and
approach arcs.
X5_CON_RETRACT The length of the feed-rate retract motion (along tool axis).
Applies to both tangential and normal connections.
X5_CON_CLEARANCE The height of the top point above the surface (along tool axis),
where the actual table rotation takes place.
CimatronE 10.0 GPP2 User Guide ⎪232

5.6.2 In-Place 5-Axis Connection

When swapping between 5X solutions, it is sometimes desired to perform the table rotation without
lifting the tool off the part. For instance, in a Table-Head machine, if the tool is nearly vertical, the
solution swap mainly involves the rotation of the table. The head only makes a very small rotation.
This behavior is controlled by the M5_SWAP_INPLACE system variable. GPP2 will perform an in-place
solution swap if the overall rotation of one axis is less than twice the value of M5_SWAP_INPLACE.
The following diagram shows a Table-Head machine, with a Z-axis table and an X-axis head. The
head is nearly vertical, and the solution swap requires the table to rotate 180 degrees while the head
only rotates from, say, -2 to +2 degrees.

Solution A Solution B
Head rotates
just a few
degrees

Table rotates
180 degrees
CimatronE 10.0 GPP2 User Guide ⎪233

Clearly, the axis with the smaller rotation here is the head (beta). Suppose that M5_SWAP_INPLACE is
set by the EX2 program to 2.5 degrees, and that the head rotates from -2.0 to +2.0 degrees. In such a
case, GPP2 will perform the move from solution A to solution B without retracting away from the part.

Total Head
Rotation = 2 * β

Head -β +β Head
Position A Position B

In-place swap happens IF:

β <= M5_SWAP_INPLACE

Notes:
• By default, the value of M5_SWAP_INPLACE is negative, so this feature is never invoked unless the
EX2 program explicitly modifies it to a non-negative value.
• Setting M5_SWAP_INPLACE to exactly 0 will perform an in-place swap only if one axis does not
need to rotate at all (e.g., the head is perfectly vertical, and only the table rotates).
• It is not recommended to perform an in-place solution swap with non-ball tools, since the
intermediary orientations may damage the part (unless one axis does not rotate at all).
• Recall that no collision check can be performed by GPP2. An in-place solution swap with a
relatively large inclination of the head may collide with the part or stock. It is the responsibility of
the PP developer and the user to ensure that this behavior is only used in safe situations.
CimatronE 10.0 GPP2 User Guide ⎪234

5.6.3 Controlling the 5-Axis Connection Point

In general, a 5X connection occurs when one of the axes reaches its hard limit, at the minimal or
maximal allowed angle. GPP2 moves to the “other” solution, which is typically within the allowed
range.
For instance, assume that a given A table axis has a range of -10 to +110 degrees. A connection will
happen near the minimum point, when the axis needs to move from -9 to -11 degrees. GPP2 will swap
solutions (from -9 to 9) and then move to 11 degrees.
It may be desired to perform this unavoidable swap at a different point, say near the 0 axis angle,
although the axis can rotate beyond 0 (till -10). For instance, a swap near the zero point may be done
using in-place swap (without leaving the part).
GPP2 provides four variables that control the location of the swap points. Each variable is relevant to
one axis (A or B) and one extreme point (minimum or maximum). The EX2 program may set one or
more of these variables in order to control the angle of each swap. Each variable only takes effect if
the relevant reason caused the swap:

M5_A_SWAP_MIN Relevant only if the swap was caused by axis A reaching its
minimum angle.

M5_A_SWAP_MAX Relevant only if the swap was caused by axis A reaching its
maximum angle.

M5_B_SWAP_MIN Relevant only if the swap was caused by axis B reaching its
minimum angle.

M5_B_SWAP_MAX Relevant only if the swap was caused by axis B reaching its
maximum angle.

Notes:
• GPP2 will ignore the setting of these variables for cyclic or resettable axes (such axes never cause
a solution swap). The variables are only considered for axes with hard limits.
• The relevant variables must be “set on” in order for GPP2 to consider them. The EX2 program
must explicitly set them on in addition to assigning them with a value (especially if that value is 0).
• The EX2 program may set one or more of these variables (independently of each other).
• While the variable names may suggest that they represent a range of some sort (min and max),
they do not. They independently refer to swaps caused by reaching the minimum and maximum
axis extreme points.
• GPP2 will look for a toolpath point that is closest to the desired swap point. However, it will not
generate a new point at the exact desired angle. Therefore, the actual swap point may not be
exactly as desired, but just near it.
• GPP2 will attempt to move the swap to the desired angle specified by the relevant control variable.
CimatronE 10.0 GPP2 User Guide ⎪235

However, the success is not guaranteed. If the algorithm fails to find a point close to the desired
angle, the swap will take place at the original position (near the extreme point that caused it).
It is possible to add a random value, within a given range, to the actual swap point. That way, the
swap point in each lane may be slightly shifted to either side, resulting in an even distribution of the
points where the tool has to break contact with the metal. This may add to the final surface quality
(because the connection points are not found on an exact line or curve).
In order to use the random range, the EX2 program needs to set the M5_SWAP_RANGE variable to the
range size. The actual swap point will be shifted to either side by a random number, between zero and
±M5_SWAP_RANGE. For instance, if the desired swap angle was zero, and M5_SWAP_RANGE is 5
degrees, then the actual swap point will be set randomly, anywhere between -5 and +5 degrees.
The M5_SWAP_RANGE variable applies to all the controlled swap positions, if (and only if) set by the
four variables (A or B, min or max) described above.
CimatronE 10.0 GPP2 User Guide ⎪236

5.6.4 In-Place Connection

The CONNECT IN PLACE block is invoked by GPP2 whenever a regular connection scenario is not
invoked because the machine is already positioned on the target point.
Without this block, GPP2 would do no connection process at all if the machine was already where it
needed to be for the next procedure. For instance, a “5X Connect” procedure starts exactly where the
previous procedure ended. Similarly, the procedure following the “5X Connect” procedure starts
exactly where the “5X Connect” procedure finished. Similar conditions may occur in other scenarios,
where no clearance planes are used.
From a pure “motion” point of view, no connection is indeed required, since no motions are required.
However, in many advanced machine post-processors, other machine commands are executed as
part of the connection scenario. In particular, the proper machine setting is defined at the END OF
CONNECTION block: a work-plane may be defined, RTCP may be set, etc. This is critical for the
subsequent motions that follow the “non-connection”. However, if no connection process takes place,
these commands will not be created in the output file, with serious consequences!
The CONNECT IN PLACE block solves this problem by being invoked by GPP2 whenever a regular
connection scenario is not invoked because the machine is already positioned on the target point. In
such cases, the single CONNECT IN PLACE block replaces the whole connection process (including
the BEGINNING OF CONNECT block, the scenario actions and the END OF CONNECT block). The
EX2 program can set the machine parameters as required for the motions ahead – just like it does
today in the END OF CONNECT block. In order to avoid program duplication, this is usually
implemented with a GPP2 procedure that is called from both places.
The CONNECT IN PLACE block has no system variables.

5.6.5 Force Regular Connection in an “In-Place Connection” situation

There are cases where the start point of a new procedure (or cutting segment within a procedure for
that matter) is in the exact same point where the previous procedure ended. This is referred to as “In-
Place Connection”. There is a connection although no motion is needed. This situation is what
happens at the beginning and end of a 5X-Connection procedure, and can also happen between any
other two procedures.
Regularly, in these cases, the CONNECT IN PLACE block is invoked and GPP2 skips the regular
connections.
The system flag FORCE_CONNECT_IF_INPLACE can be used to force regular connections in these
cases. It must be set in the STARTUP block and its default value is FALSE_. If set to TRUE_ regular
GPP2 connections are forced and the CONNECT IN PLACE block is not invoked.
In order to have an indication if a connection is forced or not, use the system flag CONNECT_FORCED.
Its default value is FALSE_. If a regular GPP2 connection was forced, GPP2 will set it to TRUE_ before
BEGINNING OF CONNECT and back to FALSE_ after END OF CONNECT.
CimatronE 10.0 GPP2 User Guide ⎪237

5.7 5-Axis Drill

5X drill procedures are often characterized by a different orientation for each hole. Two points need to
be taken into account regarding 5X drill cycles:
• Connections: A full connection may be required between two cycles if they differ by the axes
angles by more than given values. These values are determined by the CYC_CON_ALPHA and
CYC_CON_BETA variables. See a detailed discussion about cycle connections in the GPP2 Theory
of Operation manual.
• Work planes: for rotating head machines, it may be necessary to define a work plane that will be
aligned with the hole orientation (or the machine will not be able to execute the drill cycle). In 5X
drill procedures, GPP2 calculates a UCS at the center of each hole. The UCS parameters may be
used to define a work plane in the hole point. See discussions on work planes below.

5.8 Thread Mill Cycle

CimatronE Auto-Drill procedure supports, among other things, a special thread-mill cycle, which is not
supported by the legacy Drill procedure. This cycle contains several dedicated parameters, and is
expected to be executed by the machine itself, like other drill cycles.
However, many machines and controllers do not include built-in thread mill cycles. In such cases, the
cycle has to be executed using standard milling operations (linear and circular motions). The cycle
needs to be “exploded” to multiple milling motions. This used to be done inside the post-processor
(GPP or GPP2) program, and was usually limited to the basic thread mill behavior. Options like
multiple passes (at different depth) or tapered threads were hard to implement.
The feature in GPP2 does all that automatically, breaking the thread mill cycle into multiple milling
motions (if so desired). Every standard PP can handle thread milling with no modifications needed in
the PP at all.
See below for information on how to use the new feature, how to invoke it selectively even if the
machine does support thread mill cycles, and the various GPP2 variables that control execution.
Invoking GPP2 Thread Mill Processing
GPP2 will invoke the thread mill process (breaking the cycle into multiple milling motions) when the
toolpath contains a thread-mill cycle (cycle type 14, variable CYCLE_SUB is 14) and the PP does not
contain any block to handle this cycle (no CYCLE block with qualifier “specialon” or “special”). This
indicates to GPP2 that the PP has no capability to handle thread-mill cycles through the machine, and
the cycle is exploded.
Another way to invoke the cycle breakup process is available to the PP developer, from within the
CYCLE block (any cycle type). For instance, suppose the machine can handle simple thread-mill
cycles, but cannot handle tapered thread-mill cycles. In that case, the PP developer can check for
tapered angle (see variables later), and if non-zero, raise a new GPP2 system flag
(TRD_BREAK_MOTIONS) to TRUE_ (and not send anything to the machine). This instructs GPP2 to
start the whole exploded thread-mill process.
CimatronE 10.0 GPP2 User Guide ⎪238

See relevant variables in 4.10.1.8 Block: CYCLE.

Note that not all parameters are actually set by the user as part of the Auto-Drill procedure. Some are
internal to GPP2 and can be modified inside the EX2 program if the default values are not suitable.
Others are received from the NC file.
Notes:
• Auto-drill does not automatically support external threads, because it only identifies holes, not
cylinders. However, it can be used for external thread milling, by manually selecting the points in
the center of the cylinder top.
• If the stock width does not divide perfectly to the side step, then the following algorithm is applied
(similar to Profile procedure): the first passes differ by full side step, and the last pass removes the
remainder. This way, a “finish” pass can be programmed.
• The approach radius parameter is not always adhered to. If the gap between the tool and the hole
is too small – a smaller approach radius will be used. The maximum radius used is half the
difference between the thread radius and the tool radius.
• When helical approach and retract are used, note that the tooltip will slightly descend below the
hole defined depth (either in the approach in bottom-up mode, or in the retract in top-down mode).
The maximum additional depth is equal to 1/8 of the thread pitch.
• In tapered threads, the nominal diameter is always taken to represent the diameter at the top of
the thread, both for internal and external threads. The taper direction is “inside” for internal threads
(diameter becomes smaller with depth) and “outside” for external threads (diameter grows with
depth). That way, undercuts are avoided. Milling direction (top-down or bottom up) has no effect on
diameters or the taper direction.
• A work-around can be applied for using GPP2 thread milling inside legacy drill. It requires marking
the procedure in some way (e.g., special comment, or just choosing one other cycle type to
represent thread-mill). Inside the PP, the EX2 program must recognize the special marking and set
the TRD_BREAK_MOTIONS flag.
Caution: Special care must be given to the parameters, such as nominal diameter and pitch, since
they are not provided by the legacy drill procedure. Such parameters can be given through user-
defined parameters and must be copied by the EX2 program to the proper thread-mill parameters
before invoking the TRD_BREAK_MOTIONS flag.
• The GPP2 thread-mill procedure also supports “dumb” rotary head machines, where a work-plane
cannot be defined. When the thread axis is not aligned with the machine Z axis, GPP2 explodes
the thread mill cycle to full 3-axes linear motions (no arcs are generated). In addition, 2D cutter
compensation is disabled in such cases.
CimatronE 10.0 GPP2 User Guide ⎪239

5.9 Inverse Time Feed Rate

In 4/5X machines, it is sometimes required to use the “Inverse Time” feed rate mode, which helps the
controller maintain a constant feed rate at the cutting point, regardless of the axes moved and the
distance between the cutting point and the rotation axis.
In order to use this mode, it is necessary to know the actual distance of each feed-rate cutting motion
(linear or circular) and to divide the required feed rate by that length.
GPP2 provides two new variables to allow the EX2 program to use this mode whenever desired:
MOTION_LENGTH // actual length of motion

INVERSE_TIME_FEED // value of MCH_FEED divided by motion length

GPP2 verifies that the value assigned to the INVERSE_TIME_FEED variable is never larger than the
maximum value that can be formatted for output for the FEED format. This abnormal situation could
happen if the motion length is extremely small.
Whenever the EX2 program needs to use the Inverse Time mode, it can simply output the value of
INVERSE_TIME_FEED instead of MCH_FEED. The MOTION_LENGTH variable is not absolutely
necessary, and is given mostly for reference.

5.10 Managing Advanced 5-Axis Machines

Advanced 5X machines support complex features such as RTCP (e.g., M128) and the definition of
work planes. In order to properly manage such machines, it is necessary to continuously “synchronize”
GPP2 with the machine controller behavior.
For instance, in rotating table machines, setting a slanted work plane effectively moves the controller
zero point (it may have been moved by the rotation).
On the other hand, in rotating head machines, using a slanted work plane actually rotates the UCS
used by the machine controller, so that the Z axis is aligned with the slanted tool.
In order to properly control the machine, all these changes in the machine behavior must be “told” to
GPP2.

5.10.1 Set Output UCS

With advanced 5X machines, it is often required to output the G-code in reference to another UCS, not
the original “home” UCS. In some cases, the zero point needs to be shifted – for instance to the
current procedure UCS zero point. In other cases, the output UCS orientation must be changed.
The rule is simple – the output UCS must be the same UCS in which the machine controller is
expecting coordinates.
GPP2 provides one statement to control the UCS it uses as the “output” UCS.
SET_OUTPUT_UCS <position> <orientation>;
CimatronE 10.0 GPP2 User Guide ⎪240

The <position> argument may be one of the following predefined GPP constants:

POS_RESET Sets the output UCS position to (0,0,0) – the default position.
The output UCS zero is the same as the REF UCS zero. This
is the original machine home position.

POS_REF Sets the output UCS position to the position of the REF zero
point (taking the table rotation into consideration). This is the
home position as viewed on the table (or in Cimatron NC).

POS_PROC Sets the output UCS position to the position of the current
procedure UCS. All output coordinates will be referenced to
the procedure UCS (as in CimatronE NC TP list).

POS_BY_VARS Sets the output UCS position to the position stated in the
following three variables: X_NONROT_UCS, Y_NONROT_UCS
and Z_NONROT_UCS. The variables should be set to the
desired position before the command is used.

POS_NO_CHANGE This constant is in fact identical to POS_BY_VARS, and uses

the data in the three variables. It is only provided for better
EX2 program clarity.

POS_NO_CHANGE is used when the output UCS position needs to stay unchanged (the command is
used to change the orientation only). The three position variables must not be modified and
POS_NO_CHANGE used.
Making changes to the output UCS position variables (X_NONROT_UCS, etc.) and using
POS_NO_CHANGE will not work as expected. POS_NO_CHANGE is really identical to POS_BY_VARS, so
the position will be changed according to the values in the position variables.
CimatronE 10.0 GPP2 User Guide ⎪241

The <orientation> argument may be one of the following predefined GPP constants:

ROT_RESET Sets the output UCS orientation to be parallel to the REF

UCS – the default orientation.

ROT_PROC Sets the output UCS orientation to the current procedure

UCS orientation.

ROT_WORKPLANE Sets the output UCS orientation to the one calculated with the
CALC_WORKPLANE_UCS statement.
See section on CALC_WORKPLANE_UCS for more detailed
discussion on calculating work planes.

ROT_CURPOS Sets the output UCS to a UCS that is calculated based on the
current (or connection) point orientation. The UCS Z vector is
the current point IJK vector, and the UCS X vector is an
arbitrary vector perpendicular to it.
Also valid inside a connection scenario, using the connection
IJK.
Must be used in conjunction with the VA_CURPOS option of
the CALC_VIRTUAL_ANGLES statement.

ROT_BY_VARS Sets the output UCS orientation to the one defined by the
following six variables: I_NONROT_UCS, J_NONROT_UCS and
K_NONROT_UCS define the UCS Z axis direction, and
IX_NONROT_UCS, JX_NONROT_UCS and KX_NONROT_UCS
define the UCS X axis direction.
The variables should be set to the desired values before the
command is used.

ROT_NO_CHANGE This constant is in fact identical to ROT_BY_VARS, and uses

the data in the six variables. It is only provided for better EX2
program clarity.

ROT_NO_CHANGE is used when the output UCS orientation needs to stay unchanged (the command is
used to change the position only). The six orientation variables (I_NONROT_UCS, etc.) must not be
modified and ROT_NO_CHANGE used.
CimatronE 10.0 GPP2 User Guide ⎪242

Examples:
SET_OUTPUT_UCS POS_RESET ROT_RESET;
// reset output UCS (this is the default setting)
SET_OUTPUT_UCS POS_PROC ROT_NO_CHANGE;
// shift zero point to the current procedure zero – leave orientation as is
SET_OUTPUT_UCS POS_PROC ROT_PROC;
// output UCS is now identical to the current procedure UCS
SET_OUTPUT_UCS POS_NO_CHANGE ROT_WORKPLANE;
// rotate output UCS according to work plane orientation – leave zero point unchanged
The values of the current GPP output UCS are always shown in the following global system variables:

X_OUTPUT_UCS Output UCS zero point (expressed in REF UCS terms)

Y_OUTPUT_UCS
Z_OUTPUT_UCS
I_OUTPUT_UCS Output UCS Z axis direction (expressed in REF UCS terms)
J_OUTPUT_UCS
K_OUTPUT_UCS
IX_OUTPUT_UCS Output UCS X axis direction (expressed in REF UCS terms)
JX_OUTPUT_UCS
KX_OUTPUT_UCS

Each time the SET_OUTPUT_UCS statement is executed, these nine variables are set to reflect the new
output UCS. Note that in some cases, the variables are also used as input to the command (when
POS_BY_VARS is used).
CimatronE 10.0 GPP2 User Guide ⎪243

In addition to these nine variables, GPP2 also updates another set of nine variables, that describe the
same UCS, but ignoring the table rotation. These variables will be needed later to set the machine to
match the GPP settings.

X_NONROT_UCS Output UCS zero point (expressed in REF UCS terms –

Y_NONROT_UCS without any table rotations)
Z_NONROT_UCS
I_NONROT_UCS Output UCS Z axis direction (expressed in REF UCS terms –
J_NONROT_UCS without any table rotations)
K_NONROT_UCS
IX_NONROT_UCS Output UCS X axis direction (expressed in REF UCS terms –
JX_NONROT_UCS without any table rotations)
KX_NONROT_UCS

For instance, in order to shift the zero point to the current procedure origin, the machine may need a
“DATUM SHIFT” command. This command needs the position vector before any rotations – this data
will be available in the X_NONROT_UCS, Y_NONROT_UCS and Z_NONROT_UCS variables.

5.10.1.1 SET_OUTPUT_UCS Improvement

One of the advanced options of the SET_OUTPUT_UCS command is to set the position and/or the
rotation of the output UCS by explicitly setting the UCS by variables. See the POS_BY_VARS and
ROT_BY_VARS options.
When using one of these options, the EX2 program needs to set the output UCS variables
(X_OUTPUT_UCS to Z_OUTPUT_UCS for position, I_OUTPUT_UCS to K_OUTPUT_UCS and
IX_OUTPUT_UCS to KX_OUTPUT_UCS for rotation) before it uses the SET_OUTPUT_UCS command. It
was necessary to define these variables taking into account any table rotation that exists at that
moment. These variables refer to the output UCS in the machine (REF) coordinate system, and thus
include any table rotation and translation.
However, the PP programmer may find it easier to define the “non-rotated” output UCS – the output
UCS as seen on the part itself, ignoring any table rotation. In such a case, GPP2 would apply the table
rotation and translation and simplify the process for the PP developer.
In order to take advantage of this method, the EX2 program needs to set the “non-rotated” output UCS
variables before invoking the SET_OUTPUT_UCS command:
X_NONROT_UCS, Y_NONROT_UCS and Z_NONROT_UCS define the UCS zero position
I_NONROT_UCS, J_NONROT_UCS and K_NONROT_UCS define the UCS Z axis orientation
IX_NONROT_UCS, JX_NONROT_UCS and KX_NONROT_UCS define the UCS X axis orientation
When using the POS_BY_VARS option, the 3 position variables should be set.
When using the ROT_BY_VARS option, the 6 orientation variables should be set.
CimatronE 10.0 GPP2 User Guide ⎪244

5.10.2 Calculating the Work Plane UCS

In rotating head machines (table-head or head-head), setting a work plane results in the rotation of
the machine controller UCS. The controller UCS Z axis becomes aligned with the tool axis, so the
machine can perform drilling and 2.5X subroutines.
This case is illustrated in the image below, where the rotated controller UCS is shown as
REF_UCS_ROTATED (and is aligned with the tool).

X=12

Z=38

REF_UCS_ROTATED

In order for GPP2 to continue and communicate well with the controller, the GPP2 output UCS must
be redefined to be the same as the rotated controller UCS. The new Z axis is easy to tell – it is
aligned with the tool IJK (that’s why the head was rotated in the first place). However, the new X axis
of the controller UCS is not so simple to find. It is rotated with the head, but where to exactly?
GPP2 provides a statement to calculate the machine controller UCS under head rotations. The result
from this calculation is later used to set the output UCS orientation (see examples later).
CALC_WORKPLANE_UCS <mode> <alpha> <beta> ;
CimatronE 10.0 GPP2 User Guide ⎪245

The work plane <mode> may be one of the following predefined GPP2 constants:

WP_BETA Rotate the REF UCS around the machine beta axis only.
This mode is suitable for table-head machines, where only
the head rotation (beta) affects the controller UCS orientation.

WP_ALPHA_BETA Rotate the REF UCS around both the machine alpha and
beta axes. This mode is suitable for head-head machines,
where both axis rotations affect the controller UCS
orientation.

WP_ALPHA Rotate the REF UCS around the machine alpha axis only.
This mode is provided for completeness – it is not clear if it
ever needs to be used.

The results from the CALC_WORKPLANE_UCS statement are as follows:

I_WORKPLANE The resulting work plane UCS Z axis direction

J_WORKPLANE
K_WORKPLANE

IX_WORKPLANE The resulting work plane UCS X axis direction

JX_WORKPLANE
KX_WORKPLANE

After use of CALC_WORKPLANE_UCS, GPP2 is typically instructed to rotate its output UCS to the
calculated orientation, using the SET_OUTPUT_UCS command.
Examples:
For a table-head machine
CALC_WORKPLANE_UCS WP_BETA 0 B_CURPOS; // beta only
SET_OUTPUT_UCS POS_NO_CHANGE ROT_WORKPLANE; // set output UCS
For a head-head machine
CALC_WORKPLANE_UCS WP_ALPHA_BETA A_CURPOS B_CURPOS; // alpha & beta
SET_OUTPUT_UCS POS_NO_CHANGE ROT_WORKPLANE; // set output UCS
CimatronE 10.0 GPP2 User Guide ⎪246

5.10.3 Virtual Axes Rotation Angles

In some machines, it is possible to define work planes by using rotation angles around virtual axes (X,
Y and Z) – regardless of the machine axes geometry. Three virtual rotation angles define a unique
rotation matrix, accurately defining the orientation of all three axes.
There are two methods for virtual axis rotations: Euler angles and Spatial angles.
• Euler angles define rotations around three axes (e.g., around Z, then around Y, then around X),
where the second and third rotations are done around the new direction of the virtual axis. For
instance, if the first rotation around the Z axis was 20 degrees, then the second rotation (around Y)
will be done around a new Y direction (rotated in 20 degrees).
• Spatial angles also define rotations around three axes (e.g., around X, then around Y, then around
Z), but the rotations are always done around the original axes directions. For instance, if the first
rotation is 20 degrees around X, then the second rotation will still be around the original Y direction
(not the rotated Y).
Note: there is an interesting mathematical correlation between Euler and Spatial angles – the same
angles are used to obtain the required rotation, but in the reverse order. For instance, Euler rotations
in the order Z Æ Y Æ X give the same rotation matrix as Spatial rotations in the order X Æ Y Æ Z
using exactly the same rotations around the three axes.
GPP2 provides a statement to calculate virtual axes rotation angles, which can be used on the
machine.
CALC_VIRTUAL_ANGLES <ucs>
The <ucs> argument specifies which UCS should be used for the virtual axes calculation. One of the
following predefined constants may be used for the <ucs> argument:

VA_PROC Current procedure UCS.

VA_CURPOS A UCS that is defined by the current point orientation. The UCS Z
vector is the current point IJK vector, and the UCS X vector is an
arbitrary vector perpendicular to it.
Mostly used in 5X drill, where virtual angles must be used to define
the work plane for each cycle, based on the hole IJK orientation.
Also valid inside a connection scenario, using the connection IJK.
Must be used in conjunction with the ROT_CURPOS constant in the
SET_OUTPUT_UCS statement.

VA_BY_VARS Use the non-rotated output UCS, as calculated in the

SET_OUTPUT_UCS statement.
This UCS is stored in the following variables:
Z axis: I_NONROT_UCS, J_NONROT_UCS and K_NONROT_UCS.
X axis: IX_NONROT_UCS, JX_NONROT_UCS and KX_NONROT_UCS.
CimatronE 10.0 GPP2 User Guide ⎪247

The type and order of rotations is defined in the variable VIRTUAL_AXES, which must be set using
one of the following predefined GPP constants:

VIRTUAL_AXES_NONE Virtual angles are not used

EULER_ZYX Euler angles, order of rotations Z Æ Y Æ X

EULER_ZXY Euler angles, order of rotations Z Æ X Æ Y

EULER_XYZ Euler angles, order of rotations X Æ Y Æ Z

EULER_YXZ Euler angles, order of rotations Y Æ X Æ Z

EULER_ZXZ Euler angles, order of rotations Z Æ X Æ Z

EULER_ZYZ Euler angles, order of rotations Z Æ Y Æ Z

SPATIAL_ZYX Spatial angles, order of rotations Z Æ Y Æ X

SPATIAL_ZXY Spatial angles, order of rotations Z Æ X Æ Y

SPATIAL_XYZ Spatial angles, order of rotations X Æ Y Æ Z

SPATIAL_YXZ Spatial angles, order of rotations Y Æ X Æ Z

SPATIAL_ZXZ Spatial angles, order of rotations Z Æ X Æ Z

SPATIAL_ZYZ Spatial angles, order of rotations Z Æ Y Æ Z

The VIRTUAL_AXES variables must be set before the CALC_VIRTUAL_ANGLES statement is used.
Typically, it will be set in the STARTUP block, as part of the machine definition process.
Most known machines use Spatial angles with order X Æ Y Æ Z or Euler angles with order Z Æ Y Æ
X.
The results from the CALC_VIRTUAL_ANGLES statement are as follows:

VIRTUAL_ANGLE_1 The three virtual axes rotation angles, in degrees.

VIRTUAL_ANGLE_2
VIRTUAL_ANGLE_3
CimatronE 10.0 GPP2 User Guide ⎪248

Examples:
VIRTUAL_AXES = SPATIAL_XYZ;
...
SET_OUTPUT_UCS POS_PROC ROT_PROC; // current procedure UCS
CALC_VIRTUAL_ANGLES VA_PROC; // calculate angles for it

5.10.3.1 Incremental Rotations

In some case, incremental rotation angles are required, rather than standard ones.
• Standard virtual axes rotation angles define how a “unit” or “world” UCS should be rotated in order
to get to the desired UCS.
• Incremental virtual axes rotation angles define how the currently rotated UCS should be rotated
again in order to get to the desired UCS. The currently rotated UCS is the UCS that was used to
calculate the rotation angles “last time”.
GPP2 supports incremental calculations by setting a new variable, VIRTUAL_ANGLES_INCR, to
TRUE_ (1). By default the variable is set to FALSE_ (0).
GPP2 keeps the UCS used for the “last” calculation. If incremental calculation is turned on, that saved
UCS is used as the “reference” for the next calculation.

5.10.4 Setting the Axes Zero Points

Some machines support the definition of multiple “homes” on the machine, each with its own XYZ
origin and its own orientation. For such a “home”, the angle zero points are also redefined (so sending
the alpha axis to 0 will reach the new home orientation, not the original REF zero orientation).
The SET_OUTPUT_UCS statement allows the definition of a new home zero position (e.g., to the current
procedure zero point). However, it does not affect the rotary axes zero points.
In order to allow GPP2 to output correct angles in such a case, it is necessary to define the zero point
of each rotary axis. This is done with the two new system variables, M5_A_ZERO and M5_B_ZERO.
These variables should be set in conjunction to setting a new machine home (e.g., with M55 machine
code).
Examples:
M5_A_ZERO = A_CURPOS; // set the zero at the current angle
M5_B_ZERO = B_CURPOS;
CimatronE 10.0 GPP2 User Guide ⎪249

5.11 Indexed Machine Axes

Some 5X machines use non-continuous rotary axes, also known as indexed axes. These axes can be
placed at discrete positions only, for instance in steps of 2.5 degrees. Values in between are not
possible.
Such machines are not well suited for continuous 5X milling, but can be used for positioning (3X + 2X
milling) – provided that the positioning angle fits the axis step size.
The definition of the alpha or beta axis as an indexed axis is done using the M5_A_STEP and
M5_B_STEP variables respectively. They should be set to the allowed step size of the axis, expressed
in degrees. By default, both these variables are assigned zero, which indicates continuous motion.
Note that the variables must be set before the DEFINE_MACHINE statement is used.
For instance, setting M5_A_STEP to 2.5 means that the alpha axis can only accept values that divide
by 2.5 (0.0, 2.5, 5.0, 7.5, -2.5, etc.). Other values, such as 2.0 degrees are illegal.
For an indexed axis, GPP2 will always round the angle position according to the axis step size. Note
that this may cause a tool orientation error, depending on the required tool orientation. There are two
variables that indicate such an orientation error:
• INACCURATE_ORIENT is set to TRUE_ whenever an axis angle (any indexed axis) is not as
required by the toolpath (within angle formatting accuracy). Otherwise, it is FALSE_.
• INACCURATE_ERROR contains the orientation error, in degrees, between the intended and the
resulting tool orientation vectors.
The EX2 program can use these variables to identify cases of inaccurate positioning, and to decide if
processing may continue or not (e.g., depending on the error size).
In addition to setting these variables, GPP2 will issue a runtime warning to indicate the orientation
error.
Note that in 3X + 2X positioning procedures, the target angles are calculated as part of the procedure
connection process. Any rounding and orientation errors are well known at that point. Therefore, the
two orientation error variables are set as early as the BEGINNING OF CONNECT block. The decision
whether to continue processing or to abort it can be taken by the EX2 program before any connection
motions.
CimatronE 10.0 GPP2 User Guide ⎪250

5.12 6 Axes Machines – Reconfiguration

GPP2 can handle 6 axes machines through a new feature of machine reconfiguration. At any given
time, only 5 axes can be controlled by GPP2. The sixth axis must be “locked” in a fixed position.

5.12.1 Re-configuration Process

The following process must be followed in order to change the configuration of the machine defined for
GPP2:
• The EX2 program requests re-configuration to take place.
• In response, GPP2 invokes a new RECONFIG MACHINE block, as soon as it can.
• Inside that block, the EX2 program redefines the machine configuration (e.g., the head orientation
or even the machine type). It also outputs the necessary G-code commands to cause these
changes on the machine.
• Following the block, GPP2 recalculates the next steps according to the new machine configuration.
Do not ever try to reconfigure a machine outside the RECONFIG MACHINE block. GPP2 employs
extensive look-ahead techniques (where future points have been calculated based on the current
configuration). After this special block, GPP2 re-calculates its look-ahead data to fit the new
configuration.

5.12.2 When and How to Request Reconfiguration

Machine reconfiguration is requested by setting the REQUEST_RECONFIG system flag to TRUE_. This
tells GPP2 that machine reconfiguration is required.
Machine re-configuration is a delicate and complex topic. There are only several points where the EX2
program can request re-configuration. In other places, the flag is ignored.

5.12.2.1 In the START PROC Block

This is the last block in each procedure “header” process. The procedure (connection) motions start
immediately after this block.
In that block, the EX2 program already has a lot of information regarding the procedure. It can use this
information in order to make a decision regarding re-configuration. This information includes the
procedure type and name, the number of axes, the tool being used, and the procedure origin. In many
cases, this is enough to make a decision regarding the machine configuration.

5.12.2.2 In the BEGINNING OF CONNECT Block

Connections take place in several points in GPP2. In most cases, a connection takes place before the
actual procedure motions (immediately after the START PROC block). Connections also take place
between toolpath “segments” in 5X continuous milling, and optionally between cycles in 5X Drill.
The BEGINNING OF CONNECT is a very good place to make decisions based on the target angles of
the rotary axes (given in A_CONNECT and B_CONNECT). For instance, if the table’s tilt angle is above,
CimatronE 10.0 GPP2 User Guide ⎪251

say, 50 degrees, a reconfiguration of the tool orientation may be done to keep the table more
horizontal.
If the REQUEST_RECONFIG flag is set during a BEGINNING OF CONNECT block, the whole connection
process is aborted. Instead, the RECONFIG MACHINE block is invoked. Only after the machine is re-
configured, a new connection starts, taking into account the new configuration (and hence new target
angles).

5.12.2.3 In the LINEAR MOTION Block

It is also possible to request reconfiguration in the LINEAR MOTION block, even during feed rate
(cutting) motions. Clearly, this is not the best place to do so, since the tool has to leave the material in
order to do the reconfiguration (which would leave a mark on the material).
If absolutely necessary, the EX2 program can raise the request flag during any linear motion block,
and it will be acknowledged within one or several motions.
In order to minimize the mark on the material, GPP2 will perform an orderly retract from the material
(tangential or normal), exactly as it does when 5X solutions need to be swapped. Once it is far away
from the part, the RECONFIG MACHINE block will be called.
If necessary, GPP2 will make a connection to the new position above the part (that connection may be
necessary due to the reconfiguration), and will approach the cutting point again, in an orderly manner,
before continuing with the procedure motions.
Important note - in addition to requesting a reconfiguration, the EX2 program must also execute the
LINEAR MOTION block (output the coordinates). This toolpath point will not be repeated after re-
configuration.

5.12.2.4 Between CYCLE Block

It is not possible to request re-configuration inside CYCLE blocks. If re-configuration is desired after a
given cycle block, the EX2 program should initiate a connection after the cycle and request re-
configuration in the resulting BEGINNING OF CONNECT block.

5.12.3 The RECONFIG MACHINE Block

This new GPP2 block is called when GPP2 is ready for the machine to be redefined, using the
DEFINE_MACHINE statement.

The EX2 program should do the following tasks inside that block:
• Output any commands needed to the machine in order to bring it to the new configuration (e.g.,
rotate the head or one of the table axes).
• Re-assign any GPP2 variables (e.g., tool orientation vector) that are relevant to the new machine
definition.
• Call the DEFINE_MACHINE statement, with the new configuration. Note that this call must take
place even if the statement arguments are the same each time. GPP2 reads in many other
variables as response to this command.
CimatronE 10.0 GPP2 User Guide ⎪252

• In some cases, the rotary axes angles must be reset (A_CURPOS, A_LASTPOS, B_CURPOS and
B_LASTPOS). This is especially important when the machine type is being changed (e.g., from
Table-Table to Table-Head), since the actual roles of these variables change completely.
• It is wise to record the new configuration in a user variable (e.g., Vertical vs. Horizontal head) for
future processing.

5.12.4 Scenario Connections in 6-Axis Machines

When multiple machine configurations are used, multiple connection scenarios will be needed as well.
This is especially true for machine reconfiguration that changes the basic type of the machine in GPP2
(e.g., from Table-Table to Table-Head).
In most cases, the EX2 developer will have to provide two scenarios for each connection type (short,
long, etc.), and select the relevant scenario based on the current machine configuration.
CimatronE 10.0 GPP2 User Guide ⎪253

5.12.5 Example 1 – Vertical and Horizontal Head

Consider the following machine. It has two rotating axes on the table, one around the X axis and
another around the Z axis. In addition, its head can be places in one of two positions – vertical or
horizontal (parallel to the Y axis). Using the head horizontally, allows less tilting of the table major axis.

Head in Horizontal
Position
Head in Vertical
Position

Z
Second Table
Y Axis (Z)

First Table
Axis (X)

The EX2 program may request re-configuration whenever the table X axis becomes too tilted, say
above 60 degrees. By changing the head to the other position, it will be possible to continue
machining the part with a smaller tilt angle.
The machine geometry changes each time the head is switched to a different position. We can usually
assume that the controller will be able to maintain proper position of the tool regardless of the change
(in other words, the zero point does not move). However all the 5X angle calculations change because
of the different tool orientation. The following EX2 statements may be used to re-configure the
machine in both cases.
When changing to Horizontal head:
M5_TOOL_I = 0;
M5_TOOL_J = 1;
M5_TOOL_K = 0;
DEFINE_MACHINE TABLE_TABLE AX5_PX AX5_PZ; // Recalculate

When changing to Vertical head:

M5_TOOL_I = 0;
M5_TOOL_J = 0;
M5_TOOL_K = 1;
DEFINE_MACHINE TABLE_TABLE AX5_PX AX5_PZ; // Recalculate

These statements must be executed in the RECONFIG MACHINE block. Of course, other statements
are used to actually instruct the machine to change its head position.
CimatronE 10.0 GPP2 User Guide ⎪254

5.12.6 Example 2 – Full 6-Axis Machine

Now consider a similar machine, but this time the head can freely rotate around the X axis. This
machine has 3 rotary axes, two on the table (X and Z) and one on the head (X).
GPP2 cannot control 3 rotary axes simultaneously. The user has to select which axes are active at
any given time, and configure the machine accordingly. For the machine described here, either the
head or the table X axes are stationary, probably at angle zero.

Rotating Head
(X)

Z
Second Table
Y Axis (Z)

First Table
Axis (X)

When the head axis is locked in place, this machine behaves as a Table-table (X-Z) machine.
However, when the table X axis is locked, the machine behaves like a Table-Head machine (Z-X). It
means that different arguments must be given to the DEFINE_MACHINE statement in each case.
Clearly, it also requires different connection scenarios.
Note that the role of the major angle variable changes. In the Table-Table configuration, A_CURPOS
and A_LASTPOS refer to the table X axis. In the Table-Head configuration, they refer to the table Z
axis. Similar dramatic changes take place regarding B_CURPOS and B_LASTPOS.
Therefore, whenever the configuration is changed, the EX2 program has to modify these variables
according to the new configuration.
CimatronE 10.0 GPP2 User Guide ⎪255

5.13 Machine Simulation

GPP2 can provide data for the machine simulator, in a way that closely matches the generated G-
code. It creates a machine simulation motion using the actual alpha and beta angles used for the G-
code output.
GPP2 generates a motion on the machine simulation on each of the following cases:
• A linear motion
• A circular motion (broken to multiple linear motions)
• A drill cycle (simulated with linear motions)
• In response to the MOVE_MANUAL command (linear motion)
• In response to each 2.5X subroutine call. GPP2 does not generate the full simulation of the
subroutine. Instead, it generates one linear motion that represents the delta vector of the called
subroutine. In order to see the full subroutine motions, GPP2 must be run with the
SUBS_CTRL_BYPLANE variable set to DEF_NONE (so all subroutines are exploded).

5.13.1 Machine Simulation Output

The machine simulator is essentially a “bare” machine. It does not support features like RTCP, tool
length compensation or work planes. Therefore, the coordinates that GPP2 provide to the simulator
may be different than the ones listed in the G-code file.
Nevertheless, the simulated data correctly represents the machine motions even with “smart”
machines – GPP2 simply converts the “smart” data (e.g., including RTCP) with the “raw” data, suitable
for the machine simulator.

5.13.2 Safe Position

After a tool change, the exact tool position is not known in the current REF coordinate system (since
the zero can be anywhere, and the tool change position is fixed in the machine).
The G-code that is generated during a connection from the “safe position” does not assume any
known previous position. It carefully moves the tool, first in the XY plan, and then lowering it in the Z
axis.
However, the machine simulation must always be told the exact position, in all dimensions. It does not
accept a command like X30 (and no change in Y or Z). In order to properly display the tool motions
when coming from the safe position, several variables have been added to define the safe position.
Five variables are available to define the safe position (X_SAFE_POS, Y_SAFE_POS, and Z_SAFE_POS)
and orientation (A_SAFE_POS and B_SAFE_POS).
The safe position is defined in terms of the “MACHINE”, since it is not dependent on the REF UCS
position. This position is “hard wired” in the machine. The safe position is defined relative to the
machine anchor point – usually the center of the table.
CimatronE 10.0 GPP2 User Guide ⎪256

In 5X machines, the relationship between the machine anchor point and the machine REF UCS is
defined by the X/Y/Z_MACH vector.
Note – these variables have no effect on the output code. The do not have to be accurate, and are
only used to bring the simulator to a position that is similar to the safe position.

5.13.3 Move to Safe Request

It is possible to instruct GPP2 to move to the safe position. This is useful at the end of the run, or in
conjunction with a tool change.
In order to instruct GPP2 to move, the EX2 program has to set the GPP2 system flag,
MOVE_TO_SAFE, telling GPP2 which axes to move. MOVE_TO_SAFE must be set to a string that
contains one or more of the axis letters, X, Y, Z, A and B. Uppercase or lower case letters may be
used.
Examples:
MOVE_TO_SAFE = “XYZAB”; // move to safe position in all axes
MOVE_TO_SAFE = “XYZ”; // move linear axes only
MOVE_TO_SAFE = “Z”; // move up only
Several requests may be used in a series, instructing GPP2 to move the axes in any desired order.
For instance:
MOVE_TO_SAFE = “Z”; // move up only
MOVE_TO_SAFE = “XY”; // now move sideways
Note that GPP2 does not invoke any block or generate any G-Code motions in response to this
request. Creating the relevant G-Code must be done by the EX2 program, in conjunction with the
“move to safe” instruction.
What GPP2 does when the MOVE_TO_SAFE system flag is set (to a non-empty string), is to create a
simulator motion to the safe position in the relevant axes. In addition, it ensures that the subsequent
connection will be like after a tool change (since the “safe” position is not exactly known).
The following option instructs GPP2 to retract the tool along its axis:
MOVE_TO_SAFE = “T”; // Retract along tool axis
The motion will last until either of the linear axes limits is reached. In order to enable the calculation of
the retract motion’s length, there is a need to specify these limits in the EX2 file using the following
machine definition variables:
X_MACH_MIN, X_MACH_MAX // min/max linear X limit
Y_MACH_MIN, Y_MACH_MAX // min/max linear Y limit
Z_MACH_MIN, Z_MACH_MAX // min/max linear Z limit
CimatronE 10.0 GPP2 User Guide ⎪257

Note that the linear axes limits are given from the machine-simulator machine zero point (the table
center in most cases). GPP2 considers the part location on the machine table while calculating the
retract motion.
This option can be used to properly simulate the "M140 MB FMAX" Heidenhain command.
Note that the “T” axis cannot be mixed with any other linear axis in the same “move to safe” command.
For instance, MOVE_TO_SAFE = “ZT” is illegal, and will result in a GPP2 runtime error.

5.13.4 Part Position on the Table

It is possible to specify the part position relative to the simulator table center, so that the part is
automatically positioned when the simulator is run.
Three variables, X_SIM_PART_POS, Y_SIM_PART_POS and Z_SIM_PART_POS, define the location of
the Part (REF) UCS zero point relative to the table center. These variables affect the simulator
motions, as well as the part display on the simulator.
Typically, these variables can be set automatically by GPP2, from the X/Y/Z_MACH variables. In fact,
the part position vector is exactly the inverse “MACH” vector.
Note that GPP2 will assign the (inverse) values to the part position variables only if the M5_USE_MACH
variable is set to TRUE_ (this variable indicates that X/Y/Z_MACH contain valid values). Otherwise, the
three part position variables are set to 0.

5.13.5 Simulation Data Order

GPP2 creates an output file for the machine simulation. It turns out that the order of coordinates within
each motion line may vary from machine to machine, because of their internal structure.
The MACH_SIM_ORDER string variable allows control over the order of output coordinates. It is a string
of five characters, such as “XYZAB” or “XYZBA”. It tells GPP2 how to organize the data in the output
file. For instance, “XYZAB” (the default value) creates X first, then Y, Z alpha and beta.

5.13.6 Tool Compensation

The machine simulation accepts a tool compensation length, and GPP2 calculates the length based
on the holder, shank and tool lengths.
However, it turns out that with most machines, the tool compensation is not being done on the
machine simulator. A new variable, MACH_SIM_TOOLCOMP, allows control over that behavior.
If set to TRUE_, GPP2 will apply the tool length compensation by itself, assuming the machine
simulation does not do it by itself. If set to FALSE_, GPP2 will rely on the machine simulator to do the
tool length compensation.

5.13.7 Toolpath Representation

In addition to the motions file, GPP2 also generates a file that draws the toolpath on the part being
machined. That file represents the toolpath in the “PART” UCS. It uses five EX2-controlled colors to
CimatronE 10.0 GPP2 User Guide ⎪258

display different parts of the toolpath:

Motion Default Color GPP2 Variable

Feed Light Blue (0 255 255) ASC_COLOR_FEED

Rapid air motions Yellow (255 255 0) ASC_COLOR_RAPID

Max-feed air motions Green (0 255 0) ASC_COLOR_MAXFEED

Drill cycles Dark blue (0 50 255) ASC_COLOR_CYCLE

Pseudo connection motions Red (255 0 0) ASC_COLOR_CONNECT

The color variables are string variables. It is the EX2 developer responsibility to set them to valid RGB
colors. For instance, if the EX2 developer wishes to change the color of drill cycles to purple, he
should include the following command in the STARTUP block:
ASC_COLOR_CYCLE = “255 0 255”; // Red + Blue make Purple
If required, the five color variables can be set differently for each procedure. For instance, different
colors may be used for 3X and 5X procedures. In order to do that, the color variables may be re-
assigned at the BEGINNING OF PROC block. Note, however, that the use of too many colors is not
recommended.
The “pseudo” connection motions do not truly represent the tool motions during connections. These
motions can be seen when the simulator is invoked. These red lines simply connect toolpath
“segments” (or cycles) to indicate the sequence of toolpath motions.
If the ASC_COLOR_CONNECT variable is set to an empty string, then these pseudo connections are
suppressed.

5.13.8 Using 6 (or More) Axis Machines

With the machine simulator, it is possible to define and control 6 (or more) axes machines. When
writing a post-processor for such a machine, it is very important to be able to view the motions on the
machine simulator.
GPP2 supports up to 9 additional axes on the machine simulator. They can be used in addition to the
basic 5 axes (X, Y, Z, Alpha and Beta). These axes may be linear or rotary.
In order to use such an extra axis, the following steps should be taken:
• The axis letter is defined, using the new GPP2 variables, MACH_SIM_LETTER1 to
MACH_SIM_LETTER9.
• The EX2 program must provide the values to the additional axis, through the new GPP2 variables
MACH_SIM_AXIS1 to MACH_SIM_AXIS9. Typically, these values only change during machine re-
configuration.
• The additional axes must be be specified in the simulator data order variable (so GPP2 will know
CimatronE 10.0 GPP2 User Guide ⎪259

to output them in the simulator motion file). The digits 1 to 9 represent the additional nine axes.
• For instance, setting the MACH_SIM_ORDER variable to “XYZAB1” tells GPP2 to output the
additional axis 1, under the letter specified in MACH_SIM_LETTER1 and with values provided in
MACH_SIM_AXIS1.
In some cases, the additional axes may be used to actually substitute some of the regular machine
axes. For instance, some machines have two “Z” axes, one extending to a given limit and the other
one that can reach further. In such a case, the data provided by GPP2 in Z_CURPOS may be broken to
two other simulator axes (given any appropriate logic).
MACH_SIM_ORDER = “XY12”; // assume no rotary axes
MACH_SIM_LETTER1 = “Z”; // you can use the letter Z for the new axis!
MACH_SIM_LETTER2 = “W”; // this is the secondary Z axis
In each linear motion block, the value of Z_CURPOS will be broken in two, and the two variables,
MACH_SIM_AXIS1 and MACH_SIM_AXIS2 will be assigned the proper values. The data will be output
to the simulator as a 4-axis linear machine.
The following lines demonstrate such EX2 code, assuming that the major Z axis can reach no more
than 500, and the minor Z axis is used above 500. The lines also demonstrate how to output the G-
code numbers.
Regarding the machine simulator output, there is no need to do anything special with the
MACH_SIM_AXIS1/2 variables. It is enough to set their values.
IF_SET (Z_CURPOS) // Z has changed
IF (Z_CURPOS <= 500) // test value against threshold
MACH_SIM_AXIS1 = Z_CURPOS; // major can handle point
MACH_SIM_AXIS2 = 0; // minor not used
ELSE // Z is above 500
MACH_SIM_AXIS1 = 500; // major reaches 500
MACH_SIM_AXIS2 = Z_CURPOS – 500; // minor does the rest
END_IF;
OUTPUT “ “MACH_SIM_LETTER1 MACH_SIM_AXIS1; // create G-code
OUTPUT “ “MACH_SIM_LETTER1 MACH_SIM_AXIS1;
SET_OFF Z_CURPOS; // set off, for next block!
END_IF;

5.13.9 Machine Simulation Output as G-Code

To change the way the coordinates are presented in the Machine Simulation move list window, use
CimatronE 10.0 GPP2 User Guide ⎪260

the variable: SIM_SHOW_GCODE_OUTPUT. If set to TRUE_ the output is changed to be based on the
part zero (not the Machine Simulation zero) and support advanced output modes: WP, RTCP etc’. The
default value is FALSE_ which leaves the output in the standard mode.

5.13.9.1 Formatting the ‘Move List’ Display

GPP2 creates a file for the machine simulator. One option regarding that file is the ability to present
the ‘Move List’ program using G-code coordinate values (which may differ from the actual coordinates
that control the simulator motion, due to RTCP and work-plane use). That option is controlled by the
SIM_SHOW_GCODE_OUTPUT GPP2 variable (when set to TRUE_).
By default, each line in the simulator program shows the block number, followed by the X, Y, Z, A and
C axes. It is possible to customize the output format, controlling the form, content and modality of the
displayed program. Note that this has no effect on the actual simulator motions, only on the way they
are displayed to the user.
The GPP2 string variable, SIM_SHOW_GCODE_FORMAT, defines the output format using regular
characters and special parameter place holders, as follows:
• %X, %Y, %Z, %A, %B: refer to the machine coordinate (X, Y, Z, A and B), including the
corresponding letters (e.g., X30.0). Note that the actual letters used for the A and B axes are
taken from the M5_A_LETTER and M5_B_LETTER variables, respectively.
• %MX, %MY, %MZ, %MA, %MB: refer to the same machine coordinates, but in a modal way,
meaning they will only be output if they have changed since the last line.
• %F: refers to the feed rate (including the letter F, e.g., F300). In rapid motions, instead of the feed
rate, this place holder is replaced by the text found in another GPP2 variable,
SIM_SHOW_GCODE_RAPID (by default: “ “ (nothing)).
• %MF: refers to the feed rate, but in a modal way (only when changed, or when switching between
rapid and feed motions).
• %L: refers to the linear motion code. The actual code is taken from the CODE_LIN_FAST (for rapid)
and CODE_LIN_FEED (for feed), variables respectively. Note that circular motions are converted in
the simulator to linear motions, and will be shown as such.
• %ML: refers to the linear motion code, but in a modal way (basically, when switching between rapid
and feed motions).
• %K: refers to the block number. There is no modal version for this parameter.
• %N: refers to the program sequence number (GPP2 variable SEQ_NUM). There is no modal version
for this parameter.
• %%: can be used to include a single ‘%’ character in the displayed output.
Note: Modal parameters are always displayed on the first procedure motion, regardless of their value
on the last point of the previous procedure.
The default for the new format variable is "BLK %K %X %Y %Z %A %B”.
Example: “%K %ML %MX %MY %MZ %MA %MB %MF”. This will give results that are very similar to the
CimatronE 10.0 GPP2 User Guide ⎪261

actual G-code (modal).

5.13.10 Adding Comments in the Simulator File

The SIM_COMMENT command inserts a comment line in the SIM file.
SIM_COMMENT <string-expression> ;
Typical uses will be to indicate setting RTCP on or off, setting a work-plane (using which angles), and
any other information that may be useful for the user (setting cutter length compensation, coolant,
etc.).
The string can contain any text, including references to any GPP2 variable. GPP2 will replace the
variable reference with the formatted value of the variable. This is used for displaying data such as the
angles used in work-plane definition.
The format to be used is %<var-name>, e.g. %A_CURPOS.
Examples:
SIM_COMMENT “RTCP ON” ;
SIM_COMMENT “Workplane ON, A%A_CURPOS C%B_CURPOS” ;
SIM_COMMENT “Workplane ON, Euler %VIRTUAL_ANGLE_1 %VIRTUAL_ANGLE_2 %VIRTUAL_ANGLE_3”
;
SIM_COMMENT “Datum Shift X%X_OUTPUT_UCS Y%Y_OUTPUT_UCS Z%Z_OUTPUT_UCS” ;

The SUPPRESS_SIM_COMMENTS system flag allows the EX2 program to suppress all comments in
the simulator file. If set to TRUE_, the SIM_COMMENT commands are not executed.
SIM_COMMENT can also be used in standard Machine Simulation output mode. In order to block
sim_comment from being output to standard mode, set the following flag:
SUPPRESS_SIM_COMMENTS = TRUE_ ;

5.13.11 Machine Simulator – In-Motion Collision Checks

The machine simulator checks for in-motion collisions with the stock and part. In order to do so, it
needs to make some assumptions about the behavior of the simulated machine during linear motions.
Essentially, it is assumed that the machine performs linear interpolation when moving from point A to
point B. This is very simple (at least conceptually) as long as no table rotation is involved. When the
linear motion includes table rotation, the term “linear interpolation” can be interpreted in two ways:
• Dumb Machine: the motions are interpolated in the “machine space”. That means each axis is
moved without any regard to the other axes, except for time synchronization (so they all move
together, starting and stopping at the same time).
When the motion involves a large table rotation, such processing could actually cause collision,
CimatronE 10.0 GPP2 User Guide ⎪262

since the linear axes do not make any correction for the intermediate translation of the work-piece
caused by table rotation. The start and end positions may be fine, but intermediary points may
cause collision.
• Smart Machine: the motions are interpolated in the “part space” (also known as RTCP). This
means the linear axes are corrected during their motion to compensate for the linear translation
caused by the table rotation. The start and end positions are the same as the “dumb” machine, but
the intermediate trajectory is different. This machine has a better chance of not colliding with the
stock or the part (assuming, of course, the original motion calculated within CimatronE was OK in
that respect).
The following two images demonstrate the behavior of a machine with and without RTCP, when it
performs a rotation of the head. The “dumb” machine (no RTCP) simply performs an arc between the
start and end points, while the “smart” machine (with RTCP) corrects the spindle location throughout
the motion to achieve a straight line motion between the start and end points. Similar behavior can be
shown for rotating table machines.

By default, the machine simulator assumes a smart machine behavior. The in-motion collision check is
actually done in the “part space”, effectively ignoring any intermediate translation caused by table
rotation. This may be fine for some machines, but not true for others.
Note that a given machine may support RTCP in general (M5_RTCP_M128 inside GPP2), meaning it
can accept XYZ tool positions in the part UCS, and yet to perform perfect RTCP inside the linear
motion itself. The start and end points are perfect – but the motion between them does not make
perfect compensation throughout the linear motion.
It is possible to instruct the machine simulation to assume a dumb machine behavior, making the
linear interpolation in the “machine space” and checking intermediate positions for collision.
To do this, use the SIM_IN_MOTION_CHECK system flag. It is a variable of format ANGLES, meaning it
should be set in degrees. It defines the angular step, in degrees, in which the machine simulation will
check for in-motion collisions. For instance, if set to 1.0, and a given linear motion rotates the table by
5 degrees, the machine simulator will divide the motion into five segments and check the intermediate
CimatronE 10.0 GPP2 User Guide ⎪263

positions for collisions.

By default, the SIM_IN_MOTION_CHECK system flag is set to 0.0, which disables this behavior (the
machine simulator assumes perfect RTCP, smart machine interpolation). The EX2 program must set it
to a different (positive) value in order to activate the more elaborate dumb machine collision testing.
Note that such in-motion collision tests increase the machine simulator processing time. However,
when this is the way the machine really works (machine space interpolation, no intermediate trajectory
correction), such in-motion tests are extremely important.

5.13.12 Additional Spindles in the Machine Simulator

Some machines use a secondary spindle for special tools or functions. To support these additional
spindles in the machine simulator, the GPP2 variable SIM_SPINDLE_NUM (format 6) is used. Its
default value is 0.
If its value is changed to other than zero, for example 1, the following line is added to the SIM file:
“MW_TOOL_ID 1”. This will instruct the machine simulator to mount the tool on spindle number 1
(holder_transform1). If the value is zero, no line is output (so the simulator uses the default spindle).
It is recommended to change the variable inside the TOOL CHANGE block (depending on the tool
number).
CimatronE 10.0 GPP2 User Guide ⎪264

6 Report Customization

6.1 GPP2 Reports

GPP2 generates two types of reports, an NC Setup Sheet and a Tools report. Each report can be
turned on and off through a DF2 parameter.
Each report is a single HTML file, with the extension “.mht”. These special HTML files contain all the
information, including graphics, in a single file. They can be viewed using any Internet browser,
available on every computer.
Both reports are created in the same output directory as the G-Code file, and share the same name
file name with the following extensions: “.Setup” for the NC Setup Sheet, and “.Tools” for the Tools
report. Note that the reports can be renamed in the POST SCRIPT block.
The GPP2 reports are fully customizable, using HTML template files. The template files define the
structure, contents and format of the reports.

6.1.1 Using GPP2 and XML Variables

GPP2 reports may contain references to GPP2 variables. Any non-array variable may be used,
including system variables, user-defined variables and interaction variables. GPP2 replaces the
variable reference with the actual contents of the variable (formatted according to the variable format).
In addition to the system variable and user-defined variables, it is also possible to access XML file
parameter through specially defined “XML variables”. These variables are defined in the XML
configuration file explained below.
All references to GPP2 and XML variables are done by writing the variable names inside the report
template, enclosed with “||” delimiters (no spaces between the name and the delimiters). For instance,
||PROC_NAME|| refers to the PROC_NAME GPP variable (the procedure name).
In case the referred variable does not exist in the post-processor, the reference will be left intact (e.g.,
||XX_XX|| will be echoed as is to the output report).
CimatronE 10.0 GPP2 User Guide ⎪265

6.2 Selecting the Report Template

The templates are “.mht” files that must be stored in the posts directory (where the DX2 and DF2 files
are kept).
The template file names (without the mht extension) are defined in the DF2 file. When a post-
processor is loaded, they are loaded into GPP system variables that can be modified by the EX2
program.
TEMPLATE_SETUP - the NC Setup Sheet template
TEMPLATE_TOOLS - the Tools report template
If the EX2 program needs to modify the names retrieved from the DF2 file, it must be done in the
STARTUP block. Any later change will be ignored by GPP2.

6.3 Creating Report Templates

Each provider can prepare their own report templates, in their own language, as long as they follow
the procedures and rules described in this document.
A report template is an “mht” HTML file. It can contain text, tables and graphics (e.g., Cimatron logo
and the customer logo). The template file size must not exceed 1MB.
A very convenient way to create and edit the templates is with Microsoft Word. After the file is created
and formatted, it should be saved as “Single File Web Page (*.mht). The mht file can later be edited by
Microsoft Word.
A GPP2 report template file must be built with the following structure:
Report Header
Report Body
Report Trailer
CimatronE 10.0 GPP2 User Guide ⎪266

Example NC Setup Report:

CimatronE 10.0 GPP2 User Guide ⎪267

6.3.1 Report Header

This part appears one time in the report. It may contain any text, images, GPP variable references and
the parameters defined in the gpp2-xml.ini file. The header must contain exactly one table.
The report header is processed by GPP2 after the first BEGINNING OF TAPE block is executed. Only
variables that have meaningful data at that stage should be used in the header (e.g., interaction
variables or POST_NAME).
Note that the header is only processed once, even if the job uses multiple tapes (where the tape must
be cut because it is too long). It will be processed at the beginning of the first tape.

Example Report Header:

CimatronE 10.0 GPP2 User Guide ⎪268

6.3.2 Report Body

This part appears one time in the template, but may be repeated multiple times in the report. It may
contain any text, GPP variable references and the parameters defined in the gpp2-xml.ini file. In the
NC Setup Sheet, it will be repeated for each procedure, and in the Tools report it will be repeated once
for each tool used.
The report body is composed of exactly one table. It contains relevant variable references (such as
||PROC_NAME|| and ||FEED_TIME|| in the NC Setup Sheet).
It is possible to have a title row (or even several rows) at the beginning of the table. This row will be
considered part of the report header, and will only be output once. In order to define a title row, it must
contain no variable references.
GPP2 processes the NC Setup report body after the execution of the END OF PROC block.
The Tools report body is only processed at the end of the run, in order to be able to provide statistical
data on the tool usage. It is processed once for each tool used.
All the tool parameters available in the TOOL CHANGE block are also available for use in the tool
report body. In addition, several special parameters can be used in the tool report body:
TOOL_CNT is the tool serial number (1, 2, 3, etc.). Each tool is counted once, according to the order of
their first use in the job.
TOOL_FEED_TIME is assigned the total cutting time of the tool throughout the job. This is a string
variable, of the form “hh:mm:ss”, measuring the cutting time in hours, minutes and seconds.
TOOL_PROCS is assigned the number of procedures in which the tool is used. It is a special numeric
variable (format SEQUENCING) that is only valid in the tools report body.
TOOL_PROCS_LIST is a string variable containing a list of the procedures in which the tool is used.
The procedure unique ID names are used. If too many procedures exist, the list is truncated at 253
characters, and is appended with “…”.
TOOL_MIN_CLR_LEN indicates the maximum “minimum clear length” calculated at all the procedures
in which the tool is used. This can be used to decide if a shorter tool may be used. A value of -1
indicates that the data is not available.
TOOL_MIN_CLR_LEN_CHECK is a string variable indicating whether the minimum clear length was
actually checked in all the procedures in which the tool is used. If so, it is set to “Yes”, otherwise it is
set to “No”.
TOOL_COMP_2D3D is a string variable indicating if the tool is used (at least once) in a procedure that
applies 2D or 3D cutter compensation. It is set to “Yes” or “No” accordingly.
CimatronE 10.0 GPP2 User Guide ⎪269

Example Report Body:

6.3.3 Report Trailer

This part appears one time in the report. It may contain any text, images, GPP variable references and
the parameters defined in the gpp2-xml.ini file.
The report trailer is processed by GPP2 after the last END OF TAPE block is executed. This is a good
time to use variables such as FEED_TIME or X_MIN to give statistics on the entire job.
Note that the trailer is only processed once, even if the job uses multiple tapes (where the tape must
be cut because it is too long). It will be processed at the end of the last tape.

Example Report Trailer:

CimatronE 10.0 GPP2 User Guide ⎪270

6.3.4 Report Pictures

These are the pictures that appear in the NC Report when using the Standard option of the NC
Report. The types of pictures that can be defined, are listed below.
The process of including a picture in the NC Report depends on the type of picture, however, the
general rule is:
1. Design the template of the Report.
2. Capture the master pictures to be included in the Report. The pictures should be of the
required size (without scaling) and given the names described in the table below. During the
Report creation process, these master pictures are automatically replaced by the ones
captured by the user. However, if for some reason replacement pictures were not found, the
master pictures remain in the Report.
3. Define the master picture names and sizes in the NcReportImage.xml file in the folder
Cimatron\CimatronE\Data.
4. Insert the master pictures into the <Report_name>.Setup.mht and/or
<Report_name>.Tools.mht template file in the folder
Cimatron\CimatronE\Program\NC\Customized Reports.
The following types of pictures can be defined:

Permanent This picture is not changed when producing a report (for example a
company logo).
To include this type of picture in the report:
1. Capture the picture.
2. Insert the picture in the required place.
3. This picture can be given any name, but should not include the
string defining changeable pictures (see below).
This picture can be displayed anywhere in the report.

Default This picture is automatically created when the user runs NC Report
using the Standard option.
To include this type of picture in the report:
1. Capture the picture and save it with the following name:
[email protected].
2. Define the picture name and size in the NcReportImage.xml
file. The width and height sets the dimension of the black
frame in the graphics area when using the Standard template
of the NC Report.
3. Insert the picture in the required place.
This picture can be displayed anywhere in the report.
CimatronE 10.0 GPP2 User Guide ⎪271

Pictures List These are additional pictures that are included as per customer
request (for example ISO picture, Standard Views, Stock Used, etc.).
These pictures are captured by the user via the Capture Report
Images tool.
To include this type of picture in the report:
1. Define the picture name(s); i.e. Initial_Stock.
2. Capture each required picture and save it with the following
name:
NcReportGeneralImage@<defined_name>; i.e.
NcReportGeneralImage@Initial_Stock.
3. Define each picture name and size in the NcReportImage.xml
file. The width and height sets the dimension of the black
frame in the graphics area when using the Standard template
of the NC Report.
4. Insert the picture(s) in the required place(s).
These pictures can be displayed anywhere in the report.

Procedure This picture type is currently not supported.

Pictures
This is a procedure-specific picture that appears in each procedure
data row in the body of the report.
These pictures are captured by the user via the Capture Report
Images tool.
To include this type of picture in the report:
1. Capture the picture and save it with the following name:
NcReportProcedureImage.
2. Define the picture name and size in the NcReportImage.xml
file. The width and height sets the dimension of the black
frame in the graphics area when using the Standard template
of the NC Report.
3. Insert the picture in the required place in the procedure data
row.

Notes:
• The captured images are saved in the folder:
\Cimatron\CimatronE\Data\NC\Report_Images\<elt_document_name>.
• Since a folder containing images is created every time you capture an image, it is recommended to
delete these folders when they are not required.
CimatronE 10.0 GPP2 User Guide ⎪272

6.3.5 Debugging Report Templates

Sometimes, GPP2 will fail to recognize a seemingly perfect variable reference. This is probably the
result of a problem in the template, where the original structure ||VAR_NAME|| has been broken into
several text pieces.
GPP2 will only recognize a variable reference if it finds the full sequence (including the || delimiters)
with no breaks or interruptions.
If a variable reference is not recognized, it will be echoed to the output report without GPP2
substituting the reference with the actual variable contents.
The following cases are known to break a single variable reference so that GPP2 does not recognize
it. The table also shows how to correct the template.

Problem Explanation How to Fix

Spelling If Microsoft Word identifies the Change the variable name to all
variable name as a spelling CAPITAL letters. Microsoft Word
mistake, it will separate the name usually ignores such words in
from the delimiters. spelling. Alternatively, suppress
spelling.

Formatting If the variable reference contains Make sure the entire variable
more than one format (e.g., reference uses the same format
||USER_NAME|| or (e.g., ||USER_NAME||).
||USER_NAME||), Microsoft
Word will separate the name from
the delimiters.

To double check this issue in case of problems, open the mht template with a neutral editor (i.e.
Microsoft Notepad), search for the required parameter and make sure it meets the rules above. If
spaces or other problematic characters are found, delete them and save the mht file.
CimatronE 10.0 GPP2 User Guide ⎪273

6.4 XML File Configuration

GPP2 can read the XML report file and load relevant procedure data into special GPP XML system
variables. Note that starting with version 7.2 patch, the XML file is created each time old GPP is run
and executed.
The names of these special XML system variables, and the mapping of XML data into these variables
is defined in a configuration file called gpp2-xml.ini that is stored in the GPP2 program directory
(where GPP2.EXE is stored).
This configuration file has to be modified by the Cimatron provider in order to properly work with
translated versions of CimatronE (since the XML parameter names are translated text).
Note that a single gpp2-xml.ini file can be installed and used with a single installation of
CimatronE. It should contain all the XML variables that are used in all post processors and all reports
expected on the target computer.
The file is a simple text file, with multiple lines. Each line is either a comment line (starting with a ‘*’,
like in the EX2 files) or defines a single XML parameter as follows:
<id> <XML parameter String> <XML Variable Name> <format>
<id> is the unique ID number of the XML parameter. For instance, the “Part Surface Offset”
parameter has ID 55. Not all XML parameters have a unique ID. For hose that do not have one use
the number -1 (they will be identified by their name).
The advantage of using the unique ID when available is that these lines do not need to be translated –
the ID stays the same in all languages, and allows identification of the XML parameter.
<XML parameter string> is the name of the XML parameter (the same name that appears in the
CimatronE NC grid). This name is not critical for XML parameters with a unique ID number. For the
others (ID -1), it must be exactly the same as the name used in the XML file (the translated name).
<XML Variable Name> is the name of the new GPP2 system variable that will get the value of the
XML parameter. The name must follow the standard naming of GPP2 system variables. By
convention, it starts with XML_.
<format> is the format of the new GPP2 system variable, in numeric form (from 0 to 18). See the
GPP2 Language Reference Manual for details on GPP2 formats.
CimatronE 10.0 GPP2 User Guide ⎪274

Examples:
-1 "Procedure Unique ID" XML_PROC_UID 0
3207 "Spin " XML_PROC_SPIN 4
55 "Part Surface Offset" XML_SURF_OFF 1
Note the first example, with XML variable name XML_PROC_UID. This is a special name and must be
kept as is in all configuration files. GPP2 is expecting this XML system variable name in order to
properly handle multi-tool procedures.
Spaces, tabs and the comma character can be freely used in the gpp2-xml.ini file. Comments at
the end of each line (starting with //) are also supported.

6.4.1 Many-to-One Mapping

Multiple XML parameters can be mapped to a single GPP2 XML system variable. For instance, the
“vertical step” has different names in various NC procedures. This means it comes as different XML
parameters in the XML file. However, all these parameters should be mapped to a single GPP2 XML
system variable that can be used in the report for all procedures.
This is accomplished with the following lines in the XML configuration file:
13 "Down Step" XML_V_STEP 1
3410 "Fixed Vertical Step" XML_V_STEP 1
-1 "Max Vertical Step" XML_V_STEP 1
20538 "Max. Vertical Step" XML_V_STEP 1
3409 "Vertical Step" XML_V_STEP 1
Of course, the same format should be used each time. In fact, the format is used only on the first line,
where the GPP2 XML system variable XML_V_STEP is created.
CimatronE 10.0 GPP2 User Guide ⎪275

6.4.2 GPP2 Processing of XML Data

Whenever GPP2 starts to process a procedure, it performs the following:
• It first clears all XML system variables. Numeric variables are set to 0 and string variables are set
to the empty string. All XML system variables are set off.
• It now reads the relevant XML section, and interprets each XML parameter it finds for that
procedure. If a mapping is found to a GPP2 XML system variable, then the variable is assigned the
value of the XML parameter, and is set on.
• Later, when such an XML system variable is referred to inside a report template, GPP2 checks its
“set” status. If not set (meaning it was not present in the XML file for that procedure), GPP2
replaces the variable reference with a single space character.
In multi-tool procedures, which are broken by GPP2 to multiple procedures, this process only happens
once, in the first GPP2 procedure.