Block type or name respectively

Cycle attributes

Control attributes

Refers to subsequent contour

Function

"Auxiliary Point for Radius Compensation"

This block type exists only once in the CAM library with exactly this name.

You can also use your own blocks as auxiliary points. However, so that the program recognizes them as auxiliary points for the radius compensation, the block names must begin with one of the following strings: "Hilfspunkt", "Auxiliary Point", or "AuxPoint" (all not case-sensitive).

No

The control text for cycles (attributes) is not called but only the variables ~AuxX~ and ~AuxY~ are initialized.

None

Yes (refer to working variable ~UseAuxPoint~)

The insertion point of the CAM block instance "Auxiliary Point for Radius Compensation" is used as an auxiliary point to approach a closed contour with activated radius compensation (G41/G42). Refer to CAM Introduction, sample "Milling with Radius Compensation").

"Dummy Point"

This block type exists only once in the CAM library with exactly this name.

Yes, but no content (empty).

The control text for cycles (attributes) is called but the variable ~CycleCommands~ contains an empty text.

None

No

The insertion point of the CAM block instance "Dummy Point" is approached at clearance height, apart from that there are no further actions. Refer to CAM Introduction, sample "Drilling with Drilling Cycles").

Normal Cycle

This block type may exist any number of times in the CAM library, consequently the name is not fixed.

For example blocks: "Drilling Cycles\G200 Drilling" and "Milling Cycles\G210 Slot"

Yes

The control text for cycles (attributes) is called and the variable ~CycleCommands~ contains the content of all cycle attributes of the current CAM block instance.

None or ENFORCE-CYCLE-SEQUENCE

(Content doesn't matter)

This control attribute is optional. If two or more subsequent but different CAM block instances have this control attribute then they are treated like a sequence of the same CAM block instance.

No

The content of variable ~CycleCommands~ is copied to the NC file according to the object order. The coordinates of the insertion point of the CAM block instance are applied to the cycle. A sequence of the same CAM block instance or the existence of the optional control attribute ENFORCE-CYCLE-SEQUENCE in two or more subsequent but different CAM block instances respectively is detected and treated separately (variables ~StartOfCycleSequence~ and ~EndOfCycleSequence~). Refer to CAM Introduction, samples "Drilling with Drilling Cycles" and "Create Slots with Milling Cycles".

Cycle for Contour-Subprogram

This block type may exist any number of times in the CAM library, consequently the name is not fixed.

For example block: "Milling Cycles\Contour: 1. Defining and Roughing"

Yes

The control text for cycles (attributes) is called and the variable ~CycleCommands~ contains the content of all cycle attributes of the current CAM block instance.

CONTOUR-SUBPROGRAM

(Content doesn't matter)

Yes (the position of the CAM block instance doesn't matter)

The subsequent contour is copied to the end of the NC file as a contour subprogram. This export is enclosed in calls of the control text for contour subprogram start and contour subprogram end.

The contour subprogram is then used by special cycles which are defined in the cycle attribute of this block type. For that the content of variable ~CycleCommands~ is copied to the NC file according to the object order.

This cycle has two functions: On the one hand it defines the subsequent contour as contour subprogram. On the other hand it calls this contour subprogram.

There maybe multiple CAM block instances referring to the same subsequent contour. Refer to CAM Introduction, sample "Roughing out Kidney with Milling Cycles".

Cycle Merging with Contour

This block type may exist any number of times in the CAM library, consequently the name is not fixed.

For example block: "Milling Cycles\G26/G27 Tangential Approach and Departure" and "Milling Cycles\G25 Rounding Corner"

Yes

The control text for cycles (attributes) is called and the variable ~CycleCommands~ contains the content of all cycle attributes of the current CAM block instance.

Actually the control text is not only called when the cycle's NC commands are exported to the NC file, that is directly after the export of the control text of the corresponding definition point, but also before the control text of the corresponding definition point is called. However this call serves only for initializing the variables (no export to the NC file).

MERGE-WITH-CONTOUR

(Content doesn't matter)

Yes and further the CAM block instance must be placed exactly on a definition point of the subsequent contour.

The content of variable ~CycleCommands~ is copied behind the NC commands of the corresponding definition point of the subsequent contour. That is to say, the cycle is merged with the contour. There maybe multiple CAM block instances referring to the same subsequent contour.

If multiple definition points of the contour are placed at the same position, e.g. start-point and end-point, then the merging process is carried out for each of these definition points. Refer to CAM Introduction, sample "Merge Contour with Milling Cycles".

Ordinary Block

This block type may exist any number of times in the CAM library, consequently the name is not fixed.

No

The control text for cycles (attributes) is called but the variable ~CycleCommands~ contains an empty text because the block does not have a cycle attribute.

None

No

With the help of an ordinary block from the CAM library, you can access the normal attributes of the block instance (i.e. no cycle or control attributes) in the control text for cycles, such as you access variables, e.g. with ~Z-Depth~. In contrast to cycle attributes, the maximum text length is limited to 500 characters per tag.