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 RunNcLines(string, IEnumerable<string>, MachiningSession, StepDiagnosticProgress, NcDiagnosticProgress, 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.

MappingAnchorDependency

Narrow NC-pipeline dependency that lets a CSV semantic convert an absolute controller instant to a run-relative timecode against the project mapping anchor, without reaching the whole IMachiningService surface (cf. MachiningServiceDependency). The host wires ToTimecodeProvider to TimeMapping.ToTimecode, whose set-once ??= seeds (lazily builds) the anchor on first use.

Runtime-only: the provider is wired per host and not persisted; serialization writes only the empty element so the dependency survives an XML round-trip.

NcKinematicsDependency

Provides IMachineKinematics as an INcDependency for SoftNcRunner.PipelineNcDependencyList.

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>().

NcLineSourceDependency

In-memory line source for NC “files” with no disk backing — inline NC-code plays whose FilePath is a command-title pseudo-path (e.g. “NC Code”). Control-flow re-segmentation (WHILE reverse jump, backward GOTO, M99 P{seq} caller re-entry — every LabelScanUtil scan) re-reads the host file by path; an inline play's pseudo-path never exists on disk, so without this source those jumps fall through (loops that do not loop) or error with a *FileNotFound diagnostic. RunNc(string, string) registers the play's raw lines under its pseudo-path before running; LabelScanUtil consults this source first and only falls back to disk.

Entries persist for the runner's lifetime, the latest registration of a path winning — deliberately NOT ISessionResettable: the session-reset sweep runs inside the first RunNcLines(string, IEnumerable<string>, MachiningSession, StepDiagnosticProgress, NcDiagnosticProgress, CancellationToken) of a fresh session, which would wipe the registration made moments earlier for that very play. A registered pseudo-path shadows an identically-named disk file during re-segmentation, so inline command titles should not mirror real project-relative NC paths.

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; RunNcLines(string, IEnumerable<string>, MachiningSession, StepDiagnosticProgress, NcDiagnosticProgress, CancellationToken) wires the provider to its own Segmenter at the start of each session run, so this dependency can sit in PipelineNcDependencyList without participating in XML serialization (see MakeXmlSource(string, string, bool)).

SentenceIndexCounterDependency

Per-session monotonically-increasing SentenceIndex allocator. Holds the counter as a private field; Allocate() returns the next unused value and increments. OnSessionReset() rewinds to 0 — the owning RunNcLines(string, IEnumerable<string>, MachiningSession, StepDiagnosticProgress, NcDiagnosticProgress, 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.

This dependency exists to fix the sentence-index double-booking bug: before it, the host file's lazy enumerator numbered pieces from layers[0].Count captured at file-append time while subprogram / macro / control-flow re-segmentation numbered from layers[0].Last.Value.SentenceIndex + 1 — two independent sequences that overlap as soon as a call is inlined mid-stream (host blocks after M98 and the inlined body shared the same indices). With this counter, GetSyntaxPieces(ISegmenter, List<INcDependency>, IEnumerable<IndexedFileLine>, int, NcDiagnosticProgress, CancellationToken) allocates one value per piece at materialization time, which the lazy pipeline pulls in execution order — indices are session-globally unique and strictly increasing along the executed stream, at the cost of no longer being contiguous per file (eager label scans discard their pre-label prefix, leaving gaps).

Values are never negative, preserving the -1 "not in pipeline" sentinel used by SentenceIndex and SentenceIndex. When this dependency is absent from the pipeline list, GetSyntaxPieces(ISegmenter, List<INcDependency>, IEnumerable<IndexedFileLine>, int, NcDiagnosticProgress, CancellationToken) falls back to the caller-supplied begin-index numbering — the legacy colliding behavior. Only code-built runners can hit that fallback: XML rehydration back-fills a missing instance (the SoftNcRunner XML constructor's system-wired back-fill), because saves that predate this dependency never self-heal by round-tripping — re-saving stamps a new ApiVersion on the same incomplete list.

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; RunNcLines(string, IEnumerable<string>, MachiningSession, StepDiagnosticProgress, NcDiagnosticProgress, 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.

ToolHouseDependency

Exposes the project's MachiningToolHouse to NC pipeline components — the narrow counterpart of MachiningServiceDependency for syntaxes / semantics that only look up or register tools (e.g. the CLSF pipeline's TLDATA-driven tool creation).