TCP 5-axis kinematics
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
Please Log in or Create an account to join the conversation.
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
switchKinsAxis_mm.ini
G12-test.ngc
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
- grandixximo
-
- Offline
- Expert Boarder
-
- Posts: 134
- Thank you received: 3
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...
Please Log in or Create an account to join the conversation.
- grandixximo
-
- Offline
- Expert Boarder
-
- Posts: 134
- Thank you received: 3
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
Please Log in or Create an account to join the conversation.
- grandixximo
-
- Offline
- Expert Boarder
-
- Posts: 134
- Thank you received: 3
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
Without this mode inverse time would be needed.
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.