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, and by the Heidenhain L / C parsers for the klartext IA+/IB+/IC+ words) 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: the McAbcCyclicPathSyntax tail-pass keeps an Incremental-stamped axis literal (a chain dimension is a signed traverse, never re-shortened), so even a +270° step survives as net rotation. 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.

Modal G91: a rotary word with no per-word entry follows the block's Positioning state (written ahead of this syntax by PositioningSyntax on every brand list) the way the linear words follow it in IncrementalResolveSyntax — under G91 it takes the same anchor + delta path as the Incremental override, so G91 … C20. repeated turns the table 20° further each block (Fanuc / Siemens / Heidenhain DIN-ISO all read an incremental rotary word as a signed traverse; the McAbcCyclicPathSyntax tail-pass keeps it literal for the axes the IncrementalWords record lists). A per-word entry of any value beats the modal state for its word (G91 C=AC(90) is absolute). Rotary values another writer put on the block without a word — G53p1RotaryPositionSyntax, the Heidenhain PLANE syntax — are absolute targets and are not touched. HardNc differs here by design of its own: HardNcLine.BuildOrdinaryMcAbc writes the word as an absolute angle under G91 and warns ("G91 is not effect for commands ABC"), so the two engines diverge on G91 rotary words — the parity fixtures assert the SoftNc leg only.

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.

Every rotary word the block actually carried is also recorded, as programmed, in the one-shot block-root RotaryWords section ({ "C": 40 }) — the resolved angle goes into MachineCoordinateState, which after the modal carry can no longer tell "commanded" from "carried". Downstream consumers that need that distinction (CannedCycleResolveSyntax repeating an active canned cycle on a rotary-only block, WriteCompoundMotion(JsonObject, string, JsonArray, Vec3d) riding the block's ABC on the cycle's pre-positioning item) read the record; the section is never modal-carried. Its sibling IncrementalWords records, with the programmed delta, the rotary words this syntax accumulated as increments (per-word IC()/IC+ or a bare word under modal G91): the MC value is an absolute angle from then on and the modal Positioning still says G91, so without the record an accumulated word would read like a programmed absolute. IncrementalResolveSyntax adds the block's linear increments to the same record later in the list, and McAbcCyclicPathSyntax reads it to pass the listed axes through the shortest-path wrap literally.

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). The words the block spoke are recorded as programmed in the one-shot RotaryWords section: #BeforeBuild: 
{ "Parsing": { "B": 45, "C": 90 } }
#AfterBuild: 
{
  "MachineCoordinateState": { "B": 45, "C": 90 },
  "RotaryWords": { "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 (FindPreviousMcAxisDeg(LazyLinkedListNode<SyntaxPiece>, string)) — and stays out of RotaryWords, which lists commanded words only: #Previous: 
{ "MachineCoordinateState": { "B": 0, "C": 0 } }
#BeforeBuild: 
{ "Parsing": { "B": 30 } }
#AfterBuild: 
{
  "MachineCoordinateState": { "B": 30, "C": 0 },
  "RotaryWords": { "B": 30 }
}
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. RotaryWords keeps the programmed delta, not the accumulated angle, and the accumulated word is listed in IncrementalWords: #Previous: 
{ "MachineCoordinateState": { "B": 10, "C": 40 } }
#BeforeBuild: 
{
  "PositioningOverride": { "C": "Incremental" },
  "Parsing": { "C": 21.5 }
}
#AfterBuild: 
{
  "PositioningOverride": { "C": "Incremental" },
  "MachineCoordinateState": { "B": 10, "C": 61.5 },
  "RotaryWords": { "C": 21.5 },
  "IncrementalWords": { "C": 21.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 (RotaryWords keeps the position number the program spoke): #BeforeBuild: 
{
  "PositioningOverride": { "C": "CodedAbsolute" },
  "Parsing": { "C": 3 }
}
#AfterBuild: 
{
  "PositioningOverride": { "C": "Absolute" },
  "MachineCoordinateState": { "C": 180 },
  "RotaryWords": { "C": 3 }
}
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 },
  "RotaryWords": { "C": 2 }
}
Modal G91 with no per-word entry (the Fanuc G91 … C20. canned-cycle repeat block): the rotary word is a signed traverse like the linear words, so it accumulates onto the previous modal C exactly as the Incremental override above (20 + 20 = 40); B has no word and fills from lookback. RotaryWords keeps the programmed delta and IncrementalWords lists the word — the modal section still says G91, and this record is what tells the accumulated 40 apart from a programmed C40.: #Previous: 
{ "MachineCoordinateState": { "B": 10, "C": 20 } }
#BeforeBuild: 
{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "Parsing": { "C": 20 }
}
#AfterBuild: 
{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "MachineCoordinateState": { "B": 10, "C": 40 },
  "RotaryWords": { "C": 20 },
  "IncrementalWords": { "C": 20 }
}
Modal G91 with a per-word Absolute entry (the Siemens G91 … C=AC(90) shape): the entry beats the modal state for its word, so C is written as the absolute 90 — the same rule IncrementalResolveSyntax applies to X=AC(25) under G91: #Previous: 
{ "MachineCoordinateState": { "B": 10, "C": 20 } }
#BeforeBuild: 
{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "PositioningOverride": { "C": "Absolute" },
  "Parsing": { "C": 90 }
}
#AfterBuild: 
{
  "Positioning": { "Term": "G91", "Mode": "Incremental" },
  "PositioningOverride": { "C": "Absolute" },
  "MachineCoordinateState": { "B": 10, "C": 90 },
  "RotaryWords": { "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