Table of Contents

Namespace Hi.NcParsers.Dependencys.SystemWired

Classes

FileIndexCounterDependency

Per-session monotonically-increasing file index allocator. Holds the counter as a private field; Allocate() returns the next unused value and increments. OnSessionReset() rewinds to 0 — the owning RunControlLines(string, IEnumerable<string>, MachiningSession, SessionProgress, CancellationToken) invokes it via the ISessionResettable sweep on the same edge that initializes a fresh NcRunnerSessionState, so a controller power-reset clears both the syntax-piece pipeline and this counter in lock-step.

Two consumers share one allocator:

Holding the counter on this dependency rather than on NcRunnerSessionState avoids a duplicate source-of-truth: the dep is the single seam through which syntaxes reach the counter, and there is no third reader that would benefit from session-state visibility.
MachiningServiceDependency

Exposes the full IMachiningService surface to NC pipeline components — currently provided for client-authored syntaxes / semantics that need broad host access (machining equipment, session, tool house, time mapping, …). The built-in CSV pipeline does not consume this dependency; it uses the narrower StepPropertyAccessDictionaryDependency instead.

NcKinematicsDependency

Provides IMachineKinematics as an INcDependency for SoftNcRunner.NcDependencyList.

The actual kinematics instance is resolved at runtime via KinematicsProvider. This supports scenarios where the machine tool is loaded or changed after the runner is configured (e.g., XML config loaded first, kinematics assigned later).

Consumed by G53p1RotaryPositionSyntax, IsoG68p2TiltSyntax, and McLinearMotionSemantic via dependencyList.OfType<IMachineKinematics>().

ProjectFolderDependency

Exposes the absolute base directory of the project that owns this runner. Resolved at runtime via BaseDirectoryProvider; the host (e.g. LocalProjectService, a test harness) wires the provider to its known project root after the runner is constructed, because SoftNcRunner itself does not retain the baseDirectory argument it sees during XML deserialization.

Consumed by syntaxes that need to resolve a project-relative path to an absolute file system location — e.g. SubProgramCallSyntax for O<n> subprogram lookup under InternalFolder. Reading FilePath is not a substitute: that path is relative and resolving it via Path.GetFullPath would anchor against the process working directory, not the project root.

SegmenterDependency

Exposes the active ISegmenter to syntaxes that need to re-segment auxiliary NC text mid-pipeline (e.g., SubProgramCallSyntax reading an O<n> subprogram file and re-using the host runner's segmenter so the inlined blocks are split with the same rules).

The actual segmenter is resolved at runtime via Hi.NcParsers.Dependencys.SystemWired.SegmenterDependency.SegmenterProvider; RunControlLines(string, IEnumerable<string>, MachiningSession, SessionProgress, CancellationToken) wires the provider to its own Segmenter at the start of each session run, so this dependency can sit in NcDependencyList without participating in XML serialization (see MakeXmlSource(string, string, bool)).

StepPropertyAccessDictionaryDependency

Exposes the host's step-variable registry to NC pipeline components (today: CsvRowSyntax) as a narrow IStepPropertyAccessHost surface.

The provider is wired by the host (e.g. LocalProjectService) so the dependency does not carry strong references to host types; this lets the runner be created before the host is fully constructed and reused across project loads.

A sibling MachiningServiceDependency exposes the broader IMachiningService surface to client-authored syntaxes. The two dependencies are independent — production hosts typically wire both providers to the same backing object, but a test fixture can supply just this narrow one.

SyntaxPieceLayerDependency

Exposes the per-session SyntaxPiece layer chain (one LazyLinkedList<T> per pipeline stage, owned by NcRunnerSessionState) to syntaxes that need to inject additional source pieces mid-pipeline — most notably SubProgramCallSyntax, which inlines a subprogram file's blocks back into layers[0] immediately after the M98 host node so the entire syntax pipeline naturally re-processes them.

The actual layer list is resolved at runtime via Hi.NcParsers.Dependencys.SystemWired.SyntaxPieceLayerDependency.LayersProvider; RunControlLines(string, IEnumerable<string>, MachiningSession, SessionProgress, CancellationToken) wires the provider to the active session's SyntaxPieceLayers at the start of each call. Index 0 is the source layer (init seed + sentence-derived pieces); indices 1..N are post-NcSyntax layers — same convention as NcRunnerSessionState.