Stall Protection on pyserial() print

sean

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?

dc42

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

sean

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"

dc42

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.

sean

@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.

dc42

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.

sean

@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!