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

    No Stall detection

    Scheduled Pinned Locked Moved
    Tuning and tweaking
    3
    5
    420
    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.
    • Jorgeundefined
      Jorge
      last edited by

      Hi again,

      I have read, that the stall detection is not working so good on a coreXY as they have long belts and therefore soft current edges. But I wanted to give it a try though.

      In my config.g stands:
      M574 X1 Y1 S3

      And my homing script is:
      G91 ; relative positioning
      G1 S1 X-247 F2400 ; move quickly to X axis endstop and stop there (first pass)
      G1 X5 F6000 ; go back a few mm
      G1 S1 X-247 F360 ; move slowly to X axis endstop once more (second pass)
      G90 ; absolute positioning

      The problem is, that no stall is detected. I tried to modify the configuration but I can not configure it to trigger at all. I thought, that there must be a threshold value, at which it triggers instantly. But even if I go down to
      M915 P0 S-64
      , no stall is detected.

      One more thing: The homing speed is limited to something less than 600mm/s. But why? The specified 2400mm/min are never reached.

      deckingmanundefined 1 Reply Last reply Reply Quote 0
      • deckingmanundefined
        deckingman @Jorge
        last edited by

        @jorge I could never get stall detection to work on my third CoreXY gantry. I suspect it has more to do with having to stall 2 motors than it has to do with a belt lengths. Or it might just have been the quite powerful motors that I use. Switches are cheap and reliable whereas stall detection will never be reliable due to temperature effects.

        Ref homing speed, I'm a bit confused. You say the speed is limited to less that 600mm/s but the specified speed in 2400 mm/minute so you are mixing mm/minute and mm/second. 600mm/sec is 36,000 mm/minute and 2400mm/min is 40mm/sec, hence my confusion. That aside, the usual reason why the feed rate might be lower than expected is because the maximum speed value in M203 is set too low.

        Ian
        https://somei3deas.wordpress.com/
        https://www.youtube.com/@deckingman

        1 Reply Last reply Reply Quote 0
        • Jorgeundefined
          Jorge
          last edited by

          So Sorry, I always meant mm/min.
          So the homing is much slower than specified.
          M203 is set to 60.000 mm/min.

          Where you able to make the stall detection trigger at all? I know it will unlikely work, but I would like to test it though. But I think I must do something wrong, as it never triggers, regardless of the threshold.

          deckingmanundefined 1 Reply Last reply Reply Quote 0
          • deckingmanundefined
            deckingman @Jorge
            last edited by

            @jorge said in No Stall detection:

            Where you able to make the stall detection trigger at all? I know it will unlikely work, but I would like to test it though. But I think I must do something wrong, as it never triggers, regardless of the threshold.

            No I could never get stall detection to trigger. Someone suggested that I needed to use a higher speed but with my motors and the mass of my carriages, there is a real danger of serious damage if I were to slam the carriage into the frame at a fast speed.

            This was for a third gantry - I already had XY and UV so if I were to name this gantry it would be WA. Newer firmware allows me to map drives and end stop switches to axes so I can now home this WA gantry using conventional switches, which is cheap and reliable and negates the need for sensor less homing.

            For Mr Prusa, it allows him to save a few cents on the production cost of his printers, which might be significant when you produce printers by the thousand. But for the rest of us, IMO the cost saving is insignificant, especially when that cost saving is at the expense of reliability.

            TBH it makes no sense at all to me if you already have the switches because there is no cost saving, so all you are doing is making the printer less reliable and gaining nothing.

            Ian
            https://somei3deas.wordpress.com/
            https://www.youtube.com/@deckingman

            1 Reply Last reply Reply Quote 0
            • Phaedruxundefined
              Phaedrux Moderator
              last edited by

              For what it's worth the E3D tool changer uses stall detection and it's CoreXY and they claim it's reliable enough in their testing. So it can be done, though I personally don't think it's the best way to go.

              Can you post your full config file?

              Are you dropping the motor currents for homing?

              The speed needs to be fast enough to trigger the stall. If it's too slow it won't register.

              Z-Bot CoreXY Build | Thingiverse Profile

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