Table of Contents

Class McAbcSyntax

Namespace
Hi.NcParsers.LogicSyntaxs
Assembly
HiMech.dll

Writes rotary axis values (A/B/C) into MachineCoordinateState from Parsing and modal lookback.

Only active when IMachineAxisConfig declares rotary axes. Works for both 3+2-axis (no IMachineKinematics) and simultaneous 5-axis configurations.

This syntax is intentionally ABC-only. When the block is rotary-only (no ProgramXyz, e.g. G00 A30.) the section is created with ABC but without X/Y/Z. McAbcXyzFallbackSyntax — placed after McXyzSyntax — copies X/Y/Z from the previous block's MachineCoordinateState to finish the section. Splitting the XYZ fill out lets this syntax run before McXyzSyntax (and before G43p4RtcpSyntax) without accidentally filling X/Y/Z from prev and thereby short-circuiting DeriveMcXyz(JsonObject, Mat4d).

Missing rotary axes are filled from previous MachineCoordinateState lookback, unless the current section already has the value (e.g., from HomeMcInitializer). Values are stored in degrees (matching McAbcCyclicPathSyntax).

Per-word override: a block-root PositioningOverride section (written by SiemensAcIcSyntax for the Siemens AC()/IC() coordinate functions) marks a rotary word Incremental: the parsed value is then added to the previous modal value of that axis (previous MachineCoordinateState lookback, falling back to a value already present in the current section, then 0) instead of being written as an absolute angle. The accumulated raw degrees stay monotonic across iterations — each per-block step is well inside the ±180° window, so the McAbcCyclicPathSyntax tail-pass keeps it as net rotation instead of re-normalizing it away. An Absolute entry (from AC()) matches the default write and needs no special path — and so, deliberately, do the rotary-family entries Shortest (DC()) / PositiveOnly (ACP()) / NegativeOnly (ACN()): this syntax writes the raw absolute target and the shortest/directional swing is resolved by the McAbcCyclicPathSyntax tail-pass, which owns the wrap math. Brands that never write the section keep the exact legacy behavior.

Coded-position overrides (Siemens CAC()/CIC()/CDC()/CACP()/CACN()) carry an indexing position number instead of an angle: the number is resolved through IIndexingPositionConfig via TryResolveCodedTarget(IIndexingPositionConfig, string, string, double, double, ISentenceCarrier, NcDiagnosticProgress, out double, out string) and the override entry is rewritten to the plain vocabulary (Absolute / Shortest / PositiveOnly / NegativeOnly — a cyclic CIC keeps its programmed direction through the directional values) before the tail-pass runs, so the tail-pass never sees a coded value. A failed resolve (invalid number, missing table) reports an error and holds the axis at its previous value.

Must be placed before McXyzSyntax so syntaxes that need the current-block ABC to compute transforms (e.g. G43p4RtcpSyntax) can see it; and before McAbcCyclicPathSyntax and LinearMotionSyntax. 

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

Examples

Cases 1 and 2 inject a TestDeps.AxisConfig declaring B and C as Rotary. Values are stored as raw degrees; shortest-cyclic resolution is a downstream pass via McAbcCyclicPathSyntax.

No IMachineAxisConfig dep on the list — early-return no-op (the syntax only fires when rotary axes are declared):

#BeforeBuild: 
{ "Parsing": { "B": 45, "C": 90 } }
#AfterBuild: 
{ "Parsing": { "B": 45, "C": 90 } }
AxisConfig declares B+C rotary; Parsing.B/C are consumed into a freshly created MachineCoordinateState section (X/Y/Z are deliberately left out so McXyzSyntax can still derive XYZ later — see class summary): #BeforeBuild: 
{ "Parsing": { "B": 45, "C": 90 } }
#AfterBuild: 
{ "MachineCoordinateState": { "B": 45, "C": 90 } }
Only Parsing.B on the current block; #Previous: carries a full MC including C=0. The missing C is filled from the per-axis backward lookback (FindPreviousMcAxis(LazyLinkedListNode<SyntaxPiece>, string)): #Previous: 
{ "MachineCoordinateState": { "B": 0, "C": 0 } }
#BeforeBuild: 
{ "Parsing": { "B": 30 } }
#AfterBuild: 
{ "MachineCoordinateState": { "B": 30, "C": 0 } }
Per-word incremental override (the Siemens C=IC(...) shape after the unwrap + evaluation stages) — the parsed 21.5 is added onto the previous modal C instead of overwriting it; B has no override entry and fills from lookback as usual: #Previous: 
{ "MachineCoordinateState": { "B": 10, "C": 40 } }
#BeforeBuild: 
{
  "PositioningOverride": { "C": "Incremental" },
  "Parsing": { "C": 21.5 }
}
#AfterBuild: 
{
  "PositioningOverride": { "C": "Incremental" },
  "MachineCoordinateState": { "B": 10, "C": 61.5 }
}
Coded-position absolute (the Siemens C=CAC(3) shape after the unwrap + evaluation stages). The case injects a SiemensMachineDataTable declaring C rotary and assigned to indexing table 1 = [0, 90, 180, 270]: position number 3 resolves to 180° and the override entry is rewritten to Absolute for the tail-pass: #BeforeBuild: 
{
  "PositioningOverride": { "C": "CodedAbsolute" },
  "Parsing": { "C": 3 }
}
#AfterBuild: 
{
  "PositioningOverride": { "C": "Absolute" },
  "MachineCoordinateState": { "C": 180 }
}
Coded-position incremental with the same table — from 270° (position 4), advancing 2 positions wraps the 4-position cycle to position 2 (90°), and the positive count becomes a PositiveOnly approach so the swing keeps the programmed direction: #Previous: 
{ "MachineCoordinateState": { "C": 270 } }
#BeforeBuild: 
{
  "PositioningOverride": { "C": "CodedIncremental" },
  "Parsing": { "C": 2 }
}
#AfterBuild: 
{
  "PositioningOverride": { "C": "PositiveOnly" },
  "MachineCoordinateState": { "C": 90 }
}

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