Updating LinuxCNC for example from 2.7.0 to 2.7.1 and your PC is connected to the internet is an automatic process. You will see an update prompt after a minor release along with other software updates. If you don’t have an internet connection to your PC see Updating without Network.

1. Upgrade to the new version

This section describes how to upgrade LinuxCNC from version 2.7 to the new version. It assumes that you have an existing 2.7 install that you want to update.

To upgrade LinuxCNC from a version older than 2.7, you have to first upgrade your old install to 2.7, then follow these instructions to upgrade to the new version.

If you do not have an old version of LinuxCNC to upgrade, then you’re best off making a fresh install of the new version as described in the section Getting LinuxCNC.

To upgrade major versions like 2.6 to 2.7 when you have a network connection at the machine you need to disable the old linuxcnc.org apt sources and add a new linuxcnc.org apt source for 2.7, then upgrade LinuxCNC.

The details will depend on which platform you’re running on. Open a terminal then type lsb_release -ic to find this information out:

lsb_release -ic
Distributor ID: Debian
Codename:       wheezy

You should be running on Debian Wheezy (as above), or Ubuntu Precise, or Ubuntu Lucid.

1.1. Setting apt sources

  • Open the Software Sources window. The process for doing this differs slightly on the three supported platforms:

    • Debian Wheezy:

      • Click on Applications Menu, then System, then Synaptic Package Manager.

      • In Synaptic, click on the Settings menu, then click Repositories to open the Software Sources window.

    • Ubuntu Precise:

      • Click on the Dash Home icon in the top left.

      • In the Search field, type "software", then click on the Ubuntu Software Center icon.

      • In the Ubuntu Software Center window, click on the Edit menu, then click on Software Sources... to open the Software Sources window.

    • Ubuntu Lucid:

      • Click the System menu, then Administration, then Synaptic Package Manager.

      • In Synaptic, click on the Settings menu, then click Repositories to open the Software Sources window.

  • In the Software Sources window, select the Other Software tab.

  • Delete or un-check all the old linuxcnc.org entries (leave all non-linuxcnc.org lines as they are).

  • Click the Add button and add a new apt line. The line will be slightly different on the different platforms:

Platform apt source line

Debian Wheezy

deb http://linuxcnc.org wheezy base 2.7-rtai

Ubuntu Precise

deb http://linuxcnc.org precise base 2.7-rtai

Ubuntu Lucid

deb http://linuxcnc.org lucid base 2.7-rtai

Setting apt sources
  • Click Add Source, then Close in the Software Sources window. If it pops up a window informing you that the information about available software is out-of-date, click the Reload button.

1.2. Upgrading to the new version

Now your computer knows where to get the new version of the software, next we need to install it.

The process again differs depending on your platform.

1.2.1. Debian Wheezy and Ubuntu Lucid

Debian Wheezy and Ubuntu Lucid both use the Synaptic Package Manager.

  • Open Synaptic using the instructions in Setting apt sources above.

  • Click the Reload button.

  • Use the Search function to search for linuxcnc.

  • Click the check box to mark the new linuxcnc and linuxcnc-doc-* packages for upgrade. The package manager may select a number of additional packages to be installed, to satisfy dependencies that the new linuxcnc package has.

  • Click the Apply button, and let your computer install the new package. The old linuxcnc package will be automatically upgraded to the new one.

1.3. Ubuntu Precise

  • Click on the Dash Home icon in the top left.

  • In the Search field, type "update", then click on the Update Manager icon.

  • Click the Check button to fetch the list of packages available.

  • Click the Install Updates button to install the new versions of all packages.

2. Updating without Network

To update without a network connection you need to download the deb then install it with dpkg. The buildbot builds new debs each time something is updated and stores them at http://buildbot.linuxcnc.org/dists/

You have to drill down from the above link to find the correct deb for your installation. Open a terminal and type in lsb_release -ic to find the name of your OS.

> lsb_release -ic
Distributor ID: Debian
Codename:       wheezy

Pick the OS from the list then pick the major version you want like 2.7-rt for real time or 2.7-sim for the simulator only.

Next pick the type of computer you have i386 for 32 bit and amd64 for 64 bit.

Next pick the version you want from the bottom of the list like linuxcnc_2.7.4.46.g5954dcf_i386.deb. Download the deb and copy it to your home directory. You can rename the file to something a bit shorter with the file manager like linuxcnc_2.7.4.deb then open a terminal and install it with the package manager with this command sudo dpkg -i linuxcnc_2.7.4.deb

sudo dpkg -i linuxcnc_2.7.4.deb

3. Updating Configuration Files

The new version of LinuxCNC differs from version 2.7 in some ways that may require changes to your machine configuration.

3.1. Distribution Configurations (updates for joints_axes)

The LinuxCNC distribution includes many example configurations organized in directory hierarchies named: by_machine, by_interface, and sim (simulated machines). These configurations are often used as starting points for making a new configuration, as examples for study, or as complete simulated machines that can run without special hardware or real-time kernels.

The configuration files in these directory trees have been updated for the changes required for the joints_axes updates.

3.2. Automatic updates (update_ini script for joints_axes)

Since the joints_axes updates require a number of changes to user ini files and their related halfiles, a script named update_ini is provided to automatically convert user configurations.

This script is invoked when a user starts an existing configuration for the first time after updating LinuxCNC. The script searches the user ini file for a [EMC]VERSION item. If this item 1) does not exist, or 2) exists and is set to the historical CVS value "$Revision$", or is a numerical value less than 1.0, then the update_ini script will popup a dialog to offer to edit the user files to create an updated configuration. If the user accepts, the configuration will be updated.

For example, if the user configuration is named bigmill.ini, the bigmill.ini file and its local associated hal files will be edited to incorporate joints_axes changes. All files of the initial configuration will be saved in a new directory named after the original configuration with a ".old" suffix (bigmill.old in the example).

The update_ini script handles all common user items that are found in basic machines employing identity kinematics. Less common items used in more complex machines may not be converted automatically. Examples of complex machine configurations include:

  • gantries with two joints for an axis

  • machines with jogwheels

  • robots with non-identity kinematics

  • configurations using haltcl files

The following subsections and the section for Hal Changes list items that may require additional user edits to ini or hal files.

3.3. TRAJ velocities, accelerations names

With incorporation of joints_axes functionality, some names were changed to clarify available functionality.

was: [TRAJ]MAX_VELOCITY         is: [TRAJ]MAX_LINEAR_VELOCITY
was: [TRAJ]DEFAULT_VELOCITY     is: [TRAJ]DEFAULT_LINEAR_VELOCITY

was: [TRAJ]MAX_ACCELERATION     is: [TRAJ]MAX_LINEAR_ACCELERATION
was: [TRAJ]DEFAULT_ACCELERATION is: [TRAJ]DEFAULT_LINEAR_ACCELERATION

3.4. Kinematics modules

The gentrivkins and gantrykins kinematics modules have been removed as their functionality is now available in the updated trivkins module.

The gentrivkins module has only been available in prior joints_axes branches. To convert, it is necessary to change the name.

Hal file examples:

was: loadrt gentrivkins
 is: loadrt trivkins

was: loadrt gentrivkins coordinates=xyyz
 is: loadrt trivkins    coordinates=xyyz

Configurations using gantrykins should be updated to use trivkins with the kinstype= parameter set to BOTH (for KINEMATICS_BOTH).

Hal file example:

was: loadrt gantrykins coordinates=xyyz
 is: loadrt trivkins   coordinates=xyyz kinstype=BOTH

See the trivkins man page for additional information ($ man trivkins)

Note: the most supported usage for specifying kinematics in joints_axes is to set values in the configuration ini file [KINS} section and then reference them within the specified [HAL]HALFILES ( .hal .tcl files). For example:

inifile:    [KINS]
            KINEMATICS = trivkins
            JOINTS = 3
            ...

halfile:    loadrt [KINS]KINEMATICS

haltclfile: loadrt $::KINS(KINEMATICS)

3.5. Lathe Configurations

Prior to joints_axes incorporation, lathes were often configured as if they were three axis (XYZ) machines with an unused axis (Y). This was convenient for sharing Hal files (especially for simulation configs) but required specification of [TRAJ]AXES =3, a dummy AXIS_Y section, and provisions for homing the unused Y coordinate. These arrangements are no longer required or recommended.

Historical lathe configurations used the default options for the trivkins kinematics module. These default options configure all axis letters (XYZABCUVW). With joints_axes incorporation, a more appropriate kinematics specification sets the coordinates to the exact ones used (XZ) and sets the number of joints accordingly to 2. There is no need for an ini file [AXIS_Y] section and only two [JOINT_N] sections need be defined.

Example ini file items for a lathe (only sections relevant to kinematics are shown):

[KINS]
KINEMATICS = trivkins coordinates=xz
JOINTS = 2

[TRAJ]
COORDINATES = XZ
...

[AXIS_X]
...

[AXIS_Z]
...

[JOINT_0]
...

[JOINT_1]
...

Note that some simulation configurations may still use the historical lathe configuration precedents.

3.6. Consistent Joints/Axes specifications

Ini file items that affect joints and axes usage must be consistent.

The motion kinematics module typically loaded with [KINS]KINEMATICS= must use a number of joints equal to the number specified with [KINS]JOINTS=.

The kinematics module must implement axis letters that are consistent with the specification used by the task module item [TRAJ]COORDINATES=.

Examples:

Three axis Cartesian machine using trivkins (KINEMATICS_IDENTITY):

  [KINS]KINEMATICS  = trivkins
  [KINS]JOINTS      = 3
  [TRAJ]COORDINATES = XYZ

Two axis lathe using trivkins (KINEMATICS_IDENTITY) with non-consecutive axis letters:

  [KINS]KINEMATICS  = trivkins coordinates=XZ
  [KINS]JOINTS      = 2
  [TRAJ]COORDINATES = XZ

Gantry using trivkins with duplicated axis letters and KINEMATICS_BOTH to allow individual joint positioning (for homing):

  [KINS]KINEMATICS  = trivkins coordinates=XYYZ kinstype=BOTH
  [KINS]JOINTS      = 4
  [TRAJ]COORDINATES = XYYZ

Gantry using trivkins (KINEMATICS_BOTH) with duplicated axis letters and a rotary axis with skipped axis letters (A,B skipped):

  [KINS]KINEMATICS  = trivkins coordinates=XYYZC kinstype=BOTH
  [KINS]JOINTS      = 5
  [TRAJ]COORDINATES = XYYZC

Linear Delta Robot with non-identity kins (KINEMATICS_BOTH) working in Cartesian frame with an additional rotary coordinate:

  [KINS]KINEMATICS  = lineardeltakins
  [KINS]JOINTS      = 4
  [TRAJ]COORDINATES = XYZA

Note: Some general-purpose kinematics modules (like trivkins) implement identity kinematics with support for coordinate specification (axis letters). Axis letters may be omitted. Axis letters may be duplicated. Joints are assigned to axis letters in a defined manner ($ man trivkins).

Note: For trivkins module loading, do not include spaces about the = sign or letters:

This:     [KINS]KINEMATICS = trivkins coordinates=XZ
NOT This: [KINS]KINEMATICS = trivkins coordinates = X Z

Note: Custom kinematics modules that implement non-identity kinematics (like lineardeltakins) define machine-specific relationships between a set of coordinates and a set of joints. Typically, custom kinematics modules compute the joints-axes relationships within the custom module but it is important to use consistent settings for the related ini items: [KINS]JOINTS and [TRAJ]COORDINATES. The details will usually be explained in the module man page (for example, $ man lineardeltakins).

3.7. Home sequences

Negative values may be used for the ini file items named [JOINT_n]HOME_SEQUENCE. Prior to joints_axes incorporation a value of -1 or the ommission of the item indicated no sequence was applicable. Now, only omission of the item is used for that purpose. See the chapter: Homing Configuration for more information.

3.8. Locking rotary indexer (updates for joints_axes)

With joints_axes, an indexer is a joint that can be homed (joint mode) but must also be unlocked from gcode. This requires a one-to-one correspondence between a single joint and an axis.

Specify the joint number that corresponds to a rotary axis (L = A,B, or C) with an ini file setting for the axis:

  [AXIS_L]LOCKING_INDEXER_JOINT = joint_number_for_indexer

Specify that the joint is a locking indexer with an ini file setting for the joint (N is the joint_number_for_indexer):

  [JOINT_N]LOCKING_INDEXER = 1

Hal pins can be created to coordinate use of a locking indicator joint:

   joint.N.unlock      (BIT output from Hal)
   joint.N.is-unlocked (BIT input  to   Hal)

To create these hal pins for locking joints, specify all joints that are used as locking indexers with the unlock_joints_mask parameter for the motmod module. (bit0(LSB)==>joint0, bit1==>joint1, etc.)

  [EMCMOT]
  EMCMOT = motmod unlock_joints_mask=BITMASK

As an example, consider a machine using trivkins kinematics with coordinates XYZB where B is a locking indexer. For trivkins, joint numbers (starting with 0) are assigned consecutively to the coordinates specified (axis coordinate letters may be omitted). For this example, X==>joint0, Y==>joint1, Z==>joint2, B==>joint3. The mask to specify joint 3 is 000001000 (binary) == 0x08 (hexadecimal)

The required ini file entries for this trivkins XYZB example are:

  [KINS]
  JOINTS = 4
  KINEMATICS = trivkins coordinates=XYZB
  ...

  [TRAJ]
  COORDINATES = XYZB
  ...

  [EMCMOT]
  EMCMOT = motmod unlock_joints_mask=0x08
  ...

  [AXIS_B]
  LOCKING_INDEXER_JOINT = 3
  ...

  [JOINT_3]
  LOCKING_INDEXER = 1
  ...

For more complex kinematics, select the joint number as required — there must be a one-to-one correspondence between the rotary axis and the joint number.

(See the motion man page ($ man motion) for more information on motmod)

3.9. Stricter INI file syntax

Lines with numeric INI variables are no longer allowed to have trailing text. In earlier versions of LinuxCNC any text after the number was silently ignored, but as of this version such text is totally disallowed. This includes hash characters ("#"), which in this position are a part of the value, not a comment character.

For example, lines like this will no longer be accepted:

MAX_VELOCITY = 7.5 # This is the max velocity of the axis.

They could be transformed into pairs of lines like this:

# This is the max velocity of the axis.
MAX_VELOCITY = 7.5

4. Hal Changes (updates for joints_axes)

4.1. Wheel or MPG (manual pulse generator) jogging

Prior to incorporation of joints_axes updates, wheel jogging was supported in joint mode only and controlled with hal pins:

   bit   IN  axis.M.jog-enable
   float IN  axis.M.jog-scale
   s32   IN  axis.M.jog-counts
   bit   IN  axis.M.jog-vel-mode

where M is a number corresponding to an axis letter (0==>X, 1==>Y, etc.)

With incorporation of joints_axes updates, wheel jogging is available for joints in joint mode and for each axis coordinate in teleop mode. The controlling hal pins provided are:

   bit   IN  joint.N.jog-enable
   float IN  joint.N.jog-scale
   s32   IN  joint.N.jog-counts
   bit   IN  joint.N.jog-vel-mode

   bit   IN  axis.L.jog-enable
   float IN  axis.L.jog-scale
   s32   IN  axis.L.jog-counts
   bit   IN  axis.L.jog-vel-mode

where N is a joint number and L is an axis letter.

To use an MPG in identity kins configurations where there is a one-to-one correspondence of a joint number and an axis letter, it may be convenient to connect the corresponding hal pins. For example, if joint 1 corresponds exactly to axis letter y:

   net jora_1_y_enable   => joint.1.jog-enable => axis.y.jog-enable
   net jora_1_y_scale    => joint.1.jog-scale  => axis.y.jog-scale
   net jora_1_y_counts   => joint.1.jog-counts => axis.y.jog-counts
   net jora_1_y_vel-mode => joint.1.jog-counts => axis.y.jog-vel-mode

(The signal names jora_1_y_* are examples, names prior to conversion for joints_axes will depend upon the specific configuration details.)

Configurations with non-identity kinematics and configurations that use duplicated axis letters (for example, gantries using more than one joint for an axis coordinate) will require appropriate independent control logic to support both joint and teleop (world) jogging.

4.2. Ini Hal pins

Hal pins are created for ini file items for both joints ([JOINT_N] stanzas) and axes ([AXIS_L] stanzas):

For N = 0 ... [KINS](JOINTS -1)
Ini File Item              hal pin name
[JOINT_N]BACKLASH          ini.N.backlash
[JOINT_N]FERROR            ini.N.ferror
[JOINT_N]MIN_FERROR        ini.N.min_ferror
[JOINT_N]MIN_LIMIT         ini.N.min_limit
[JOINT_N]MAX_LIMIT         ini.N.max_limit
[JOINT_N]MAX_VELOCITY      ini.N.max_velocity
[JOINT_N]MAX_ACCELERATION  ini.N.max_acceleration
[JOINT_N]HOME              ini.N.home
[JOINT_N]HOME_OFFSET       ini.N.home_offset
For L = x y z a b c u v w:
Ini File Item              hal pin name
[AXIS_L]MIN_LIMIT          ini.L.min_limit
[AXIS_L]MAX_LIMIT          ini.L.max_limit
[AXIS_L]MAX_VELOCITY       ini.L.max_velocity
[AXIS_L]MAX_ACCELERATION   ini.L.max_acceleration

Note: In prior versions of LinuxCNC (before joints_axes updates), the hal pin names ini.N.* referred to axes with 0==>x, 1==>y, etc. (pins were created for all 9 axes) See the man page ($ man milltask) for more information

5. Hal Changes (Other)

5.1. Parameter to Pin changes

The following hal output pins were changed from parameters to pins so that they can be connected to signals:

   motion.servo.last-period    (servo last period in clks)
   motion.servo.last-period_ns (kernel-dependent availability)

6. Interface changes for joints_axes

6.1. python linuxcnc module

The jog() interface includes a joint-flag to specify joint (True) or teleop (False) jogging:

jog(command, joint-flag, axis-or-joint-number, velocity[, distance]])

jog(linuxcnc.JOG_STOP, joint-flag, axis-or-joint-number)
jog(linuxcnc.JOG_CONTINUOUS, joint-flag, joint-flag, velocity)
jog(linuxcnc.JOG_INCREMENT, joint-flag, axis-or-joint-number, velocity, distance)

7. GUIs (updates for joints_axes)

7.1. Notes on joint/axis jogging, homing, and kinematics

With incorporation of joints_axes updates, LinuxCNC enforces the distinctions of joints and axes (coordinate letters) — but some guis (like the axis gui) may hide some of the distinctions for simple machines.

In most cases, you can think of joints as motors.

The relationships between joints and axis coordinates are determined by the mathmatical kinematics functions that describe a machine’s motion.

World coordinates (X,Y,Z,A,B,C,U,V,W) are determined by applying FORWARD kinematics operations to joint (motor) positions.

When moving in world space (e.g., gcode movements) the required joint (motor) positions are determined by applying INVERSE kinematics operations to the coordinates requested for motion in world space.

Moving in world space is possible only after homing.

For simple machines (like mills and lathes) there is a one-to-one equivalence of joints and axis coordinate letters. For example, on an XYZ mill, the relationships are typically: axisX==joint0, axisY==joint1, axisZ=joint2. This correspondence is characterized as IDENTITY kinematics and the kinematics module used is usually trivkins (trivial kinematics). (See the trivkins man page $ man trivkins)

Joint jogging (by joint number 0,1,…) is used in joint mode (usually used only BEFORE homing). When homing is completed, the jogging mode is AUTOMATICALLY switched from joint mode to world mode and axis jogging (coordinate letter X,Y,…) is used. This is appropriate for all gcode moves requested by MDI commands or by gcode programs.

Although jogging in joint mode is often never required after homing, some guis (like axis) provide a keyboard shortcut ($) to allow toggling between joint and world (teleop) modes for machines that use non-IDENTITY kinematics.

In many common situations, joint jogging is never needed since homing is accomplished using home switches and/or the various homing methods provided by LinuxCNC. One simply turns on the machine, issues the Home-All command, the machine homes and changes to world mode automatically. See Homing Configuration

Machines that do not use home switches may require manual jogging in joint mode before homing each and every joint. It is also possible to use immediate homing (see the homing docs) for joints that do not require homing to a fixed position.

Although a gui may hide joints/axes distinctions for IDENTITY kinematics machines, it is usually important to complete homing in order to run programs or use features provided by a gui.

By default, the trivkins module declares itself as having IDENTITY kinematics. The distinctions of joint/world operations can be made visible in the axis gui when using trivkins by setting the kinemetics type to a non-IDENTITY type using kinstype=both. The both setting indicates that both forward and inverse kinematics functions are available and gui provisions that hide the distinctions of joints and axis letters should not be employed. For example, for an xyz configuration, specify:

[KINS]
KINEMATICS = trivkins coordinates=xyz kinstype=both

With this setting, identity kinematics will be used but the axis gui will:

  1. show joint numbers prior to homing

  2. show axis letters after successful homing

  3. support toggling between joint and teleop modes with the $ key

7.2. Halui

Halui now supports teleop jogging resulting in some changed pin names and numerous new names for jogging-related pins.

See the man page ($ man halui) for all pin names.

7.2.1. TELEOP jogging (also called axis or world jogging)

New pins for teleop jogging are:

      new: halui.axis.jog-speed
      new: halui.axis.jog-deadband

      new: halui.axis.L.plus
      new: halui.axis.L.minus
           ... etc.

where L is a letter corresponding to one of the axis letters specified by [TRAJ]COORDINATES or selected for the axis selected by the halui.axis.L.select pins.

7.2.2. Joint jogging

All pins for joint jogging were renamed for specificity:

      was: halui.jog-speed          is: halui.joint.jog-speed
      was: halui.jog-deadband       is: halui.joint.jog-deadband

      was: halui.jog.N.plus         is: halui.joint.N.plus
      was: halui.jog.N.minus        is: halui.joint.N.minus
           ...  etc.                    ... etc.

where N is a joint number (0 … num_noints-1) or selected for the joint selected by the halui.joint.N.select pins.

7.2.3. Aditional pin renames

The hal pins for selected joints were renamed for consistency with related pins.

      was: halui.joint.selected.is_homed
       is: halui.joint.selected.is-homed

      was: halui.joint.selected.on-soft-limit
       is: halui.joint.selected.on-soft-min-limit

7.3. AXIS GUI

7.3.1. Identity Kinematics

The axis gui continues to support identity kinematics configurations. This gui hides the distinctions of axes and joints in order to simplify the display and usage of simple machines.

7.3.2. Special case kinematics

Some machines, typically gantrys, may use a configuration with more than one joint assigned to an axis letter. This can be done with the trivkins kinematics module using repeated coordinate letters. For example, a machine configured with ini settings:

[KINS]
KINEMATICS = trivkins coordinates=XYYZ kinstype=BOTH
...
[TRAJ]
COORDINATES = XYYZ
...

This machine, after homing, has a one-to-one correspondence between a single axis letter (Y) and a pair of joints (1,2). Using kinematics=BOTH allows control of individual joints in joint mode if/when required.

7.3.3. Non-identity kinematics

The axis gui supports configurations using non-identity kinematics with:

  1. Key binding ($) to toggle joint or teleop mode

  2. Preview Tab display of joints or axes according to joint or teleop mode

  3. Preview Tab display of Home and Limit icons in joint mode

  4. Preview Tab display of All-homed and 'Any-limit icons in teleop mode

  5. DRO Tab display of joint or axes according to joint or teleop mode

  6. Jogging is supported in both joint and teleop motion modes

  7. External changes to the joint/teleop motion mode are detected.

7.3.4. Home icons

For identity kinematics, Home icons are shown for the correspoinding (one-to-one) axis letter when a joint is homed.

For non-identity kinematics, Home icons are shown for individual joints when a joint is homed in joint display mode. An All-homed icon is displayed for all axis letters when ALL joints are homed in world display mode.

7.3.5. Limit icons

For identity kinematics, Limit icons are shown for the corresponding (one-to-one) axis letter when a joint limit is active.

For non-identity kinematics, Limit icons are shown for individual joints when the joint limit is active in joint display mode. An Any-Limit icon is displayed if any joint is at a limit in teleop display mode.

7.3.6. Key bindings for a fourth axis

In the AXIS gui, jogging keys are assigned to axes in a configurable fashion. For 3-axis machines, XYZA machines, and lathes the default is the same as in 2.7. For other machines, the 4 pairs of jogging keys are assigned to the first 4 axes that exist in the order XYZ ABC UVW. These assignments can be controlled by new inifile directives in the [DISPLAY] section of the inifile

Note that the parameters used for jogging may not be appropriate for both modes for machines with non-identity kinematics.

7.4. tklinuxcnc

The tklinuxcnc gui supports both identity and non-identity kinematics, includes gui radiobuttons and a key bindiing ($) for toggling joint and teleop modes. External changes to joint or teleop motion mode are detected. Jogging is supported in both joint and teleop motion modes. Note that the parameters used for jogging may not be appropriate for both modes for machines with non-identity kinematics.

OpenGL is not used by tklinuxcnc so it may be used to isolate problems and system dependencies that are exposed with more modern guis like axis.

The rudimentary backplot gui provided is available for use with identity kinematics (xyz) machine configurations.

7.4.1. emcsh commands

The code of emcsh.cc provides the set of tcl commands used by tklinuxcnc. The commands are available to tcl applications as the tcl package named Linuxcnc. A number of commands previously required the use of a numeric argument to specify an axis coordinate (0-->X, 1-->Y, …, 8-->W). These commands have been simplified to use an argument that is just the coordinate letter.

Commands now using a coordinate letter argument are:

  1. emc_pos_offset

  2. emc_abs_cmd_pos

  3. emc_abs_act_pos

  4. emc_rel_cmd_pos

  5. emc_rel_act_pos

  6. emc_tool_offset

  7. emc_probed_pos

7.5. touchy

The touchy gui continues to support the identity kinematics configurations that it supported prior to joints_axes incorporation. Jogging is done in teleop mode.

7.6. gscreen

The gscreen gui continues to support the identity kinematics configurations that it supported prior to joints_axes incorporation. Jogging is done in teleop mode.

7.7. gmoccapy

The gmoccapy gui continues to support the identity kinematics configurations that it supported prior to joints_axes incorporation. Jogging is done in teleop mode.

7.8. shuttlexpress driver renamed to shuttle

The HAL driver for the Contour Designs ShuttleXpress device has been renamed from "shuttlexpress" to just "shuttle". If your hal files include some variant of "loadusr shuttlexpress", replace "shuttlexpress" with "shuttle".

Support has been added for the ShuttlePRO, a bigger version of the ShuttleXpress, so the old driver name is no longer accurate.

7.9. linuxcncrsh

"Home All" is now supported with the set home subcommand by using -1 for the joint number

The jogging commands have been altered to accomodate both joint (free) and teleop (world) jogging.

    was: set jog      joint_number             speed
     is: set jog      joint_number|axis_letter speed

    was: set jog_incr joint_number             speed increment
     is: set jog_incr joint_number|axis_letter speed increment

    was: set jog_stop
     is: set jog_stop joint_number|axis_letter

Note: Test for teleop mode using command: get teleop_enable if TELEOP_ENABLE=YES, use axis_letter else use joint_number

Note: Formerly, the command set jog 0 1.234 would jog the zeroth axis (X) with requested speed=1.234 in any mode (free or teleop). This command now attemps to jog the zeroth joint (Joint0) provided the mode is free (not teleop). To jog the X axis, the mode must be teleop and the corresponding command is: set jog x 1.234

8. Obsolete Guis

The guis mini, keystick, and xlinuxcnc have been removed in conjunction with updates for joints_axes. All related source code, examples, and documentation are available in the git repository.

9. Deprecated Guis

The linuxcnclcd gui is a candidate for removal. Should this component be removed, all related source code, examples, and documentation will be available in the git repository.

10. Simulator configurations (updates for joints axes)

10.1. Pre-joints_axes

Prior to joints_axes incorporation, the halfiles used in sim configs typically supported a common milling machine — a Cartesian system with trivial kinematics and three axes named X Y Z. Typical halfile entries:

[HAL]
HALFILE = core_sim.hal
HALFILE = sim_spindle_encoder.hal
HALFILE = axis_manualtoolchange.hal
HALFILE = simulated_home.hal

Lathe configs often shared the same halfiles and used the expedient method of specifying 3 axes with Y unused. More complex sim configs provided specific sets of halfiles according to the configuration purpose.

10.2. Post-joints_axes

With the incorporation of joints_axes functionality, may sims provided in the distribution now take advantage of a general purpose halfile that supports numerous configurations automatically. A typical sim config HALFILE specification is:

[HAL]
HALFILE = LIB:basic_sim.tcl

The basic_sim.tcl HALFILE supports a number of commonly required functions for any number of joints as specified by:

[KINS]
...
JOINTS = number_of_joints
...

Functions supported include:

  1. ddts — differentiator hal components are loaded and connected for each joint (and xy, xyz for trivkins machines)

  2. simulated_home — a sim_home_switch hal component is loaded and connected for each joint. The homing conditions are specified by the usual [JOINT_n]HOME_* ini file items.

  3. use_hal_manualtoolchange — the user space hal_manualtoolchange component is loaded and connected.

  4. sim_spindle — the sim_spindle component is loaded and connected to additional loaded hal components to simulate the inertia of a rotating spindle mass.

The functions are activated by default but can be excluded using options: -no_make_ddts, -no_simulated_home, -no_use_hal_manualtoolchange, -no_sim_spindle.

For example, to omit creation of ddts:

HALFILE = LIB:basic_sim.tcl -no_make_ddts

Omitting one or more of the core functions allows testing without without the function or addition of new HALFILEs to implement or expand on the functionality.

10.2.1. Equivalent Hal commands file

When LIB:basic_sim.tcl is used, an equivalent halfile is created (in the configuration directory) to show the halcmd commands issued. The file name is based on the name of the inifile with _cmds appended to the basename and a conventional .hal file extension. Example:

inifilename:            example.ini
equivalent_halfilename: example_cmds.hal

The equivalent halfile file supersedes previous instances of files with the same filename. Inifile variables substitutions specified in the inifile and interpreted by halcmd are automatically substituted in the created halfile. If there are [HAL]HALFILEs specified before LIB:basic_sim.tcl, their halcmd commands are included too.

The equivalent halfile can be used to create a new configuration based on the original configuration made with LIB:basic_sim.tcl with the following steps:

1) Run the simulator configuration to create a new equivalent halfile, for example: example_cmds.hal.

To use this new equivalent halfile in the original simulator configuration inifile (or a copy of it), edit to change:

[HAL]
HALFILE = LIB:basic_sim.tcl other_parameters

to:

[HAL]
HALFILE = ./example_cmds.hal

10.2.2. Notes

All components and connections made by LIB:basic_sim.tcl can be viewed using halcmd. The entire hal configuration (except for userspace components loaded with loadusr) can be saved to a file using:

$ halcmd save > hal.save

Use of LIB:basic_sim.tcl reduces the effort needed to make a simulation config since it handles most of the required component loading and hal connections.

The sim config Sample Configurations/sim/axis/minimal_xyz.ini demonstrates a working xyz configuration that uses LIB:basic_sim.tcl with a minimal number of ini file settings.

11. Ongoing updates to development branch

Commits to unreleased branches may make changes that affect testers and early-adopters of the unreleased software.

11.1. Hal pins

Name changes:

was: axis.L.vel-cmd
 is: axis.l.teleop-vel-cmd

New pins:

motion.homing-inhibit (see motion manpage)

11.2. Hal component updates

  1. siggen: new pin reset to set output signal values to predefined state

  2. biquad: pins type,f0,Q,s1,s2 were formerly params

11.3. XHC-HB04 Pendant Support

11.3.1. xhc_hb04_util.comp (helper component)

Remove unused pin jogenable-off

Add pin amux-enable so that the multiplexed acceleration reductions are now enabled by the ANDing the pins: is-manual and amux-enable. These two pins are typically connected to halui.mode.is-manual and halui.mode.is-teleop respectively.

11.3.2. xhc_hb04.tcl (optional LIB configuration halfile)

Remove signal pendant:jogenable-off for removed pin pendant_util.jogenable-off

Support connection of halui.mode.is-teleop to pendant_util.amux-enable via the signal pendant:amux-enable. This change allows homing and joint mode jogging to occur at normal (not reduced) acceleration settings.

11.4. [JOINT_n]HOME_SEQUENCE Starting values

Starting sequence values may be 0, 1 (or -1) only. See the "Homing Configuration" documentation for more information.

11.5. [JOINT_n]HOME_SEQUENCE Negative values

Joints using a negative HOME_SEQUENCE are not allowed to jog in joint mode in order to prevent misalignment (racking) in common gantry configurations. As always, machines with any kinematics type must be homed prior to enabling conventional world mode jogging.