Incorrect rapid move restoration

[amoruga]

I think I stepped on a bug with rapid move restoration - the tool path is not common (Contour used as side cut with a slitting saw), likely this is what's triggering it, never had such issue before. The stock is 0.5 in diameter, zero at center, so anything below Z0.5 is a part. The generated code begins like this:

%
(T41  D=1.988 CR=0. - ZMIN=-0.308 - slot mill)
G90 G54 G64 G50 G17 G40 G80 G94 G91.1 G49
G20 (Inch)
G30

N10 (Contour2)
T41 G43 H41 M6
S480 M3 M8
G54
G0 X-1.3102 Y-0.361
G00 Z1.225 (Changed from: "G1 Z1.225 F3.1")
G00 Z-0.308 (Changed from: "G1 Z-0.308")
G2 X-0.9438 Y-0.3879 I0.1776 J-0.0894 F3.1 (Feed rate added)
G3 X-0.8601 Y-0.5744 I0.9439 J0.3118
G00 X-0.671 Y-0.9019 (Changed from: "G1 X-0.671 Y-0.9019")

Note the last line - this is a cut move after lead-in, rapid rate would cause a tool break. There are many similar patterns later in the code (raising the tool, move to a new position, lower to a new height, lead-in, cut), but apparently only first one is set to rapid move during cutting. let me know if any additional info is needed to troubleshoot it

[TimPaterson]

If you could, generate a complete G-code file for a single operation without rapid restore, and one with it, and attach them both. The smallest case that reproduces the problem would help.

[amoruga]

Will do, need a day or two but will attach it here

[amoruga]

Attached two G-code files. line 25 in the "rapid_restore.nc" file is problematic. Note also line 33 - second pass of the same cut at different Z - it is correct. no_rapid_restore.nc.txt rapid_restore.nc.txt

[TimPaterson]

I've made a change that solved the problem in the test case you gave me.

[amoruga]

The issue is resolved, thank you!