No stop for filament change

Snapmaker 2.0
1

hello makers,
since a short time, my a350t doesnt execute the stops for filament changes.
i checked the gcode for M600 and the code is there, but my printer doesnt pause anymore.
any idea what is causing the problem?
thank you!!

2

Are you printing from touchsreen?
What toolhead did you use?
I guess for the single extruder there is a setting for enabling/disabling the runout sensor on the touchscreen (which is excecuted as M600 as well, if i´m not wrong).

Its possible to turn the runout sensor on by M412 S1 over the terminal, maybe you disabled it?- But this is only guessing…

3

hello, thanks for you reply.
no i start the print with luban over wifi.
i never used M412 S1.
yes, i use the single extruder that was shipped with the a350t.
the thing is that about two weeks ago i had no problem printing with color changes.
i will cut some filament and test if the runout sensor is activated

4

I also just found out M600 doesn’t work like it use to. I found Profile - raypfountz - Snapmaker: where creation happens said to use M76. I tried M600 followed by M76 and that worked. I didn’t try M76 alone. I had previously used M600, but that was a couple years ago. Try the M76 and see.

5

hmm, that means i always have to open the gcode and change it manually?
but how did it change? i havent updated the firmware

6

runout sensor is working. it stopped after filament was empty

7

Interesting, I wonder why this isn’t a part of SMFix if it’s a thing that needs to be done.

Perhaps @macdylan never used M600?

8

its still in the wiki

grafik
grafik1361×430 12.9 KB

9

Also, you’re using Prusaslicer, you can edit the “pause print” custom gcode under Printers > Custom G-code (you may need to enable advanced mode to get this to show up). You could add M76 there.

M600 might only work when printing from the touchscreen or luban, if you’re running from octoprint, since SM have done “interesting choices” in gcode execution, it may not trigger correctly.

10

Weird, M76 doesn’t really do anything:

Perhaps they’ve distributed an update that they haven’t put in the github repo (GPL violation).

11

I have M76 as “Pause the print job timer” so I’m not sure why that works with the M600, but it seemed to do it where M600 alone didn’t.
I just went back to the M600 that ‘worked’ (2/2023) and noticed I actually used a M0 - M600 combination. M0 is “Unconditional stop” so I’m not sure if it was M0 or M600 that was doing my pause to change filaments. Guess we have to play with it and see.

12

There could also be more to that code, most likely the systemservice is causing the pause stuff to run, but planner.synchronize() could be kicking off a chain of events that causes the m600 to actually execute, or something could be listening to the terminal for that echo.

13

Okay, that was a fun learning experience. M0 (Unconditional stop) doesn’t seem to do anything. M76 (Pause the print job timer) puts the print head to top right rear (320 x 335 x 315?). NOW M600 is working like it should, sort of. I wrote some simple gcode to move the head around and inserted the various commands. M600 (no modifiers tried; just straight M600) triggered a filament change but initially, about a line and a quarter after it should have fired (meaning, it moved to the next spot, and starting to move to another spot before it fired). BUT, if I included extrusion before (or after?) the M600 as part of the movement, it worked where it should! If I did a M600 followed by the M76, only the M76 fired; no filament change screen. If I put in the extrusion into the movement, it fired where it was supposed to, and actually did BOTH M600 followed by M76. So, as @nivekmai suggests, “there could also be more to that code” with systemservice or planner.synchronize; but that is beyond me. So, M600 sort of does work for filament changes. Not sure why I had problems with it the other day not working at all.

14

It doesn’t work with my files. The standard M600

15

planner.synchronize tells the code to pause and wait for the current gcode chunk to complete executing before the next line is executed. It’s there to make sure conflicting commands aren’t sent while something is in motion.

16

i tryed it via wifi and from the usb drive. both no stop.
so do i understand it right, that i manually have to search for the M600 and add “e 10” for example directly before M600?

17

If you are referring to my post, the extrusion was part of the movement line before the M600 line: as in G1 X200 Y20 E30 then next line M600 (example). I wrote the simple movement code and did it through the USB transfer, not through Luban. I don’t have good wi-fi to the SM. I still have to play around some more with it to try and figure it out. Intuitively, it doesn’t make sense. So, yes, you have to go into your project code at this time.

18

ok it looks like it has to do with the size of the object.
i made a small test with a very small object of only 28x28x20mm.
i added a color change (standard change of prusaslicer) at layer 5 of 100 layers. ive sent the file via wifi. the printer stopped at layer 5.
i dont understand what the problem is…

19

are there officials on this forum who could give a statement on the issue? it doesnt look like its something that only occurs with my machine.

20

While I was putting together [GUIDE] Octoprint + (stock) Filament runout detection, I found that the way SM tracks a job being in progress is a bit finnicky, and can get into a bad state (there’s even comments in the code where the team doesn’t understand why things are happening). The easiest way to reset the state is to just reboot the machine.

So in your testing, make sure you try rebooting the machine between each print (and maybe even, between each pause), and that should get you more consistent behavior. (unfortunately, if it only works from reboot → pause, then that means you can only do a single filament swap, which is kinda useless).

Also, for that I found that doing

M600
M76

worked best for actually pausing the print and allowing for me to handle filament runout, so maybe just edit the Pause Print G-Code in Printers in Prusaslicer to send both.

BTW, the reason I did this was because I saw that M600 does basically nothing in the firmware.

BUT WAIT! @scotthuang and team just committed some changes to M600…

So maybe there’s some fixes coming?

Specifically in this, M600 now calls event_filament_runout, which means it should actually work for real (before it was just calling ResetFilamentState which does nothing).

1 Like