PATHTRACE ENGINEERING SYSTEMS

Customization Training

Code Wizard
;Code: Workshops
 PAT H T R A C E E N G I N E E R I N G S Y S T E M S

;Code: Workshop Notes

 Pathtrace Plc
45 Boulton Road • Reading
RG2 0NH • England
Phone +44 (0)118 975 6084 • Fax +44 (0)118 975 6143

All copyrights and trademarks are the property of their respective owners and are hereby acknowledged.
Table of Contents
INTRODUCTION...................................................2
Key Notes..............................................................2
WORKSHOP 1........................................................3
Objective................................................................3
Files used in this Workshop..................................3
Solution Strategy...................................................4
The Problem..........................................................4
Reproduce Problem...............................................5
Eliminate User Errors............................................6
Evaluate Related Problems....................................7
The Solution..........................................................7
The Source File......................................................8
User Variables.......................................................9
Finishing Touches.................................................9
Summary..............................................................10
WORKSHOP 2......................................................11
Objective..............................................................11
Files used in this Workshop................................11
Solution Strategy.................................................12
The Problem........................................................12
Reproduce Problem.............................................12
The Solution........................................................13
The Source File....................................................13
More User Variables............................................14
Summary..............................................................16
WORKSHOP 3......................................................17
Objective..............................................................17
Files used in this Workshop................................17
The Problem........................................................18
The Solution........................................................18
Worked Example.................................................19
Hiding ;CODE:....................................................20
Summary..............................................................21
WORKSHOP 4......................................................22
Objective..............................................................22
Files used in this Workshop................................22
The Problem........................................................23
The Solution........................................................23
Worked Example.................................................24
Summary..............................................................25
Conclusion...............................................................26
Introduction
This manual is supplied to explain the customization exercises covered in the Code
Wizard customization Workshops.

The assumed skill level is a competent EdgeCAM user who can create code generators
using the Code Wizard.

Each stage of the exercise is explained and you are expected to work through the notes
until you understand each element of the workshop.

You are advised to print these notes and write your own observations. This will help you
to consolidate the information as you have understood it.

Key Notes
The icons on the left for will be used to highlight important points
I C O N K E Y within the notes
 Load Example Part
 Expert Tips
 Keyboard Input
 Digitise
 Check box

The “expert tips” icon highlights important concepts that are noteworthy. The other icons
indicate that you are expected to do something by following the instructions in the notes.

3
Workshop 1

Objective
The objective of this exercise is to examine how to use the “USER” tokens to generate
values needed to produce a correct NC program when the supplied tokens are
insufficient.

Although the example here is fictitious, the principle holds for a wide variety of similar
solutions that use the techniques learned here.

Files used in this Workshop

You should have a CD or ZIP file with the files associated with this document and they will
be found in a folder called Workshop 1.

The files for this workshop are:

 SimpleBlock.ppf
The EdgeCAM part file used to produce code in this exercise.

 SimpleBlock.a3mod
A Partmodeller model of the part.

 SimpleStock.a3mod
The stock for the above.

 Code-ex1.cgd
A Code Wizard document without the customization.

 Code-ex1-ANS.cgd
A Code Wizard document of the solution.

 Solution.txt
A text file summarizing the solution.

 Code-ex1.nc
The NC output file.

If any of the files are missing or corrupt they can be obtained by sending an email to:

[email protected]

NOT to the Service Helpdesk.

4
Solution Strategy
You will learn how to identify this type of problem and the systematic approach to
resolving it. You will also learn how to navigate effectively through the source file and use
“inside knowledge” to produce the solution.

Although the solution in this case is very straightforward, the strategy can be used for
more complex problems.

The strategy flow can be summarized as:

 Reproduce the problem

 Eliminate user errors

 Predict related issues

 Look for pointers to the solution

 Test

 Implement

The Problem
In this exercise the fictitious problem is a 3 axis milling code generator that cannot be
configured to output the correct Z values for the drill canned cycle.

The controller is based upon ISO code and the CGD file was produced using a Fanuc
based template.

The user has noticed that the Z value output on the G81 line is incorrect.

He claims that the block of code,

N150 G98 G81 Z-9.5 R-6.5 F740.0

should be coming out as:

N150 G98 G81 Z-3.0 R-6.5 F740.0

And, that this block,

N260 G98 G81 Z-15.101 R-6.5 F176.0

should be:

N260 G98 G81 Z-8.0 R-6.5 F176.0

This is because his control implements the Z value as an incremental distance from the R
value, which is absolute.

5
Reproduce Problem
 Open Code-ex1.cgd with the Code Wizard and compile it. Then open
SimpleBlock.ppf with EdgeCAM and generate the NC Program

 Open the NC file and confirm the output matches the claims of the user.

 The next step is to check that the Code Wizard cannot do this request already.

 Open the code constructor for the Drill Cycle and look for any tokens that might be
used for this purpose.

On this occasion there are none.

 It is always worth looking. Tokens are often added on version changes due to support
calls exposing a shortfall in the templates.

 Now look at the Hole Cycles Tab in NC Style, G-Codes and Modality to see if there are
any switches that enable the functionality you are looking for.

The Cycle Z Depth option, does offer 2 alternatives to Absolute.

 Try each of these to see if they work.

 If you still have the editor open, just hit the re-run button in the Code Wizard to
update the code.

This actually fixes the Z Value on line N150, but it makes the R Value incremental too. So
unfortunately it is not the solution we need. Also, the Z Value on N260 has not been
corrected by this adjustment. This might point to a user input error.

 Set the Cycle Z depth setting back to Absolute.

6
Eliminate User Errors
Sometimes reported problems can be made to appear worse because of the way the part
has been programmed. We need to check the part supplied to ensure that the input by
the user is correct and giving the results that we expect.

 Open the part again and check the input Z depths for the Hole Cycle on instruction 5.

This Level and Depth value should have resulted in a Z value of Z-14.5. The NC file was
reporting the depth at Z-15.101.

Why would EdgeCAM output that value?

Look at tool change command at instruction 4

on the browser and click on the More Tab.

The user has accidentally or inadvertently

selected that the tool should be programmed
for full diameter. This means that EdgeCAM
will add on the Z tip length of the drill bit to
ensure that the full diameter of the drill goes to
the programmed depth.

 Change this back to “To Point” and generate the NC File again. You should now have
Z-14.5 on block N260.

 Although this problem has been artificially produced for a training exercise, it illustrates
the typical test loop an engineer should go through to solve a problem.

The average user will regularly assume that any NC errors are purely down to the Code
Generator. In this example that statement is true, to an extent, however, he has made
things more confusing by misunderstanding how he has applied his machining inside
EdgeCAM.

7
Evaluate Related Problems
We know that the user reported the problem with his G81, probably because that is the
first operation that went wrong in his program. He also checked his next G81 and
confirmed that it was wrong too.

What was not confirmed was whether the controller applies the same rules across all hole
cycles. Note that the program supplied contains a tapping (G84) cycle. It is also likely
that if multi-level or multi-depth were used, that they would need the same fixes we are
now about to apply.

The Solution
We have looked at the NC output file and established that the Z Value is not what is
required by the user. We have also checked and resolved any programming issues in
the part file itself. We are now ready to try to fix the problem.

We are going to use the ;CODE: syntax inside a code constructor to deliver the value the
user wants to achieve.

This syntax allows us to add and alter the logic within the code constructor.

 Be Careful!! Syntax errors can cause compilation failure.

 Open Code-Ex1.cgd and go to the Drill Cycle code constructor.

We know that the tokens [ZDEPTH] and [RPLANE] are displaying the correct values for
the current configuration of the CGD file.

We can also notice that if we could create a variable that was the arithmetical difference
between these two values we would have the value the user requires.

8
The Source File
We now know we need to get at the variables behind the tokens [ZDEPTH] and
[RPLANE]. However, the source code from the Code Wizard is likely to be around 6000
lines long.

 We can add “Bookmarks” inside the Code Constructor to make it easier to find the
relevant section of code we are looking for.

 Insert the following fragment of code before the standard output line

;CODE:<workshop1>
 ;CODE: must be UPPER CASE.

The syntax <workshop1> means print “workshop1” to the NC File.

 Re-generate the NC code and confirm that the text “workshop1” appears in the NC file.

By adding this piece of code, we have seen that we can intercept code generation and
place our own logic inside the code generator

 Open Code-Ex1.mxt now. It will be in the cam\machdef folder.

 Search for the string “workshop1”

*
%PROCEDURE=CODECON_DRILL-CYCLE

%IF $CONDEBUG=N @NO_CON-DEBUG

<***** Code Constructor : Drill Cycle *****>
@NO_CON-DEBUG

;Sequence Definition^<27>Drill Cycle^-1^<415>Hole Cycles^

;Use Tokens^DELETE^BLKNUM^DRILLGCODE^XMOVE^YMOVE^ZDEPTH^RAPIDGCODE^ZCLEAR^RPLANE^….
;Default Sequence^;CODE:<workshop1>
;Default Sequence^[DELETE]^[BLKNUM]^[RETRACTGCODE]^[DRILLGCODE]^[XMOVE]^[YMOVE]^[ZDEPTH]
<workshop1>
%CALL=PT_BINC
#SPEED=SPEED:%CALL=PT_SPINDLE
<[#DELETE=25][#BNUM=20] … [#YMOVE=1][#ZMOVE=27][#RPLANE=35][#FEED=28][#HCODE=11] …

;MCB - why does this include RAPIDGCODE

%CALL=HOLD
%ENDM

We have found the values we need in the line beginning <[#DELETE=25]….

The values we want are #ZMOVE and #RPLANE.

 The syntax [#ZMOVE=27] is how numeric variables are passed to the NC File. The
variable must be enclosed inside square brackets and associated with a line on the
format table. The ZDEPTH token is associated with line 27 of the format table.

9
User Variables
Now that we have found the values we want to use in our logic, we have to use a variable
to contain the result. For convenience, the code wizard templates declare 20 numeric
variables for use specifically with ;CODE:. In addition, 10 of these can be output as
tokens.

The tokens are named [USER-1] through to [USER-10]. These are associated with the
numeric variables #USER1 through to #USER10.

 Open the Drill Cycle code constructor again and add the code fragment below.

;CODE:#USER1=#ZMOVE-#RPLANE
;CODE:<* TEST USER 1 [#USER1=27]>
We should now be able to regenerate the code and test that the variable #USER1 has
the desired value.

 We did not actually have to use ;CODE: to output #USER1, because it already has a
token attached. This is just shown here to illustrate that you can use traditional code
generator logic to output variables to specific Format Table references.

Finishing Touches
Now that we have set up the variable associated with token [USER-1] we simply need to
replace [ZDEPTH] with [USER-1] in the code constructor. Your code constructor should
now look something like the image below.

Finally, go to the format section of the Code

Wizard and set up the letter address and format
for the token [USER-1].

Now when you regenerate the code, the G81

cycles should be correct.

10
Summary
In this exercise you have used ;CODE: to assign a value to a user variable. This has
enabled you to fix a problem where a system token could not be configured to supply the
desired value.

The exercise walked you through applying the fix to the G81 cycle.

If you have time, add the fix to the other hole cycle code constructors, including Hole
Cycle Points.

The main concepts that were put forward were.

 Reproduce the problem

Verification of the reported fault through the analysis of the supplied data.

 Eliminate user errors

Confirmation that the results obtained are true results, and not results caused by
accidental user input.

 Predict related issues

Knowing that more than what was reported may be effected and taking stock of
the “knock-on” effect

 Look for pointers to the solution

Does EdgeCAM help me get what I want. We just used #ZMOVE and #RPLANE
which quickly gave us the answer we needed.

We looked at “tricks of the trade” on how to drop a bookmark into a source file so
we can look at the code constructor’s source format.

 Test

Make sure our efforts deliver the requested function.

 Implement

Assigning the value to #USER1, replacing [ZDEPTH] with [USER-1] and setting
the format of [USER-1] in the format table were all part of the implementation.

We know we may need to add this fix to other code constructors.

We also need to remind the user of the To Point/Full Diameter option in the
toolchange command.

11
Workshop 2

Objective
In this exercise we are going to examine how we can change the behavior of the NC File
by changing the rules when rapid moves are being output.

This type of alteration is typical of situations where, due to unique circumstances, the
correct code from EdgeCAM is not desirable and needs to be altered to suit the
conditions required by the user.

Files used in this Workshop

The files can be found in the folder Workshop 2.

The files for this workshop are:

 ConvertRapids.ppf
The EdgeCAM part file used to produce code in this exercise.

 PocketBlock.a3mod
A Partmodeller model of the part.

 Code-ex2.cgd
A Code Wizard document without the customization.

 Code-ex2-ANS.cgd
A Code Wizard document of the solution.

 Solution.txt
A text file summarizing the solution.

 Code-ex2.nc
The NC output file.

12
Solution Strategy
Apply your solution strategy again. Understand and reproduce the problem. Produce a
viable test. Bookmark the code constructors to quickly locate the relevant code sections.

The Problem
In this exercise the user machines a lot of deep nested pockets out of solid billets. To
optimize cycle times they never retract out of the part when roughing the nested pockets.

However, this means that they are cutting blind for a lot of the roughing phase. When
they programmed manually they used to break a lot of tools during prove-out, even when
running in single block.

To overcome this problem they learned to only plunge in Z using feed moves, when
below Z0. This allowed them to control the tool descent using the feed override function
of the control. They still had to reprogram the part, but at least they did not damage the
machine, tooling or fixture.

They have found that EdgeCAM does not give them an option to feed when plunging
using the commands they employ.

Reproduce Problem
 Open Code-ex2.cgd with the Code Wizard and compile it. Then open
ConvertRapids.ppf with EdgeCAM and generate the NC Program.

 Open the NC file and confirm the output matches the claims of the user.

Line N1900 contains a move that would need converted.

 Remember to check that EdgeCAM or the Code Wizard cannot do this request
already.

Actually, the new roughing cycle has got an option “Feed when plunging”, but we will
assume that the user does not have, or refuses to use this command.

 Look at the Rapid Traverse tab in NC Style.

By experimenting with these

settings you can get results
that look hopeful, however, it
also converts upward rapids.

The user says that these

moves waste time and insists
he only wants downward
moves converted.

13
The Solution
We have looked at the NC output file and confirmed what the user has claimed and
looked for alternatives that have been rejected. The part appears to be programmed
correctly and there are no obvious knock-on effects of implementing a workaround.

We now need to use the ;CODE: syntax to alter the behavior of rapid moves. It seems
likely that we will need to intercept the Rapid Move code constructor.

 Switch on Code Constructor Trace to double check this assumption.

The Source File

We now know we need to do something to alter the output inside the Rapid Move code
constructor.

 Add a bookmark and locate it within the source file.

;CODE:<workshop2>

*
%PROCEDURE=CODECON_RAPID-MOVE

%IF $CONDEBUG=N @NO_CON-DEBUG

<***** Code Constructor : Rapid Move *****>
@NO_CON-DEBUG

*%CANCEL=#XMOVE,#YMOVE,#ZMOVE,#FEED,#COOL
;Sequence Definition^<438>Rapid Move^-1^<902>General Motion^
;Use Tokens^DELETE^BLKNUM^ABS-INC^RAPIDGCODE^EXACTSTOPGCODE^XMOVE^YMOVE^ZMOVE^…
;Default Sequence^;CODE:<workshop2>
;Default Sequence^[DELETE]^[BLKNUM]^[RAPIDGCODE]^[XMOVE]^[YMOVE]^[ZMOVE]^…
<workshop2>
%CALL=PT_BINC
<[#DELETE=25][#BNUM=20][#GCODE=19][#XMOVE=0][#YMOVE=1][#ZMOVE=2][#FEED=7][#COOL=18]>

;
%CALL=HOLD
%ENDM

We can see that #XMOVE, #YMOVE and #ZMOVE variables are used to contain the
values for the position to move to. This is not enough information for our logic; we need
to know where we were previously.

 You will notice a call to a procedure called HOLD at the end of the listing here. This is
typical of all code generators. Code generator authors use the HOLD procedure to store
the current tool position, so that they are aware of the previous position when the next
move starts.

You can look at the HOLD procedure in your own time, but suffice to say at this stage you
only need to know that the variables #XHOLD, #YHOLD and #ZHOLD exist and reflect
the last position the tool was at before performing the current move.

14
More User Variables
We know the internal variables that tell us where we are now and where we were
previously. This is sufficient for us to do a test to see if we are moving in Z and in which
direction.

There is another internal variable that is set up by an internal procedure called

NOMOTION. This procedure is used to filter out any moves that EdgeCAM might
generate that are actually smaller than the resolution of the machine. This can
sometimes occur in surface machining at very small tolerances.

The variable that this sets up is called #MOVE. On a 3 axis mill the possible values for
#MOVE give us information about the axes that have moved.

Value Meaning
0 No axis movement

1 X axis movement

2 Y axis movement

3 X and Y movement

4 Z axis movement

5 X and Z

6 Y and Z

7 X, Y and Z

 Open the Rapid Move Code constructor again and add the code fragment below.

;CODE:%IF #MOVE=4 %THEN <* Z ONLY>

Regenerate the code and confirm that this logic pin points all vertical rapid moves.

 You might want to switch Code Constructor Trace off to make your own debug stand
out better.

We now have enough information to implement the logic we require with minimal coding.

Consider fragment of pseudo code on the following page.

15
Pseudo code example

IF move is vertical goto PossibleConvert

* Jump to here for normal moves

DoNormalMove

<OUTPUT FOR NORMAL G0>

Goto TheEnd

PossibleConvert

IF Z Move is upwards goto DoNormalMove

IF Final Z is above Z0 goto DoNormalMove

* IF I get here I Need to convert G0 to G1

<THE OUTPUT FOR THE G1>

TheEnd

Pseudo code is a programmers technique that enables you to consider your logic in a
syntax free way. It is also likely to be understood by laymen and can be more
communicative than a conventional flowchart.

This code would then translate to the following inside the code constructor.

;CODE:
;CODE: %IF #MOVE=4 %THEN %GOTO @ZONLY
;CODE: @NORMAL
;CODE:
[DELETE][BLKNUM][RAPIDGCODE][XMOVE][YMOVE][ZMOVE][COOLANT ON]
;CODE:
;CODE: %GOTO @OK
;CODE:
;CODE: @ZONLY
;CODE:
;CODE: %IF #ZMOVE>#ZHOLD @NORMAL
;CODE: %IF #ZMOVE=#ZHOLD @NORMAL
;CODE: %IF #ZMOVE>0 @NORMAL
;CODE:
;CODE: #GCODE=1:#FEED=2500
;CODE:
[DELETE][BLKNUM][RAPIDGCODE][XMOVE][YMOVE][ZMOVE][FEED][COOLANT ON] (CONVERTED)
;CODE:
;CODE: @OK

 Note the spacing used here to aid readability.

 Open code-ex2-ANS.cgd and use re-run to see the effect of this code.

 You can use the Code Generator Help (cgcomp.hlp) to learn more about the syntax of
the code generator language.

16
Summary
In this exercise you have used ;CODE: to apply a rule to change the way the code
generator behaves when processing rapid moves.

This illustrates the powerful influence you can exert on NC file generation if you know
some of the internal workings of the Code Generator.

You have learned about the HOLD and NOMOTION procedures and the use of the
variables they produce.

If you have time, alter the rule to have some different effect.

e.g.

Adjust the feed rate so that all converted moves take 10 seconds.

Split moves longer than 30mm so that the last 10mm only is converted.

17
Workshop 3

Objective
This exercise is a variation of the previous exercise. It uses inside knowledge of the code
generator to effect code generation behavior.

Where this differs is how the solution is implemented.

There is a lot of logic to deploy, and it can make the code constructors very awkward to
edit safely. Given that you really want your user to edit the CGD file himself, you do not
want to create “Danger Zones”.

We will look here at hiding the ;CODE: from the user.

Files used in this Workshop

The files can be found in the folder Workshop 3.

The files for this workshop are:

 ReduceFeedrates.ppf
The EdgeCAM part file used to produce code in this exercise.

 feedrates.cgd
A Code Wizard document without the customization.

 Reduce feeds.nc
The NC code required.

 Solution.txt
A text file summarizing the solution.

18
The Problem
This time the user has a high speed router capable of feeds in excess of 20m/min.
However, some of his parts have intricate profiles that do not lend themselves to this
approach.

If he programs at F22800 then the machine overshoots on a lot of the short vectors and
produces an unacceptable part.

If he programs the part at F1500 the part is good, but costs him money to make.

Ideally he wants the code generator to sense the vector lengths and adjust the feed rate
automatically.

The problem becomes obvious on moves less than 100mm.

The Solution
We have already seen that we know where we are and where we were. If you can
remember anything about Pythagoras’s triangle then you won’t need too much of a clue
on how we will sense the length of lines.

Arcs are similarly easy, but you need to know that there is an internal variable called
#INCANGLE which represents the included angle of the arc. You also know the radius
from the system variable RADIUS.

 Note that RADIUS is negative for clockwise arcs, you will need to use ABS().

19
Worked Example
 Open the file ReduceFeedrates.ppf and feedrates.cgd.

Compile and generate code.

Notice first that the code is full of debug from the programmer. This is deliberate,
because we want to confirm that our math is good before making logical decisions on the
answer. The NC file is as good a place as any to dump a report to ourselves.

We will always remove it before shipping.

 Look at the Linear Interpolation Code Constructor

 Notice that the only line of code is a call to a procedure.

 Now look at the CLW and CLW Code Constructors.

Where are these procedures?

20
Hiding ;CODE:
Because the logic for calculating the vector lengths would be more than a couple of lines,
the programmer has chosen to hide it somewhere else where it won’t “annoy” the user.

Also, if it is hidden away somewhere discreet, then there is less chance of someone
breaking it.

 Drill down into the Warnings Code Constructor.

 Note here that the first line of ;CODE: issues a %ENDM.

This actually terminates the Warnings Code Constructor, which itself is just a procedure.

This leaves us free to write procedures and declare variables or paste PDI commands.

 Scroll through the code constructor to observe how the logic has been deployed.

 Note how #USER1 and #USER2 are used to set the control parameters for the logic.

21
Summary
This exercise was similar in requirement to Workshop 2, but implemented in a totally
different way.

You have now seen that you can write your own procedures and call them from any code
constructor.

Exploiting the Warnings Code Constructor is a very useful way of hiding customization
where it would be disruptive for the normal user to have to see it.

If you learn more about writing Code Generators from a source file you will learn there is
much more you can do with this “back door” technique.

22
Workshop 4

Objective
This exercise looks at adding an M_Function inside the Code Wizard that is used to
select different post processing rules. The rule is then selectable by the user as a
command from within the manufacturing module, and can be applied as necessary at the
discretion of the user.

Files used in this Workshop

The files can be found in the folder Workshop 4.

The files for this workshop are:

 PartialPostProcess.ppf
The EdgeCAM part file used to produce code in this exercise.

 PostFromToolX.cgd
A Code Wizard document without the customization.

 Partial.nc
The NC code required.

 Partial-DELETED.nc
The suppressed NC code.

 Solution.txt
A text file summarizing the solution.

23
The Problem
In this exercise the user would like to be able to post process only part of the machining
sequence. His reasons for this are, if tool 4 breaks he wants to produce a new NC file that
starts at tool 4.

His machine is set up for drip feeding because it only has 8Kb of bubble RAM so he
cannot rewind the program to the start of the required tool.

His friend uses MasterCAM, and it can do this.

The Solution
EdgeCAM provides no CAM tools to perform this function. It is possible to create a new
sequence and copy only the instructions needed to produce the new program, but this
can be time consuming, particularly if there are surface machining cycles.

Ideally we are looking for the option to suppress output for a section of the program and
then switch it back on again.

EdgeCAM code generators have the ability to write 2 NC files whilst post processing.

The main file is called STANDARD and is the default file the user selects when he picks
generate code from the menu.

The secondary file is called the APPEND file. Typically this is used to produce tooling
sheets, but can in theory be used for anything.

The code generator writer can control which file to send output to by using the %OUTPUT
directive.

The code fragment below illustrates how this is programmed.

; To enable %OUTPUT support the system variable APPEND must be set to 1
; (i.e APPEND=1)
; This is automatically done in all code wizard files

< This is output to main file (say ‘myfile.nc’ >

$NAME=LIST

%OUTPUT=$NAME ; redirect output to (myfile-LIST.nc)

< This code is sent to the append file >

< so is this >

%OUTPUT=STANDARD ; set output back to main file

< Now back in main file again >

We are going to look at how this trick has been deployed in the example files.

24
Worked Example
 Open the file PartialPostprocess.ppf and PostFromToolX.cgd.

Compile and generate code.

You will notice that the NC file only contains the machining for the last tool in the
sequence. The append file “partial-DELETED.nc” contains all of the excluded
instructions.

Identify the M_Function in the sequence and move it around to see the effect it has on the
processed code.

 View the Code Constructor for the M_Function inside the Code Wizard.

Note the first line of logic that tests the MASK system variable.

 Remove this line.

 Set the instruction list back to only outputting the last tool.

You should observe that the hole subroutine appears in the wrong file.

This is because it gets generated when the first hole cycle is processed. This cycle is
suppressed so the subroutine gets suppressed too. Our test above, therefore, says
suppress only mainline code, still output subroutines to the STANDARD file.

Actually, this would not matter in the scenario here. Drip fed machines cannot process
subroutines by definition. We would need to make sure the user was aware of that.

The demonstration of the use of MASK was to illustrate that you know when you are
processing main code or processing subroutines depending on the value of MASK.

25
Summary
You have now seen that you can add an M_Function that is designed to apply a post
processing rule at the point of use. This can be an important tool when customers have
complex requirements.

e.g.

“When we do chuck work we program this way, but when we do bar work…..”

or

“We program like this for a casting, but this way on tombstone work”

This can make the difference between supplying two code generators or one. Users
usually do not like having more than one code generator per machine.

If you have time, try some variations on this technique.

e.g.

Make the rule applied in Workshop2 selectable.

Add a command to switch Code Constructor Trace on.

Add a command to suppress/enable block numbers.

26
Conclusion
You have now seen four different problems solved by the Code Wizard using ;CODE:.
This proves that you can provide a unique solution to an individual user who has
demands just beyond the product’s capabilities.

It can be an easy trap to think that if the Code Wizard cannot achieve something, then
EdgeCAM cannot achieve it.

This is simply not true. There is a lot of untapped power lurking inside the Wizard that is
just waiting to get out. To expose this power to the interface would turn the product into a
Developers tool and not a Users tool; which it is meant to be.

Conventional code generator writers have been used to this power for years, and hence
know where to look for information. Code Wizard users only look as far as the user
interface for functionality.

To be truly proficient at applying ;CODE: you need to be able to write code generators
from a text editor. Only then, when you’re inside the bubble, can you see exactly what
you can achieve.

Some types of customization can only be done inside the code Generator, because you
do not have access to those areas via ;CODE:. You cannot add more rows to the format
table, for example.

Code generators cannot do everything, even the conventional programmers run out of
functionality eventually, but they can support more complex machines and highly
demanding users better.

The Code Wizard should be the first port of call when writing a Code Generator. Even if
you only get 85% of the way there you only have 15% to finish off in the editor.

27