How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
Configuration with Machinekit and the Hardware Abstraction Layer
The first post of this series saw a major overhaul of the control system of our CNC plasma cutter, with the cabinet almost entirely rewired and many components replaced. With the X and Y axes now moving under new control – a BeagleBone Black (BBB) running Machinekit – this post will cover tuning the axes, homing and torch positioning.
The majority of this configuration will take place via the .hal and .ini files. Together, these allow for flexible configuration of machine control, as well as bed size, emergency stop buttons, spindle control and so forth.
Note that Machinekit is a fork of the popular LinuxCNC software, with much of the existing documentation being relevant to both.
Disclaimer: Plasma cutting torches use lethal voltages. This post and others on this project will describe aspects of our conversion. This is not intended as a comprehensive guide or how-to. Each machine and working environment is different and it is your responsibility to ensure that any modifications you make to a machine meet appropriate safety standards.
Keeping it simple
The Stepconf GUI can help generate your first configuration files
As is often the case it is sensible to begin with a known starting point. We took a version of the configuration files we knew worked well with the BBB and Probotix Breakout Board (or PBX-BB), removing or commenting out everything except X and Y axis configuration.
If you don't have a basic set of configuration files from which to start, you can use the tool that comes bundled with Machinekit, 'Stepconf'. This provides a GUI for input of different variables relating to your machine and generates the necessary files to get you started. These can later be modified with a text editor as necessary.
Axis of control
Once Machinekit has been configured with the aforementioned files, control is achieved via the AXIS GUI.This has software 'pins' which are configured in the .hal to be connected to other 'pins' – either software or hardware – to enable control and display of values.
The CNC plasma cutter is a moving gantry style machine with two axes of motion across the bed: X and Y. This is controlled by stepper motors, one for the X axis and two for Y due to the large mass of the gantry. Though each stepper motor has it's own driver module, the two Y axis driver modules are linked and treated as one by the control system.
Once the axes were moving they could be configured. Upon first boot of Machinekit it was clear that the scaling was way out, with approximately 100mm of real-world movement for 5mm of software movement! Factors to be taken into account for scaling include:
- steps per revolution of the stepper motors
- any micro-stepping performed by the stepper drive modules
- ratio between timing pulleys on stepper motor shaft and the axis
- any other factors such as lead screw pitch, rack and pinion pitch etc
After arriving at an initial value and some trial and error, a scale value of 55 was set in our .ini config file to give correct axis movement. This was first checked with a ruler as a loose guide before using a dial gauge for more accurate measurement.
Homing and soft limits
With axis motion now working as expected attention was turned to configuring the home switches and homing sequence. Each axis has one home switch, connected to a relay and in turn to an input pin on the PBX-BB. These GPIO pins need to be configured in the .hal file,firstly as inputs, before being connected to to the appropriate AXIS pins.
As with our last machine modification, Charles Steinkuehler's spreadsheet provided the necessary pin information to determine how to add these inputs to our .hal file. For example, the X axis home switch is connected to the terminal marked 'XLIMIT' on the PBX-BB. Referring to the spreadsheet shows that the corresponding 'hal_bb_gpio' pin number is 118, and 'proposed GPIO' pin number 818. The two screenshots below show this in two parts – first of all using 'setp' to set the pin as an input, secondly using the 'net' command to configure it as the X axis home switch, making a user-defined signal name 'switches-x' to help identify this.
More information on using commands within the .hal file can be found in the HAL tutorial page.
Once the home switches were configured and tested, the .ini file was edited to set up the 'HOME SEQUENCE'. A series of parameters are used to control the homing sequence, detailed here. The screenshot below shows part of the .ini file that defines the homing behaviour of the X axis.
Note the use of a negative value to change the direction of travel for the latch movement. Use of negative values can also help when it comes to changing the direction of overall axis movement, should an axis travel in the wrong direction.
The screenshot above also shows the maximum and minimum limits for the X axis. These are the 'soft limits' and act in the place of limit switches; once homed the machine will not travel further than designated by these values.
Both the X and Y axes have stepper motor control, meaning that once homed, the control system relies on counting the number of steps sent to the motors to calculate the position of the head. This is an acceptable method providing the motors work as expected, though there are others including the use of encoders to feed back actual machine position to the control system. This is a more reliable solution but is more complicated and expensive to implement.
Both of these solutions are appropriate for axis control within AXIS / Machinekit. In contrast, the plasma torch on our machine is moved up and down by a single DC motor that does not have an encoder providing feedback, making it unsuitable for use as the 'Z axis'.
A simple solution was devised in order to provide a method of setting the plasma torch height whilst other solutions were investigated. Using a H-bridge module installed during the cabinet refit, the plan was to control the motion of the head up or down with custom commands.
G-Code is a widely used numerical control programming language that has many variants. Generally speaking, G-Code is generated in CAM (Computer Aided Machining) software and is used to control movement of a machine. However it is also possible to write your own G-Code with a text editor, or enter codes directly into AXIS.
According to the LinuxCNC reference there are a range of codes reserved for user-defined commands: M100 – M199. When these codes are run, Machinekit will look for an executable file with that name. Two new executable files were created to position the plasma torch height: M100 to move it up and M101 to move it down. These files are shell scripts that use halcmd to control the machine, and take a parameter which specifies how long they run for.
Whilst the above will suffice for rudimentary torch height adjustment, a more advanced torch height control system is planned for the future. This is a reasonably interesting problem to solve but beyond the scope of this post. Further detailed information can be found on the Hypertherm website.
The Hypertherm Powermax45 plasma cutter on our machine is interfaced via a multi-pin connector. Referring to the data sheet, a cable was made with pins connected for both 'arc on' control and 'arc OK' (AKA transfer) feedback.
Like the home switches, these were connected to the PBX-BB ('arc on' via a relay) and configured in the .hal file. Before connecting the new cable to the cabinet, this new plasma control system was tested with two different methods.
Firstly, using a feature in AXIS called HAL configuration, it is possible to see the state of input and output pins. This can be used to highlight errors in the software, for example if Machinekit is trying to alter the state of a particular pin or not, and which pin it is changing.
Secondly and in conjunction with the HAL configuration tool, a multimeter was used to confirm that pins were changing state as shown in the software. Together, this software and hardware testing confirmed that the plasma unit could be controlled from within AXIS.
A final test was carried out whereby a design file was loaded into AXIS and the job executed. The plasma cutter 'arc on' signal triggered, with 'arc OK' simulated by manually connecting two contacts, following which the X and Y axes moved according to the design file.
With the bulk of the machine configuration completed we are almost ready to start cutting. The axes are moving correctly, the homing switches and sequence are working and the soft limits are set. We have torch height positioning working to a point where we could feasibly cut some sheet metal.
In the next post we will look at the workflow from design file to G-Code, modifying the G-Code as necessary before finally cutting some metal and making sparks fly!