Namespace Hi.Mech

Classes

ChainCodeUtil

Chain code — a bracket notation for the connectivity of an assembly's anchors and branches, e.g. [Comp1][Comp2][Comp3];[Comp1][Comp4] — as static functions over the members of an IMechanism: Seed(string, IReadOnlyList<string>, out Asmb, out Anchor) materializes a fresh assembly and root from a code, CarryOver(IMechanism, Asmb, Dictionary<Anchor, Solid>) brings the transformers (each with the error-term mark of its branch) and solids of same-named components over from a previous mechanism, and DeriveChainCodes(IMechanism, Func<IReadOnlyList<Anchor>, int>) reads the code back from any assembly. The notation knows nothing but topology: every seeded branch carries a NoTransform, and which components play which role (a machine's mounts and axes, a fixture's anchors) is the mechanism's own convention, applied by it on top of the seeded triple.

Notation: each segment declares branches left to right — [O][Y];[Y][X];[X][w] pairs, or the concatenated sugar [O][Y][X][w]. Words merge by exact name across segments; [] is an anonymous component (each occurrence is a fresh one). A branch is named after the component farther from the ground anchor — the one that moves — so [O][Y] and [Y][O] both name the branch Y and differ only in direction. The first component of the whole code is the ground anchor, the root of the seeded assembly.

ErrorTermRoleException

Thrown when a role of a machining chain — an axis or the spindle of a machine tool, the key branch of a CL device — falls on a branch marked as an error term (IsErrorTerm).

An error term is taken as NoTransform by the controller's model of the machine (XyzabcSolver); a role treated that way would take its axis out of the model without a word. With the project switch off (EnableErrorTerms false) the machine itself takes an error term as NoTransform on its runtime face, so a marked role would take its axis out of the machine too, not only out of the controller's model. The mark is therefore refused by name (RequireRoleBranchesNotErrorTerm(IMachiningChain)), whatever the switch says, in two places: where the chain is about to be solved on (the solver), and where a run starts — an NC play (RunNcLines(INcRunner, string, IEnumerable<string>, CancellationToken)), and the act entry a session script plays through.

Two situations raise it. The marked branch is the one the role is played on — the role branch itself or, where the role's own branch was detached or has left the assembly and its transformer drives another branch in its place, that branch: BranchName names it, RoleBranchName is null, and clearing the mark on it repairs it. Or — met by the solver alone — the role's transformer object was put on a second branch beside a role branch that is still in place, and that second branch is marked: BranchName is the second branch and RoleBranchName the role branch. Clearing the mark is no repair then (the transformer would go on driving the second branch); the transformer has to be put on the role branch again, as the message says.

GeneralMechanism

General Mechanism: the pure-topology IMechanism — an assembly, a root anchor and the solids on the anchors, nothing else. It is the file type of the Mechanism Builder (.GeneralMechanism) and the side file a machine file points at for its topology.

MachiningChainUtil

Utility methods for machining chains.

MechanismSolidShare

Makes a copied mechanism display the SAME Solid instances as the mechanism it was copied from — the rule the authored equipment face applies when it materialises the runtime face, so the heavy machine-body geometry is built and held once.

MechanismXml

Reads and writes the three members of an IMechanism — <Asmb>, <Root> and <AnchorToSolid> — as direct children of a host element. The layout is the one GeneralMechanism has always written, so a <GeneralMechanism> element is itself a valid host. The role-reference helpers persist which anchor or branch of the topology a mechanism's role names, by Guid, under the mechanism's own element name for that role.

Interfaces

IGetAnchorToSolidDictionary

Provides functionality to retrieve a dictionary mapping anchors to their corresponding solids.

IGetMachiningChain

Provides functionality to retrieve a machining chain instance.

IMachiningChain

Represents a machining chain with two ends, connecting a tool and a workpiece. A machining chain is an IMechanism — its assembly, root anchor and solids are its own — that also names its two mount anchors and, for a coordinate-driven machine, its machine-coordinate transformers.

IMechanism

A mechanism: a key Asmb holding the anchors and branches, a root anchor the kinematics are measured from, and the dictionary of the solids hung on those anchors. Every mechanism type — the stand-alone GeneralMechanism, the machining chains (IMachiningChain) and the two equipment faces — owns those three members itself and exposes them through this contract, so one topology editor, one XML reader/writer (MechanismXml) and one solid-sharing rule (MechanismSolidShare) serve them all. Which anchors and branches play which role (the mounts, the axes) is each mechanism's own business: plain properties the user sets, named and persisted by the mechanism itself.

Invariants (pinned by the mechanism invariant tests): the root anchor is inside the key assembly (an equipment with no chain mounted may report a null root); every key of the solid dictionary is reachable from the root; the dictionary returned is the live instance, edited in place, never a copy. The displayee list defaults to the anchors plus the solids that have one; implementers with their own display convention (a solid-only machine, a theme-colored fixture) override it.