TCP 5-axis kinematics

my question woudt be is there a Switch that connects the Joints
so when i move only A the others follow on point to point
in Heidenhein the switch that connects and opens the point lock is a Mcode
on okuma its a Gcode
i cand find anything on that behavior on the kins of
xyzac-trt-kins
ofcause the TCP system

When G12.1 P1 is activated, so is TCP, and as such moving A will make the other axis move. Activating G12.1 P0 will disable TCP.

This is basically done by activating the forward and reverse kinematic functions for TCP or the forward and reverse functions for trivial kinematics.

Not sure this answers your question?

my question woudt be is there a Switch that connects the Joints
so when i move only A the others follow on point to point
in Heidenhein the switch that connects and opens the point lock is a Mcode
on okuma its a Gcode
i cand find anything on that behavior on the kins of
xyzac-trt-kins
ofcause the TCP system

there are some versions where you can switch kinematics with mcode but the big problem is the A,B and C axis has to be at zero or it will create following error.

with switchkins i have noticed that not only are the other axes being transformed but also when i manually turn the z axis motor axle then the other axes will move accordingly (i guess, have to build a "movement testing" machine to see if everything works how it should).

Check out the patch file I uploaded on page 18. It shows the changes I made against the master branch.

i will have a look, didnt see it first.

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.

3D-Master wrote:

my question woudt be is there a Switch that connects the Joints
so when i move only A the others follow on point to point
in Heidenhein the switch that connects and opens the point lock is a Mcode
on okuma its a Gcode
i cand find anything on that behavior on the kins of
xyzac-trt-kins
ofcause the TCP system

there are some versions where you can switch kinematics with mcode but the big problem is the A,B and C axis has to be at zero or it will create following error.

with switchkins i have noticed that not only are the other axes being transformed but also when i manually turn the z axis motor axle then the other axes will move accordingly (i guess, have to build a "movement testing" machine to see if everything works how it should).

Check out the patch file I uploaded on page 18. It shows the changes I made against the master branch.

i will have a look, didnt see it first.

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.

That is how our matsuura AC machine works.

There are 4 parameters

X center of rotation
Y center of rotation
Distance from the face of the table to the center of rotation.
Distance from spindle gauge line to center of rotation.

The control uses these parameter to calculate the position during TCP and tilting work plane operation.

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.