Incorrect incremental distance mode moves with gexec()

[Erhannis]

My read of the code suggests that G91 is implemented, and should enable incrementalDistanceMode, but I'm getting weird results with gexec. Consider the following tpl:

gexec("G91");
gexec("G0 X10");
gexec("G0 Y10");
gexec("G0 X10");
gexec("G0 Y10");
gexec("G0 X10");
gexec("G0 Y10");

Based on what I've seen of the system so far, I'd expect this to output

G0 X10.
G0 Y10.
G0 X20.
G0 Y20.
G0 X30.
G0 Y30.

However, I instead get

N1 G0 X10.
G0 X0. Y10.
G0 X10. Y0.
G0 X0. Y10.
G0 X10. Y0.
G0 X0. Y10.

Which is sorta two weird things: 1. it parsed the input gcode commands in absolute mode, and 2. inferred a return to 0 for the axes not specified in a given command.

On the other hand, if I put the same input gcode into a file and load it with gcode("file.gcode"), the result IS what I'd expect:

N2 G0 X10.
N3 G0 Y10.
N4 G0 X20.
N5 G0 Y20.
N6 G0 X30.
N7 G0 Y30.

So it seems like the system CAN parse the gcode correctly - not sure why it has a problem with gexec. Does the system discard state between calls to gexec, or something?

[Erhannis]

Further testing: if I split the gcode into two files:

G91

and

G0 X10
G0 Y10
G0 X10
G0 Y10

and then run

gcode("s1.gcode");
gcode("s2.gcode");
gcode("s2.gcode");
gcode("s2.gcode");

I get

N1 G0 X10.
N2 G0 Y10.
N1 G0 Y0.
N2 G0 Y10.
N1 G0 Y0.
N2 G0 Y10.

which seems like it's discarding state between gcode calls, too? Is this expected? I'd have expected loading a gcode file to alter the current simulated state until otherwise overruled, same as inserting a chunk of gcode into the outgoing stream of gcode would have done.

[jcoffland]

Yes. That looks like a bug.