[2.2.0-alpha] Custom printer with center of bed at 0,0 results in "toolpath outside print area"

[paukstelis]

Version

2.2.0-alpha

Operating system type + version

Ubuntu 18.04

3D printer brand / version + firmware version (if known)

Flashforge Creator Pro

Behavior

Using profiles that worked for 2.1.0. After slicing the model is moved off the bed and "toolpath outisde the print area was detected" message is given. It appears that gcode is OK after exporting (haven't confirmed with a print yet, but the coordinates look reasonable).

[BirkBinnard]

Strange - I have a delta printer (FLSun QQ-S) with 260 mm dia. bed and center at 0,0 and have no problem at all. But I'm running Windows 10. Could that be the difference?

[paukstelis]

Hmm, if that's the case perhaps it is due to the fact that the FFCP has Sailfish firmware, so gcodes are slightly different.

[paukstelis]

Here are screenshots showing the issue. This likely has something to do with Sailfish gcode. The left and right extruder definitions give the same gcode, but the sliced model display moves them to different positions.

[BirkBinnard]

Not sure what to suggest - this is what I see immediately after loading a part:

The image looks the same after slicing.

[bubnikv]

@paukstelis

Please provide 3MF.

[paukstelis]

Attached. flashforgeissue.zip

[bubnikv]

The initial tool path preview is correct, but the final G-code preview is not only offsetted in XY plane, but it seems to float above the print bed as well.

@enricoturri1966 would you please look into it? Thanks.

[enricoturri1966]

@paukstelis The problem seems to be due to the start g-code you are using. If I comment out the highlighted lines:

; Replicator 1 dual start.gcode M73 P0 ; enable build progress G162 X Y F3000 ; home XY maximum G161 Z F1200 ; home Z minimum ;;G92 Z-5 ; set Z to -5 <<<<<<<<<<<<<<<<< G1 Z0 ; move Z to 0 G161 Z F100 ; home Z slowly M132 X Y Z A B ; recall home offsets M135 T0 ; load right extruder offsets ;;G1 X150 Y-70 Z30 F9000 ; move to wait position right hand side of the table <<<<<<<<<<<<<<<<< G130 X20 Y20 Z20 A20 B20 ; lower stepper Vrefs while heating M126 S0 M140 S[first_layer_bed_temperature] M190 S[first_layer_bed_temperature] M134 T0 ; stabilize bed temperature M104 S[first_layer_temperature] T0 M133 T0 ; stabilize left extruder temperature G130 X127 Y127 Z40 A127 B127 ; default stepper Vrefs G92 A0 B0 ; zero extruders ;;G1 Z0.4 ; position nozzle <<<<<<<<<<<<<<<<< M135 T0 ; right tool ;;G1 X-140 Y-70 F9000 ; reposition nozzle <<<<<<<<<<<<<<<<< ;;G1 X-100 Y-70 E25 F300 ; purge nozzle <<<<<<<<<<<<<<<<< ;;G1 X-110 Y-70 Z0.15 F1200 ; slow wipe <<<<<<<<<<<<<<<<< ;;G1 X-100 Y-70 Z0.5 F1200 ; lift <<<<<<<<<<<<<<<<< G92 A0 B0 ; zero extruders M73 P1 ;@body (notify GPX body has started)

the generated g-code gets properly placed in the preview (see picture). Do you really need those lines ?

[paukstelis]

Yeah, you do need those lines, since they are setting the positions of the Z axis and doing priming. This worked fine on 2.1.0, so this was something introduced in 2.2.

[bubnikv]

This worked fine on 2.1.0, so this was something introduced in 2.2.

Maybe it was fixed actually?

There is no way PrusaSlicer could understand how your machine coordinate system differs from what you told it in the print bed definition. If you adjust the coordinate system of your printer using G92 codes in the custom start G-code, PrusaSlicer correctly interprets these codes and shifts the print preview accordingly. I suppose there may have been a bug in earlier versions of PrusaSlicer, where these adjustments were not taken into account by the G-code preview.

[paukstelis]

The only G92 that should impact positioning is the G92 Z-5. There are no other G92's that reset XY positions.

[bubnikv]

There is a bug in void GCodeAnalyzer::_processG92(const GCodeReader::GCodeLine& line) which processes G92 A0 B0 ; zero extruders as G92 thus it resets all axes.

I will try to fix this issue for the final release.

However, your G-code will still be floating above the print bed if you keep the G92 Z there. I advise you to set the Z offset in Printer profile using the z_offset parameter instead.

[bubnikv]

Fixed with 046f0dbfa26eb6e566626f15f2c934e63190dfea The fix will be part of PrusaSlicer 2.2.0 final. Closing.