Advanced Variable Usage

The use of Code Generator variables can be much more than storing and outputting values. A variable (name and value) can be passed from the model to the Code Generator via a User Command or from the JOS system Job Notes or Step Notes. The value of any JOS system tag can be assigned to a variable with the use of the JOS(tag name) function. Certain information about an element can be extracted and assigned to a variable.

The internal SmartCAM evaluator is accessible to the Code Generator system. The use of many of the macro system functions are also available in the Code Generator system with the use of the #EVAL command.

JOS Tags

Job Operations Setup (JOS) tags are names of the data inside the Planner. These tags and their values are available throughout SmartCAM, including the Code Generator system. See the Job Operations Setup Data Tags topic for a complete list of the tags.

When using these tags, the variable data type must match the data type of the tag. The JOS(tag name) is used to access numeric data; integers and decimal data. When accessing string data use the JOS_STR(tag name) function.

The JOS(tag name) and JOS_STR(tag name) functions cannot be output directly and must be assigned to a declared variable, and the variable's value can then be output. Unlike the macro system, the context of the JOS tag is not important to the Code Generator system because the Code Generator works through the element data an element at a time. The context of the JOS tag is relevant to the current element.

Here is an example of two types of JOS tag contexts, and how they are output.

@TOOLCHG
#EVAL(#programmer=JOS_STR(creator))
#EVAL(#tlength=JOS(length))
@

When processed, at each tool change sequence #tlength will obtain the tool length information for the step of the current element. This tag is at the Tool level context, therefore will change any time the tool changes. #programmer will remain as the value of Created by: of the Planner because it is at the Job_info level context.

User Commands

A variable embedded in a User Command can be passed to the Code Generator system, name and value. The variable needs only to be declared in the CGT file. When the User Command is processed, the variable and its value are transferred to the Code Generator.

For the example below, a User Command exists in the model assigned to a step.

  1. File - New to start with an empty model.
  2. On the Insert Properties Bar change to CAM mode. If you change to CAM mode, without any defined Steps, the Add Process Step dialog will automatically be launched; so that you can create your needed Step.

  3. Use all defaults for a new step. The data is unimportant for this demonstration.
  4. Create - User Elmts - User Event and pick a location in the graphics view.
  5. Enter #usrCmd=123 into the Event Text field. Go.

    Save this model for use later in this discussion

This creates a User Command that will pass the variable and its contents to the Code Generator. The following is an example of how a CGT (Code Generator Template) might use this.

@DECLARE
#INT#usrCmd
@

@TOOLCHG
The value of usrCmd is #usrCmd
@

When processed, the following is output to the G-Code file at each tool change sequence:
The value of usrCmd is 123

Because #usrCmd was declared as an integer (#INT#usrCmd) any math or other numeric handling of #usrCmd is possible. If it were declared as a string (#STR#usrCmd) it would have to be treated as such.

Other User Commands can update #usrCmd simply by adding a new User Command with a new value where ever you wish the value to change. Feed changes use this method by passing a new value for the system variable #FEED to the Code Generator. You can see this by simply creating a Create - Machine Events - Feed Change. Use Utility - Element Data to see that Feed Change simply creates a User Command with #FEED and a new value.

Job and Step Notes

Much like User Commands, Job and Step Notes can also pass a variable and its contents to the Code Generator system. The main difference is the level of context. User Commands are at the element level, where Job Notes are at the Job Info level and Step Notes are at the Step level. This means that Step Notes will update at any step change, while the Job Notes are updated once at the beginning. The following will demonstrate.

  1. Open the model created in the first example.
  2. On the Insert Properties Bar, make sure you are in CAM mode, then click the pop-up menu button and select Add Step.

  3. Click Accept and the Edit Process Step page opens. Click Step Notes.
  4. Enter #stNotes=2nd step notes in the Notes field, Accept and press Accept on the Edit Process Step page.
  5. Click Job Info and enter #jbNotes=job notes in the Job Notes field. Close the Planner.
  6. Create another User Command using this new step.

    Save this model for use later in this discussion

The following is an example of how a CGT (Code Generator Template) might use this.

@DECLARE
#STR#stNotes
#STR#jbNotes
@

@START
The value of stNotes is #stNotes
The value of jbNotes is #jbNotes
@

@TOOLCHG
The value of stNotes is #stNotes
The value of jbNotes is #jbNotes
@

This example will output the following:

The value of stNotes is
The value of jbNotes is job notes

The value of stNotes is 2nd step notes
The value of jbNotes is job notes

The first section called after the @DECLARE section is the @START section. At this point step one is active, but there are no Step Notes for step one, therefore there is no value output. At the @TOOLCHG section, when the model changes to step two, the value of #stNotes is set and output. This is useful for outputting special notes to the operator about specific steps, or setting machine parameters for certain tools that are not available with SmartCAM.

Note: When assigning variables in Notes fields, be sure to place the variable assignment at the beginning of a new line. If additional text is to follow the variable assignment on the same line, a comma must be used as a delimiter.

CGT Functions

It is sometimes useful to be able to find the current SmartCAM element being processed, so that tests can be applied to the element and specific information returned. The following two CGT file functions can find this information.

CDEL()

This function returns the current active element number, for code generation only. It does not return the element number from the Process Model list view. Code generation automatically creates on-the-fly elements that do not exist in the actual Process Model.

This CGT function can be used in an evaluation statement, along with selected macro commands, to get specific information about the current element; such as element type, clearance, direction, among others.

Example:
#EVAL(#FOO=IS_LEADIN(CDEL()))

This checks whether the current element is a lead-in element and returns the status in #FOO.

PMEL()

This function returns the element number of the parent element, that is currently being processed by code generation. Though PMEL() is a general purpose function, the intended purpose is to access system-defined attributes from a system-generated container. If using PMEL() to find the parent element, outside of the previously specified primary purpose, there may not be a parent element and the function may have unexpected results.

This function returns the current active element number, for code generation only. The function returns the Process Model element number. If the current code generation element is an on-the-fly element; an element created during the code generation process that is not a Process Model element, it will back track up until it finds the original Process Model element number. Then it returns this value.