G92 (and post-processing) breaks in PrusaSlicer 2.4 alpha2

[sej7278]

This line in start_gcode seems to move the print outside of the printable area:

G92 X118 Y72.5 Z0 E0 B0; set (rough) reference point (also set E and B to make GPX happy). This will be overridden by the M132 below but ensures correct visualisation in some programs.

Alpha1 is fine, so it might be related to: https://github.com/prusa3d/PrusaSlicer/issues/6996 but are we ok to remove that line (noticed the reference to GPX)? Even 2.3.3 gcode displays as off to the bottom left in prusa-gcodeviewer 2.4

Also, the x3g file isn't being moved to the final target, its staying in /tmp/, which looks like https://github.com/prusa3d/PrusaSlicer/issues/6952

My workaround is to give make_fcp_x3g.pl a path to pass to gpx based on the new SLIC3R_PP_OUTPUT_NAME environment variable:

333,334c333,340
<   print "Executing: ${gpx_esc} ${arg_p} -m \"${MACHINE}\" ${in_esc}\n" if($verbose);
<   my $gpx_out = qx(${gpx_esc} ${arg_p} -m "${MACHINE}" ${in_esc} 2>&1);
---
>   my $out_esc;
>   if ($ENV{'SLIC3R_PP_OUTPUT_NAME'}) {
>       $out_esc = $ENV{'SLIC3R_PP_OUTPUT_NAME'};
>       $out_esc =~ s/\.gcode$/\.x3g/g;
>       $out_esc = shellEscape($out_esc);
>   }
>   print "Executing: ${gpx_esc} ${arg_p} -m \"${MACHINE}\" ${in_esc} ${out_esc}\n" if($verbose);
>   my $gpx_out = qx(${gpx_esc} ${arg_p} -m "${MACHINE}" ${in_esc} ${out_esc} 2>&1);

Which is akin to the hacks suggested in https://github.com/prusa3d/PrusaSlicer/issues/6042 which is a change that makes no sense to me (or others!)

2.4.0a2 output:

[2021-09-25 20:42:53.379256] [0x00007f3c94ff4640] [error]   GCodeProcessor encountered an invalid toolchange, maybe from a custom gcode.
Highest Z coordinate found: 150
Fixing incorrect M104 command for single-extrusion setup
Ensuring correct display in gcode.ws
Running retraction script...
Executing: "/usr/local/bin/retraction-improver.pl" -o "/tmp/LnDay2lQQu" "/tmp/.108708.gcode.pp"
Invoking GPX...
Executing: "/usr/bin/gpx" -p -m "fcp" "/tmp/.108708.gcode.pp" "/home/simon/PinHeaderSnappingJig.x3g"

2.3.3 output:

Highest Z coordinate found: 150
Fixing incorrect M104 command for single-extrusion setup
Ensuring correct display in gcode.ws
Running retraction script...
Executing: "/usr/local/bin/retraction-improver.pl" -o "/tmp/GypogpiayX" "/home/simon/233.gcode"
Invoking GPX...
Executing: "/usr/bin/gpx" -p -m "fcp" "/home/simon/233.gcode" 

[DrLex0]

This looks like a regression of prusa3d/PrusaSlicer#3082. I don't know why they insist on keeping on messing this up. They seem to assume that G92 is always used with zero arguments. I have filed prusa3d/PrusaSlicer#7016.

If the G92 command is omitted, GPX will output a warning with every file because it doesn't know where the extruder is at the start of the print, and visualisation in some programs will be messed up. I could give in to this weird interpretation of the G92 command, and shift everything such that the homing position becomes (0, 0). That would however be extremely annoying because all print coordinates would then be negative and it would be difficult to figure out where a particular coordinate is.

About the other issue: I'm not going to add even more hacks to the script to work around bugs in PS. If this affects so many people, it should be fixed by the time it enters beta stage.

[DrLex0]

@sej7278 It's strange, I got mail notifications of replies you have made, but I don't see them here.

The change they made to the post-processing seems to be intended for idi…, sorry, people saving their files directly to an SD card or other slow storage media. In those cases it makes sense to do all the post-processing in /tmp before copying the result to the final destination. Of course, if the post-processing also creates other files, these will then remain stuck in /tmp/.

This is fixable thanks to that environment variable they provide, but your fix isn't enough. I would also have to fix the handling of the _orig copy and the WARN file. Moreover, I don't think the WSL way of invoking the script has any chance of surviving. I can imagine this will break many other people's workflows as well.

The best solution if they really want to provide this new post-processing method, is to make it optional.

[sej7278]

Yeah I deleted some comments to not pollute the issue as I was debugging. Ideally we need them to revert it or make it optional.

And yes my fix is only partial, hence I didn't make a PR.

Seems like a lot of people facing hassle due to one guy saving straight to sdcard.