TCP 5-axis kinematics

Thanks for your reply,

the problem is not switching kinematics at all, the problem is that the axis have to be at zero (at least form my knowledge, might have to loook into J0-J5) to not trigger a following error. I was able to switch trivial and 5 axis kinematics with my beaglebone but the axis needed to be at zero and this is (at least for me) very disadvantageous because the Cam software might not always go back to ABC=0 before disabling TCP and also i want to write a subprogram to use a touch probe to calibrate the exact center of rotation. So if i use the normal coordinates (XYZABCUVW) i want to stay with them the whole program if you understand right.

thanks

Hello,

Take a glance at switchKins branch also uploaded here is a video demonstrating switch between kinematics right within a NGC program irrespective of where currently machine is positioned.

Branch is also having required files:
ini gcode with which this was tested.

That is something that could be really useful! Great work.

I've tested your configuration, it's exactly what is needed, thank you!

Only one thing I noticed, before homing the machine it doesn't seem to be possible to move axis C, i haven't looked in depth in the ini or hal files, is this a problem due to kinematics or is it fixable by hal/ini?

If it's not possible to move C before homing it's a major drawback because you can't override limits and get out of them, you would have to change settings to be able to come out of limits.

Tomorrow I'll have a deeper look into the ini and Hal to see if I can fix it from there...

I've looked and can't find anything wrong with the hal or ini file that would prevent C from moving before homing.

this is the error that pops up in the terminal when trying to move

Exception in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1544, in __call__
return self.func(*args)
File "/usr/bin/axis", line 2562, in jog_plus
speed = get_jog_speed(a)
File "/usr/bin/axis", line 1761, in get_jog_speed
if joint_type[a] == 'LINEAR':
IndexError: list index out of range

I think i figured it out, it's because in the Kinematics B is skipped, so the Axis interface somehow before homing thinks C should be joint 5 (according to X=>J0,Y=>J1,Z=>J2,A=>J3,B=>J4.C=>J5), but joint 5 doesn't exist, the jog pins for joint 4 (which is axis C in your configuration) work fine, it's because the manual switch is not available by pressing shift+4, so the interface before homing is not sure which joint is which axis, it is a bug but not related to the switch, i think the same would happen in master with a similar configuration but without switch.

how do you tell linuxcnc where the center of rotation of ABC is? can you specify the values in the var file? that would be great because i could correct the center of rotation (with a calibration program) without possibly restarting the machine.

3D-Master wrote: how do you tell linuxcnc where the center of rotation of ABC is?

You can't tell it, and to an extent it doesn't need to know.

It would be useful to be able to do this to get a more accurate graphical preview, but it has no effect on what the G-code does.

In theory it could also be used to convert angular moves into linear feed rates, but I am not sure if any controls actually do that. LinuxCNC doesn't.
Because of this it is better to use inverse-time feed rates when linear and rotary axes are used simultaneously. This needs to be done in the CAM system which _can_ be told where the actual centre of rotation is.

Part of the problem is that this issue simply isn't considered in standard G-code. One interesting solution might be to add a new G-code (G94.1 is available) that defines the rotary axis origin in the current coordinate system. I think that this would be rather beyond the scope of a remapped routine, however.

On fanuc if you are in g43.4 TCP it uses a standard feed rate. The actual is allover the place depending where on the rotary or trunion it is. Almost like constant surface footage.

Without this mode inverse time would be needed.

Leon82 wrote: On fanuc if you are in g43.4 TCP it uses a standard feed rate. .

That's interesting. So there is an established G-code for this?

<Google> studylib.net/doc/6993852/fanuc-5-axis-programming-codes

So, not exactly what I was hoping for.
Still, it is an interesting idea to simply create a new feed or tool-length G-code that does this calculation. G94.1 Xn Yn Zn... for example.