Repository navigation
interp: keep the current point when G10 L2 turns the system in effect under G92 - #4815
Open
grandixximo wants to merge 1 commit into
Open
grandixximo wants to merge 1 commit into
grandixximo wants to merge 1 commit into
Conversation
… under G92 The current point is in program coordinates, with G92 inside the XY rotation of the coordinate system: world = G5x + R * (point + G92). When G10 L2 changed R of the system in effect, the interpreter turned the point without its G92 and turned it back the same way, so with a G92 in effect it lost track of where the tool is until task resynchronised it from the machine. Within a program nothing does that: G54 at R0, the tool at X5 Y0, G92 X0 Y0, then G10 L2 P1 R90 leaves the tool at X-5 Y-5 of the turned system, but the interpreter had X0 Y0. A G91 G0 X0 Y0 on the next line, which should not move, moved the tool 7 mm to X0 Y5 of the machine, and a G91 G2 X0 Y2 I0 J1 ended at X-2 Y5 instead of X3 Y0. In MDI, task resynchronises the interpreter between commands, so it did not show there. The change now takes the current point through the whole chain to the machine frame before it and back after it, with program_to_world_xyz() and world_to_program_xyz(), as selecting a coordinate system and the tilted work plane already do. Fanuc, Heidenhain and Siemens also take the program position from the machine position after an offset change. A G10 L2 that changes only the origin, G10 L20 and selecting a system behaved correctly before and give the same result now; G10 L20's own fix-up of the point, which the round trip replaces, is gone. tests/interp/rotation/abs-pts changes R on G54 with a G92 in effect and reads the absolute position back: wrong on master, 1 2 3 here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current point is in program coordinates, with G92 inside the XY rotation of the coordinate system: world = G5x + R * (point + G92). When
G10 L2changed R of the system in effect, the interpreter turned the point without its G92, so with a G92 in effect it lost track of where the tool is until task resynchronised it from the machine.Within a program nothing resynchronises it. Example: G54 at R0, tool at X5 Y0,
G92 X0 Y0, thenG10 L2 P1 R90. The tool is at X-5 Y-5 of the turned system and the DRO says so, but the interpreter had X0 Y0:G91 G0 X0 Y0on the next line, which should not move, moved the tool 7 mm to X0 Y5 of the machine;G91 G2 X0 Y2 I0 J1ended at X-2 Y5 instead of X3 Y0.In MDI task resynchronises the interpreter between commands, so it did not show there.
The fix takes the current point through the whole chain to the machine frame before the change and back after it, with
program_to_world_xyz()andworld_to_program_xyz(), as selecting a coordinate system and the tilted work plane already do. Fanuc, Heidenhain and Siemens also take the program position from the machine position after an offset change.No behaviour changes elsewhere, so the docs stay as they are; they already say G92 applies after the rotation and a new offset on the active system takes effect immediately. A
G10 L2that changes only the origin,G10 L20and selecting a system were already right and give the same results; I checked each on a sim, from MDI and from a program, before and after.tests/interp/rotation/abs-pts now changes R on G54 with a G92 in effect and reads the absolute position back: wrong on master, 1 2 3 here.