Navigation

    Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Stall Protection on pyserial() print

    Tuning and tweaking
    2
    7
    687
    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.
    • john
      john last edited by

      Reviewing the forums for Stall Protection information, it seems like Stall Protection is not recommended for Cartesian printers, or for prints which are -not- from a GCode file:

      https://forum.duet3d.com/topic/3986/how-to-tune-stall-detection/2
      https://forum.duet3d.com/topic/2066/stall-detection/2

      Can you confirm this is the case?

      We run a Cartesian pick & place system for electronics boards with mechanical endstops for homing, and a reed switch to identify when the pick system has retracted properly. Our pick system descends into the build area to pick/place as needed.

      As a safety feature we wanted to enable stall protection so if the pick system is extended into the work area and the motors decide to start moving, the system senses the increased load (b/c contact w/ something) and stop movement.

      Is it possible to enable Stall Protection in this case?

      1 Reply Last reply Reply Quote 0
      • dc42
        dc42 administrators last edited by

        Stall protection should be OK for Cartesian printers. It's delta printers that I don't recommend it for.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • john
          john last edited by

          And a cartesian printer sending commands from pyserial() over USB? To quote one of your other comments: "Stall detection is only enabled when printing a GCode file"

          1 Reply Last reply Reply Quote 0
          • dc42
            dc42 administrators last edited by

            When a stall is detected when printing from SD card, the firmware knows exactly where it has got to. When printing over USB, the firmware doesn't know anything about the program sending the commands, or how many commands the PC has buffered up in the USB subsystem. So there is very little that the firmware could do, other than stop printing and tell pyserial that there is a problem. pyserial wouldn't know where to start sending commands from, and the USB subsystem on the PC would still empty its buffers by sending commands to the Duet.

            We could make the firmware send a warning when a stall occurs even when not printing from SD card, but without a great deal of cooperation from the host program, that's all.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            john 1 Reply Last reply Reply Quote 0
            • john
              john @dc42 last edited by

              @dc42 Our pyserial() connection is able to handle error messages sent back from the Duet because we listen for expected responses. For example, when we're looking for the "ok" from M400, or the Endstop Status message from M119, if we get a string of text other than what is expected, we push an error message to the host program that stops progress and halts the machine.

              If the Duet were to send a message back when Stall was detected, such as "Warning: Stall Detected" or anything remotely similar that would not be accidentally interpreted as an "everything is ok keep moving" response, that would be a great place for Stall protection to start when not printing from SD Card.

              1 Reply Last reply Reply Quote 0
              • dc42
                dc42 administrators last edited by

                Bear in mind that of you wait for an OK response after sending every command, the throughput you get on the USB channel will be somewhat limited and the printer may stutter when printing curves composed of short segments. How much of a problem this is depends on what operating system you use. Waiting for OK was necessary on 8-bit controllers that used an add-on serial-to-USB converter with no flow control, but it isn't necessary with the Duet or other controllers that have a native USB port.

                I'll add to the firmware wishlist an option to generate warning messages if stalls occur when not printing from SD card.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                john 1 Reply Last reply Reply Quote 0
                • john
                  john @dc42 last edited by

                  @dc42 Thanks for the heads up on that. We move large distances on single g-commands, because we're not a printer that has to do stuff along the way. We also have natural pauses before and after each move for other activity. So, waiting for the OK is fine for us.

                  I'll be looking out for the warning messages during stall. Thank you!

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