Kinematics switch
11 Sep 2019 06:17 #144785
by pl7i92
Replied by pl7i92 on topic Kinematics switch
Question
isent ther a WORLD agreement between mashine controll builders to switch TCP and Trivial on M128 M129
as okuma heidenhain maho deckel uses this
isent ther a WORLD agreement between mashine controll builders to switch TCP and Trivial on M128 M129
as okuma heidenhain maho deckel uses this
Please Log in or Create an account to join the conversation.
12 Sep 2019 09:28 #144949
by m.bofi
Replied by m.bofi on topic Kinematics switch
andypugh: It is possible and as a matter of fact that will be my course of action. To notify the user to jog inbetween the programs
pl7i92: i have heard that too and that was my original idea but i couldnt implement it
pl7i92: i have heard that too and that was my original idea but i couldnt implement it
Please Log in or Create an account to join the conversation.
17 Sep 2019 15:45 #145398
by andypugh
One reference I found says : M121-M128 Pulsate (on/off) fast output byte bit 1 (to 8).
Another describing Hurco says "Tool Center Point Management (M128) and
Tool Center Point Management Cancel (M129)"
RepRap says M128: Extruder Pressure PWM / M129: Extruder Pressure Off
So we might be in this area
LinuxCNC makes it relatively easy to remap M128 / M129 to alter the value of a HAL pin that could be used to switch the kinematics calculations (via pin created by the kins). Though that isn't quite the same as having a code that actively switches kinematics calculations on and off.
I think that all G-codes are broken down into the canonical commands here:
github.com/LinuxCNC/linuxcnc/blob/master...mc/nml_intf/canon.hh
And maybe searching the code for these constants:
github.com/LinuxCNC/linuxcnc/blob/master...ml_intf/canon.hh#L86
Would help to figure out if adding M128 / M129 would be easy or hard.
(You can call canonical commands in remap routines)
I have no real feel for whether this is an easy or hard thing to achieve.
Replied by andypugh on topic Kinematics switch
Question
isent ther a WORLD agreement between mashine controll builders to switch TCP and Trivial on M128 M129
One reference I found says : M121-M128 Pulsate (on/off) fast output byte bit 1 (to 8).
Another describing Hurco says "Tool Center Point Management (M128) and
Tool Center Point Management Cancel (M129)"
RepRap says M128: Extruder Pressure PWM / M129: Extruder Pressure Off
So we might be in this area
LinuxCNC makes it relatively easy to remap M128 / M129 to alter the value of a HAL pin that could be used to switch the kinematics calculations (via pin created by the kins). Though that isn't quite the same as having a code that actively switches kinematics calculations on and off.
I think that all G-codes are broken down into the canonical commands here:
github.com/LinuxCNC/linuxcnc/blob/master...mc/nml_intf/canon.hh
And maybe searching the code for these constants:
github.com/LinuxCNC/linuxcnc/blob/master...ml_intf/canon.hh#L86
Would help to figure out if adding M128 / M129 would be easy or hard.
(You can call canonical commands in remap routines)
I have no real feel for whether this is an easy or hard thing to achieve.
Please Log in or Create an account to join the conversation.
04 Nov 2019 10:44 #149534
by automata
Replied by automata on topic Kinematics switch
Hi Andy,
I know this is an old thread but I just came across it.
I wanted to make clear the need for switchkins.
In a robot/5 axis CNC, you will come across a scenario where some motion commands will be specified in the joint coordinates and some in the world cooridnates.
The joint and world coordinates are releated by the kinematics.
Now linuxcnc allows only to specify XYZABC(UVW) motion in a program.
These coordinates could mean different motion based on the kinematics that are being used.
In a single program, when you want to switch between motion specified in joint mode and then subsqquently motion is specified in task mode (like turn on RTCP), you need to switch the kinematics.
Ofcourse this can be done through HAL pins. But doing it that way does not take one scenario into account.
That is when switching from joint mode to task mode or vice-versa, the current coordinates of the axes in the planner change based on the kinematics used. So the current values of the axes in the new coordinate system need to be provided to RS274 as well as the motion planner.
This job is done by G12.1. It also acts as a queuebuster.
When G12.1 is encountered, all the motions before are completed. Then using the forward kinematics, the current values of the joint encoders, new axes positions are computed using the forward kinematics and these new values are synced to RS274 (not really needed) and motion planner.
This way the new motion plan can start from the current value of XYZABCUVW of the new coordinate sytem/kinematics.
The requirement stems mostly because both RS274 + linuxcnc motion planner cannot specify the coordinates with a selection of kinematics. So G21.1 acts as a modal selection of current kinematics.
Hope this helps.
Regards
-automata
I know this is an old thread but I just came across it.
I wanted to make clear the need for switchkins.
In a robot/5 axis CNC, you will come across a scenario where some motion commands will be specified in the joint coordinates and some in the world cooridnates.
The joint and world coordinates are releated by the kinematics.
Now linuxcnc allows only to specify XYZABC(UVW) motion in a program.
These coordinates could mean different motion based on the kinematics that are being used.
In a single program, when you want to switch between motion specified in joint mode and then subsqquently motion is specified in task mode (like turn on RTCP), you need to switch the kinematics.
Ofcourse this can be done through HAL pins. But doing it that way does not take one scenario into account.
That is when switching from joint mode to task mode or vice-versa, the current coordinates of the axes in the planner change based on the kinematics used. So the current values of the axes in the new coordinate system need to be provided to RS274 as well as the motion planner.
This job is done by G12.1. It also acts as a queuebuster.
When G12.1 is encountered, all the motions before are completed. Then using the forward kinematics, the current values of the joint encoders, new axes positions are computed using the forward kinematics and these new values are synced to RS274 (not really needed) and motion planner.
This way the new motion plan can start from the current value of XYZABCUVW of the new coordinate sytem/kinematics.
The requirement stems mostly because both RS274 + linuxcnc motion planner cannot specify the coordinates with a selection of kinematics. So G21.1 acts as a modal selection of current kinematics.
Hope this helps.
Regards
-automata
Please Log in or Create an account to join the conversation.
04 Nov 2019 11:11 #149537
by andypugh
Replied by andypugh on topic Kinematics switch
Is there a convention for how joint-mode motions are specified in G-code?
Is it usual to use XYZABCUVW mapped 1:1 to joint numbers, or is it something like "G0 J2 Q30" to move joint 2 to 30 degrees?
Is it usual to use XYZABCUVW mapped 1:1 to joint numbers, or is it something like "G0 J2 Q30" to move joint 2 to 30 degrees?
Please Log in or Create an account to join the conversation.
05 Dec 2019 04:44 #152044
by thang
Replied by thang on topic Kinematics switch
I tried to use G12.1 command and ran into a problem. Both mode use axis max_acceleration and max_velocity parameters , joint following error will occur if axis parameter is higher than joint parameter. example:
axis X: max_acceleration = 1000
max_velocity = 1000
Joint 0: max_acceleration = 500
max_velocity = 500
command "G0 X400" will trigger joint following error
axis X: max_acceleration = 1000
max_velocity = 1000
Joint 0: max_acceleration = 500
max_velocity = 500
command "G0 X400" will trigger joint following error
Please Log in or Create an account to join the conversation.
Time to create page: 0.073 seconds