Table of Contents

Class HeidenhainLnSyntax

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

Heidenhain LN (surface-normal block) syntax — the CAM-generated straight line carrying the endpoint plus up to two normalized vectors, in the manual's fixed element order X,Y,Z → NX,NY,NZ → TX,TY,TZ: the surface-normal vector NX/NY/NZ (the 3D tool-compensation direction) and the optional tool vector TX/TY/TZ (the tool-axis orientation, acted on only under M128 / FUNCTION TCPM). Strips the leading LN — spaced or glued straight onto an axis or vector word — writes the shared StatementKey statement marker (an LN block is a feed-rate linear move, so the shared motion-mode mapping serves it unchanged), sweeps the six vector components into the nested Parsing.LN record, and grabs endpoint axis words and RL/RR/R0 onto the Parsing root exactly like HeidenhainLSyntax. The Parsing.LN record — created even when the block carries no vector words, so the LN identity always reaches the Logic stage — is consumed by HeidenhainLnOrientationSyntax, which applies the manual's posture rules and writes the brand-agnostic ToolOrientation/SurfaceNormal sections.

Vector words are grabbed before the root axis words as ordering hygiene; correctness does not depend on it — RegexFlagPrefix rejects a tag preceded by a letter, so a bare X can never claim the X of NX. Runs ahead of HeidenhainLSyntax in the bundle; the L gate's lookahead already excludes LN, so this is ordering hygiene as well, not a claim race.

Incremental endpoint words (LN IX+20 IY-15 …, mixed with absolute ones at will) land under the same plain axis keys with the per-axis "PositioningOverride": { "Y": "Incremental" } stamp on the block root, exactly like HeidenhainLSyntax — see HeidenhainIncrementalAxisWordUtil. The manual states the I prefix as a general rule for programmed positions and gives the LN endpoint no exception (its syntax table says only "coordinates of the straight-line end point"), so the endpoint follows that rule; the vector words have no incremental form. The glued gate admits the prefixed spelling too (LNIX+20). 

public class HeidenhainLnSyntax : ISituNcSyntax, INcSyntax, IMakeXmlSource
Inheritance
HeidenhainLnSyntax
Implements
Inherited Members
Extension Methods

Examples

Full CAM shape — endpoint, surface normal, tool vector, R0: #BeforeBuild.UnparsedText: LN X+31.737 Y+21.954 Z+33.165 NX+0.2637581 NY+0.0908784 NZ-0.960348 TX+0 TY+0.6558846 TZ+0.7548612 R0 #AfterBuild:

{
  "Parsing": {
    "L": true,
    "LN": {
      "NX": 0.2637581, "NY": 0.0908784, "NZ": -0.960348,
      "TX": 0, "TY": 0.6558846, "TZ": 0.7548612
    },
    "X": 31.737, "Y": 21.954, "Z": 33.165, "R0": true
  }
}

Glued post shape, tool vector only (“LN with T, no N” is legal — peripheral milling); the FMAX residue stays for the flag syntax: #BeforeBuild.UnparsedText: LNX+10Y+20Z+5TX+0TY+0TZ+1R0FMAX #AfterBuild:

{
  "UnparsedText": "FMAX",
  "Parsing": {
    "L": true,
    "LN": { "TX": 0, "TY": 0, "TZ": 1 },
    "X": 10, "Y": 20, "Z": 5, "R0": true
  }
}

Surface normal only (posture falls to N under TCPM); the F word stays for the shared feed capture: #BeforeBuild.UnparsedText: LN X+0 Y+0 Z+0 NX+0 NY+0 NZ+1 F1000 #AfterBuild:

{
  "UnparsedText": "F1000",
  "Parsing": {
    "L": true,
    "LN": { "NX": 0, "NY": 0, "NZ": 1 },
    "X": 0, "Y": 0, "Z": 0
  }
}

No vector words — the empty record still marks the block as LN for the Logic consumer: #BeforeBuild.UnparsedText: LN X+10 Y+20 Z+5 R0 #AfterBuild:

{
  "Parsing": {
    "L": true, "LN": {}, "X": 10, "Y": 20, "Z": 5, "R0": true
  }
}

Incremental endpoint words — the manual's general I-prefix rule on the LN endpoint: the values land under the plain axis keys, the block-root override stamps only the incremental axes, and the vector record is untouched: #BeforeBuild.UnparsedText: LN X+31.737 IY+21.954 IZ-5 NX+0.2637581 NY+0.0908784 NZ-0.960348 R0 #AfterBuild:

{
  "Parsing": {
    "L": true,
    "LN": { "NX": 0.2637581, "NY": 0.0908784, "NZ": -0.960348 },
    "X": 31.737, "Y": 21.954, "Z": -5, "R0": true
  },
  "PositioningOverride": { "Y": "Incremental", "Z": "Incremental" }
}

Constructors

HeidenhainLnSyntax()

Initializes a new instance with default settings.

public HeidenhainLnSyntax()

HeidenhainLnSyntax(XElement)

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

public HeidenhainLnSyntax(XElement src)

Parameters

src XElement

Source XML element.

Fields

KeyConst

Key of the nested vector record written under Parsing; consumed by HeidenhainLnOrientationSyntax.

public const string KeyConst = "LN"

Field Value

string

NormalTags

Surface-normal component tags (the 3D-compensation direction).

public static readonly string[] NormalTags

Field Value

string[]

ToolVectorTags

Tool-vector component tags (the tool-axis orientation).

public static readonly string[] ToolVectorTags

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