HAL Introduction

The Hardware Abstraction Layer (or with a reference to the 2001 Space Odyssey movie just "HAL") is a software to

In itself, this Middleware is agnostic about its application on CNC. An Internet search, for example, found an astronomical application to control telescopes using LinuxCNC. Motors move the telescope into the right position, and it needs to know how to map motor activity with the effect of that positioning with the real world. Such a synchronisation of motor positions with real-world positions is reminiscent of what CNC machines need to do, or space craft.

Any machine controller needs to know:

The HAL layer consists of parts (referred to as "components") that

Taken together, HAL allows

HAL has no direct interaction with the user. But multiple interfaces have been provided that allow HAL to be manipulated

but none of these interfaces are HAL itself.

HAL itself is not a program, it consists of one or more lists of loaded programs (the components) that are periodically executed (in strict sequence), and an area of shared-memory that these components use to interchange data. The main HAL script runs only once at machine startup, setting up the realtime threads and the shared-memory locations, loading the components and setting up the data links between them (the "signals" and "pins").

In principle multiple machines could share a common HAL to allow them to inter-operate, however the current implementation of LinuxCNC is limited to a single interpreter and a single Task module. Currently this is almost always a G-code interpreter and "milltask" (which was found to also work well for lathes and adequately for robots) but these modules are selectable at load-time. With an increasing interest in the control of multiple cooperating machines, to overcome this limitation is likely one of the prime steps for the future development of LinuxCNC to address. It is a bit tricky though and the community is still organizing its thoughts on this.

HAL lies at the core of LinuxCNC and is used and/or extended by all the parts of LinuxCNC, which includes the GUIs. The G-code (or alternative language) interpreter knows how to interpret the G-code and translates it into machine operations by triggering signals in HAL. The user may query HAL in various ways to gain information about its state, which then also represents the state of the machine. Whilst writing during the development of version 2.9, the GUIs still make bit of an exception to that rule and may know something that HAL does not (need to) know.

HAL is special in that it can communicate really fast

And while communicating, the part of LinuxCNC that is talked to does not need to prepare for the communication: All these actions are performed asynchronously, i.e. no component is interrupting its regular execution to receive a signal and signals can be sent rightaway, i.e., an application may wait until a particular message has arrived - like an enable-signal, but it does not need to prepare for receiving that message.

The communication system

The communication with the hardware of the machine itself is performed by respective dedicated HAL components.

The HAL layer is a shared space in which all the many parts that constitute LinuxCNC are exchanging information. That space features pins that are identified by a name, though a LinuxCNC engineer may prefer the association with a pin of an electronic circuit. These pins can carry numerical and logical values, boolean, float and signed and unsigned integers. There is also a (relatively new) pin type named hal_port intended for byte streams, and a framework for exchanging more complex data called hal_stream (which uses a private shared memory area, rather than a HAL pin). These latter two types are used relatively infrequently.

With HAL you can send a signal to that named pin. Every part of HAL can read that pin that holds that value of the signal. That is until a new signal is sent to the same named pin to substitute the previous value. The core message exchange system of HAL is agnostic about CNC, but HAL ships with a large number of components that know a lot about CNC and present that information via pins. There are pins representing

In a analogy to electronic cables, pins can be wired, so the value changing in one pin serves as input to another pin. HAL components prepare such input and output pins and are thus automatically triggered to perform.

The many "expert" software parts of LinuxCNC are typically implemented as components of HAL, conceptually also referred to as modules. These computer-implemented experts perpetually read from HAL about a state that the machine should strive to achieve and compare that desired state with the state the machine is in at the current moment. When there is a difference between what should be and what the current state is then some action is performed to reduce that difference, while perpetually writing updates of the current states back to the HAL data space.

There are components specializing on how to talk to stepper motors, and other components know how to control servos. On a higher level, some components know how the machine’s axes are arranged in 3D and yet others know how to perform a smooth movement from one point in space to another. Lathes, mills and robots will differ in the LinuxCNC component that are active, i.e. that are loaded by a HAL configuration file for that machine. Still, two machines may be looking very different since built for very different purposes, but when they both use servo motors then they can still both use the same HAL servo component.

On the lowest (closest to hardware) level, e.g. for stepper motors, the description of a state of that motor is very intuitive: It is the number of steps in a particular direction. A difference between the desired position and the actual position translates into a movement. Speeds, acceleration and other parameters may be internally limited in the component itself, or may optionally be limited by upstream components. (For example, in most cases the moment-by-moment axis position values sent to the step-generator components have already been limited and shaped to suit the configured machine limits or the current feed rate.)

Any G-code line is interpreted and triggers a set of routines that in turn know how to communicate with components that are on a middle layer, e.g., to create a circle.

HAL has a special place in the heart of its programmers for the way that the data flow between modules is represented. When traditional programmers think of variables, addresses or I/O ports, HAL refers to "pins". And those pins are connected or assigned values to via signals. Much like an electrical engineer would connect wires between pins of components of a mill, a HAL engineer establishes the data flow between pins of module instances.

The LinuxCNC GUIS (AXIS, GMOCCAPY, Touchy, etc.) will represent the states of some pins (such as limit switches) but other graphical tools also exist for troubleshooting and configuration: Halshow, Halmeter, Halscope and Halreport.

The remainder of this introduction presents

HAL is based on the same principles that are used to design hardware circuits and systems, so it is useful to examine those principles first. Any system, including a CNC machine, consists of interconnected components. For the CNC machine, those components might be the main controller, servo amps or stepper drives, motors, encoders, limit switches, pushbutton pendants, perhaps a VFD for the spindle drive, a PLC to run a toolchanger, etc. The machine builder must aselect, mount and wire these pieces together to make a complete system.

Figure one would be written in HAL code like this:

This section is a glossary that defines key HAL terms but it is a bit different than a traditional glossary because these terms are not arranged in alphabetical order. They are arranged by their relationship or flow in the HAL way of things.

As an example, suppose we have a parport component named hal_parport. That component defines one or more HAL pins for each physical pin. The pins are described in that component’s doc section: Their names, how each pin relates to the physical pin, are they inverted, can you change polarity, etc. But that alone doesn’t get the data from the HAL pins to the physical pins. It takes code to do that, and that is where functions come into the picture. The parport component needs at least two functions: One to read the physical input pins and update the HAL pins, the other to take data from the HAL pins and write it to the physical output pins. Both of these functions are part of the parport driver.

Each HAL component is a piece of software with well-defined inputs, outputs, and behavior, that can be installed and interconnected as needed. The section HAL Components List lists all available components and a brief description of what each does.

Unlike the physical wiring models between black boxes that we have said that HAL is based upon, simply connecting two pins with a HAL-signal falls far short of the action of the physical case.

True relay logic consists of relays connected together, and when a contact opens or closes, current flows (or stops) immediately. Other coils may change state, etc., and it all just happens. But in PLC style ladder logic, it doesn’t work that way. Usually in a single pass through the ladder, each rung is evaluated in the order in which it appears, and only once per pass. A perfect example is a single rung ladder, with a NC contact in series with a coil. The contact and coil belong to the same relay.

If this were a conventional relay, as soon as the coil is energized, the contacts begin to open and de-energize it. That means the contacts close again, etc., etc. The relay becomes a buzzer.

With a PLC, if the coil is OFF and the contact is closed when the PLC begins to evaluate the rung, then when it finishes that pass, the coil is ON. The fact that turning on the coil opens the contact feeding it is ignored until the next pass. On the next pass, the PLC sees that the contact is open, and de-energizes the coil. So the relay still switches rapidly between on and off, but at a rate determined by how often the PLC evaluates the rung.

In HAL, the function is the code that evaluates the rung(s). In fact, the HAL-aware realtime version of ClassicLadder exports a function to do exactly that. Meanwhile, a thread is the thing that runs the function at specific time intervals. Just like you can choose to have a PLC evaluate all its rungs every 10 ms, or every second, you can define HAL threads with different periods.

What distinguishes one thread from another is not what the thread does - that is determined by which functions are connected to it. The real distinction is simply how often a thread runs.

In LinuxCNC you might have a 50 µs thread and a 1 ms thread. These would be created based on BASE_PERIOD and SERVO_PERIOD, the actual times depend on the values in your INI file.

The next step is to decide what each thread needs to do. Some of those decisions are the same in (nearly) any LinuxCNC system. For instance, motion-command-handler is always added to servo-thread.

Other connections would be made by the integrator. These might include hooking the STG driver’s encoder read and DAC write functions to the servo thread, or hooking StepGen’s function to the base-thread, along with the parport function(s) to write the steps to the port.