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.

Known divergences (recorded, corpus-benign): the cycle's mapped feed enters the modal Feedrate section during expansion (ISO semantics; the Siemens MCALL precedent accepts the same leak); 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.

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

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

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