Issue with Restoring Rapids (and potential fix)

Hello. Thank you for your amazing work on this extension.

I recently found a weird issue with restoring rapid movements. I've attached the fusion file I'm using, as well as the GCODE that was generated from PostProcessAll:

GCODE_Output.txt Fusion_File.zip

The issue happens when Fusion combines a Z-movement line with an X or Y movement line, and the Z-height is the same as the retract height.

The block of code that causes the issue starts on line 1183 of the PostProcessAll main python file:

if Zcur != None and Zfeed != None and Zcur > Zfeed and Gcode != None and 
     Gcode != 0 and len(XYcur) != 0 and (Ztmp != None or Gcode != 1):
     # We're above the feed height, but made a cutting move.
     # Feed height is wrong, bring it up
     Zfeed = Zcur + 0.001

The issue with this is the part where len(XYcur) != 0. I have attached a Fusion file and the generated GCODE from PostProcessAll. This is the line that kicks off the problem, line 14522:

X8.4542 Y7.1818 I0.2018 J0.3394
G1 Y7.1819 Z0.9

For my file, the retract height is 0.9". For some reason, Fusion combined the retract and a Y-axis movement (it moved the Y-axis one ten-thousandth of an inch) on one line, so even though it's going up to the current retract height of 0.9", it's also making a miniscule Y-axis movement, which makes PostProcessAll think that it's doing a cutting move.

Unfortunately when this happens, it triggers the above code block, which takes the current Zfeed and sets it to Zcur + 0.001. This means that now PostProcessAll thinks my feed height going forward is 0.901". Since it's never going to be that high (my retract height is 0.900"), PostProcessAll gets confused and only rapids on the Z-axis movement. After the above line (14522), this is what every rapidized line looks like (this is from line 14576, but it continues all the way to the end of the file):

G00 Z0.9 (Changed from: "Z0.9")
G01 X10.6866 Y7.1906 F100.0 (Changed from: "X10.6866 Y7.1906")

This gets rid of nearly all the value from the rapidizer, because the short Z axis movement is rapid, but the long X and Y axis movement is set at the current feed rate. Even worse, the issue will never fix itself because PostProcessAll thinks any z-feed below 0.901 is not a rapid, and 0.900 is the highest the GCODE will ever go.

I altered the python code starting at line 1183 to this, and it seems to work in my case:

if Zcur != None and Zfeed != None and Zcur > Zfeed and Gcode != None and \
Gcode != 0 and len(XYcur) != 0 and (Ztmp != None or Gcode != 1):
    #We have a Z-movement that is higher than the current Zfeed, but it's on the same line as an X or Y movement
    #I think in this case we just don't want to do anything
    x = 0

if Zcur != None and Zfeed != None and Zcur > Zfeed and Gcode != None and \
Gcode != 0 and len(XYcur) == 0 and (Ztmp != None or Gcode != 1):
    # We're above the feed height, but made a cutting move.
    # Feed height is wrong, bring it up, but only if this is a Z-movement by itself
    Zfeed = Zcur + 0.001

I changed it so that if Zcur is > Zfeed but there is either an X or Y movement line on the same line, then just ignore this line and process it normally. It will only increase the Zfeed height if the Z command is on a line by itself.

I haven't tested this exhaustively but I think the logic makes sense (famous last words). I have some 3d adaptive cuts and scallops that make extensive use of various z-heights in cutting moves, and it hasn't messed any of them up yet. If there was ever a Z-movement above the retract height this would fall back into the broken state of before, but I don't think that should ever happen.

A more permanent fix would probably be to first run through the entire GCODE file and catalog all the various Z-heights and the frequencies they appear, and set the most common one as Z-feed max that you will never increase ZFeed over. I can't think of a situation where a generated program would hit another Z-height more often than the retract height. However I figured I'd get your input on that before I spent time trying to build it.

TimPaterson / Fusion360-Batch-Post

Issue with Restoring Rapids (and potential fix) #40