TCP 5-axis kinematics

3D-Master wrote: would it be possible to read the position of the center of rotation for the rotary axes from the .var file? this would be really awesome so i could write myself a routine which probes the real center of rotation and i dont have to fiddle around in the ini everytime the position changes.

From a switchkins perspective I think that as long as the values are set while in trivial kinematics, this should not be a problem.

While in TCP mode, changing the origin would, I suspect, cause an immediate following error.

However, there are so many configuration items on the ini file as is, having the origin of the 5 axis on the ini file, does not disturb me. It’s not like I want to probe the position often nor that it changes frequently.

What is the scenario where having to restart LinuxCNC due to the 5 axis origin change becomes a nuisance?

Maybe I’m missing the frequent use case for moving the 5 axis clamping position?

Just curious why couldn't this be set up to respond like applying an offset where the new position created doesn't cause a movement, but takes effect on the next command move. Or am I naive to think that.

On next move, would leave the machine in an inconsistent state until the next move.

Also, what rules should the machine execute that offset move with? Same as the next move? With Rapid speed?

Ideally we would recalculate the coordinate system offsets based on the new origin of the 5 axis and thus require no move at all.

I’m positive something could be done to enable this, I just don’t see the benefit for the effort.

so this mode TCP can only be activaded from the center of rotation with the Z as the only free Axis
as i do understand this right
as of a impellar id like to get it activated at a Cx Ax and then turn over to the oposit in C and the XYZ is following on TCP point
isent this posible

You can activate TCP at any time and at any position of any of the axis. I was speaking of changing the TCP center of rotation while in TCP is activated.

So imagine the machine is started, TCP is activated, G12.1 P1 and then the operator decides to move the 5 axis clamping position. Now TCP will not work until the new center of rotation of the 5 axis is made known to LinuxCNC. The question raised earlier was, can’t we change the known center of rotation without having to update the ini file and subsequently restart LinuxCNC.

At work, at this point I would schedule a meeting so we could align further

So the kinematic functions, that is the math behind it, need to know where the center of rotation of the 5 axis is.

With this approach, you can then set your g54, g55, etc zero where ever you want, corner of your workpiece, center, etc. The cam software is told the same, i.e. the zero is the corner, center, etc of the workpiece.

Another approach is that you configure the center of rotation in the cam software only, eg Fusion 360, and then g45, g55 zero needs to be set to the center of rotation of the 5 axis - which in my view is terrible.
With this second approach the kinematics module does not need to know the 5 axis center of rotation.

So essentially, for TCP to work, the kinematic functions, the work offsets (g54, g55) and the cam software needs to be in sync - that is consistent to one another.