Skip to content

rs274ngc: back the rotary tool offset out of machine coordinates - #4416

Open
grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:g53-rotary-tool-offset
Open

rs274ngc: back the rotary tool offset out of machine coordinates#4416
grandixximo wants to merge 1 commit into
LinuxCNC:masterfrom
grandixximo:g53-rotary-tool-offset

Conversation

@grandixximo

Copy link
Copy Markdown
Contributor

Summary

G53 and the G28/G30 return are meant to reach a machine coordinate. Canon adds the G5x offset, the G92 offset and the tool offset to everything the interpreter hands it, so the interpreter has to subtract all three first. It does that for X, Y, Z, U, V, W and for A, B and C when the axis is wrapped. On an unwrapped rotary it subtracts the first two and not the tool offset, and canon still adds it.

So with a tool that carries a rotary offset, G53 G0 A0 parks the axis on the offset instead of on machine zero, and G28 returns to the stored position plus the offset. It is quiet because nothing disagrees: get_abs_position() adds tool_offset.a too, so #5024 reports the same wrong number that was commanded, and the error tracks the loaded tool.

59e57c0 added the tool offset term to every other coordinate when the offset became a nine axis pose, including the wrapped rotary case in the same hunks. The unwrapped one was missed, so this has been the behavior since 2009.

Change

Six lines. The else branch of the A, B and C cases in find_ends() (G53) and in find_relative() (G28, G30, tool change return) gains - tool_offset.<letter>, matching the wrapped branch directly above it.

#3969 adds a branch just above these same six else lines without touching them, so the two should not conflict beyond adjacency.

Behavior change

This does change what an existing machine does. It is a change in the correct direction, and it only bites if the tool table or G43.1 sets a nonzero A, B or C offset. Such a machine has been landing G53 and G28 off by exactly that offset all along, so anyone who noticed will have compensated somewhere else and will need to remove that compensation. Configs with no rotary tool offset, which is nearly all of them, are unchanged.

Test

New tests/interp/rotary-tool-offset, failing on master and passing here. With G43.1 Z5 A7 B11 C13 in force:

#5024-#5026 on master here
G53 G0 X1 Y2 Z3 A20 B30 C40 27, 41, 53 20, 30, 40
G28 to a stored 20, 30, 40 27, 41, 53 20, 30, 40

Nothing else in the tree is affected: no .tbl under tests/ has an A, B or C column, G43.1 appears in one test with no rotary words, and G10 L1 with rotary words appears nowhere in tests/ or configs/.

Canon adds the tool offset to every coordinate it is handed, so an
interpreter target meant to land on a machine coordinate has to have
that offset taken out first.  G53 and the G28 and G30 return subtract
the G5x offset, the G92 offset and the tool offset from the number the
operator wrote.  Every coordinate is covered except A, B and C when the
axis is not wrapped, which subtract the first two and not the third.

Canon still adds the third, so G53 G0 A0 parks on the offset instead of
on machine zero and G28 returns to the stored position plus the offset.
Nothing disagrees along the way, which is why it is quiet:
get_abs_position() adds tool_offset.a as well, so the interpreter
reports the same wrong number it commanded.

59e57c0 gave every other coordinate its tool offset term when the
offset became a nine axis pose, the wrapped rotary case directly above
included.  The unwrapped one was missed.

With G43.1 Z5 A7 B11 C13 in force, G53 G0 A20 B30 C40 reported #5024 to
#5026 as 27, 41 and 53.  It reports 20, 30 and 40.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant