TCP 5-axis kinematics

Since I can't test it now, I see only two ways forward, you reproduce it in the Vismach configuration and then I can test it as well, or you attach your config files and I have a look at it .... other ideas?

maybe if i replace all changed files with the original ones and then re-changing them to suit switchKins the error will be gone.

I've created a branch to test/demonstrate kinematics
switching (xyzac & trivkins, xyzbc & trivkins).

The branch is based on the original work of Rudy du Preez
and subsequent modifications by Rushabh, JSKangas, Plopes
(and probably others). The branch supplies kinematics
modules (xyzac-trt-switchkins,xyzbc-trt-switchkins) and
modifies the motion module.

The branch incorporates a simplified approach that
avoids changes to the interpreter, task, and nml.
Kinematics switching uses a new hal pin and existing
interpreter synching commands.

---

Summary:

1) A new hal pin (motion.switchkins-type) instructs a
candidate kinematics module to switch to a specified
kinematics type.

2) A gcode subroutine (switchkins.ngc) sets a motion analog
output pin netted to motion.switchkins-type and issues M66
(wait-on-input) commands to synchronize task and motion.

---

Since the code changes are limited to the motion module,
this branch presents a low risk for incorporation into the
master branch (if it survives user testing).

The branch is on github as dgarr/s_kins and includes
sim configs:
configs/sim/axis/vismach/5axis/table-rotating-tilting/xyzac-trt-switchkins.ini
configs/sim/axis/vismach/5axis/table-rotating-tilting/xyzbc-trt-switchkins.ini

---

Many aspects can be tested with the sim configs but
I lack equipment to do hardware tests. Interested
users are encouraged to respond to this thread with
testing results (or email me d g a r r e t t at panix dot com)


Ref: github.com/LinuxCNC/linuxcnc/commits/dgarr/s_kins

Thank you dgarret. The other approach was more elegant but I understand that this makes it more likely to get included.

I very much appreciate your effort to get it in.

I just had a quick look but will have a more thorough look at the weekend.

Unfortunately my machine is dismantled atm (I’m scraping the ways) so I can’t really do hardware testing but will certainly try the simulation.

Thanks again for trying to push this.

Hello

I also took a look at it.
I did not find any indication of defining a rotary point what is a one of the essential point in this.

For me it looks like in this you need to define your machine zero and zero point in center of rotation axis's?

I did not find any indication of defining a rotary
point what is a one of the essential point in this.

Not an expert on the math but the XYZAC
(xyzac-trt-switchkins.c) code includes
*_rot_point halpins used in the forward
and inverse non-triv calculations:

Ref: github.com/LinuxCNC/linuxcnc/blob/dgarr/...zac-trt-switchkins.c
Lines: 105 ... xyzacKinematicsForward()
Lines: 179 ... xyzacKinematicsInverse()

This switchkins xyzac-trt-switchkins.c code incorporated
in the branch dgarr/s_kins is based on the following
information from prior forum posts:

1) Forum post of 25jan19:
forum.linuxcnc.org/10-advanced-configura...tics?start=90#124848
which seems to refer to this source:
github.com/rushabhGH/linuxcnc/blob/switc...ematics/switchKins.c

2) Updates to above switchKins.c from forum post of 04nov19:
forum.linuxcnc.org/10-advanced-configura...ics?start=170#149538
which includes this patch:
forum.linuxcnc.org/media/kunena/attachme...-homing-option.patch

This patch adds the *_rot_point halpins for XYZAC kinematics.

The code for XYZBC kins (xyzbc-trt-switchkins.c):
Ref: github.com/LinuxCNC/linuxcnc/blob/dgarr/...zbc-trt-switchkins.c
probably needs similar additions.

I can update xyzbc-trt-switchkins.c if someone supplies
a patch for incorporating the required *_rot_point hal pins.

History:

This thread discusses a complicated subject with
several contributors, a number of interested users,
a variety of nomenclature, several false starts and
some reports of success.

My interest with the dgarr/s_kins branch is to provide
a common branch to unify efforts. I will accept patches
by email (d g a r r e t t at panix dot com) and
force-push incorporated patches.

dgarret, your analysis is correct, AC has center of rotation, BC does not.

jsskangas if you could update the bc file with your center of rotation we would cover both.

Once again, thank you dgarret for putting this together.

Ok.

I will make updated packet from my machine.
I will correct one error in kinematic calculation and will send packet to dgarret.

I will try to get it done during next week.


I have not yet tested this branch and I only took fast look around changes made to code.
Can someone give me a quick heads up.

What command is used to switch between kinematics and can this switch be done when rotary axes are pre-positioned?

From reading the code, the script configs/sim/axis/vismach/5axis/table-rotary-tilting/examples/switchkins.ngc contains a function that does the switch.

so calling
o<switchkins>call[0] ;switch to XYZBC or XYZAC
o<switchkins>call[1] ;switch to TRIVKINS

the call with argument 0 will switch to AC or BC depending on the KINEMATICS loaded:
[KINS]
KINEMATICS = xyzac-trt-switchkins or KINEMATICS = xyzbc-trt-switchkins

The simplified kinematics switching method using
the motion module hal pin motion.switchkins-type
requires a user to:

Then the command to switch within gcode is:

In the provided sim configs:
So the switckins.ngc file is:

github.com/LinuxCNC/linuxcnc/blob/dgarr/...mples/switchkins.ngc

Other files in the same examples directory should work too:
github.com/LinuxCNC/linuxcnc/tree/dgarr/...ary-tilting/examples


Some may require touch off for Z, see:
github.com/LinuxCNC/linuxcnc/blob/dgarr/...otary-tilting/README



The sim configs gui includes buttons and
a label display to:

1) set to XYZAC (or XYZBC) via a halui mdi pin
or
2) set to trivkins via a halui mdi pin
3) Display the current active kins type

These may be useful for testing using jog
buttons (after homing of course)

Ok, so there is a sub program that does switching.

M66 a sync command? does some needed trick internally?
then switching a kinematics by hal pin with M68 command
and M66 again

Can we combine this all under one G or M code that is modal, like M128 what is user defined M command?
And M129 to deactivate it.

Would be easier from CAM/post point of view.
And NC-code would be more readable.
M128 is modal, so TCP active state is readable from active modal codes in UI.