Macro Invocation

Macros are automatically invoked (i.e., called) by the macro processor when specific events happen, or when “matching” CL records are read from the CL file or from other macros. There are two types of macros used by the post-processor:

Enable/Disable Macro Matching (MATCH)

The MATCH macro command can be given within a macro to turn User-Defined macro matching ON or OFF. Startup, shutdown and event macros are not affected by the MATCH command.

\textbf{MATCH / } \begin{pmatrix}\begin{array}{l} \textbf{ON} \\ \textbf{OFF} \end{array}\end{pmatrix}

MATCH/ON specifies that User-Defined record matching should be enabled. This is the initial condition at the start of any macro. MATCH/OFF specifies that User-Defined macro matching should be disabled.

When macro matching is disabled, no attempt is made to invoke other User-Defined macros that match the CLDATA record generated by the OUTPUT or post-processor commands in the current macro.

Macro matching is always automatically turned back on when the current macro is exited.

Outputting the Identifier or Event (OUTPUT)

The OUTPUT command tells the macro processor to perform the action or event that caused the macro to be invoked.

An OUTPUT command in a User-Defined macro causes the original matching CLDATA record to be processed. If the MATCH condition is ON (see above) then the macro processor will first look to see if any other inactive User-Defined macro matches the CLDATA record. If so, it will begin processing of the first available matched User-Defined macro. If the MATCH condition is OFF, or there are no inactive User-Defined macros that match the CLDATA record, then built-in processing of the CLDATA record is performed. When completed, processing resumes at the statement following the OUTPUT command.

An OUTPUT command in a Cycle Startup macro tells GENER to output the canned cycle codes and then continue processing in the Cycle Startup macro. If a Cycle Shutdown macro is defined, it will be processed as usual once the startup macro exits (i.e., the shutdown macro is not affected by the use of OUTPUT in the startup macro).

An OUTPUT command in a Register macro tells GENER to write the register as defined in the $P2 variable to the pending MCD block and then continue processing in the Register macro.

An OUTPUT command in a Tape macro tells GENER to write the MCD as defined in the $P3 variable and then continue processing in the Tape macro.

The OUTPUT command cannot be used in other Startup/Shutdown macro types.

Invoking Startup/Shutdown Procedures

Startup and Shutdown macros enable customization at the start and end of certain key events, as follows:

Macro Type

When Executed

Declaration

Start of macro processing

Machine startup

Start of post-processing

Machine shutdown

End of post-processing

Break startup

Start of program segment/reel

Break shutdown

End of program segment/reel

First tool change startup

Just before first tool is loaded

First tool change shutdown

Just after first tool is loaded

Tool change startup

Just before a tool is loaded

Tool change shutdown

Just after a tool is loaded

CYCLE startup

Just before a canned cycle is output

CYCLE shutdown

Just after a canned cycle is output

Motion startup

Just before a motion is output

Motion shutdown

Just after a motion is output

LCS startup

Just before an LCS change is output

LCS shutdown

Just after an LCS change is output

Operation event

Just before an operation<operation_event_macro>`

Register

Just before outputting a register

Tape

Just before outputting a block of MCD

If there are both user-defined post-processor macros and startup/shutdown macros for a given major word, the user-defined post-processor macros are run first.

When a startup macro is invoked, a set of predefined $P variables hold values specific to the type of startup/shutdown macro. The startup macro can modify the $P values to change the type of processing performed. When the shutdown macro is invoked, it has access to the same $P values and local user variables set in the corresponding startup macro. (The only exception to this rule is that the machine startup and machine shutdown macros do not share local variables).

Declaration Macro

The declaration macro is executed once only, at the start of macro processing. The sole purpose of a declaration macro is to provide a standard place where GLOBAL, OBJECT and FUNCTION variables can be declared and optionally assigned an initial value. No other commands are permitted in a declaration macro.

The declaration macro is used in combination with the “Strong Declaration” macro setting that appears at the bottom of the RMD and macro editors. There are 3 settings that control how strict the macro processor is concerning where and when variables are declared.

  • OFF: Variables can be declared when and wherever desired. The Declaration macro can be used, but it is not mandatory.

  • PARTIAL: GLOBAL, OBJECT and FUNCTION variables can only be declared in the Declaration Macro. LOCAL variables do not have to be declared before being used.

  • FULL: Same as PARTIAL, but LOCAL variables must be declared in a macro before being used.

The strong declaration setting can be changed during post-processing (see “Tools»Preferences…”). A run-time setting is also available to warn when variables are referenced before being set (which can be a potential source of error).

The declaration macro and strong data typing features are designed to help developers create more stable macro code and catch misspellings and improper use of variables in QUEST instead of at run-time (if at all).

There are no $P variables associated with a declaration macro.

Machine Startup/Shutdown Macros

The machine startup and shutdown macros are executed at the beginning and end of CL file processing respectively.

In a composite post, the machine startup macro for a specific machine component is run each time the component is selected (via the APPLY post-processor command). The shutdown macro is run when a component is being swapped out for a different one or at the end of the program. The main post-processor startup/shutdown macros are run once only, at the start and end of processing.

Use the machine startup macro to output program startup codes and other information desired at the start of the NC program. Use the machine shutdown macro to wrap up processing, for example by turning off spindle and coolant and outputting an end-of-program code.

There are no $P variables associated with a machine startup and shutdown macro.

Break Startup/Shutdown Macros

The BREAK startup and shutdown macros are executed when a tape break (program segmentation) occurs. The shutdown macro is run first to wrap up processing for the original program segment or tape reel; the startup macro is run second to initialize the next program segment or tape reel.

There are no $P variables.

First Tool Change Startup/Shutdown Macros

The “First” tool change startup and shutdown macros are invoked at the first tool change. They have the same $P variables as the normal tool change startup and shutdown macros.

These macros can be forced to run on a subsequent tool change, by setting the $FT variable to 0 (zero). See “Tooling Variables”.

Tool Change Startup/Shutdown Macros

The tool change startup macro has access to many parameters (coded or default) and can change them if desired to affect the outcome of the tool change operation. The shutdown macro can reference the same list of parameters.

Use the tool change startup macro to safely take the old tool home, for example by stopping coolant, spindle and returning the tool home. Use the tool change shutdown macro to output codes necessary to safely start processing a new tool operation.

$P18 and $P19 are only available with turning tools (i.e., lathes in turning mode). $P21 and onwards are only available with milling tools.

$P

Description

$P1

Tool pocket number (–1:AUTO)

$P2

Length compensation ADJUST method (1:NOW,2:NEXT)

$P3

Type of tool change (1:MANUAL,2:AUTO)

$P4

Drum rotation for tools

(1:select CLW/put-away CLW, 2:CCLW/CCLW, 3:CLW/CCLW, 4:CCLW/CLW)

$P5

OSETNO value (–1:SAME,$NULL:NA)

$P6

Tool LENGTH

$P7

Gripper size (1:SMALL,2:LARGE)

$P8

START option for the tool (1:on,$NULL:NA)

$P9

Tool ID number if available, otherwise tool pocket number

$P10

Tool RETAIN option ($NULL:NA)

$P11

Tool DIAMET option ($NULL:NA)

$P12

Tool TIMES option ($NULL:NA)

$P13-15

Tool SETOOL xyz offset ($NULL:NA)

$P16

Tool ATANGL value ($NULL:NA)

$P17

Tool SETANG value ($NULL:NA)

$P18

Main/side head, for lathe only (1:MAIN,2:SIDE)

$P19

Turn/Mill mode, for lathe only (1:TURN,2:MILL)

$P20

Tool name (string)

$P21

Head pocket number (–1:AUTO,$NULL:NA)

$P22

Head type (0:Fixed, 1:Single rotary, 2:Dual rotary)

$P23-25

SETOOL xyz offset of secondary rotation point (0=default)

$P26-28

SETOOL xyz offset of primary rotation point (0=default)

$P29-31

SETOOL xyz offset of tool load point (0=default)

$P32

Drum rotation for heads

(1:select CLW/put-away CLW, 2:CCLW/CCLW, 3:CLW/CCLW, 4:CCLW/CLW)

$P33

ATANGL for secondary rotary axis (0=default)

$P34

ATANGL for primary rotary axis (0=default)

$P35

ATANGL for tool axis (0=default)

$P36

SETANG for secondary axis (0=default)

$P37

SETANG for primary axis (0=default)

$P38

SETANG for tool axis (0=default)

$P39

Manual or auto head change (1:Manual,2:Automatic)

$P40

START option for heads (1:on,$NULL:NA)

$P41

Head ID number if available, otherwise head pocket number

$P42

Head TIMES factor ($NULL:NA)

$P43

Head definition format (1:RAM, 2:ROTATE)

$P44

Head name (string)

$P45-47

SETTCP xyz offset of RTCP control point (0=default)

Cycle Startup/Shutdown Macros

The CYCLE startup and shutdown macros are executed before and after a canned cycle is output. These macros are not invoked when a CYCLE is being simulated, or when a lathe threading cycle is being output. The following $P variables are available in both the startup and shutdown macros:

$P

Description (Drilling Cycle)

$P1

Cycle type (1:regular, 2:activator definition)

$P2

CL coordinates of the control point

$P3

Local machine coordinates of the control point

$P4

Actual cycle type being used (see $CYTYPE definitions)

$P5

Set $TRUE if cycle is being activated

$P6

Alternate motion flag (0:NA, 1:available)

$P7

Alternate machine coordinates of the control point

$P8

Set $TRUE if a feed rate value will be output

$P9

Calculated feed rate value

$P10

Set $TRUE if clearance plane will be output

$P11

Calculated clearance plane value

$P12

Set $TRUE if depth plane will be output

$P13

Calculated depth plane value

$P14

Set $TRUE if retract plane will be output

$P15

Calculated retract plane value

$P16

Number of peck register values to output

$P17

Peck register values

$P18

Peck number (0:last)

$P19

Cycle axis (see description)

$P20

Set $TRUE if BORE-BACK bottom plane will be output

$P21

Calculated BORE-BACK bottom clearance plane value

When the cycle startup macro exits or an OUTPUT command is encountered, the value of $P1 is checked by GENER to determine how the cycle should be processed. Setting $P1 to 0 will cause the cycle point to be ignored. Setting $P1 to –1 will cause the cycle to be emulated using point-to-point motions. In both of these cases the cycle shutdown macro will not be processed. Setting $P1 to –2 will only perform the feed rate processing of the cycle when OUTPUT is next called. This can be used to force feed information out in a block separate from other cycle output.

Some of the $P variables are sequences (i.e., lists of values). The ( ) array operator can be used to extract each component of the sequence. For example, the CL Z coordinate of the control point is obtained by the expression $P2(3), where $P2 refers to the variable containing the coordinates of the motion point in CL coordinates and (3) refers to the third element in the $P2 sequence.

$P2 is a sequence of elements corresponding to the CL “xyz” position of the control point. If MULTAX is on, the “ijk” vector information will also be included.

$P3 is a sequence of 6 elements corresponding to the machine position of the control point. The first three elements are the machine “xyz” positions. The 4th through 6th elements define the positions of active rotary, nutating and or extending axes. There are often two different machine configurations that can satisfy any given tool axis requirement on machines with two or more rotary axes. When this is the case, $P6 will be set to a non-zero value and the less preferred (or alternate) machine configuration can be found in $P7 as a sequence of 6 elements.

$P4 holds the cycle type. Valid values are:

1

DRILL or CSINK

2

FACE or DRILL with dwell or CSINK with dwell

3

TAP-FLOAT

4

Reverse TAP-FLOAT

5

BORE

6

BORE with dwell

7

BORE with ORIENT

8

BORE-BACK

9

REAM

10

REAM with dwell

11

DRILL-DEEP

12

DRILL-BRKCHP

13

THRU

14

TAP-RIGID

15

Reverse TAP-RIGID

16

TAP-DEEP

17

Reverse TAP-DEEP

18

TAP-BRKCHP

19

Reverse TAP-BRKCHP

$P5 will be set $TRUE on the first cycle point or whenever a cycle definition is modified. For post-processors defining “Macro” driven cycles (Automated Canned Cycles / General Drill Cycle Information question #1), the $P5 variable should be set $TRUE once the pending tape block contains sufficient information to cause a cycle to occur.

$P8, $P10, $P12, $P14 and $P20 are all changeable. Setting one of these to $FALSE or $TRUE will inhibit or force output of the associated data. Setting one of $P11, $P13, $P15 or $P21 to a numeric value will change the output of the associated register (however GENER will not adjust timing or tool positions due to changes in the output).

$P17 is a sequence of elements listing the individual peck register values to be output. $P16 identifies the number of elements in the $P17 sequence.

$P19 defines the cycle axis. Valid values are:

–3

–Z axis

–2

–Y axis

–1

–X axis

0

Oblique

1

+X axis

2

+Y axis

3

+Z axis

6

Quill (extending axis)

If desired, an OUTPUT command can be coded in the cycle startup macro to indicate the point where cycle processing is to occur. Macro processing continues at the following statement once the cycle has been output, eliminating the requirement to write a separate cycle shutdown macro. However, if a cycle shutdown macro is defined, then it will be processed as usual once the startup macro exits (i.e., the shutdown macro is not affected by the use of OUTPUT in the startup macro).

Commands coded in the cycle startup macro are processed before the cycle block is output; commands coded after the OUTPUT command or in the cycle shutdown macro are processed after the cycle block is output. Any motions processed in the cycle startup and shutdown macros are not candidates for cycle processing. Also note that commands processed in the startup and shutdown macros cannot be matched by any macros that are already active.

The CYCLE startup/shutdown macros can be toggled on or off by use of the $CYCMAC macro system variable ($TRUE or $FALSE).

Motion Startup/Shutdown Macros

The motion startup and shutdown macros are executed for each motion in the program defined by a motion record in the CL file, or created in a macro via one of the GOTO, FROM or GODLTA macro commands.

Many $P variables are available to a motion startup macro. Linear motions use the first 7 $P variables; circular and spline motions use the remaining $P variables.

$P

Description

$P1

Motion subclass

$P2

CL coordinates of the motion

$P3

Local machine coordinates of the motion

$P4

CL record number of the first record in the motion sequence

$P5

CL record number of the last record in the motion sequence

$P6

Alternate motion flag (0:NA, 1:available)

$P7

Alternate local machine coordinates of the motion

$P8

Total points in circle

$P9

Direction of circle (1:clw,2:cclw)

$P10

Plane of circle (0:3D Circle,1:xy,2:zx,3:yz)

Plane of Spline (1:xy,2:zx,3:yz,4:xy+zx,5:xy+yz,6:zx+yz,7:all)

Pattern type (1:Linear,2:Arc of holes,3:Bolt hole circle,4:Grid)

$P11

Last point on circle or spline in CL coordinate system

$P12

Last point on circle or spline in machine coordinate system

$P13

Circle center in CL coordinate system

$P14

Circle center in machine coordinate system

$P15

Circle axis vector in CL coordinate system

$P16

Circle axis vector in machine coordinate system

$P17

Radius of surface (from 3000 class record)

$P18

Radius of circle

$P19

Helical motion component of circle

$P20

Starting angle

$P21

Ending angle

$P22

Included angle

$P23

Curve type (0:regular,1:curve fitting, 3: filleting)

$P24

Spline motion tangent vector at start point in CL coordinates

$P25

Spline motion tangent vector at end point in CL coordinates

$P1 specifies the type of motion being processed. It can be set from within the macro to change how GENER processes the motion. $P1 will be set as follows when the macro starts:

1

Circular or helical arc

3

FROM command

5

GOTO command

6

continuation of a GOTO command

9

Spline record

10

Pattern

When the motion startup macro terminates, the value of $P1 is checked by GENER to determine how the motion should be processed. The $P1 variable can be set within the motion macro to change the default behavior of the motion. In all cases, setting $P1 to 0 will cause the motion to be ignored when the motion macro ends (the motion shutdown macro will not run in this case). Circular, spline and pattern motions are complex ones, typically representing a group of motions in the CL file. These complex motions can be replaced by simple point-to-point ones by setting $P1 to 3, 5 or 6. On the other hand, it is illegal to change the value of $P1 to 1, 9 or 10, since there is no provision to convert simple motions to complex ones, or to convert one complex motion type to another.

Many of the $P variables are sequences (i.e., lists of values). The ( ) array operator can be used to extract each component of the sequence. For example, The CL Z coordinate of the motion is obtained by the expression $P2(3), where $P2 refers to the variable containing the coordinates of the motion point in CL coordinates and (3) refers to the third element in the “xyzijk” sequence.

$P2 is a sequence of elements (normally six elements) corresponding to the CL “xyzijk” position of the motion. If MULTAX is on, the “ijk” vector information is as specified in the CL data. If MULTAX is off then GENER computes an “ijk” value based on the relationship of the tool and part. Some CL files contain additional information (e.g., tool normal vectors) for each motion record. The $MULSIZ macro system variable indicates the size of the motion record. The additional information is available to the programmer via the $P2 variable.

$P3 is a sequence of 6 elements corresponding to the machine position of the motion. If an LCS (local coordinate system) is active, $P3 defines the position in the local coordinate frame. The first three elements are the machine “xyz” positions. The 4th through 6th elements define the positions of active rotary, nutating and or extending axes.

For linear motions, there are often two different machine configurations that can satisfy any given tool axis requirement on machines with multiple rotary axes. When this is the case, $P6 will be set to a non-zero value and $P7 will contain the alternate (i.e., less preferred) machine configuration axis sequence. For circular, spline and pattern motions, $P6 identifies the first motion and $P7 indicates the total number of motions in the underlying point-to-point representation of the arc, spline or pattern. This alternate representation for $P6 and $P7 may change in a future release.

The values of $P2 and $P3 found at the start of a circular motion reflect the first interpolation point of the motion, not the end of the circle. The $P11 and $P12 variables define the circle end position in the same manner.

$P13 defines the circle center using 3 elements representing the CL “xyz”; $P14 defines the center in machine “xyz” coordinates. $P15 variable defines the axis of the circle using 3 elements representing a CL “ijk” vector; the $P16 does the same in machine “ijk” coordinates.

All other $P variables are simple values. Angles are expressed in degrees, distances are expressed in machine units, counters and sizes are whole numbers.

Note that $P19, the helical component of a circle, can be changed from within the motion startup macro. This is particularly useful if post-processing for systems that cannot drive a helix.

Commands coded in the motion startup macro are processed before the motion block is output; commands coded in the motion shutdown macro are processed after the motion block is output. Note that commands processed in the motion startup and shutdown macros cannot be matched by any macros that are already active. If $P1 is set to 0 in the motion startup macro, the motion is suppressed and the motion shutdown macro is not invoked.

Inserting additional motions in a motion startup macro prior to a circular arc (i.e., when $P1 is 1) will cause the arc to be processed linearly when the startup macro ends unless one of the following 2 conditions is true: 1) The current machine position is reset to the location it was at when the macro was invoked or 2) the current machine position is set to the first tolerance point location.

The motion startup/shutdown macros can be toggled on or off by use of the $MTNMAC macro system variable ($TRUE or $FALSE). See the “Post-Processor Macro Samples” annex for an example of a motion macro.

LCS Startup/Shutdown Macros

LCS startup and shutdown macros are executed just before and after the output of LCS (local coordinate system) codes in the block. Their purpose is to provide fine tune control over the generation of LCS codes, especially where this requires multiple blocks or knowledge of the machine configuration. The LCS startup macro is called before the LCS block (or blocks) are written out to the tape file. There are restrictions on the types of unmatched post processor commands that can be used in LCS startup and shutdown macros (described further below).

The LCS macros will execute immediately on “immediate” forms of LCS, e.g., LCS/NOW. They will execute following the motion:startup and/or cycle:startup macro on “deferred” forms of LCS, e.g., LCS/matrix,NEXT. They will not be executed when LCS is changed via the $LCS system variable. Also, an LCS command in an LCS macro will not cause another instance of the LCS macro to be executed (in the same way that a GOTO in a motion macro does not cause another instance of a motion macro to be executed).

An LCS startup macro has the following $P variables.

$P

Description

$P1

Flag (–1:omit tape output, 1:process)

$P2

Action (0:deactivate LCS, n:activate LCS

$P3

Source (0:immediate, 1:deferred)

$P4

Matrix (equivalent to $LCSMX)

$P5

Rotation angle (equivalent to $LCSANG)

$P6

Rotation axis values (equivalent to $LCSROT)

$P7

Rotation axis type (equivalent to $LCSORD)

$P8

Rotation or scale center point (equivalent to $LCSCEN)

$P9

Translation parameters (equivalent to $LCSTRA)

$P10

Scale parameters (equivalent to $LCSSCA)

$P11

Mirror parameters (equivalent to $LCSMIR)

$P21

Motion (equivalent to $LCSMTN)

$P22

CL coordinates of the motion

$P23

Local machine coordinates of the motion

$P24

Base machine coordinates of the motion

$P25

Index of first and second rotary axes in $P23 and $P24 (0:NA)

$P26

Position of first and second rotary axes

$P1 and $P21 are settable. All other $P variables are read-only.

$P1 controls LCS block output. Setting $P1 to –1 will perform LCS processing but inhibit output to the tape.

$P2 indicates if LCS is being deactivated (0) or activated (n), where n can be any combination of the values 10:translation, 100:rotation, 1000:scale and 10000:mirror.

$P3 indicates if LCS is being changed because of an immediate command in the CLDATA (0) or due to automatic or deferred LCS processing (1).

$P4–$P11 contain the $LCSxxx system variable values that will be set when LCS built-in processing completes.

$P12–$P20 are reserved for future use.

$P21 will be positive if the LCS will generate a motion, with $P22–$P26 defining the motion end-point. A value of 1 indicates that the LCS will cause a rotary-only motion at the machine. A value of 2 indicates that the rotary motion will occur around the tool-tip (i.e., an RTCP type motion). A value of 3 will use the current active RTCP setting to determine the motion type. A value of 0 (zero) or –1 indicates that the LCS frame will be established, but no motion will be generated. $P21 is settable (if not –1). Note that the “alternate” motion end-point solution is not available. This is because it is not the responsibility of the LCS macro (or LCS processing in general) to choose between the available machine solutions.

If desired, an OUTPUT command can be coded in the LCS startup macro to indicate the point where LCS processing is to occur. Macro processing continues at the statement following OUTPUT after LCS processing has completed, eliminating the requirement to write a separate LCS shutdown macro. However, if an LCS shutdown macro is defined, then it will be processed as usual once the startup macro exits (i.e., the shutdown macro is not affected by the use of OUTPUT in the startup macro).

Due to internal processing requirements, LCS startup and shutdown macros cannot invoke a look-ahead either via functions or variables. They also cannot contain the following commands:

  • motion processing with the exception of MOVETO and CLAMP

  • APPLY, BREAK, CYCLE, END, OPTYPE, REWIND

  • CALSUB, COPY, DEFSUB, ENDSUB, INDEX

  • COUPLE, HEAD, THREAD

  • LOAD, LOADTL, SELECT, SELCTL, TLNAME, TOOLNO, TURRET, UNLOAD

  • FINI, MULTAX, UNITS

The LCS startup and shutdown macros can be turned off and on using the “Enable LCS macro” and “Disable LCS macro” RMD actions. These RMD actions set and clear an $LCSMAC macro system variable. If $LCSMAC is set to $FALSE, the LCS startup and shutdown macros will not be invoked. If $LCSMAC is set to $TRUE (the default), the LCS startup and shutdown macros are invoked for each change in LCS to be output.

Operation Event Macro

The operation event (OE) macro is executed whenever a new operation is signaled via an OPTYPE command. When an OPTYPE command is processed, it sets the $OELOOK system variable true and enters look-ahead processing to determine information about the upcoming operation. look-ahead processing continues to the start of the cutting motion, or to the next OPTYPE command, or to a macro instruction turning $OELOOK false, whichever comes first. A cutting motion is defined as one whose programmed velocity is less than the high feed threshold defined by the FEDRAT/ RAPID command.

When the look-ahead ends, the original processing state is reinstated as though nothing had happened. Tape file and listing file processing are resumed. The CL file pointer and macro call stack are reset. All local, object, global and system variables are restored to their original values, with the exception of $OE.* and $INFO.* system variables, which contain the information gathered during the look-ahead (see “Look-Ahead Variables”). Finally, the operation event (OE) macro is activated with the following $P variables:

$P

Description

$P1

The operation type. Also available as $OE.OPTYPE

$P2

OPTYPE command arguments. Also available as $OE.OPARGS

$P3

CL record number of the OPTYPE command

$P4

CL record number at the start of the first cutting motion

$P5

Number of positioning start-up points

Note that there is no requirement for the OE macro to output anything. The post-processor developer may choose to have the OE macro output some, all, or none of the information provided to it via the look-ahead.

When information gathered by the OPTYPE look-ahead is output in the OE macro, care must be taken to ensure that the information is not output a second time when the motion or post-processor command is later processed. To guard against this, although GENER normally outputs redundant information resulting from post-processor commands, it will not do so between the time an OE event macro exits and the start of the cutting motion. Also, GENER does not normally output redundant motions, so the first positioning motion following the OPTYPE command should not generate any output. If necessary, the developer can use the CL record number information provided by the OE macro ($P3 and $P4) to hide problematic records using TAPEOP/DELETE.

Operation Event processing can be inhibited by setting the $OEMAC system variable to $FALSE.

Register Macro

The register macro is executed whenever a matching register is to be output. The macro is called before the register is written to the tape buffer. The register can be modified, ignored or additional registers inserted using the register macro feature. Register macros have the following $P variables:

$P

Description

$P1

Flag (0:Delete, 1:Output)

$P2

String containing the formatted register value

$P3

Register index number in the register table

$P4

Unformatted value of the register ($NULL if none)

$P5

CODE or DATA identifier of the register (REG_NONE if none)

$P1 controls the register macro. When a matching register (see $REGMATCH below) is ready for output, the register macro is called with $P1 set to 1. When the macro terminates, the value of $P1 is checked by GENER to determine if the register should actually be output. Setting $P1 to zero will cause the register to be ignored. Setting $P1 to any other value will cause the register to be output to the tape buffer.

$P2 is a string containing the formatted register and $P3 is the register table index number of the register being output. $P2 and $P3 can be changed as required; the $FREGFMT and $FREGPOS macro functions can help in this regard (see “Other Functions”). When the macro exits, GENER uses the $P3 variable to determine the output order in the tape buffer of the $P2 formatted register text. If $P3 is less than 1, then the $P2 register text will be prefixed to the current tape buffer. If $P3 is greater than the highest register index number, then the $P2 register text will be appended to the current tape buffer.

$P4 is the original unformatted register numeric value, or $NULL if the register only contains text (e.g., an ALT string register value). The $FREGFMT() macro function can be used to return a

$FSWRIT() compatible output format descriptor of the register index $P3, which can then be used to modify the $P2 formatted register string as some function of $P4. For example, to output SIN instead of degrees:

$P2=$FSWRIT($FREGFMT($P3),$FSIN($P4))

$P5 is the CODE or DATA identifier of the register being output, or REG_NONE if not defined. This makes it possible to differentiate between register output for different functions that use the same register (e.g., x-axis used for both position and delay time).

You can output multiple register values by coding an OUTPUT command. When coded, the contents of $P2 are output to the register location $P3. Processing continues in the motion macro at the statement following the OUTPUT command with $P2 and $P3 unchanged.

Register macros must not contain post-processor commands. Register macros can modify user global and object variables as well as macro system variables. Register macros can also use any macro commands excluding those that generate CL records.

The Register macro can be toggled on or off by use of the $REGMAC macro system variable ($TRUE or $FALSE). By default, when $REGMAC is active the register macro executes for every register that is output. A $REGMATCH sequence system variable can be set to define the registers that are candidates for register macro processing. If empty or $NULL, all registers are candidates for matching. The $REGMATCH sequence can contain zero or more of the following:

  • The register index number as listed in the register table. To match a register by its descriptor, use $FREGPOS('descriptor-text') to get the register index number.

  • The CODE or DATA identifier of the register.

  • A string regular expression (RE) matching from the first character of the register output. See the $FEDIT function for a description of RE’s.

For example, to match only the A and B axes registers (assuming these registers are the only ones starting with the letters A and B):

$REGMAC=$TRUE
$REGMATCH={'[AB]'}

The use of $REGMATCH to define registers of interest is recommended, since without it, GENER will invoke the register macro (if defined) for every register output, which can noticeably increase processing time.

Tape Macro

The tape macro is executed whenever a block of tape is ready for output. The macro is called before the block is written out to file and before it is shown in the listing file. The tape block can be modified, deleted or additional tape blocks inserted using the tape macro feature. Tape macros have the following $P variables:

$P

Description

$P1

Flag (0:Delete, 1:Output, n:Output and restart)

$P2

Tape file (0:Subprogram, 1:Primary, 2:Secondary)

$P3

Tape block

$P4

Sequence number and OPSKIP character (if programmed)

$P5

Block excluding SEQNO and OPSKIP

$P1 controls the tape macro. When a new block is ready for output, the tape macro is called with $P1 set to 1. When the macro terminates, the value of $P1 is checked by GENER to determine how the block should be processed. Setting $P1 to zero will cause the tape block to be deleted. Setting $P1 to any other value will cause the tape block to be output. If the $P1 value is not 0 or 1, the macro will be restarted.

$P2 indicates which tape file (subprogram, primary or secondary) the block will be output to.

$P3 is a string containing the tape block data. When the macro terminates, GENER uses the $P3 variable as the tape data. Changes made to $P3 will show up in both the tape file and the output listing. $P4 and $P5 are the components of $P3: $P4 contains the OPSKIP character and sequence number; $P5 contains the remainder of the block.

You can output multiple tape blocks by coding an OUTPUT command. When coded, the contents of $P3 are output to the appropriate tape file. $P3, $P4 and $P5 are then reset to an empty block containing OPSKIP code (if active), SEQNO value (if active), inverse-time feed rate “no motion” code (if applicable) and an EOB code (if required). Processing continues in the tape macro at the statement following the OUTPUT command.

You can also output multiple tape blocks by setting $P1 to some value other than zero or 1 before you exit the macro. On exit from the macro, the contents of $P3 are output to the appropriate tape file. $P3, $P4 and $P5 are reset as described above. $P1, $P2 and all local variables remain unchanged. Processing then restarts from the first line of the macro. Note that if $P1 is not reset to zero or 1 at some point, an endless loop will occur.

Tape macros must not contain post-processor commands. Tape macros can modify user global and object variables as well as macro system variables. Tape macros can also use any macro commands excluding those that generate CL records.

The tape macro can be toggled on or off by use of the $TAPMAC macro system variable ($TRUE or $FALSE).

Diagnostic Macro

A diagnostic macro is executed whenever a diagnostic (message, warning, error, fatal) is processed. The macro will be called even if the diagnostic is disabled, however it will not be called if all diagnostic processing is disabled via the $ERRMSG system variable. The macro is called before the diagnostic is output and counted in the statistics. The diagnostic message can be modified, deleted or additional diagnostics inserted using the diagnostic macro feature.

Diagnostic macros have the following $P variables:

$P

Description

$P1

Flag (0:Disabled/Delete, 1:Enabled/Output)

$P2

Diagnostic number

$P3

Severity number

$P4

Diagnostic occurrence

$P5

Diagnostic message

$P1 controls the diagnostic macro. On entry, $P1 represent the enabled status of the diagnostic number. When the macro terminates, the value of $P1 is checked by the post-processor to determine if the diagnostic should actually be output. Setting $P1 to zero will cause the diagnostic to be discarded. Setting $P1 to any other value will cause the diagnostic to be output to the UI, listing and also counted in the statistics.

$P2 is a real number representing the diagnostic number as defined in the pos260.err file (see “Error File”). $P2 is can be modified in order to output other diagnostics.

$P3 is the diagnostic severity number as defined in the pos260.err file. The severity can be changed by modifying the value of $P3. This is the equivalent of calling the $FERSEV function.

$P4 is a real number representing the number of times the diagnostic identified by $P2 has been generated. The first occurrence of a specific diagnostic will have $P4 set to 1 on entering the macro. Subsequent occurrences will increment $P4. This variable is read-only.

$P5 is a string containing the formatted diagnostic message text. This variable can be altered in order to customize the message that will be output.

You can generate additional diagnostic messages by coding an OUTPUT command. This command causes the diagnostic message, as identified by the $P variables, to be output. The $P variables can then be changed, and OUTPUT called again.

Diagnostic macros must not contain post-processor commands. Diagnostic macros can modify user global and object variables as well as macro system variables. Diagnostic macros can also use any macro commands excluding those that generate CL records.

The diagnostic macro can be toggled on or off by use of the $DIAGMAC macro system variable ($TRUE or $FALSE).

Invoking User Defined Macros

User-defined post-processor macros can be defined to match any type of record read from the CLDATA file or generated by macro processing. The first non-comment line of a user-defined macro defines the “match” condition that will cause the macro to be executed. This first line is called an SDL, which is short for Syntax Definition Line. The remaining lines of the user-defined macro (i.e., the body) define the action to take when the CL record about to be processed matches the SDL.

A user-defined macro must have an SDL, but it does not have to have to have a body. A user defined macro without a body has the effect of ignoring the matched records. This can be done for example to ignore unimportant and/or unsupported post-processor commands that GENER would otherwise diagnose with a warning message.

A user-defined macro body can optionally contain an OUTPUT command (see “Outputting the Identifier or Event (OUTPUT)”) which causes the CL record that matched the SDL to be processed at the point where the OUTPUT command is coded. If an OUTPUT command is not coded, then the matching CL record will not be processed. This can be done for example to convert a command that is not recognized by GENER into a command or series of commands that are recognized by GENER.

Once a user-defined macro is running, it cannot be matched again until the macro has completed execution. This means that user-defined macros cannot be written to be recursive.

SDL Class:Subclass

The SDL (Syntax Definition Line) must be the first non-comment line of the user-defined macro. The SDL defines the CL record syntax that will cause the macro to be matched. The SDL follows the same syntax as a post-processor command, starting with a Major word, optionally followed by a “/” and a list of required and optional arguments (to be discussed in the next section).

The Major word can be specified by name (see the “Post-Processor Major Words” annex) or can be specified in the form #class:subclass, where class is the Major word class code and subclass is the Major word subclass code. For example, specifying SPINDL or #2000:1031 has the same effect. The macro processor uses the class:subclass codes internally and will only show the keyword name if one is defined for that particular class:subclass combination.

An asterisk “*” can be specified in the SDL command in place of the class or subclass code, to provide wildcard matching of records. For example, “#2000:*” would match any 2000 class post-processor command and “#*:*” would match any record. When searching for matching records, the macro processor first checks those with a wildcard before checking those without. It does so in the following order: “#*:*” first, followed by “#class:*” and finally by “#*:subclass”.

By tradition, post-processor command (i.e., 2000 class records) having an subclass code value less than 1000 should be coded without parameters (e.g., STOP or PENUP), whereas post-processor commands having a subclass code value greater or equal to 1000 should be coded with parameters (e.g., COOLNT/FLOOD). SDL lines for post-processor commands therefore should only define SDL arguments in the latter case, where the subclass code is 1000 or higher.

SDL Arguments

The SDL can optionally contain SDL arguments to be matched against the keywords, numbers and strings in the input CL record. Most SDL arguments will be $P variables, which take on the value of the arguments that they that matched from the CL record. $P arguments can be referenced and set within the macro. There are 99 $P arguments available for use: $P1 through $P99. Traditionally, the first $P argument of the SDL should be $P1 and each successive $P argument should increment by 1. The macro editor provides a right-mouse context menu “Resequence $P Variables” selection that can be used to reorder the $P variables.

The following is a list of SDL argument types:

Form

Example

Description

$Pn

$P4

matches a number

$Pn()

$P5()

matches any keyword

$Pn(~[keyword])

$P1(ON,OFF)

matches only keywords listed

$Pn''

$P3''

matches a string

$Pn?

$P12?

matches any single argument

$Pn*

$P6*

matches zero or more arguments

When the user-defined macro is matched, the $P variables will contain the matched value. It is also possible to define SDL arguments without a $P portion, to match arguments from the CL record without the overhead of making the information available to the user-defined macro:

Form

Example

Description

keyword

ON

matches the specified keyword

(~[keyword])

(ON,OFF)

matches only keywords listed

()

()

matches any keyword

''

''

matches a string

?

?

matches any single argument

*

*

matches zero or more arguments

The SDL argument list is composed of a sequence of zero or more required SDL arguments, followed by zero or more SDL options. Each SDL option consists of an “optional” sequence of SDL arguments that does not have to match against record arguments. SDL options are enclosed in square brackets [ ].

Required SDL Arguments

In order for an input record to match a macro, it must match the required arguments in the given order. For example:

Macro SDL

SPINDL/$P1,$P2(CLW,CCLW)

CLDATA input

Matches

SPINDL/400,CLW

$P1=400 $P2=CLW

SPINDL/400,CCLW

$P1=400 $P2=CCLW

SPINDL/CCLW,400

no match: $P1 must be numeric

SPINDL/400

no match: missing $P2

Optional SDL Arguments

If the required arguments of the SDL match successfully against the first arguments of the input record, the options are used to match against any remaining arguments. The options may be matched in any order, where each option may be matched at most once. If an option does not match, its $P arguments are set to $NULL. $NULL is a macro system variable indicating “no value”.

Macro SDL

SPINDL/$P1,[$P2(SFM,RPM)],[$P3(CLW,CCLW)],[RANGE,$P4]

CLDATA input

Matches

SPINDL/300,CCLW,RPM,RANGE,3

$P1=300 $P2=RPM

$P3=CCLW $P4=3

SPINDL/300,RPM,CCLW

$P1=300 $P2=RPM

$P3=CCLW $P4=$NULL

SPINDL/RPM,CCLW

no match: missing $P1

SPINDL/300

$P1=300 $P2=$NULL

$P3=$NULL $P4=$NULL

The * SDL Argument

A “$Pn*” SDL argument matches zero or more input record arguments and stores the sequence in the $P variable. The $FLEN function can be used to determine the length of the sequence stored in a $P variable and the ( ) array operator (see “Variable Array”) can be used to extract a given element of the sequence.

Macro SDL

SPINDL/$P1,RANGE,MEDIUM,$P2*

CLDATA input

Matches

SPINDL/200,RANGE,MEDIUM

$P1=200 $P2=<>

SPINDL/200,RANGE,MEDIUM,CLW,$

,SFM,MAXRPM,970

$P1=200

$P2=<CLW,SFM,MAXRPM,970>

In the second of the two samples above, $FLEN($P2) would return a value of 4. $P2(1) would return CLW, $P2(2) would return SFM and so on.