TCP 5-axis kinematics

You need the 5th axis as the W axis.
joint 6 must be a tandem axis as the Y2 or X2 axis.
The W axis is the depth into the material.

Isn´t the W axis for a head-head configuration? I have a table-table configuration.

I reinstalled buster 2.8.2 and updated to the buster master-rtpreempt. Now it is working
I want to thank everyone, who helped me in this amazing forum getting to this point.

I am trying to understand TCP in combination with G28. While staying in TCP mode for the whole program, is the G28 position in space bound to the moving coordinate system? I am asking because of safe retracts. In joint mode, a safe retract with G28 could be considerd a safe position in machine space, but with TCP on, G28 position could move in machine space?

I think that G28 happens in joint space, but I wouldn't want to assume that without testing.

So... Load one of the 5-axis simulators with a graphical machine model and see what happens there?

sim/axis/vismach/5-axis is the place to look, in the sample configs.

Trying to read through the 47 pages of posts, could I please get a summary here?

Can something here be used to jog two joints in joint mode? Reason being, I just switched the makerspace machine from 2.7 to 2.8 and people can't jog the 2-motor synchronized X gantry prior to homing (joint mode). Logically it's a straightforward command to just issue the same move to both joints as specified in the config. People expect it to, it doesn't work, they can workaround by homing (sometimes painfully slow, it's a large machine and the homing seek is slow), and I'd like to add a workaround.

I don't strictly need the AXIS arrows key to do this, which is good because that's not in the custom HAL. Mostly I work with the XHC HB04 mpg which goes through the custom HAL. So I can maybe mux the jogwheel command over to 2 joints at the same time if in joint mode?

dannym wrote:

....they can workaround by homing (sometimes painfully slow, it's a large machine and the homing seek is slow), and I'd like to add a workaround.

Set a higher value for
HOME_SEARCH_VELOCITY =
in the ini file, numbers are in machine units per second.

I was wondering, is it possible to use 

in trivkins? It should be I guess, otherwise switching between two kinematic modules, which do not both support these offsets, the coordinate system would be displaced in space? 

No, trivkins has no idea about those offsets and does not create those pins.

Is there an existing kinematics module, which takes these two offsets into account without using TCP?