Table of Contents

Class IncrementalResolveSyntax

Namespace
Hi.NcParsers.LogicSyntaxs
Assembly
HiMech.dll

Resolves G91 incremental axis values to absolute in-place within Parsing and its sub-sections. Reads Term written by PositioningSyntax.

Per-word override: a block-root PositioningOverride section (written by SiemensAcIcSyntax for the Siemens per-word coordinate functions, and by the Heidenhain L / C / CC / CYCL CALL POS parsers for the klartext I-prefixed words — see HeidenhainIncrementalAxisWordUtil; the CYCL CALL POS words never reach this syntax, HeidenhainCannedCycleSyntax resolves them on the spot ahead of it) beats the modal term for the listed axes on this block only: an Incremental entry converts that word even under G90, an Absolute entry skips it even under G91 — as does, deliberately, every other non-Incremental value (the rotary-family Shortest / PositiveOnly / NegativeOnly entries are absolute targets; their swing resolution lives in McAbcCyclicPathSyntax, not here). A coded-position entry (CodedAbsolute / CodedIncremental — Siemens CAC()/CIC() on a linear indexing axis) carries an indexing position number instead of a coordinate: the number is resolved through IIndexingPositionConfig via TryResolveCodedTarget(IIndexingPositionConfig, string, string, double, double, ISentenceCarrier, NcDiagnosticProgress, out double, out string), the word is rewritten to the resolved absolute coordinate, and the entry to Absolute; a failed resolve reports an error and holds the last program position. Axes without an entry follow the modal term unchanged, so brands that never write the section (Fanuc/...) keep the exact legacy behavior.

WorkingPathList specifies which JSON paths contain axis values that need incremental-to-absolute conversion. Default: [["Parsing"], ["Parsing", "G28"]]; the Heidenhain bundle instead walks ["Parsing", "CC"] for the klartext circle-center record (CcAwareIncrementalResolveSyntax). All matching paths are converted against the same last program position — a nested record's words are distances from where the tool stands, exactly like the root's.

Canned cycle paths (Parsing.G81, G82, G83, …) are intentionally excluded — their Z/R incremental semantics differ from normal axes (R is relative to init level, Z is relative to R-point). Resolution is handled by ResolveCycleCoordinates(JsonObject, Vec3d, double?, double?, double, double, HashSet<string>) inside each cycle syntax class, which runs before this syntax.

Uses AxisNames to determine which tags are motion axes. Traces backward nodes for last known ProgramXyz to resolve incremental values. After this syntax, all axis values in the working paths are absolute — ProgramXyzSyntax can consume them without incremental logic.

Rotary words (A/B/C) at the Parsing root never reach this syntax — McAbcSyntax consumes them upstream and follows the modal G91 itself. Inside a nested record they do (G91 G28 C10. — the Parsing.G28 intermediate), and a rotary axis has no program→MC transform, so its anchor is the previous modal angle (FindPreviousMcAxisDeg(LazyLinkedListNode<SyntaxPiece>, string)) rather than a component of the program XYZ: the intermediate lands at current + 10°, the way HardNc's ParseG28 reads it against the previous MC. A never-set rotary axis anchors at 0.

The rewrite is in place, and the modal Positioning section keeps saying G91 (the next block's lookback needs it), so a converted word is indistinguishable from a programmed absolute. Every word this syntax converts is therefore also recorded, as programmed, in the one-shot block-root IncrementalWords section, shaped like the Parsing tree it came from ({ "X": 10, "G28": { "C": 10 } }). The record doubles as the idempotency guard: a word already listed at its path is left alone, so a second pass over the same block — a project file whose serialized list carries two instances, a re-run over a frozen piece — cannot add the anchor twice. Coded-position words are not recorded (they are not increments of a coordinate; their trace is the rewritten override entry). 

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

Examples

G90 (absolute) on the block — the syntax early-returns without touching Parsing.X/Y/Z, even though the values look like incremental deltas: #BeforeBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "Parsing": { "X": 10, "Y": 20, "Z": 30 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "Parsing": { "X": 10, "Y": 20, "Z": 30 }
}

G91 (incremental) with a #Previous: block carrying MachineCoordinateState=(100,200,300). Under the identity ProgramToMcTransform chain, GetLastProgramXyz recovers program XYZ equal to MC, so each axis in Parsing is rewritten to lastAbs + incremental; the programmed deltas go to IncrementalWords: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "X": 10, "Y": 20, "Z": 30 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "X": 110, "Y": 220, "Z": 330 },
  "IncrementalWords": { "X": 10, "Y": 20, "Z": 30 }
}

G91 + Parsing.G28 sub-section — exercises the second entry of the default WorkingPathList; the root Parsing has no X/Y/Z so the first path no-ops, but the [“Parsing”,“G28”] path picks up the G28 intermediate axes and resolves them against the same lastProgramXyz. The record mirrors the nesting — the words sit under G28: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "G28": { "X": 5, "Y": 10, "Z": 15 } }
}

#AfterBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "G28": { "X": 105, "Y": 210, "Z": 315 } },
  "IncrementalWords": { "G28": { "X": 5, "Y": 10, "Z": 15 } }
}

G90 (absolute) with a per-word PositioningOverride — the Siemens X=IC(10) shape after SiemensAcIcSyntax unwrapped it. Only the overridden X converts against the last program position; Y follows the modal G90 and stays: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "Incremental" },
  "Parsing": { "X": 10, "Y": 20 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "Incremental" },
  "Parsing": { "X": 110, "Y": 20 },
  "IncrementalWords": { "X": 10 }
}

G91 (incremental) with an Absolute override on X — X is skipped (already absolute, e.g. from X=AC(25)) and stays out of the record, Y still converts under the modal G91: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "PositioningOverride": { "X": "Absolute" },
  "Parsing": { "X": 25, "Y": 20 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "PositioningOverride": { "X": "Absolute" },
  "Parsing": { "X": 25, "Y": 220 },
  "IncrementalWords": { "Y": 20 }
}

Coded-position absolute on a linear indexing axis (the Siemens X=CAC(2) workholder shape after the unwrap + evaluation stages). The case injects a SiemensMachineDataTable declaring X linear and assigned to indexing table 1 = [-200, -100, 0, 100]: position number 2 resolves to -100 mm and the entry is rewritten to Absolute: #BeforeBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "CodedAbsolute" },
  "Parsing": { "X": 2 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "Absolute" },
  "Parsing": { "X": -100 }
}

The Heidenhain instance (CcAwareIncrementalResolveSyntax) on a klartext CC IX+0 IY+11 block after the CC parser: the nested record resolves against the last programmed position (the tool stands at (10, 20)), so the center lands at (10, 31); the Parsing root carries no axis word on a CC block and is untouched: #Previous:

{ "MachineCoordinateState": { "X": 10, "Y": 20, "Z": 0 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "Incremental", "Y": "Incremental" },
  "Parsing": { "CC": { "X": 0, "Y": 11 } }
}

#AfterBuild:

{
  "Positioning": { "Term": "G90", "Mode": "Absolute" },
  "PositioningOverride": { "X": "Incremental", "Y": "Incremental" },
  "Parsing": { "CC": { "X": 10, "Y": 31 } },
  "IncrementalWords": { "CC": { "X": 0, "Y": 11 } }
}

G91 + Parsing.G28 carrying a rotary word (G91 G28 X0 C10. on the A/B/C fallback axis list): the rotary anchor is the previous modal angle in #Previous: MachineCoordinateState.C, so the intermediate C is 30 + 10 = 40 — while X still resolves against the last program position (100 + 0). A root rotary word would never be here: McAbcSyntax consumes it first: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300, "C": 30 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "G28": { "X": 0, "C": 10 } }
}

#AfterBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "G28": { "X": 100, "C": 40 } },
  "IncrementalWords": { "G28": { "X": 0, "C": 10 } }
}

A second pass over an already-resolved block — the #BeforeBuild: is the previous case's #AfterBuild: for a root word: the record lists X, so the syntax leaves the (now absolute) 110 alone instead of adding the anchor again. The guard is what makes the in-place rewrite safe against a list that runs the resolve twice: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 200, "Z": 300 } }

#BeforeBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "X": 110 },
  "IncrementalWords": { "X": 10 }
}

#AfterBuild:

{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "X": 110 },
  "IncrementalWords": { "X": 10 }
}

Constructors

IncrementalResolveSyntax(List<List<string>>)

Initializes a new instance with the given working path list.

public IncrementalResolveSyntax(List<List<string>> workingPathList)

Parameters

workingPathList List<List<string>>

JSON paths to scan for incremental axis values; see WorkingPathList.

IncrementalResolveSyntax(XElement)

Initializes a new instance by deserializing the working path list from the given XML element. Falls back to Default.WorkingPathList when the element has no Path children.

public IncrementalResolveSyntax(XElement src)

Parameters

src XElement

Source XML element.

Properties

Default

Default instance with working paths covering the Parsing root and the Parsing.G28 intermediate XYZ subsection.

public static IncrementalResolveSyntax Default { get; }

Property Value

IncrementalResolveSyntax

Name

Syntax kind name (typically the concrete type name).

public string Name { get; }

Property Value

string

WorkingPathList

JSON paths where this syntax searches for axis values (X/Y/Z) to convert from incremental to absolute when G91 is active. Each path is a list of segments navigating nested JSON objects. All matching paths are converted.

public List<List<string>> WorkingPathList { get; }

Property Value

List<List<string>>

Examples

[["Parsing"]]              → Parsing root (normal XYZ)
[["Parsing", "G28"]]       → Parsing.G28 (G28 intermediate XYZ)

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