Table of Contents

Class HeidenhainCannedCycleSyntax

Namespace
Hi.NcParsers.LogicSyntaxs.Heidenhain
Assembly
HiMech.dll

Bridges the klartext machining-cycle vocabulary onto the shared ISO canned-cycle machinery. Owns the self-carrying MachiningCycleDef store (single-step lookback + rewrite on every block — the P1 datum-shift pattern) and the call-once vs modal split:

  • Definition (Parsing.MachiningCycle from HeidenhainMachiningCycleSyntax): mapped to ISO slots at definition time — 200 → G81/G82/G83 (peck when Q202 < |Q201|), 232 → G81 (start point Q225/Q226/Q227, end Q386, feed Q207), 251/252/253 → G81/G83 (surface Q203, clearance Q200, depth Q201, plunge feed Q206, step-down Q202). A definition never executes by itself. Unsupported numbers (19, …) are recognized-but-not-simulated: consumed whole with HeidenhainCycl--Unsupported, stored unarmable so a later call warns instead of moving. Required parameters that are missing or non-literal make the store unarmable with HeidenhainCycl--ParamsNotLiteral.
  • Call-once (CYCL CALL [POS] record from HeidenhainCyclCallSyntax, or an M99 flag on a positioning block — the TNC block-wise call, unrelated to the Fanuc return M99): writes the mapped cycle as a direct Parsing.G8x sub-section on this block, which CannedCycleResolveSyntax resolves and the shared cycle syntaxes expand into a CompoundMotion. POS coordinates override the stored X/Y; the POS Z is a pre-position, recorded but never fed into the hole-bottom slot. Words carrying the klartext incremental stamp — POS words (CYCL CALL POS IX+20) and root words on the M99/M89 forms (L IX+20 R0 FMAX M99 — the manual's hole-group shape), see HeidenhainIncrementalAxisWordUtil — are resolved against the last programmed position here, on the spot: this syntax runs ahead of the shared IncrementalResolveSyntax and consumes the words, so the per-word override would otherwise be lost and the hole drilled at the raw distance. The ISO modal-lookback branch is deliberately bypassed: it has no positioning gate, so an armed CannedCycle would re-execute on flag-only blocks — wrong for klartext.
  • Modal (M89): sets Modal; each subsequent block carrying root axis words (and no CArc statement) fires the same direct-section path with the block's X/Y consumed into the cycle. M99 fires once and clears the modality; a new CYCL DEF replaces the store.
  • Seal: on every non-firing block whose previous block carries an active CannedCycle term, a G80 flag is injected (the P0 G00/G01 injection pattern) so CannedCycleResolveSyntax writes the cancel sentinel — the one-shot execution never leaks into ISO modal repetition.

The cycle's mapped feed (Q206 / Q207) enters the modal Feedrate section during the shared expansion (ISO semantics, where the F of a cycle line is the modal F); on the control a cycle parameter is no F word and the feed in effect stays until a new one is programmed (TNC 640 p.126), so the section as the call found it is kept in the call record (ModalFeedrateKey; none, when none is in effect at the call — an F on the call block itself is, the feedrate syntax running first) and put back — or removed again — by HeidenhainCyclePrePositionSyntax once the expansion has run; the Siemens MCALL precedent still accepts the leak. Known divergences (recorded, corpus-benign): the final retract plane is the ISO G98 initial level, not Q204's second set-up clearance (Q204 is recorded in the definition store only) — and an incremental Z word chained off a cycle end (L IZ.., CYCL CALL POS IZ..) inherits that gap, since it adds to the simulated end plane; and the positioning of a call block programmed at a feed (CYCL CALL POS … F500, L … F300 M99) runs at rapid as the expansion's first item where the control positions at the machining feed (TNC7 p.712) — the block latches G01 all the same, so a Heidenhain approach after it reads the feed.

Must run after the tilt/RTCP family and immediately before CannedCycleResolveSyntax. 
public class HeidenhainCannedCycleSyntax : ISituNcSyntax, INcSyntax, IMakeXmlSource
Inheritance
HeidenhainCannedCycleSyntax
Implements
Inherited Members
Extension Methods

Examples

A block of no cycle vocabulary after an armed modal definition (M89): the store and the CYCL CALL POS reference are carried single-step: #Previous:

{
  "MachiningCycleDef": { "Number": 200, "Armable": true, "Modal": true },
  "HeidenhainCyclCallPos": { "X": 10, "Y": 20 }
}

#BeforeBuild:

{ "Parsing": { } }

#AfterBuild:

{
  "Parsing": { },
  "MachiningCycleDef": { "Number": 200, "Armable": true, "Modal": true },
  "HeidenhainCyclCallPos": { "X": 10, "Y": 20 }
}

The same block first after a program end – #Previous: carries the ProgramEnd section (END PGM, or the reset a stop leaves) next to the armed definition. This is the reset edge (ProgramEndSyntax): no modally effective program information survives it, so neither the store, its M89 modality included, nor the reference is carried: #Previous:

{
  "ProgramEnd": { "Term": "END PGM" },
  "MachiningCycleDef": { "Number": 200, "Armable": true, "Modal": true },
  "HeidenhainCyclCallPos": { "X": 10, "Y": 20 }
}

#BeforeBuild:

{ "Parsing": { } }

#AfterBuild:

{ "Parsing": { } }

Constructors

HeidenhainCannedCycleSyntax()

Initializes a new instance with default settings.

public HeidenhainCannedCycleSyntax()

HeidenhainCannedCycleSyntax(XElement)

Initializes a new instance by deserializing from the given XML element.

public HeidenhainCannedCycleSyntax(XElement src)

Parameters

src XElement

Source XML element.

Fields

M89Flag

Modal cycle-call M function.

public const string M89Flag = "M89"

Field Value

string

M99Flag

Block-wise cycle-call M function (TNC semantics, not the Fanuc return).

public const string M99Flag = "M99"

Field Value

string

ModalFeedrateKey

Key in the HeidenhainCyclCall record of the modal Feedrate section as the call found it, for HeidenhainCyclePrePositionSyntax to put back after the shared expansion wrote the cycle's own feed into it.

public const string ModalFeedrateKey = "ModalFeedrate"

Field Value

string

Properties

Name

Syntax kind name (typically the concrete type name).

public string Name { get; }

Property Value

string

XName

XML element name used to register this syntax with XFactory.

public static string XName { get; }

Property Value

string

Methods

Build(LazyLinkedListNode<SyntaxPiece>, List<INcDependency>, NcDiagnosticProgress)

Build syntax arrangement into the syntaxPieceNode in-place.

public void Build(LazyLinkedListNode<SyntaxPiece> syntaxPieceNode, List<INcDependency> ncDependencyList, NcDiagnosticProgress ncDiagnosticProgress)

Parameters

syntaxPieceNode LazyLinkedListNode<SyntaxPiece>
ncDependencyList List<INcDependency>
ncDiagnosticProgress NcDiagnosticProgress

MakeXmlSource(string, string, bool)

Creates an XML representation of the object. This method may also generate additional resources such as related files.

public XElement MakeXmlSource(string baseDirectory, string relFile, bool exhibitionOnly)

Parameters

baseDirectory string

The base directory for resolving relative paths

relFile string

The relative file path for the XML source

exhibitionOnly bool

if true, the extended file creation is suppressed.

Returns

XElement

An XML element representing the object's state

Remarks

For the demand of easy moving source folder (especially project folder) without configuration file path corruption, the relative file path is applied. The baseDirectory is typically the folder at the nearest configuration file folder. Since the folder can be moving with the configuration file.

Reg(XFactory)

Registers this type's deserializer with the given XFactory (or Default when factory is null). Idempotent.

public static void Reg(XFactory factory = null)

Parameters

factory XFactory