Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    Problems setting up stall detection

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    3
    8
    569
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • TomFundefined
      TomF
      last edited by

      I am trying to set up stall detection without sensorless homing (I have microswitches) but the printer seems to be ignoring me, as there is no expected response. The documentation says "Once your print is going and stall detection is flashing in the console.." but I don't get any such indication. I don't get any messages in the console either. It's like I've missed a basic step, but where? This coding is really at the limit of my experience so I may have missed the obvious.

      I have:

      • set up as stated in the documentation, as far as I can tell.
      • Created a rehome.g file and saved to system files
      • made changes to my SuperSlicer START and END custom codes
      • Tweaked M906, M201, M566 in config.g
      • Tested several prints with different slicing parameters but none has made any difference

      Board: Duet 3 Mini 5+ (Mini5plus)
      Firmware: RepRapFirmware for Duet 3 Mini 5+ 3.4.0 (2022-03-15)
      Duet WiFi Server Version: 1.26

      X and Y Motors: Nema 17 48mm, 1.8 degree/step

      Slicer START.txt
      Slicer END.txt
      rehome.txt
      config.txt

      1 Reply Last reply Reply Quote 0
      • TomFundefined TomF referenced this topic
      • Phaedruxundefined
        Phaedrux Moderator
        last edited by Phaedrux

        Where are you enabling stall detection? It's commented out in your config.g

        ;M915 X Y S3 R1 F1 ; stall detection

        Only in your slicer start gcode?

        I think you've misunderstood the point of the rehome,g file. Yours just has the M915 command in it again. This file should also contain some commands to actually rehome the axis. Like G28 XY.

        When you force a stall during a print what actually happens?

        Z-Bot CoreXY Build | Thingiverse Profile

        TomFundefined 2 Replies Last reply Reply Quote 0
        • TomFundefined
          TomF @Phaedrux
          last edited by

          @phaedrux

          Thanks for the feedback.

          I had M915 enabled in config.g but it didn't make any difference. The documentation doesn't say to change anything in config other than modify the speed, acceleration, etc., so I then commented the M915 command out. Now I know, I'll enable it again.

          I understand there's more to rehome but haven't done so yet as there is no response to the basics like 'stall detection enabled'. I'll add the home XY instruction anyway and try again.

          1 Reply Last reply Reply Quote 0
          • TomFundefined
            TomF @Phaedrux
            last edited by

            @phaedrux

            I made those changes to config and rehome and still no response. When I force a stall of the X or Y axis, it just stalls and carries on from it's new location. There is no message in console, there's no 'stall detection' flashing in the console. Basically no indication that anything is different from before.

            Updated files:

            rehome.txt
            config.txt

            OwenDundefined 1 Reply Last reply Reply Quote 0
            • OwenDundefined
              OwenD @TomF
              last edited by OwenD

              @tomf

              See the notes in M915 documentation
              In RRF v3.4 and later there is no longer a distinction between R2 and R3; both cause an event to be created when the driver stalls. To handle the event, RRF calls driver-stall.g passing the stalled local driver number in param.D and the CAN address of the board concerned in param.B. File rehome.g is no longer used. If file driver-stall.g is not found then the print is paused without running pause.g and the error is reported.

              On my system I have in config.g

              M915 H240 X Y S3 R2 	; set stall detection for X & Y axis. driver-stall.g will be run.
              if !exists(global.InMacro) ; macro used to check if we're already in a macro to avoid running triggers multiple times
              	global InMacro = false
              else
              	set global.InMacro = false
              

              And in driver-stall.g I have the code below.

              ;0:/sys/driver-stall.g
              ; check if a driver stall is already being acted on.
              if  global.InMacro = true
              	echo "Driver stall macro already running - no further action taken"
              	M99 ; exit macro
              set global.InMacro=true
              if job.file.fileName!= null ; check if we are printing
              	echo " A driver stall has occured on driver " ^ param.D
              	echo "Layer shifting may have occured at X:",move.axes[0].machinePosition, "Y:", move.axes[1].machinePosition, "Z:", move.axes[2].machinePosition
              	G4 P5
              	; if a tool is selected and the heater is up to temp we'll retract
              	if heat.heaters[tools[max(state.currentTool,0)].heaters[0]].current > heat.coldRetractTemperature
              		G10
              	G1 F1800 ; reduce speed before homing
              	G28 X Y
              	; if a tool is selected and the heater is up to temp, we'll un-retract if required.
              	if (heat.heaters[tools[max(state.currentTool,0)].heaters[0]].current > heat.coldExtrudeTemperature) && (tools[max(state.currentTool,0)].isRetracted)
              		G11
              	G4 S1
              set global.InMacro = false
              

              You may have to tune the settings to get reliable results.

              TomFundefined 2 Replies Last reply Reply Quote 0
              • TomFundefined
                TomF @OwenD
                last edited by

                @owend

                Thanks! I had missed the part about rehome.g being 'discontinued' and driver-stall.g being used instead when R2 (or R3) is called.

                That said, I haven't called either R2 or R3 yet. I'm still on R1 "just log it" and the root of my problem is that there is no console report when I force a stall, or at any other time. There is no message flashing in the console - I am simply getting no response whatsoever to my attempts to implement stall detection.

                As I understand it, with R1, the driver-stall.g is not needed.

                But once I get past this current hurdle, then I certainly will need to go to R2 and the fun really starts. I'm struggling to understand what you have done in the driver-stall.g file because I'm not very experienced in gcode and macros are above my level. Your comments in the file are very helpful and I see what you are doing but not sure about the details. Are the macros necessary in config.g? And in driver-stall.g? Is it possible to just have the M915 H240 X Y S3 R2 line in config, and G28 XY in driver-stall.g?

                OwenDundefined 1 Reply Last reply Reply Quote 0
                • OwenDundefined
                  OwenD @TomF
                  last edited by

                  @tomf
                  Yes, you could just have those two commands

                  1 Reply Last reply Reply Quote 0
                  • TomFundefined
                    TomF @OwenD
                    last edited by

                    @owend
                    Do you get a stall detection message flashing in the console?
                    When a stall occurs or if you force a stall, do you get a message in the console?

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post
                    Unless otherwise noted, all forum content is licensed under CC-BY-SA