G10 rotations

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.

Thanks Andy. I'll give that a try.

If you are in the code could you modify it to work with lathes (XZ only)?

Can you say a bit more about applications for such a change?

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

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.

@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.
 



   

 

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