VERY new user

clive wrote: KINEMATICS = trivkins coordinates=XYZA
#This is a best-guess at the number of joints, it should be checked
JOINTS = 4[/b]
to
KINEMATICS = trivkins coordinates=XAYZ since the A stepper needs to be ganged to the X stepper ??
or should it be
KINEMATICS = trivkins coordinates=XYZX
or
KINEMATICS = trivkins coordinates=XXYZ kinstype=BOTH

all very confusing.

If the X axis has two motors, and the second motor was previously configured as an A axis, then XYZX is what you want.

Think of a "joint" in the config as a motor.
An "axis" is an actual cartesian direction, controlled by a G-code XYZABCUVW word.

So, previously you (probably) had the X axis moved by motors 0 and 3. And you never had an actual A axis, ie a motor that could be moved by an "A" in the G-code?

In that case XYZX means X = 0, Y = 1, Z = 2, X2 = 3

Is it that the hal and ini files are responsible for describing the formal logical axes and then assigning them to physical axes and their parallel port pin assignments?

So in the hal file the joints [JOINT_0] through [JOINT_3] are known as x,y,z,a as in: but in the ini file the axes are more formally described in upper case letters, such as this:
The mapping from logical to physical is done with the JOINT_ nomenclature?
The kinstype=BOTH ties the two logical X axes together?

But I see a problem. The ini file has a reference to AXIS_A which doesn't exist (as an logical axis) and perhaps is linked to JOINT_3. JOINT_3 should have the same values as JOINT_0 since both are the X-axis motors.

Not really.

XYZ (and friends) are directions in the workspace. And are controlled by matching words in the G-code.
These are the "axes"

A physical machine consists of one or more "joints" with typically a single motor per joint.

Joints have numbers, starting from 0. The kinematics file configures how an axis motion from the G-code is translated to a joint motion.

In the case of trivkins this is very simple (trivial, even).

coordinates = XYZX means that the X-number from G-code goes to joints 0 and 3.

Don't read too much in to the signal names in the HAL file (the first thing after "net". Those are just labels and can be anything. In fact it would probably be sensible to change the "astep" and "adir" to be "x2step" and "x2dir" everywhere to help dispel some of this confusion. You don't have an A-axis. You do have a joint-3.

I can see the sense behind the use of the word "joint" since it's a plausible term for arm-like devices, though somewhat odd for stepper motors. A rose by any other name.

Your comment that, in my case, the G-Code X-number goes to joints 0 and 3 makes things very clear. Thank you.

XYZABCDE = Joints 0, 1, 2, 3, 4, 5, 6, 7 for rather simplified legs on a spider but some legs probably always move together so XYZZYXDA is also possible.

Do I need that kinstype=BOTH statement at all?

What performs the linkage between the logical joints and the physical connections? Is it the statements in the hal file?

clive wrote: I can see the sense behind the use of the word "joint" since it's a plausible term for arm-like devices, though somewhat odd for stepper motors. A rose by any other name.

It is about as good as anyone seems to have come up with for as a word to describe both sliding and rotating mechanisms.

[/quote]Do I need that kinstype=BOTH statement at all?[/quote]

What that does is start the machine up in joint-mode (you will see the DRO showing 0,1,2,3 until you are homed) This is almost certainly what you want for a gantry, but the docs should explain further. linuxcnc.org/docs/2.8/html/man/man9/trivkins.9.html
(Though having read that, I am not 100% sure which I would prefer)

What performs the linkage between the logical joints and the physical connections? Is it the

Code:

setp stepgen.0.position-scale [JOINT_0]SCALE

statements in the hal file?

The actual links between the joints and a particular stepper motor are defined by the HAL file.
Look for a line containing "joint.0.motor-position-cmd". That is connecting a specific logical joint to a specific step-generator. (and there is no requirement that joint.0 has to use stepgen.0, but it would be unusual not to)
Then the outputs of that step genearotor (step and dir pins) are steered to a specific parallel port pin elsewhere in the HAL file.

This might appear complicated, but it means that you can use external hardware to generate steps, or connect to an analogue servo, or digital serial positioner with simple edits to the file.

clive wrote: I can see the sense behind the use of the word "joint" since it's a plausible term for arm-like devices, though somewhat odd for stepper motors. A rose by any other name.

It is about as good as anyone seems to have come up with for as a word to describe both sliding and rotating mechanisms.

Do I need that kinstype=BOTH statement at all?

What that does is start the machine up in joint-mode (you will see the DRO showing 0,1,2,3 until you are homed) This is almost certainly what you want for a gantry, but the docs should explain further. linuxcnc.org/docs/2.8/html/man/man9/trivkins.9.html
(Though having read that, I am not 100% sure which I would prefer)

What performs the linkage between the logical joints and the physical connections? Is it the

Code:

setp stepgen.0.position-scale [JOINT_0]SCALE

statements in the hal file?

The actual links between the joints and a particular stepper motor are defined by the HAL file.
Look for a line containing "joint.0.motor-position-cmd". That is connecting a specific logical joint to a specific step-generator. (and there is no requirement that joint.0 has to use stepgen.0, but it would be unusual not to)
Then the outputs of that step genearotor (step and dir pins) are steered to a specific parallel port pin elsewhere in the HAL file.

This might appear complicated, but it means that you can use external hardware to generate steps, or connect to an analogue servo, or digital serial positioner with simple edits to the file.[/quote]

I see: but only that one appears. I guess there should be four of them?

Well, there will be joint.1.motor-pos-cmd, joint.2.... etc
One for each joint.

And if you follow the xstep signal through the HAL file you will see where that is sent.

Attached are my much edited ini and hal file. They are accepted without error, however, I can't manually move the X axis. Y and Z are OK.

Ideas? I feel I am getting close

You probably won't be able to jog X until both sides are homed.
I don't see any homing information in the INI file.

Try adding HOME_SEARCH_VELOCITY = 0 and a HOME_SEQUENCE = to each joint (0 for Z, 1 for Y and -2 for X, I think)