Component Store

The Component Store is the set of component definitions available to place in projects.

Built-In LinuxCNC Catalogs

NoHAL includes a built-in library of component definitions by LinuxCNC version:

• 2.7
• 2.8
• 2.9
• 2.10

The project stores a target LinuxCNC version, and the library view can be browsed by version.

What Is Included and What Is Missing

The built-in library is generated by scanning LinuxCNC source and parsing available .comp component definitions into NoHAL component metadata (pins, params, functions, docs, and load/runtime details when they can be derived).

This does not cover everything that can exist in a real machine install. In particular, it may not include:

• custom C-based HAL components that are not represented as .comp
• machine-specific components not covered by the generated library sources

Some important non-.comp components are modeled manually in the built-in library, but that manual coverage is incomplete.

If you run into missing components or incorrect metadata, contributions to improve the built-in library are welcome.

Manual Sources (Dir Source and .comp Import)

The store supports adding additional sources so your project can use the components that exist on your machine, not just the built-in library:

• import a single .comp file
• add a directory as a “dir source”

Imported/refreshed sources update the store’s component definitions and make them available for placement. This is how you typically bring in:

• machine-specific components shipped with your configuration
• local forks or patched versions of .comp components
• components installed outside the standard LinuxCNC source set used to generate the built-in library

Custom Component Definitions (Project vs Global)

Custom components are user-defined component definitions that are not backed by a .comp source file. They exist so you can model and export machine-specific components even when there is nothing for NoHAL to parse.

There are two custom-component scopes:

• Project Custom Components: stored inside the project and only used by that project.
• Global Custom Components: stored in the Component Store and shared across projects.

Custom components can define:

• HAL component name
• runtime kind: rt, userspace, or unknown
• an optional load string
• an optional max instance count
• pins
• params and default values
• optional realtime functions metadata (for addf)

Moving Between Scopes

Project custom components can be promoted into the Component Store. Promotion moves the definition out of the project, creates a global custom component definition, and repoints existing placed instances to the store version.

Load Strings and Instance Limits

Load strings support interpolation tokens for instance names and counts (for example, count=%{count} or -Wn %{first_instance}), and max instance count is used to constrain instance creation/export behavior for that definition.

Refreshing Store Sources

Store sources are refreshable.

Refreshing re-scans the source and updates the store definitions.