Testing, Verification and Debugging

The Debugging Process

When debugging a code generator, it is best to open your CGT file with your text editor, open your SMF file with Machine Define, and open the model in SmartCAM that you will use for testing G-code at the same time. Create a G-code file, examine it for the changes required, edit and save the CGT or SMF file, recode the G-Code file and repeat until the G-code file is as desired.

Outputting CGT Diagnostics Information to the code file

There are four diagnostic options available on the Code dialog box that can be used to output additional data to the code file to aid in finding and fixing issues with CGT files. These options can be toggled on or off as needed, directly on the Code dialog box. For more information, see the Help - Code Checking and Reporting topic.

Sections - output @section names

Line Refs - output CGT line numbers

Conditions - output complete conditionals

Errors - output error information

Use Comments Generously

Use comments throughout your CGT file to document things like what is being done, why, what variables are used, etc. Create a header section to contain a running history of changes, when they occurred and why. Well documented CGT files are much easier to edit and maintain especially when a long period of time has passed since the last edits, or if someone else is editing the file.

A single line comment beings with a // (double forward slash) on a line in the CGT file. SmartCAM ignores any information that follows the comment characters, until it reaches the end of the current line. You can add the // comment characters to any part of the line - keeping in mind once reached the rest of the line is ignored. At the start of the next line, SmartCAM begins processing information again.

Use an @COMMENT section for a header that contains the high level information about the CGT file. The section name can be anything that SmartCAM would not use for actual processing. The Code Generator will skip sections it is not processing, so if you name the section as something that will not be used, you can add any text in any format you wish and the Code Generator will not error, or even read the section. It has been customary to use the section name @COMMENT or @NOTES for this.

Here is an example of how a CGT file should be documented.

@COMMENT
Machine: Acme horizontal mill
Control: Acme 2B
Machine notes: B axis, 10 tool turret

Author: John Doe
Origin date: 3 Mar 1998

Revision History:
10 May 1999  JMD:  Added B axis support
6 Jan 2000   JDG:  Fixed issue with #INT variable - #myInt

Variables used:
#myInt - used with part counter in @time section
#S1 - programmer name
#S2 - part name
@

@DECLARE
#INT #myInt // part counter in @time section
#INT #myClamp // flag for operator to move clamp
@

// this @section automatically called at beginning of @START
@$INIT
#EVAL(#myInt=1) // reset part counter to start
#EVAL(#myClamp=0) // turn off clamp flag to start
@

Note that any text inside of the @COMMENT section does not require comment characters (//). It is assumed that this section would not be called by the system with a #CALL(COMMENT) command or with a @COMMENT user command.

Use Caution when Outputting Test Values

Make sure any test you devise does not interfere with the way the CGT file functions. For example, if you output a CGT word such as #XPOS to check its value, SmartCAM updates the word and then skips to the next coordinate in the database. If that same CGT word is then used in a calculation or is output elsewhere in the CGT section, the result may be incorrect. It may show information derived from the subsequent coordinate.

To avoid this, set the variable as user assigned and output the value of the user-assigned variable, as shown in the following example:

@LINE
#EVAL(#V4=#XPOS)
**xpos=#V4
#EVAL(#V4=#V4*3.14159^2)
#MOV X#V4 Y#YPOS
#UPDATE(#XPOS)

SmartCAM outputs the contents of the variable, but does not update the CGT word (#XPOS) before it is used in another calculation. This is accomplished by the last line of the example.