G10 rotations
06 Oct 2021 21:14 #222404
by rgb
G10 rotations was created by rgb
I've been reviewing the interpreter code in some detail with respect to xy rotations specified via G10 R parameters. I think there may be a few problems. The code in some cases appears to assume that the results of an translation followed by a rotation about the translated Z axis is the same as a rotation about the current Z axis followed by a translation. In other cases the (g28, g30) the code doesn't take the rotations into account.
The purpose of this note is to tie down the semantics. Here's what I think they are, using the G5x code as a "gold standard".
1) Tool x, y offsets are relative to the machine coordinate system.
2) G10 xy rotations should be around the G5x translated axis. Ie, first you translate then you rotate.
3 G92, G52 offsets are relative to the current G5x coordinate system
Comments please. I'm deep enough into this now that I can probably come up with a set of proposed patches for people to play with. There are dragons out there though given that persistent parameters (g28 saved positions, for example) may be interpreted differently after the changes.
The purpose of this note is to tie down the semantics. Here's what I think they are, using the G5x code as a "gold standard".
1) Tool x, y offsets are relative to the machine coordinate system.
2) G10 xy rotations should be around the G5x translated axis. Ie, first you translate then you rotate.
3 G92, G52 offsets are relative to the current G5x coordinate system
Comments please. I'm deep enough into this now that I can probably come up with a set of proposed patches for people to play with. There are dragons out there though given that persistent parameters (g28 saved positions, for example) may be interpreted differently after the changes.
Please Log in or Create an account to join the conversation.
06 Oct 2021 22:53 #222410
by andypugh
Replied by andypugh on topic G10 rotations
You are unlikely to get many of those who understand the deep level stuff reading your posts on the forum. It is probably worth taking this to the developers mailing list.
Chris Radek added rotation back in 2009:
github.com/LinuxCNC/linuxcnc/commit/c72e...e312e9e340fe8abd6163
Chris has rather moved on, I haven't heard from him for quite some time.
Chris Radek added rotation back in 2009:
github.com/LinuxCNC/linuxcnc/commit/c72e...e312e9e340fe8abd6163
Chris has rather moved on, I haven't heard from him for quite some time.
Please Log in or Create an account to join the conversation.
06 Oct 2021 23:31 #222412
by rgb
Replied by rgb on topic G10 rotations
Thanks Andy. I'll give that a try.
Please Log in or Create an account to join the conversation.
07 Oct 2021 00:50 #222417
by cmorley
Replied by cmorley on topic G10 rotations
If you are in the code could you modify it to work with lathes (XZ only)?
Please Log in or Create an account to join the conversation.
07 Oct 2021 16:37 #222467
by rgb
Replied by rgb on topic G10 rotations
Can you say a bit more about applications for such a change?
Please Log in or Create an account to join the conversation.
08 Oct 2021 01:00 #222505
by cmorley
Replied by cmorley on topic G10 rotations
Sorry, I should have done that.
In a lathe, back tool machining is much easier if you mirror the coordinate system.
Rotating the system does this nicely.
It seems G10 requires XYZ to be present to work.
In 2.7 all axis were defined in the background by linuxcnc even in an XZ machine, so it just worked.
in 2.8 + (because of joint/axes work) you must define XYZ for a lathe to use rotation.
Most code assumes with a lathe only X and Z are used.
It also not intuitive to get Y axes errors on a XZ lathe (if you configure something wrong)
and finally it complicates GUI code between joints and axes conversion.
I'm hoping it not too bad to allow rotation around Z with only X.
It's not very often we get someone willing to dig deep into the code to do this kind of work.
Chris
In a lathe, back tool machining is much easier if you mirror the coordinate system.
Rotating the system does this nicely.
It seems G10 requires XYZ to be present to work.
In 2.7 all axis were defined in the background by linuxcnc even in an XZ machine, so it just worked.
in 2.8 + (because of joint/axes work) you must define XYZ for a lathe to use rotation.
Most code assumes with a lathe only X and Z are used.
It also not intuitive to get Y axes errors on a XZ lathe (if you configure something wrong)
and finally it complicates GUI code between joints and axes conversion.
I'm hoping it not too bad to allow rotation around Z with only X.
It's not very often we get someone willing to dig deep into the code to do this kind of work.
Chris
Please Log in or Create an account to join the conversation.
08 Oct 2021 01:49 #222510
by rgb
Replied by rgb on topic G10 rotations
Thanks for the note. I was afraid that you wanted to specify the XZ plane and do arbitrary rotations on it... Which got me thinking about 3d rotation matrices.This sounds much more straightforward. I'll keep it in mind while I poke around in there.
The following user(s) said Thank You: cmorley, tommylight
Please Log in or Create an account to join the conversation.
26 Oct 2021 00:19 #224311
by yam
Replied by yam on topic G10 rotations
@rgb
I came to the same conclusion, as I found G10 L2 P0 R45 is not correctly working.
(In comparison with my experience)
My setup:
A base program that calculates a point to point patern depending on the settings of Variables
In essence the zero is in middle of the patern and then shifting by a G52. to have all Zero's on the calculated points, so a subprogram can be executed on this calculated Zero (point).
The main program will on very point do an O-call to execute a subprogram.
So in short, by example; A patern of 3*3, distance between the points is X20 Y20 and execute O53 on every (zero)point.
See pic "No rotation"
Now I want to rotate the subprogram on every point.
So before the O-call of the subprogram I put
G10 L2 P0 R45 in the main program.
and after the O-call of the subprogram I write
G10 L2 P0 R-45
to put the coordinate system again to it's original position,
as a new G52 will follow, to navigate to the next point without the rotation.
What happens is that the whole base program is shifted by 45° instead of every subprogram around it's proper Zero point).
Pic R45
And more strange the -45 gives a logic that I can not explain. (different values R315 do not work neither).
Pic R45 & R-45 (look at the logic of the points (dashed lines)
I found in the manual in section: 13. G10 L2 Set Coordinate System
Quote" When programming a coordinate system with R, any G52 or G92 will be applied after the rotation."
In my opinion it does not make sence to work in this way.
This interpretation of rotation is neither found on a Heidenhein nor on a Haas? And it does not explain the strange effect of the -45°
As you remarked in your point 2, first a translation and then a rotation, even if the translation is effectuated by a G52.
If you are able to find a solution for this it would be awesome.
At this point I can only recalute the rotation of the values inside the subprogram to effectuate a rotation, and that is a hell of a job.
Unless of course I'm missing some knowledge here.
Regards,
Jan.
I came to the same conclusion, as I found G10 L2 P0 R45 is not correctly working.
(In comparison with my experience)
My setup:
A base program that calculates a point to point patern depending on the settings of Variables
In essence the zero is in middle of the patern and then shifting by a G52. to have all Zero's on the calculated points, so a subprogram can be executed on this calculated Zero (point).
The main program will on very point do an O-call to execute a subprogram.
So in short, by example; A patern of 3*3, distance between the points is X20 Y20 and execute O53 on every (zero)point.
See pic "No rotation"
Now I want to rotate the subprogram on every point.
So before the O-call of the subprogram I put
G10 L2 P0 R45 in the main program.
and after the O-call of the subprogram I write
G10 L2 P0 R-45
to put the coordinate system again to it's original position,
as a new G52 will follow, to navigate to the next point without the rotation.
What happens is that the whole base program is shifted by 45° instead of every subprogram around it's proper Zero point).
Pic R45
And more strange the -45 gives a logic that I can not explain. (different values R315 do not work neither).
Pic R45 & R-45 (look at the logic of the points (dashed lines)
I found in the manual in section: 13. G10 L2 Set Coordinate System
Quote" When programming a coordinate system with R, any G52 or G92 will be applied after the rotation."
In my opinion it does not make sence to work in this way.
This interpretation of rotation is neither found on a Heidenhein nor on a Haas? And it does not explain the strange effect of the -45°
As you remarked in your point 2, first a translation and then a rotation, even if the translation is effectuated by a G52.
If you are able to find a solution for this it would be awesome.
At this point I can only recalute the rotation of the values inside the subprogram to effectuate a rotation, and that is a hell of a job.
Unless of course I'm missing some knowledge here.
Regards,
Jan.
Please Log in or Create an account to join the conversation.
26 Oct 2021 05:18 #224327
by rgb
Replied by rgb on topic G10 rotations
Hi Jan,
I submitted a pull request to the project. See
github.com/LinuxCNC/linuxcnc/pull/1297
The changes are currently in review. I would love to have your input and/or testing. There are several tests included in the two patches.
Bob
I submitted a pull request to the project. See
github.com/LinuxCNC/linuxcnc/pull/1297
The changes are currently in review. I would love to have your input and/or testing. There are several tests included in the two patches.
Bob
Please Log in or Create an account to join the conversation.
Time to create page: 0.088 seconds