No Homing before printing ?

[Shine753]

When generating the GCode, I don't see any G28 homing command before the print starts...
How can this be ? Did I miss something ?

; generated by SuperSlicer 2.3.57 on 2021-10-24 at 01:27:46 UTC

; 

; external perimeters extrusion width = 0.43mm
; perimeters extrusion width = 0.48mm
; infill extrusion width = 0.46mm
; solid infill extrusion width = 0.48mm
; top infill extrusion width = 0.46mm
; first layer extrusion width = 0.62mm

; object:{"name":"Test","id":"Test.stl id:0 copy 0","object_center":[117.500000,117.500000,0.000000],"boundingbox_center":[117.500000,117.500000,12.000000],"boundingbox_size":[38.059071,23.200001,24.000000]}
; Total objects to print: 1
M486 T1
; plater:{"center":[117.500000,117.500000,0.000000],"boundingbox_center":[117.500000,117.500000,12.000000],"boundingbox_size":[38.059071,23.200001,24.000000]}

M140 S65 ; set bed temperature
;TYPE:Custom
M107
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
M109 S210 ; set temperature and wait for it to be reached
M190 S65 ; set bed temperature and wait for it to be reached
;LAYER_CHANGE
;Z:0.28
;HEIGHT:0.28
;=========================================== CHANGING LAYER
G1 Z0.28 F7800
G1 E-8 F2400
G1 X93.036 Y99.346 F7800
G1 E0 F2400
;TYPE:Skirt
;WIDTH:0.44
G1 F1800
G1 X94.324 Y98.3 E0.0638
G1 X95.716 Y97.4 E0.1276
G1 X96.956 Y96.759 E0.18128

[supermerill]

Some printers don't require homing, or only one time when powered up, not at every print.
If the one you have needs it before each print, add it to your custom start gcode.

[supermerill]

I have

                   "This start procedure is inserted at the beginning, after any printer start gcode (and "
                   "after any toolchange to this filament in case of multi-material printers). "
                   "This is used to override settings for a specific filament. If Slic3r detects "
                   "M104, M109, M140 or M190 in your custom codes, such commands will "
                   "not be prepended automatically so you're free to customize the order "
                   "of heating commands and other custom actions. Note that you can use placeholder variables "
                   "for all Slic3r settings, so you can put a \"M109 S[first_layer_temperature]\" command "
                   "wherever you want. If you have multiple extruders, the gcode is processed "
                   "in extruder order."

as tooltip for start_filament_gcode.
Where did you see "it's run after the bed has heated up and before the nozzle heats up" ?

[Shine753]

I've seen in in the tooltip of the start_gcode section.

I clearly don't want to use the GCode override for the temperatures, even more for such a purpose, because it's just confusing and a nonsense. You do not know when changing filament profile if the temperature that will be used is the one that is displayed into the filament section, or one previously put in some custom GCode, or elsewhere.

[supermerill]

I've seen in in the tooltip of the start_gcode section.

oh, yes, i see.
They start to heat from the get-go.
It's just that it's the best for bed levelling as you need the bed to be stabel and you don't care of the extruder temp.
If you want to control your heating, write the gcode and the slicer won't start heating before you.

You can copy-paste the start gcode from the prusa mk3 or ender-3, should be good for the majority of printers.

mmm
I may remove all auto-stuff for start-gcode from the slicer, as it's too much hassle for me with people wanting things and things. That way, everyone has to write what they want.

[Shine753]

I understand the purpose of only waiting for the bed to heat without waiting the nozzle heating. It does not suit my purpose, but it's ok. And please, don't remove the auto-stuff. It's precious.
For the little history, I discovered SuperSlicer looking at a Youtube video, and Wooow, it has all the base mechanisms I'm looking for since years, that nor Cura, nor S3D implements. And they don't want to go in that direction, even thinking of it for an unknown reason.

I know how it's difficult to deal with such a lot of parameters and try to satisfy everyone. But sometimes, some things have to be sacrificed to keep better things. I just note that both Cura and S3D can deal with what I'm asking for, without sacrificing the auto-stuff. So I don't doubt, even if I know there can be insurmountable obstacles, that SuperSlicer can also do the same.

I'm pretty sure the things I'm wanting can be integrated without changing a lot in SuperSlicer, but that need some Interface brainstorming to know where to go with the most clever way, to integrate them... or not.

If you want, I'm ok to help you to brainstorm to improve the interface of SuperSlicer if I can on part of my free time (I mean not only on my own askings, but globally). But I won't code for the moment, just because I don't have the time to. But why not in the future :)

[supermerill]

why not. I'm open to most contribution.

I have already a list of 500 things to do (and I'm a bit tired , sorry for that).
So I'm priorizing stuff heavily.
Adding another option that change things to avoid writing a line in the start gcode that should already be written by the wizard... not on the top of my list right now.

If the problem is moving from a slicer to Susi, I think the best way to do that is a kind of "translator" that take a cura / S3D profile and import it, adjusting stuff to try to reproduce the s3D/cura behaviour as good as possible.