Table of Contents

Class MachineCoordSelectSyntax

Namespace
Hi.NcParsers.LogicSyntaxs
Assembly
HiMech.dll

Handles machine coordinate selection — non-modal, one-shot. The axis values (X/Y/Z) in the block are interpreted as machine coordinates, bypassing all work offsets, local coordinates, tool height compensation, and coordinate rotations. If G91 (incremental) is active, the code is ignored per ISO standard. A per-word incremental stamp on the block (block-root PositioningOverride entry Incremental — Siemens SUPA Y=IC(-10), klartext L IY-10 M91) is a distance in the machine frame: the word is added to the previous machine position of that axis.

Defaults to ISO G53. Brands with additional one-shot machine-coordinate codes widen SupportedCodes — the Siemens preset adds G153 and SUPA (both suppress every active frame for one block; in this pipeline all of those reduce to "bypass the composed ProgramToMcTransform", which the ProgramXyz back-derivation below already models). The matched code is stamped verbatim into Term for bidirectional source recovery. Rotary words on the same block (e.g. SUPA G0 B0, G53 A0 C0) are consumed by McAbcSyntax ahead of this syntax — machine and program rotary coincide while no rotary offsets are modeled — and the block is still a machine-coordinate positioning: the linear axes hold their machine position when no X/Y/Z word is given, and the motion is always McLinear. A machine-coordinate block never takes the RTCP tool-center-point linkage: on a real controller G53 applies no compensation, so a rotary swing commanded through it turns the axis in place instead of dragging X/Y/Z to pin the tool tip (the tip's post-swing program coordinate is what the back-derivation reports).

Must be placed before IncrementalResolveSyntax and ProgramXyzSyntax in the syntax chain. When a supported code is active, this syntax consumes X/Y/Z from Parsing and writes MachineCoordinateState directly, preventing ProgramXyzSyntax from processing them as program coordinates — and, ahead of the resolve, reading a per-word incremental word raw instead of re-based into the program frame. 

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

Examples

G53 with full XYZ on a first block (no #Previous:) — FindPreviousMc falls back to Vec3d.Zero, transform defaults to identity, so ProgramXyz equals MachineCoordinateState. A non-modal MotionEvent is stamped with Term: “G53” for bidirectional source recovery (per the precedence rule on Term); IsRapid inherits from the modal MotionState.Term (G00 → true, G01/G02/G03 → false, none → true as the conservative “safe rapid” default common in practice): #BeforeBuild:

{ "Parsing": { "Flags": ["G53"], "X": 10, "Y": 20, "Z": 30 } }

#AfterBuild:

{
  "MachineCoordinateState": { "X": 10, "Y": 20, "Z": 30 },
  "ProgramXyz": { "X": 10, "Y": 20, "Z": 30 },
  "MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}

G53 with only Z specified — FindPreviousMc picks up X/Y from the previous block's MachineCoordinateState; Z is overwritten; MotionEvent stamped as above: #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 50, "Z": -200 } }

#BeforeBuild:

{ "Parsing": { "Flags": ["G53"], "Z": 0 } }

#AfterBuild:

{
  "MachineCoordinateState": { "X": 100, "Y": 50, "Z": 0 },
  "ProgramXyz": { "X": 100, "Y": 50, "Z": 0 },
  "MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}

G91 active on the same block — G53 incompatible with G91 incremental positioning per ISO standard. Syntax emits validation error Coord-MachCoord–006, consumes the G53 flag and any X/Y/Z, and writes no machine state. Positioning section preserved: #BeforeBuild:

{
  "Parsing": { "Flags": ["G53"], "X": 10 },
  "Positioning": { "Term": "G91" }
}

#AfterBuild:

{ "Positioning": { "Term": "G91" } }

Standalone G53 with no X/Y/Z — G53 by itself has no destination to interpret as machine coordinates, so the syntax emits validation error Coord-MachCoord–007 and consumes the flag without writing machine state: #BeforeBuild:

{ "Parsing": { "Flags": ["G53"] } }

#AfterBuild:

{}

Siemens SUPA retract (SUT configured with SupportedCodes = [“G53”, “G153”, “SUPA”]) — corpus shape N5 SUPA G0 Z1150 D0: the matched code is stamped verbatim as Term, missing X/Y fill from the previous machine position, the motion-mode flag is claimed into the modal MotionState (LinearMotionSyntax skips this block, so nobody else would), and the D word stays in Parsing for its own consumer: #Previous:

{ "MachineCoordinateState": { "X": 500, "Y": 1000, "Z": -30 } }

#BeforeBuild:

{ "Parsing": { "Flags": ["SUPA", "G00"], "Z": 1150, "D": 0 } }

#AfterBuild:

{
  "Parsing": { "D": 0 },
  "MachineCoordinateState": { "X": 500, "Y": 1000, "Z": 1150 },
  "ProgramXyz": { "X": 500, "Y": 1000, "Z": 1150 },
  "MotionState": { "Term": "G00" },
  "MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "SUPA" }
}

Per-word incremental word on the machine-coordinate block (klartext L IY-10 M91, Siemens SUPA Y=IC(-10)) — a distance in the MACHINE frame: added to the previous machine position, never re-based through the program frame. This is why the syntax sits ahead of IncrementalResolveSyntax in every brand list; the override section stays on the block (one-shot, nobody consumes it): #Previous:

{ "MachineCoordinateState": { "X": 100, "Y": 50, "Z": -200 } }

#BeforeBuild:

{
  "Parsing": { "Flags": ["G53"], "Y": -10 },
  "PositioningOverride": { "Y": "Incremental" }
}

#AfterBuild:

{
  "PositioningOverride": { "Y": "Incremental" },
  "MachineCoordinateState": { "X": 100, "Y": 40, "Z": -200 },
  "ProgramXyz": { "X": 100, "Y": 40, "Z": -200 },
  "MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}

Rotary-only machine-coordinate block under RTCP (G0 G53 A0. while G43.4 is active) — McAbcSyntax has already consumed the rotary word into MachineCoordinateState, and G43p4RtcpSyntax has tagged the chain Dynamic because the tool orientation changes across the block. The linear axes hold the previous machine position (G53 applies no compensation, so the swing turns the axis in place instead of pinning the tool tip) and the motion is stamped McLinear; ProgramXyz is the tip's program coordinate after the swing — the 10 mm tool-height entry is inverted, MC Z 0 → program Z −10: #Previous:

{ "MachineCoordinateState": { "X": -1, "Y": -1, "Z": 0, "A": 90 } }

#BeforeBuild:

{
  "Parsing": { "Flags": ["G53", "G00"] },
  "MachineCoordinateState": { "A": 0 },
  "ProgramToMcTransform": [
    {
      "Source": "ToolHeightCompensation",
      "Kind": "Dynamic",
      "Mat4d": [1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,10,1]
    }
  ]
}

#AfterBuild:

{
  "MachineCoordinateState": { "A": 0, "X": -1, "Y": -1, "Z": 0 },
  "ProgramToMcTransform": [
    {
      "Source": "ToolHeightCompensation",
      "Kind": "Dynamic",
      "Mat4d": [1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,10,1]
    }
  ],
  "ProgramXyz": { "X": -1, "Y": -1, "Z": -10 },
  "MotionState": { "Term": "G00" },
  "MotionEvent": { "Form": "McLinear", "IsRapid": true, "Term": "G53" }
}

Constructors

MachineCoordSelectSyntax()

Initializes a new instance with default settings.

public MachineCoordSelectSyntax()

MachineCoordSelectSyntax(XElement)

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

public MachineCoordSelectSyntax(XElement src)

Parameters

src XElement

Source XML element.

Properties

Name

Syntax kind name (typically the concrete type name).

public string Name { get; }

Property Value

string

SupportedCodes

One-shot machine-coordinate codes this syntax consumes; defaults to ISO G53. The Siemens preset widens the list to G53 + G153 + SUPA. The first list entry present in Parsing.Flags is stamped as Term; every listed code present on the block is consumed so none re-triggers the unconsumed-parsing warning.

public List<string> SupportedCodes { get; set; }

Property Value

List<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