[LinuxCNC/linuxcnc Issue#563] G30.1 and coordinate system rotation About GRBL HAL

Issue #563 | 状态: 进行中 | 作者: grandixximo | 创建时间: 2019-02-22

标签: affects 2.7 affects master affects 2.8

Here are the steps I follow to reproduce the issue:

1. open sim axis configuration
2. Home and send this g-code

G53 G0 X5Y5
G10 L20 P2 X1 Y1
G30.1
(debug,X#5181 Y#5182)
G10 L2 P2 R180
G55
G30.1
(debug,X#5181 Y#5182)
G10 L2 P2 X0 Y0 R0
G30.1
(debug,X#5181 Y#5182)
M2

This is what I expected to happen:

X5.000 Y5.000
X5.000 Y5.000
X5.000 Y5.000

This is what happened instead:

X5.000 Y5.000
X3.000 Y3.000
X5.000 Y5.000

It worked properly before this:

I don’t know since when this problem has been there, probably a long long time

Information about my hardware and software:

* I am using this Linux distribution and version (often, shown by lsb_release -a):Ubuntu 18.04.2 LTS
* I am using this kernel version (shown by uname -a):4.15.0-45-generic
* I am running …
* [ ] A binary version from linuxcnc.org (including buildbot.linuxcnc.org)
* [x] A binary I built myself from latest master from github
* [ ] A binary version from some other source besides linuxcnc.org
* I am using this LinuxCNC version (shown in package manager or, for git versions, scripts/get-version-from-git):latest master from github LINUXCNC – 2.8.0~pre1
* I am using this user interface (GUI) (e.g., AXIS, Touchy, gmoccapy, etc): Axis
* I am using this interface hardware vendor and chipset (e.g., parallel port, ethernet port, FPGA card): i’m running simulation, no hardware

##################################

I was playing around with coordinate systems rotations, and i wanted to get the absolute position to make some if statements, and i experienced some weird behavior, upon further inspection, the G30.1 doesn’t always get the absolute position, seems like coordinate system rotations are effecting the values that G30.1 stores in the parameters.

#1 – grandixximo 于 2019-03-18

Is this an isolated problem? can anyone confirm?

#2 – robEllenberg 于 2019-04-17

I’ve seen similar behavior recently (have yet to confirm 100% though). I think the interpreter is applying offsets / rotation in the wrong order in some operations. It’s correct in canon (and therefore motion) because emccanon has its own state for current position and coordinate offsets.

#3 – grandixximo 于 2019-06-12

Can anyone else confirm 100% this?
According do documentation G30.1 should always give current absolute position, but if you run the code i posted, even tought the absolute position doesn’t move, G30.1 returns different values, this is wrong…

Here is a simpler g-code where G30.1 stores wrong values in #5181 and #5182

G53 G0 X5Y5
G10 L2 P2 X-2 Y-2 R120
G55
G30.1
(debug,X#5181 Y#5182)
M2

It should give out X5 Y5, instead i get X0.562178 Y-11.562178

#4 – robEllenberg 于 2019-06-12

Looked into it further, I see it too, and have an experimental fix (needs rebasing onto 2.7 / 2.8 though). @SebKuzminsky, should this be fixed in 2.7, or just in 2.8? My fix does a lot of under-the-hood overhaul in the interpreter.

#5 – SebKuzminsky 于 2019-06-12

Does this bug exist in 2.7? If so a targeted fix would be great, but if the fix involves overhauling the interpreter then doesn’t belong in 2.7.

原始Issue: https://github.com/LinuxCNC/linuxcnc/issues/563

Here are the steps I follow to reproduce the issue:

This is what I expected to happen:

This is what happened instead:

It worked properly before this:

Information about my hardware and software:

评论 (5)