CSS/G96 for other than X-axis?

Aciera wrote:

one advantage of using switchable kinematics is that all joints can be homed normally on startup.

Trying to digest all this and a couple questions occurred to me...

Is this the part of the component/programming that changes the position of the joints?:

• CASE 1
  • pos->tran.x = j[0];
  • pos->v = j[2];
• Case 2
  • pos->tran.x = j[2];
  • pos->v = j[0];

More specifically, when the kinematics switch is made is the above what causes the X and V axes DRO's to switch?

Why does X has a 'tran' and V doesn't?  I saw that stuff in userkins.comp, but I can't find an explanation of the programming language/syntax.

 

Why does X has a 'tran' and V doesn't?

I cannot give you a totally clear answer but that is basically just the way the data structure is setup:

pos->tran.x, pos->tran.y and pos->tran.z are the 'translational' parts of the cartesian axis pose (ie X,Y,Z axes)

The other axes elements are just called pos->a, pos->b, pos->c, pos->u, pos->v and pos->w

Is this the part of the component/programming that changes the position of the joints?:

The lines with 'pos->* = j[*]' are part of the 'Forward' kinematic model (ie the section you have on your last post). This is used to calculate the AXIS position after the respective joint has been homed. In your particular case the axis is set the same as the joint.

The lines with ' j[* = pos->*]' are part of the 'Inverse' kinematic model . This is used to calculate that particular JOINT position according to the requested AXIS position. In your particular case the joint is set the same as the axis.

Note that in your CASE 1 the joints/axes mapping is actually trivial just like 'trivkins' and the only thing you do in CASE 2 it to swap the joints/axes

So each 'CASE n' in the forward model needs to have a matching reciprocal 'CASE n' in the inverse model. In other words, if you run a joint position value through the forward kinematic and you run the resulting axis position value through the inverse model you should get the exact joint position value you started out with. If the models do not match upyou will get unstable results (eg runaway values).

More specifically, when the kinematics switch is made is the above what causes the X and V axes DRO's to switch?

The switch is made using a case structure in the forward and the inverse kinematic:
Each case represents a kinematic model. In millturn.comp we have two but you can have as many as you like.
The 'switchkins_type' value is changed using an analog motion pin which is connected to a dedicated hal pin (see [HAL] section of the millturn sim config):

For a more comprehensive switchable kinematics example see:

sim/axis/vismach/5axis/table-dual-rotary

which uses:
github.com/LinuxCNC/linuxcnc/blob/master.../xyzab_tdr_kins.comp

You can download a detailed html documentation on how the kinematic component above was derived:
forum.linuxcnc.org/10-advanced-configura...mill?start=80#263694




For an example using four kinematic models see:
github.com/Sigma1912/LinuxCNC_Demo_Confi...egrex_200y_kins.comp

@Aciera - thank you.

right after I posted the question I found an explanation from Andy & RodW that (sort-of) cleared up my confusion:

forum.linuxcnc.org/24-hal-components/327...again?start=40#93573

That was an 'Ahh-ha!' moment:  I don't know anything about C (or any other programming language) so that stuff all looks like gibberish to me.

Lets see if I've got everything now that I've had a good think:

• INI
  • V-axis
    • change HOME/HOME_OFFSET to "0" (to match X-axis/Joint0)
  • X-axis
    • add min/max limit entries for switched state
    • add max_vel & max_accel for switched state
  • Remap M-codes
  • [KINS]
    • KINEMATICS = parting_slide (yes/no?)
• M-CODES
  • M300 - normal mode;  set #<kinstype> = 0, call M100
  • M301 - switched mode;  set #<kinstype> = 1, call M101
  • M100 - set V-axis min/max limits and vel/accel to normal
  • M101 - set V-axis min/max limits and vel/accel to switched values
• HAL
  • net KINSTYPE-SEL <= motion.analog-out-01 => motion.switchkins-type
  • (analog-out-01 verified to be free)
• COMPONENT
  • parting_slide.comp created from millturn.comp.
  • substituted @Aciera's suggested edits and added comments
  • compile/install
• OPTIONAL?
  • Add G53 G0 V0 initial move to M301 so V and X are both at "0" before switching anything
  • Some sort of safety so joint0 jogging is inhibited when switched?  Don't want to accidentally jog joint0 (actual X) when sub-spindle is clamped on to a part.
    • I will probably also add an X jog-inhibit to my spindle/sub synch sequence.
  • Some sort of safety so everything switches to normal on an abort/estop/similar

Assumptions:

1. I won't need new stepgen settings when switch is active because I'll be commanding the X-axis - which is now joint3.  And nothing about joint3 will have changed.  Millturn example M128/129 only changed the axis settings, not the joint settings.
2. I won't need the G10 home offsets adjustments in the millturn example since I will be setting V and X home to 0.

Still unclear:

• Is the INI [KINS] change, along with HAL file loadrt [KINS]... what calls up parting_slide.comp?
• what connects motion.switchkins-type to the Case0/Case1 settings in parting_slide.comp?

Comments/critique welcome as usual.

On second thought, I will need to include the G10 offset stuff.

Just because I set HOME = 0 for both axes doesn't mean the HOME_OFFSET is the same for both.  And if I plan to use G54 offset to get the parting tool tip at spindle centerline I need the switched X-axis G54 values to be the same as V's.

Hmm...