Incorrect arc preview (in gmoccapy)

[finngineering]

The circular arc preview in (at least) gmoccapy is sometimes wrong. Possibly because it doesn't take the current machine position into consideration.

This is with LinuxCNC 2.9.8 from the ISO and stock gmoccapy 3.4.9.

I start the gmoccapy simulation with "gmoccapy" configuration, home the machine (which moves it to X10, Y10, Z-10), load and run this g-code:

F1000
G2 I20 J0 P1
M2

You can see the difference between the preview (white) and actual motion (magenta) in the screenshot below. The preview circle has incorrect coordinates in all three axes.

I made a forum post about this a while back as well:
https://forum.linuxcnc.org/20-g-code/58285-strange-preview-for-circular-arc-g2-g3

[andypugh]

That is arguably bad G-code.
A full-circle G2 without a positioning move prior to it will result in undefined motion.
(A part-circle, with an end point, will fail most of the time in this situation as the starting point, end point and centre will only sometimes define a valid arc)

[finngineering]

Is there a reason why a full-circle G2 without positioning move would result in undefined motion? On a high level, I don't see why that would be the case. The machine is in a known position and as far as I' aware, the starting position and the arc G-code I provided should fully define the circle. How about if I program G2 I20 J0 P1 in the MDI? Would that give undefined motion as well?

We could also turn it the other way around. If the motion is undefined in this situation, then why is a preview shown and why can I run the code (the latter generates the expected circle)?

I did also previously search the documentation for any clues as to what I might be doing wrong, but did not really find anything.

[hansu]

I think the problem here is that the preview does not take the current position into account. So the first (linear) move is never displayed. Which also makes sense - the preview needs to be reloaded as soon as you jog the machine - otherwise it would display a wrong toolpath.

[andypugh]

What I am saying is that it's a bad G-code program. Depending on where the tool is positioned when you run the code you get a different diameter circle. (It would be a fixed diameter if G91.1 is active, but in a random place, but the G-code isn't setting G90.1 / G91.1 either)

[finngineering]

Yeah, in that regard I fully agree that it's a bad g-code program. G91.1 is modal and was set and visible in the screenshot, but that is beside the point. Actually, the only reason I was making this program was so I could get a preview of the programmed arc. Being fairly new to G-codes, I didn't just want to send it. But at least for now, the preview is not suitable for such tasks.

Even if we consider the g-code at fault here, I think there would be room for improvement. Also if the first move is a G1, the preview is not correct. If the first move is a G0, then it is hidden and the rest appear to be okay. Can "we" not give the current machine position as the starting point for the preview? Reading a bit between the lines here, I get the feeling that such a change may not be so easy to make? I'm not saying it would have to be perfect. Even hiding the first move even in case it's not a G0 would be better than showing a preview that is not the motion the machine will take.

And in case fixing the preview is not the way to go, maybe there could be mentioned somewhere in the documentation. Maybe there already is, and I just didn't find it?

[andypugh]

I can see an argument for feeding the preview a "dummy" G0 to the current axis position.
I suspect this might only be a problem with G2 and G3, and other motion codes require at least one axis letter.
Does the same problem exist with a half-circle?

[finngineering]

I tried a half circle and a quarter circle, and gmoccapy doesn't any either of them without a linear move first. Here the quarter circle from starting position X10 Y10 Z-10:

Here is a screenshot of only a linear G1 move. I jogged to another position to make it clear that also this preview is not in line with the actual motion that would result from running the program:

[Sigma1912]

This is likely something missing in 'gremlin.py'.
Note that this works correctly in Axis GUI which does not use 'gremlin.py'

[Sigma1912]

Also I notice that sometimes there is no preview at all: