32bit with sensorless homing origin issue "occasional extruder crash"
photodude opened this issue · 3 comments
Note: this is a 32bit sensorless homing specific issue
Follows comments in #1 by @InitialJC
I am not exactly sure what is going on with this starting Gcode or why it needs to be as complicated as it is however I have gotten much better results by priming the extruder with the following Gcode.
The current release GCode seems to crash my extruder to the left hand side without properly identifying the home/ origin point. The below Gcode will set appropriate absolute position for every print.
G21 ;metric values G90 ;absolute positioning M107 ;start with the fan off G28 X0 Y0 ;move X/Y to min endstops G28 Z0 ;move Z to min endstops G1 Z2.0 F400 ;move the platform down 15mm T0 G92 E0 ; reset extruder M117 Purge Extruder 1 G1 X-50.0 Y-92.3 Z0.0 F2400.0 G1 X50.0 Y-92.3 Z0.0 F1000.0 E10 ; draw 1st line G1 X50.0 Y-92 Z0.0 F3000.0 ; move to side a little G1 X-50.0 Y-92 Z0.0 F1000.0 E20 ; draw 2nd line G1 E19.5 F3000 ; retract filament 0.5mm G92 E0 M117 BIBO Printing...
Response in #1
The start gcode is mostly adopted from the BIBO provided Cura start gcode and was originally modified that way based on issues reported in the Facebook BIBO group. One of the big issues with the code you listed above is the lack of temperature preheating of the nozzles and bed which caused failures to print for some people.
There are some things that can be done to simplify the start gcode, but that's probably something to put in a different issue for consideration as there are a lot of things to consider such as how it's implemented for dual extrusion, E1 only, E2 only, Ditto printing printers, etc.
As for your specific left-hand crash issue ... I have noticed that when I'm consecutively printing if I don't move the print head slightly away from the homing switches, before printing occasionally the printer will start off-center. It doesn't have to be much just enough to keep the switches from being clicked before starting. the off-centered start seems to happen occasionally with cura as well.
This Issue is most for discussing direction to consider simplifications of the start gcode and potentially address the issue with the extruder head occasionally crashing.
Note: this is a 32bit sensorless homing specific issue
Response from @InitialJC in #1 Identifying the issue is specific to their 32-bit board with sensorless homing.
Yes but I'm using the 32 bit w/ UBL and sensor less homing.. the way your starting gcode is currently setup its taking origin resetting it as the starting point and crashing left. Its an order of operations issue. Also for different extruder configurations you can very easily add an addition line from the alternate extruder which is what I do for soluble filaments when printing intricate items. I haven't ever seen an issue with repetitive printing however with your current starting Gcode its fails and crashes left on every print.. not just a second print.
It's been confirmed that there is an issue with sensorless homing and marlin 2.0.x. Closing as it's not an issue with the Prusaslicer configuration and start code, but an issue with marlin 2.0.x
https://github.com/MarlinFirmware/Marlin/issues?q=is%3Aissue+is%3Aopen+sensorless+homing
An adjustment to start gcode forcing T0 before homing and removing second homeing was completed. unknown if this would have any impact