M600 Makes Nozzle Crash Into Part

#1

What is the problem?
When the filament runout switch is triggered the printer initiates a filament change with M600. However, when this happens, the nozzle moves down a couple mm and squishes the part before coming back up and going into the park position. The reverse happens when resuming a print after the filament change, The nozzle moves into the correct X/Y position and then goes down a couple mm to far, then raises to the correct height and continues printing.

What did you already try to solve it?
This problem affects the finish of the part in a minor way but it seems like something that can be fixed. I'm not sure if this is a case of relative positioning vs. absolute positioning because of the park feature working perfectly fine. I've also tried using the M600 Z "number" to add a relative lift but it seems like it goes down into the part and then goes up the extra distance. The printer also uses UBL, could that effect where the nozzle goes during a filament change?

When the sensor is triggered, this is the response to Octoprint:

Recv: echo:enqueueing "M600"
Recv: //action:pause
Pausing on request of the printer...

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)

OS: Windows 10
Browser: Chrome
Octoprint version:1.3.12
Printer: Modix Big60, Marlin 1.1.9B
Printer Board: MKS Gen 1.4
Filament Sensor: TriangleLab Filament Runout Sensor

#2

There are two general styles of printer with respect to Z:

  • The kind where the gantry moves up and down and the print bed is stationary
  • The kind where the gantry doesn't move up/down but the print bed does.

Based upon images of your printer's model from the web, I'm guessing it's the second type. If that's the case, in your OctoPrint -> Settings -> Printer -> (edit) area you might need to check the box next to invert for the Z axis.

Back in the OctoPrint -> Control tab, you should be able to select 1mm and move the print bed up and down with the Z buttons in an expected way.

So then review any Gcode scripts in the OctoPrint Settings area for pause/resume. If they're there then review the sign related to any G0 Z5.0 or similar commands here.

If there are no scripts there, then you might check the filament runout code wherever that lives. It might be in a plugin within OctoPrint or it might be in the firmware.

1 Like
#3

In addition to what has been said, also keep in mind that what the printer does on M600 is entirely up to the firmware and not under control of OctoPrint at all. The "Pausing on request of the printer" stuff will only make OctoPrint stop sending GCODE to the printer, and also trigger your onPrintPaused GCODE script. Unless you misconfigured something in that (OctoPrint doesn't ship with anything in there), you should take a look at your firmware configuration.

#4

I understand that this is not a problem with Octoprint itself, I've asked the same question to the manufacturer and on Marlin's forum with no response. I know that the Octoprint community is more active so I resorted to this forum. Thank you for building such a great platform and bringing a community together.

1 Like
#5

You are correct that the gantry stays the same and the bed moves up and down (Option two), The control has been inverted to now pressing the down button on octoprint will move the bed down and so on. My gcode scripts for "After print job is paused" and "Before print job is resumed" are blank because the firmware takes care of that. As @foosel had said, I am aware that this is most likely a problem with the firmware and not Octoprint, I just haven't been able to get any help on any other site other than this. I will do some more digging into where and what defines the M600 command and see if I can fix this. A solution will be posted on my findings.

1 Like
#6

If you actually build your own firmware (using the Arduino IDE usually) then there's likely an invert setting somewhere in there for Z.

If your printer manufacturer provided this for you then I'm at a loss.

Personally, I don't use M600 (some fork of Marlin). I probably would use another command and try to control this within OctoPrint's scripts that you saw earlier.