Making some axes independent of the motion controller

@dgarrett

Thanks for that very usefull feature, as it allows to build handling units and use separate joints for tool changers!
I played arround a little and I did set
j4.limit3.min = 0
j4.limit3.max = 100
Why is it possible to set:
j4.limit3.in = 222.75

That value is out of the limits. Is there a possibility to check for the limits?

Norbert

That value is out of the limits. Is there a possibility to
check for the limits?

The in pin to the limit3 component can be anything but the *output*
is limited according to the .min and .max pins (and the velocity
and acceleration of the output is limited according to the .maxv and
.maxa pin values).

The out pin of the limit3 is the input for the 'extra' joint after homing
as connected to joint.4.posthome-cmd. The usual joint.4.motor-pos-cmd
is the input to a motion controller (pid-motor-encoder or stepper system)
and includes the motor-offset resulting from the homing process.

Ref: linuxcnc.org/docs/master/html/man/man9/limit3.9.html

Thanks, I did not realize that. So I need to find a way to limit the possible inputs and give the user that way a information.
That is just a GUI part, so that part is easy

Hope you will include that branch to master.

Norbert

So I'm finally trying to test out this new branch that dgarrett included. (Huge thanks by the way!)
I'm not a coding guy by nature, so I'm trying to figure out how to properly install this branch. I should be able to get some help from a coworker. But, my struggles with basic github aside, I'm struggling with some syntax in your example .hal file.

Here is the demo1.hal:
I guess I'm confused by the Joint vs. Axis differences. This link doesn't have any "joint" pins the way you use them. When do I use Joint and when do I use Axis? Is the colon in the "j0:loop" a special character or is that just another variable name? I'm going to have to understand all of this if I'm going to figure out how to merge it with the rest of my .hal file. Once again, thanks for any help. Pointing me at an example or the right documentation would be a major help.

I guess I'm confused by the Joint vs. Axis differences.

One can almost always equate joints to motors (prime
movers). Axes are world cartesian coordinates (in LinuxCNC:
XYZ ABC) (UVW are available as auxiliary coordinates usually
aligned with one of the cartesian coordinates.)

When LinuxCNC is started, only joint (motor) motion is
initially available. In operation, joints must be 'homed'
using methods provided by LinuxCNC. These methods typically
use a home-switch and perhaps an encoder index signal. Once
all joints are homed, LinuxCNC switches from joint control
to world coordinate control as specified by the loaded
kinematics module. Coordinated movements include gcode
(e.g., MDI or a GCODE program) and world jogging moves
(called 'teleop' in some places).

The experimenal branch dgarr/motion_extrajoints provides a
means to specify 'extra' joints that are homed by normal
LinuxCNC methods but do *not* participate in the kinematics
transformations employed for coordinated motion.

When using 'extra' joints, one uses existing methods to
home all joints -- joints that are kinematically transformed
to world (XYZABC) coordinates *and* the 'extra' joints that
do not participate in the kinematics transformations that
translate motor postions to/from world coordinates.

After homing, when operation is switched to coordinated
mode, the 'extra' joints must be controlled by independent
motion controllers. These motion controllers are not known
to LinuxCNC or its management of planned motion in world
space. After homing, each 'extra' joint is managed by a
single hal pin (joint.N.posthome-cmd). This pin would
typically be the driven by an independent motion planner that
uses a limit3 component to manage motion. The limit3
component provides hal pins to constrain the limit3 output
in its min/max position, its position_max_velocity, and its
position_max_acceleration. As always, the implementation must
provide a means to convert the joint.N.motor-pos-cmd
output to drive its motor (for example a step generator or a
pid-amplifier-encoder setup for a servo motor) during and
after homing.

To *use* the 'extra' joints in a GCODE program, one method
would use USER M commands to provide setpoints to the
limit3 input pin (and maybe to other limit3 pins that
limit position, velocity, and acceleration). For example,
to establish a new 'extra' joint position for the 'extra'
joint numbered 4, a bash script (M155) would be something like:
An example GCODE program excerpt could be:
Note: this simple example does not show any required delays or
synchronizing steps that might be needed for a real
application.

This link doesn't have any "joint" pins the way you use them.

The link is for the current release branch 2.7.x and is not appropriate for
any experimental branch based on master.

Use the motion man page ($ man motion) for the experimental branch. Raw format:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...cs/man/man9/motion.9

The raw format may be hard to read, excerpt:

When do I use Joint and when do I use Axis?

In addition to the brief above, please see:
linuxcnc.org/docs/master/html/motion/kinematics.html

Is the colon in the "j0:loop" a special character or is that just another variable name?

The ':' is just a character in the signal name, it makes it
easy to find in halcmd reports (for example: $ halcmd show sig|grep

Pointing me at an example or the right documentation would be a major help.

The experimental branch includes two examples:
demo1.ini uses immediate homing so a user must jog a
joint before homing to see how a motor offset
due to homing is handled.
demo2.ini uses a the library halfile (basic_sim.tcl) to make
hal components and connections based on the items
specified in the ini file. The library provides
a means to simulate home switches for many
configurations.

Step-by-step instructions for these demos are provided:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...xtrajoints/demo1.txt
github.com/LinuxCNC/linuxcnc/blob/dgarr/...xtrajoints/demo2.txt



Notes:

1) all descriptions above are based on joint-axes
incorporation in the master branch (2.8~pre)

2) some guis (axis) hide the distinctions of joints and axis
coordinates when using trivial kinematics (trivkins) with
KINEMATICS_IDENTITY (the default).

3) When using trivkins with the axis gui, it is helpful to
always specify kinstype=Both to clarify the distinctions
between joints (0,1,2,...) and axis coordinates
(X,Y,Z,A,B,C...). See the trivkins (kins) man page:

linuxcnc.org/docs/master/html/man/man9/trivkins.9.html

4) Specifying extra joints in the experimental branch is a
little tricky since the branch preserves backwards
compatibility to all prior module parameters

5) User M code can receive two parameters (P
and Q) that can be used for various purposes.

linuxcnc.org/docs/master/html/gcode/m-code.html#mcode:m100-m199

6) Synchronizing 'extra' joint motion to
GCODE could be achieved with some hal logic
and GCODE reading of hal pins using M66

www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m66

7) An alternative to using user M codes for communicating to
extrajoints is to use GCODE writes to hal pins using M67 or M68

www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m67
www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m68


Note: 19mar19, branch rebased to master at commit 3f2976547

Thanks, dgarrett!

I've muscled my way through installing the RunInPlace master branch and your extrajoints branch. I've managed to modify my .hal and .ini files to open linuxcnc successfully, so that feels good. Now to do some characterization tests so that everything works the way I expect before I repeat this whole process on the computer running the actual robot.

Cheers!

I've been chasing down a following error I get when I attempt to home one of the channels, but I think it might be a mistake with my .ini and .hal files. However, I ran ./runtests because I saw that on the instructions from linuxcnc.org/docs/devel/html/code/building-linuxcnc.html. And I got a ton of errors. I'm not sure if I'm supposed to take them seriously or not. I've attached my testresults file...

I was able to find the errors with my .hal file. *phew* It was just my own stupidity...

Unrelated, I'm seeing some odd behavior with homing sequences. I was testing on my 2nd system (no steppers attached to the Mesa board) so I set all of the homing sequences to -1 except for the joint that I wanted to test. After properly homing my one joint, it then proceeded to try and home all of my other joints.

Based on this: linuxcnc.org/docs/html/config/ini-homing.html that shouldn't have been the case. Is this related to the errors? I know I was able to isolate the homing sequences during testing before...