Loading filament to the nozzle fails when using custom start gcode

[TheRealAvise]

When the plugin is enabled, if I start a single mode print, after selecting the right tool the MMU tries to load filament to the nozzle, but it just keeps feeding, eventually tearing up the filament. It behaves like when the MMU is not calibrated properly and the feeding distance is too long.

With the plugin disabled, everything works as expected.

I use a start G-code which might be the issue, as the printer first preheats the nozzle and the bed, then loads the filament, does the bed leveling and only then raises the temperature to the final value. Maybe this causes some issues for the plugin.

[jukebox42]

Oh, interesting. Can you send me the start g-code you are using? I can try to see what's causing it. I do modify the M109 but it's only additive, that might be causing issues with your start command.

[TheRealAvise]

I just tried printing with the default PrusaSlicer start G-Code and the loading worked fine, so I would say there is a problem there definitely. As you say, it might be the M109.

Here is the whole thing: ; Misc M862.3 P "[printer_model]" ; printer model check M862.1 P[nozzle_diameter] ; nozzle diameter check M115 U3.11.0 ; tell printer latest fw version M117 Initializing ; set LCD message

; Set coordinate modes G90 ; use absolute coordinates M83 ; extruder relative mode

; Set bed temp and preheat nozzle while going home M117 Nozzle preheat ; set LCD message M104 S{first_layer_temperature[initial_tool]-50} ; set lower extruder temp to prevent oozing (offset by 50C) M140 S[first_layer_bed_temperature] ; set bed temp Tx M117 Homing ; set LCD message G28 W ; home all without mesh bed level M117 PINDA warmup G0 X50 Y50 Z0.15 ; this is a good PINDA heating position M190 S[first_layer_bed_temperature] ; wait for bed temp M109 S{first_layer_temperature[initial_tool]-50} ; wait for lower extruder temp (offset by 50C) M860 S35 ; wait until PINDA is >= 35C

; Mesh bed leveling M117 Mesh bed leveling ; set LCD message G28 W ; home all without mesh bed level G80 ; mesh bed leveling M117 Saving results G81 ; save mesh leveling results

G21 ; set units to millimeters

; Goto start corner and come up to final temp M117 Final warmup ; set LCD message G1 Y-3.0 F1000.0 ; go outside print area G1 Z3.0 F1000.0; lift nozzle to 3mm M106 S255 ; Turn cooling fan on to prevent oozing M104 S[first_layer_temperature] ; set extruder actual required temp M109 S[first_layer_temperature] ; wait for extruder actual required temp

; Select extruder Tc

; Purge line M117 Printing prime line ; set LCD message G1 X55.0 F2000.0 G1 Z0.3 F1000.0; lower nozzle to 0.3mm G92 E0.0 ;reset extrusion distance G1 X240.0 E25.0 F2200.0 G1 Y-2.0 F1000.0 G1 X5.0 E25 F1400.0 G1 Y-1.0 F1000.0 G1 X190.0 E25.0 F1400.0 G1 Z0.20 F1000.0 G1 X240.0 E4.0 F1000.0 G92 E0.0 ;reset extrusion distance M106 S0 ; Turn cooling fan off before printing anything

; And a beep to let us know the print is starting! M300 S100 P10 ; chirp M117 Print in progress ; set LCD message

[jukebox42]

Thanks! Let me take a look and see. If i can at least add a hook to let you manipulate what command I modify. I suspect it's ~the purge getting called after the Tc~ the fact that you are calling M109 twice.

[jukebox42]

@TheRealAvise if you're up for it, I have a PR that might fix this issue for you. I added a new setting to let you customize the M109 line.

There's a zip file you can install manually in the plugin manager on this PR: https://github.com/jukebox42/Octoprint-PrusaMMU/pull/19

Once installed, in settings, under Advanced set M109 Command to M109 S[first_layer_temperature]. I think your issue is that you are calling it twice in your startup script so it's trying to load twice. This will be more specific to the last one being called. I have not tested your startup script but I did test using the changed M109 and it printed like normal.

[TheRealAvise]

OK, just tried it and now the MMU selector does not move to the proper filament, it just loads the one where the selector is positioned.

I made a few tests...

Normally (considering the normal is my modified start G-Code) the sequence is as follows:

• start the print from Octoprint
• select the "tool" from the printer screen
• MMU selector moves to the selected filament immediately and loads it
• printer head moves to the preheating position and heats up the PINDa probe (by keeping it close to the bed) and the nozzle and the heat bed
• printer does the bed leveling
• printer head moves to the final position and waits for the temperature of the nozzle to come up to the final temperature
• purge line

With the modified plugin enabled and the modified M109 command entered in the respective field:

• start the print from Octoprint
• select the "tool" from the OctoPrint screen (plugin)
• MMU selector DOES NOT move
• printer head moves to the preheating position and heats up the PINDa probe (by keeping it close to the bed) and the nozzle and the heat bed
• printer does the bed leveling
• printer head moves to the final position and waits for the temperature of the nozzle to come up to the final temperature
• MMU tries to load the filament but is on the wrong position
• if there is filament available on the slot where the MMU selector is currently it will load it, but incrementally, like when it has missed loading properly and continues in small steps until it reaches the hotend, otherwise it times out
• purge line

I am happy to keep testing any new ideas you may have, but if you feel like it takes to many workarounds just to accommodate my weird start G-code, feel free to devote your time to doing something that effects more than 0.001 users and thank you for your time so far!

[jukebox42]

Oh, interesting. So normally the printer is loading before your nozzle fully preheats. Thanks for giving it a test!

The diff of our starts looks like: (ignoring M117s (display message), comments and moves)

; Set bed temp and preheat nozzle while going home
-M104 S[first_layer_temperature] ; set extruder temp
+M104 S{first_layer_temperature[initial_tool]-50} ; set lower extruder temp
M140 S[first_layer_bed_temperature] ; set bed temp
Tx
M190 S[first_layer_bed_temperature] ; wait for bed temp
-M109 S[first_layer_temperature] ; wait for extruder temp
+M109 S{first_layer_temperature[initial_tool]-50} ; wait for lower extruder
+M860 S35 ; wait until PINDA is >= 35C

+ G80 ; mesh bed leveling

;go outside print area
+M106 S255 ; Turn cooling fan on to prevent oozing
+M104 S[first_layer_temperature] ; set extruder actual required temp
+M109 S[first_layer_temperature] ; wait for extruder actual required temp

- G80 ; mesh bed leveling

; select extruder
Tc

What the plugin is doing is when it catches that M109 line (or modified one) it's sending the T# (where # is the tool number) directly after it. I wonder if the mesh bed leveling is the time it needs. You are performing that before the temp change and I, after. So my GCODE would look like:

M109 ; wait for temp
T# ; specify tool
G80 ; mesh bed level
Tc ; change tool

And yours:

G80 ; mesh bed level
M109 ; wait for temp
T# ; specify tool
Tc ; change tool

Another test you could try would be to set the M109 Command to your first instance of it M109 S{first_layer_temperature[initial_tool]-50} to see if it's a race issue because of how late it's sending the T#.

These are hunches btw but relatively safe tests. Not a gcode/printer expert. I do assume there will be others in your situation so understanding what's causing it will help and so far the change is relatively minor :).

I think if this test fails tho I may want to leave it at that until we find others in your situation. I did my best to comment the plugin if you feel brave enough to try and debug further. It really comes down to:

1. Look for Tx (silence it) and pause the printer to prompt the user
2. look for M109 and send both the M109 line and T#.

All of that happens in gcode_queuing_hook, the rest of the plugin handles displaying the correct states or drawing the modal.

FYI, I noticed a small bug in the last version that will reset the M109 command in some instances. New version is uploaded on the PR

[TheRealAvise]

I tired putting the first M109 command and a couple of other things, but it always behaves the same, not moving the MMU selector.

I'll play some more when I have time and get back to you if I find anything.

Thank you for your efforts!