Question about filament runout behavior

I just got a simple runout sensor. Now I need to decide whether to connect it to my cr-10 motherboard or octoprint. Connecting to octoprint would be the simplest since I wouldn't have to update firmware in the motherboard. But I have a question.

I have noticed in the past that when I pause a print it can take a long time for the printer to finsh it's buffered commands. E.g. when it is printing long lines and each command takes a while. I'm worried that it will continue to consume filament, maybe even more than is left. Would a M600 command from octoprint have this problem?

Would this problem be the same if the sensor was connected directly to the motherboard? Any recommendations?

I really would not worry about...

  1. detecting a filament runout using a switch that's attached to the Pi
  2. ...and so many queued-up lines are in the printer board that bad things could happen by the time the pause happens as triggered from OctoPrint

The typical time delay I see between pausing and the printer board stopping is usually much less than 60 seconds. I can't imagine being able to extrude that much filament in this short of time.

M600 is an option if your Marlin supports it.

Since I'm more familiar with OctoPrint I personally would attempt to implement there instead of in the firmware of the printer board. But that's just me. Just note that if you pause it firmware-side then presumably you need to resume there as well.

1 Like

Since I posted the message I realized that things are worse on the CR-10 than I thought. The extruder motor is at the entrance to the bowden tube so if the end of the filament reaches the gear the motor can't push it any more. So I only have the distance from the switch to the extruder gear, not the length of the tube. My original idea of just putting the switch right at the printer would never work. This all assumes the M600 is put through the queue like all other commands.

I guess my original question boils down to whether the octoprint can pause the print as fast as the marlin firmware. Marlin could detect the pin change and stop the whole queue immediately. I don't think octoprint could do that.

I guess I"ll have to spend some time experimenting to see if one or both of the setups work. I googled hard and this topic never seemed to come up.

I was looking in the marlin source code and there is a variable to specify how much to keep extruding after the runout is detected. It defaults to 25mm. This surprises me since waiting longer would make my potential problem worse.

Your assumption is right. Other than triggering an emergency stop (which nukes any in progress prints) OctoPrint can do nothing to make the printer stop right now. There are no (universal) commands that stop processing of the queue. So if you need anything triggered immediately, have it in the hands of the firmware and have that also send action commands to OctoPrint to tell it to stop streaming.

1 Like