Prusa Slic3r 2.3.3 - appending gcode to the end of my start.g ??? Why - How Where to fix  

full start.g

; infill extrusion width = 0.45mm
; solid infill extrusion width = 0.45mm
; top infill extrusion width = 0.40mm
; first layer extrusion width = 0.42mm

M107
G10 S215 ; set temperature
;TYPE:Custom
;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285
G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S75				; set bed H0 temp
M568 P0 R175 S215 A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation
G28												; home X / Y / Z  w/out mesh bed level
G29 S1 P"/sys/heightmap.csv"					; Load and use latest heightmap for Mesh Bed Compensation | heightmap.csv is Default/latest 
G92 E0.0										; reset extruder distance position
G1 X5 Y5 Z20 F5000								; go to Steve's Dribble Zone and wait
M190 S75				; wait for bed temp
M116 H0 S12										; RRF3 - Waits for H0/Bed to get within 12*C | S5 Param | of Set Temp Above
M568 P0 S215 A2			; Sets Tool0  /Nozz/  | S - to 1st layer Temp | A-Sets Tool0 to Active /0-1-2/ 
M116 P0 H1										; Waits for Tool0 / H1 Heater 1  Nozz  to get to get to Print temps in M568 above
G1 Z0.24 F3000									; drop to 0.25 print height
G1 X5 Y5 F3000									; move to purge strip start position
G1 E10.0 F140									; puddle from Tilley Test
G1 Y60.0 E9.0 F1000.0							; intro line 1 from Tilley Test
G1 Y100.0 E12.5 F1000.0							; intro line 2 from Tilley Test
G92 E0.0										; reset extruder distance position
G10 S215 ; set temperature
M116 ; wait for temperature to be reached
G21 ; set units to millimeters
G90 ; use absolute coordinates
M82 ; use absolute distances for extrusion
G92 E0
M572 D0 S0.05

Not super excited about the  pre pended M107 and G10 S215 ; set temperature either - but i guess i can live with it.  Above is my full start.g + tsome of hte PS 2.3.3 added stuff.

RE: full start.g

@sputnikoc3d,

also work with PS and a Duet2 board. The following gcode is automatically output by the slicer, but it doesn't bother me:

G21 ; set units to millimeters

G90 ; use absolute coordinates

M82 ; use absolute distances for extrusion

M82 and M83 can be adjusted in PS:

wbr,

Karl

oddities

I am using that setting ... those settings.  It appears to be Physical Printer and Printer Preset selection dependent.  It doesnt append those codes on my other printers when I slice with either their physical printer or a derivative preset option for that printer.

Its A Feature - Not A Bug ....

 So after endless hours of reading github issues - really annoying to have to get to that point really.   Discovered that PS / SuperSlicer both auto generate start.g gcode to protect us all from ourselves ...

If the application does not detect a M104 / M190 etc for bed and nozzle heater warm ups and waits - it does it for you.  Sadly Prusa slicer does it with improper G10 GCode for reprap firmware.

Im using the reprap preferred M568 for nozz heater vs. the rrfw deprecated G10 - as Im using toolboards and other sundry duet items.

Seems a hack is to inject a fake M104 and m190 at the top of your start.g custom code section and the software will not feel the need to append spurious garbage gcode to the end of your custom scripts.

;Start GCode DasVoron2.4 - as of 8-30-2021
;Print Area is X10 Y10 to X285 Y285

M104 S0   ; here
M190 S0   ;here
G21												; set units to millimeters
G90												; use absolute positioning
M83												; relative extrusion mode
M140 S[first_layer_bed_temperature]				; set bed H0 temp
T0												; set Tool 0 to proper tool to get this started
M568 P0 R175 S[first_layer_temperature_0] A1	; Sets Tool0 /Nozz/ 1st layer Temp / Standby Temps | Sets Tool0 to Standby
M561											; Disable ANY and ALL Mesh Bed Level Compensation

 So if one wants reprap and to run a macro theyve designed - one must first put fake codes in.  SuperSlicer github threads indicate there is a way to turn off auto generated gcode injection but I have not seen how that is accomplished.  If anyone knows would be great to share.

GitHub is the place for bug reports, feature requests, and enhancements

Posted by: @sputnikoc3d

 So after endless hours of reading github issues - really annoying to have to get to that point really.   Discovered that PS / SuperSlicer both auto generate start.g gcode to protect us all from ourselves ...

[...] So if one wants reprap and to run a macro theyve designed - one must first put fake codes in.  SuperSlicer github threads indicate there is a way to turn off auto generated gcode injection but I have not seen how that is accomplished.  If anyone knows would be great to share.

Prusa is kind enough to include support for non-Prusa printers in their free-of-charge PrusaSlicer, but they obviously won't know (or necessarily care) about every other flavor of printer out there. If feature requests, enhancements, or bugs are reported by the normal GitHub submission process, they have a good record of accommodating other printers. If you care to improve things for others attempting the same things, submit an issue via GitHub. Other slicers have a "do not insert temperature gcode" option and this sounds like something straightforward to implement. It's worth asking politely via the established means.

Hey Bobstro ...

1. I knew this was gunna come along ... I think we've been here before.  Kindly get off my tip.  You constantly riding my arse extolling the Uber benevolence of Prusa and their developers - isnt solving the issue.  

2. When I first posted here - I didnt realize it would devolve into a need for a feature request... 

3. I posted a resolution / final comment - in hopes of helping others not have to wade through hundreds of posts / git issues and waste hours of their time - like I did.

4. I've fully supported the Prusa related eco system and all the vendors they rely on to make their printers go ... BMG / Slice / E3d / LDO etc... and then some.  I buy their [ prusa ] products too.  Just because this issue isnt 100% germane to a stock off the shelf Mk3s+ doesnt mean I should bow at the alter and sugar coat whats going on.  They built the Reprap flavor in and took over the app / fork to make this slicer relevant again.  Not all the improvements being used by Prusa devs came 100% from them - its symbiotic between Super Slicer and others adding value - that they get to bake into this slicer as well.  That said - please dont give me your passive aggressive posts acting like Im bitching about a free "thing".  If they'd make a Paid For Product for non prusa machines - by all means go for it - Id pay for it.  I dont get that option currently, all I can do to support them is the above, and buy stuff from them that they sell that meets my needs.

5. Feel free in the future to just SCROLL on by my posts if you find them so hurtful.  Or add value not controversy ...

6.  Good Luck to you in your future endeavors.

RE: Its A Feature - Not A Bug ....

@sputnikoc3d,

Thank's for the information. I have made adjustments in PS accordingly, but it would be great if one could switch this feature in the PS settings. I have defined safety features regarding temperatures in config.g, so I would not need them in PS.

wbr,

Karl

Posted by: @sputnikoc3d

1. I knew this was gunna come along ... I think we've been here before.  Kindly get off my tip.  You constantly riding my arse extolling the Uber benevolence of Prusa and their developers - isnt solving the issue.  

Posting an issue at GitHub will solve the issue for everybody.