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.

@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