Table of Contents

Class McAbcXyzFallbackSyntax

Namespace
Hi.NcParsers.LogicSyntaxs
Assembly
HiMech.dll

Fills missing X/Y/Z on an ABC-only MachineCoordinateState section. Behaviour depends on whether the block is under RTCP with rotary motion, as indicated by HasDynamicEntry(JsonObject):

  • Non-dynamic (no RTCP or RTCP with ABC stable) — the programmed tool tip stays put in MC while rotary axes (if any) are unchanged, so we simply copy X/Y/Z from the previous block's MachineCoordinateState. This matches NC modal XYZ carry-forward for rotary-only blocks such as G00 A30. (non-RTCP pivoting).
  • Dynamic (RTCP active + ABC changing) — the programmed tool tip must stay fixed in program coordinates while MC XYZ shifts to compensate the new rotary state. Looks up the last ProgramXyz and re-derives MC = inheritedProgramXyz × composedTransform, where the composed transform is the block's endpoint chain (now including PivotTransformSource as a full rotation+translation Mat4d, so the chain already encodes the kinematic IK). The carried ProgramXyz is also stamped onto the current block so downstream consumers see a consistent ProgramXyz + MC pair.

Pair with McAbcSyntax, which runs early to write ABC but deliberately leaves X/Y/Z empty so McXyzSyntax can still derive MC XYZ from ProgramXyz via the transform chain when the block carries linear motion. If McXyzSyntax has nothing to derive (no ProgramXyz), this syntax completes the MC section as described above.

Does nothing when the section already carries all three of X/Y/Z (normal linear-motion blocks), or when there is no section at all (pure parse-only block that introduces no MC). Must be placed after McXyzSyntax and before McAbcCyclicPathSyntax / LinearMotionSyntax. 

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

Examples

All cases below stay on the non-dynamic branch (no PivotTransformSource entry in the chain) so the RTCP re-derivation path is skipped.

Block has no MachineCoordinateState section at all (pure parse-only) — the syntax early-returns and the block is unchanged:

#BeforeBuild: 
{ "Parsing": { "Flags": ["G00"] } }
#AfterBuild: 
{ "Parsing": { "Flags": ["G00"] } }
MC already complete (all three of X/Y/Z present) — the second guard fires and the section is preserved verbatim (no overwrite even if a #Previous: MC differed): #BeforeBuild: 
{ "MachineCoordinateState": { "X": 10, "Y": 20, "Z": 30 } }
#AfterBuild: 
{ "MachineCoordinateState": { "X": 10, "Y": 20, "Z": 30 } }
Rotary-only MC on a rotary-only block (e.g. a 5-axis B+C trunnion machine running G00 B45. C90.) — missing X/Y/Z are copied from the #Previous: block's MC; the rotary keys keep their existing positions (insertion order) and X/Y/Z are appended. The previous block's MC carries the modal rotary state alongside X/Y/Z, but the fallback only reads X/Y/Z from it: #Previous: 
{
  "MachineCoordinateState": {
    "X": 100, "Y": 200, "Z": 300, "B": 0, "C": 0
  }
}
#BeforeBuild: 
{ "MachineCoordinateState": { "B": 45, "C": 90 } }
#AfterBuild: 
{
  "MachineCoordinateState": {
    "B": 45, "C": 90,
    "X": 100, "Y": 200, "Z": 300
  }
}

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