Sensorless Homing crashing at ending script of first print



  • Hello all! I hope everyone is well right now during this odd time.

    I am having an issue with sensorless homing. I have an Ender 3 powered by a Duet 2 Wifi running RRF 2.05.1. The same for my CR-10, although it is on RRF 3.1.1. DWC on both is 3.1.1.

    The issue with my sensorless homing is this: After completeing a first print, the print bed and print carriage both "crash" into the their respective axis minimums, e.g., the end of the aluminum v-slot extrusions. It seems to move with a reduce current on both axes, courtesy of M913, but it still crashes and does not detect the stall. Puzzling to me.

    What's even more puzzling, and obviously related to this first issue, is that when I press "print again," or select a different print, the print bed and print carriage, again crash into their axis minimums without detecting the stall.

    When I press "emergency stop," or toggle the power switch to the "off" position for a moment, everything goes back to normal. When I say normal, I mean the Duet and printer boot up properly. I can press homeall and select a print which will home properly on its starting script, only to stall and fail at the ending script.

    Attached below are all my config.g files for both my Ender 3 and CR-10.

    Ender 3:
    https://1drv.ms/u/s!AmZ7ep7HflN2hIN3w3CE11RJEqat9A?e=cSJRZO

    CR-10:
    https://1drv.ms/u/s!AmZ7ep7HflN2hIN4nKY1rqQzZCkvdw?e=8bcOxx

    Regarding slicers, I am trying to implement stall detection, and that is why I think I am having this issue. Please correct if I am wrong. And before you guys link me to the stall guard/sensorless homing dozuki, please note that I just finished rewriting the procedure, so it is exactly where I am. (The reason I rewrote the procedure is because it was entirely unclear, unhelpful, and incomplete; it did not do this feature justice).

    In my starting gcode script in both cura and simplify3d, I have implemented the following at the end of the start script: M915 X Y S6 R1 F1. This is to trigger the stall detection reporting (as I am still calibrating). At the beginning of my slicers ending script I have implemented M915 X Y S1 R0 F0 to switch it back to sensorless homing, unfiltered.

    I am really at the end of my rope with this issue. I just don't know what else to tweak. It is obviously me, as I am having the SAME issue of RRF 2.05.1 and RRF 3.1.1.

    Please advise my lack of knowledge on this! I will certainly implement these changes into the dozuki for others to follow 😄

    Thanks!

    Jordan Stephenson


  • administrators

    Most likely the slicer has sent a command that changes one of the parameter affecting sensorless homing. So I suggest you look in the GCode file for M201, M203, M906, M913 and M915 commands.

    One possibility is that the slicer is generating a M203 command to reduce the maximum speed. Slicers should not do this and it is not necessary, but unfortunately some of them do.



  • @dc42 I will make sure that those commands are absent from the slicer and then I will report back.

    Thanks!



  • @dc42 I just checked my slicers, both S3D and Cura, and neither have those commands you listed in the start or end script of the gcode. Could this be an issue with G90 or G91?


  • Moderator

    Can you post your slicer start and end gcode section please?



  • @Phaedrux absolutely.

    Cura Start Gcode:
    ; Ender 3 Custom Start G-code
    G92 E0 ; Reset Extruder
    G28; Home all axes
    G29 S1
    G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
    G1 X0.1 Y20 Z0.3 F5000.0 ; Move to start position
    G1 X0.1 Y200.0 Z0.3 F1500.0 E15 ; Draw the first line
    G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little
    G1 X0.4 Y20 Z0.3 F1500.0 E30 ; Draw the second line
    G92 E0 ; Reset Extruder
    G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed
    G1 X5 Y20 Z0.3 F5000.0 ; Move over to prevent blob squish
    M915 X Y S6 R1 F1; Turn on stall detection and set sensitivity and response

    Cura End Gcode
    M915 X Y S1 R0 F0
    G91 ;Relative positioning
    G1 E-2 Z0.2 F2400 ;Retract and raise Z
    G1 X5 Y5 F3000 ;Wipe out
    G1 Z10 ;Raise Z more
    G90 ;Absolute positionning

    G1 X0 Y{machine_depth} ;Present print
    M106 S0 ;Turn-off fan
    M104 S0 ;Turn-off hotend
    M140 S0 ;Turn-off bed

    M84 X Y E ;Disable all steppers but Z

    S3D Start Code:
    G28
    G29 S1; abl
    G1 X5 Y10 Z0.2 F3000 ; get ready to prime
    G92 E0 ; reset extrusion distance
    G1 X150 E30 F1000 ; prime nozzle
    G1 X180 F5000 ; quick wipe
    M915 X Y S7 R1 F1

    S3D Endcode:
    M915 X Y S3 R0 F0
    G91 G1 Z5 F800 H2 ; Lift z so we don't crash
    G28 X
    M106 S0 ; turn off cooling fan
    M104 S0 ; turn off extruder
    M140 S0 ; turn off bed


  • Moderator

    config.g: M915 X Y S3 R0 F0

    cura start: M915 X Y S6 R1 F1

    cura end: M915 X Y S1 R0 F0

    s3d start: M915 X Y S7 R1 F1

    S3d end: M915 X Y S3 R0 F0

    Only the S3D end code matches the config line.

    Also note that because you change the M915 in the start gcode, and only change it back in the end gcode, if you cancel a print it won't be changed back unless you also have it in the cancel.g. For this reason you might want to have the sensorless homing version of your M915 in your homing files as well.

    If you send M915 by itself in the console it will respond with the currently set value. You can use that to check its state before, during, and after printing to see how it's actually configured.

    Another thing to keep in mind is that sensitivity also changes with temperature. So at the end of a print it may not behave the same as it does at the start of the print.



  • @Phaedrux Thanks so much! I would probably not have thought of changing the cancel.g file. I added M915 X Y S3 R0 F0. I also changed the stop.g file to include the same.

    I will certainly fix the ending gcode to reflect the the config.g M915. Also, the reason I have the cura and s3d start to include the different M915 is because for the print, I want it to engage stall detection. Is there an easier way to do this through DWC and not the slicer?

    Also, I understand regarding the heat. I have a 120mm noctua blowing on my board, and I have a 40x20 noctua attached to the motors themselves, for extra cooling.


  • Moderator

    @djstephenson1 said in Sensorless Homing crashing at ending script of first print:

    Is there an easier way to do this through DWC and not the slicer?

    The slicer is an ok place to put it, but since the only place where it changes is in the homing files, perhaps it makes most sense to change it in the homing files exclusively. At the start of the file configure it for homing and at the end configure it for normal detection.

    @djstephenson1 said in Sensorless Homing crashing at ending script of first print:

    Also, I understand regarding the heat. I have a 120mm noctua blowing on my board, and I have a 40x20 noctua attached to the motors themselves, for extra cooling.

    I'm referring to the temperature of the motors themselves as that is where the back emf for stall detection is generated.



  • @Phaedrux I actually just thought a way to do this without having to employ a slicer. I realized that by changing all the files that are called up in DWC buttons, that I can make sensorless homing and stall detection work.


  • Moderator

    Yes placing the relevant commands in separate macros is a good way to do it because it means only changing it in a single place, it can be executed manually, or it can be called in other places as a macro with M98.



  • @Phaedrux okay I am starting to get it now. How successful could a macro be? Would it be easier for calibration, actual stall detection, or both?


  • Moderator

    Well it would be easier to tune, since you only have one place to change, and it's more flexible because you can just click on the macro to change the config. So it has benefits, but it won't change the actual performance of the stall detection.



  • @Phaedrux can you expand on what you mean by "won't change the actual performance of the stall detection?"



  • @Phaedrux do you have a basic structure I could use to build off of?

    It would really help an enormous amount. And I will be sure to include it in the dozuki so others can tune theirs too!



  • Perhaps something like this? 🤔

    stalld-printing.g

    ; sets stall detection values to be used when printing
    M915 X Y S7 R1 F1 ; Stall-d threshold 7, Action to 1 - log it, Filter mode 1 -filtered, one reading per 4 full steps
    

    stalld-homing.g:

    ; sets stall detection values to be used when homing
    M915 X Y S3 R0 F0 ; Stall-d threshold 3, Action to 0 - no action, Filter mode 0 - unfiltered, one reading per full step
    

    Place M98 P"stalld-homing.g" at the start of each homing file, and M98 P"stalld-printing.g" at the end of each homing file. This way you can take the commands out of your slicer and also just make changes to the stalld files for adjusting.


  • Moderator

    Yes that's exactly it. I use the same method for changing motor currents, etc



  • @Kolbi you guys are rock stars. Thank you so much. I will make sure that this info is out there for everyone else.



  • @djstephenson1 No worries. I keep meaning to do the same type of thing to my homing routines too; having homeall call the individual axes, but I've been in a combination of busy and lazy 😂



  • @djstephenson1 I just did this to my files since it was fresh on the brain but I decided to leave the homeall.g as a standalone (not calling each homing file from within it).
    You can see it here if you want: https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s



  • @Kolbi Awesome! I will certainly check it out



  • @Kolbi Your github is great!



  • @djstephenson1 Thanks! Glad you like it / found it useful. 👍


Log in to reply