filament sensor initiate auto load while printing
Hello MK3 friends,
Greetings, my name is Christian I am from Germany and since a few days I am the proud owner of the bloody smart MK3.
I am 3D printing since around 1,5 Years and got already some experience in mostly common issues but with the MK3 and all his smart sensors I experienced something new which should not be possible at this printing stage.
Okay so first my setup: latest Octoprint installation on a Raspberry 3 (no fresh installation and was working before on my 2nd printer) connected via USB to the MK3.
After around 5 hr of an estimated 8 hr print it seems (from the logfiles) that the filament sensor started to initialize auto load, please see the log lines below:
......
Send: N416408 G1 X88.007 Y115.682 E-0.1984 F1584*20
Recv: ok
Send: N416409 G1 X87.727 Y115.637 E-0.3220*120
Recv: ok
Send: N416410 G1 X87.989 Y115.250 E-0.5309*115
Recv: ok
Send: N416411 G1 X87.924 Y115.412 E-0.1985*127
Recv: ok
Send: N416412 G1 X88.105 Y115.537 E-0.2500*124
Recv: ok
Send: N416413 G1 X87.989 Y97.957 F6000*126
Recv: ok
Send: N416414 G1 E1.5000 F1800*10
Recv: echo:enqueing "G1 Z 106.434 E 0.000 F 800.000"
Recv: fsensor_autoload_check_start
Recv:
Recv: echo:enqueing "CRASH_DETECTED"
Recv: fsensor_autoload_check_stop
Recv:
Recv: echo:enqueing "G28 X"
Recv: echo:enqueing "G28 Y"
Recv: echo:enqueing "CRASH_RECOVER"
Recv: fsensor_autoload_check_start
Recv:
Recv: G28, initial world coordinates: (154.846, 115.685, 106.434)
Recv: G28, initial physical coordinates: (153.770, 115.070, 106.738)
Recv: fsensor_autoload_check_stop
Recv:
Recv: echo:busy: processing
Recv: G28, final world coordinates: (1.076, 115.382, 106.542)
Recv: G28, final physical coordinates: (0.000, 115.070, 106.738)
Recv: G28, final mesh bed leveling: 0.140 0.173 0.179 0.157 0.109 0.033 -0.070 0.169 0.215 0.232 0.220 0.180 0.110 0.012 0.200 0.252 0.275 0.270 0.237 0.176 0.086 0.233 0.284 0.309 0.307 0.281 0.228 0.150 0.268 0.310 0.332 0.332 0.311 0.269 0.205 0.304 0.332 0.345 0.343 0.327 0.297 0.252 0.342 0.348 0.348 0.342 0.330 0.312 0.289
Recv: fsensor_autoload_check_start
Recv:
Recv: G28, initial world coordinates: (1.076, 115.382, 106.542)
Recv: G28, initial physical coordinates: (0.000, 115.070, 106.738)
Recv: fsensor_autoload_check_stop
Recv:
Recv: echo:busy: processing
Recv: G28, final world coordinates: (1.311, -3.688, 106.637)
Recv: G28, final physical coordinates: (0.000, -4.000, 106.738)
Recv: G28, final mesh bed leveling: 0.140 0.173 0.179 0.157 0.109 0.033 -0.070 0.169 0.215 0.232 0.220 0.180 0.110 0.012 0.200 0.252 0.275 0.270 0.237 0.176 0.086 0.233 0.284 0.309 0.307 0.281 0.228 0.150 0.268 0.310 0.332 0.332 0.311 0.269 0.205 0.304 0.332 0.345 0.343 0.327 0.297 0.252 0.342 0.348 0.348 0.342 0.330 0.312 0.289
Recv: fsensor_autoload_check_start
Recv:
Recv: fsensor_autoload_check_stop
Recv:
Recv: echo:busy: processing
Recv: fsensor_autoload_check_start
Recv:
Recv: fsensor_autoload_check_stop
Recv:
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N416415 G1 X87.727 Y97.571 E0.0186 F3600*13
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
....
Changing monitoring state from 'Printing' to 'Offline: Too many consecutive timeouts, printer still connected and alive?'
Connection closed, closing down monitor
My assumption is that the (unexpected) attempt to do auto load filament "fsensor_autoload_check_start" while printing the printer crashed and run into a loop of failure but I am not that deep in GCODE so maybe you guys see the issue in the GCODE above.
One note: I was not physically present at the printer to check his conditions (as it happens during overnight printing).
I haven't cleaned / checked the Filament sensor (like recommended in other topics) yet but please correct me when I am wrong but I guess it should not be possible to start auto loading process while the printer is still running or?
Furthermore: I sliced the model via Simplyfy3D by using as base the MK2 profile but modified start code to be able to work with the MK3.
Short prints (~1hr) are working fine in this setup.
Thank you for supporting me and looking forward to your thoughts.
Cheers Christian
Re: filament sensor initiate auto load while printing
Hello,
Here some little update about this case:
I turned the filament sensor off and printed with the exact same setup (mentioned above) and the print was successful after around 9hr print time.
But as there is a reason for having a filament sensor 🙂 I did the following:
I cleaned the Filament sensor and made sure everything is correct.
Printing a new object sliced with a different S3D beta profile (obtained from the Facebook group which was accordingly to the post provided from S3D directly).
After a few hours of printing again the same problem: the Filament sensor wants to load new filament while the printer is printing 😯
So I ask myself is there a problem with the filament sensor behavior or the S3D Profile or octoprint? As It works fine when the filament sensor is off I guess there is some unexpected behavior in this setup.
-----
Edit:
I just have seen, that there is a new Firmware out: "Firmware 3.1.1 RC3 b138 (December 26, 2017)" which also mention this problems.
Will check this out and let you know. 😉
Re: filament sensor initiate auto load while printing
I am running the RC3 138 build on my MK3, and still receive random requests to swap filament mid print, even when printing from SD card, and the filament sensor is turned on. Turning off the sensor is the only thing that fixes the issue.
I have had to abandon Octoprint for the time being. It has been producing lots of random, weird issues. Both with the Pi Zero attached to the Einsy, and with a external Pi 2 over USB. The Pi 2 had been performing flawlessly for a year on another printer.
I am pretty frustrated over all with all the new sensors. When I get prints, they are amazing, but there are lots of false starts.
Re: filament sensor initiate auto load while printing
I am running the RC3 138 build on my MK3, and still receive random requests to swap filament mid print, even when printing from SD card, and the filament sensor is turned on. Turning off the sensor is the only thing that fixes the issue.
I have had to abandon Octoprint for the time being. It has been producing lots of random, weird issues. Both with the Pi Zero attached to the Einsy, and with a external Pi 2 over USB. The Pi 2 had been performing flawlessly for a year on another printer.
I am pretty frustrated over all with all the new sensors. When I get prints, they are amazing, but there are lots of false starts.
Could it be a problem with the sensor itself? Have you seen more people with your issue?
Re: filament sensor initiate auto load while printing
I am running the RC3 138 build on my MK3, and still receive random requests to swap filament mid print, even when printing from SD card, and the filament sensor is turned on. Turning off the sensor is the only thing that fixes the issue.
I have had to abandon Octoprint for the time being. It has been producing lots of random, weird issues. Both with the Pi Zero attached to the Einsy, and with a external Pi 2 over USB. The Pi 2 had been performing flawlessly for a year on another printer.
I am pretty frustrated over all with all the new sensors. When I get prints, they are amazing, but there are lots of false starts.
Could it be a problem with the sensor itself? Have you seen more people with your issue?
I have the same problem. As long as the filament sensor is ON it stops multiple times during a print - Running now FW 3.1.1-RC4 - Build 139
@Fladby3Dprint - Norway
MK3s
MK3s-MMU2s
Raise3D E2
Re: filament sensor initiate auto load while printing
As I understand it the sensor stops printing when it detects no filament and when it detects jammed filament. Since it detects the lack of movement in the second case it would seem there is a programmed timer in the program or sensor. I.E. if the filament stops moving for a certain amount of TIME it assumes it is jammed and stops printing. If that is correct, and it very well may not be as I am making assumptions and have no real knowledge of how it is set up, then it may have something to do with lack of movement of the filament when the extruder is "idle" when coasting (I think that is when it kinda relieves the back pressure in the nozzle with no extruder pushing the filament) or perhaps when there is a number of moves which do not involve the extruder actually pushing filament. For instance a combination of Z-hop, coast, and position change.
I'm probably wrong and nowhere in the ballpark with this but as I understand it (or don't) is it possible that could be the problem? If not then could someone tell me why. I really don't mind being called an idiot (been carrying an ID10T card for years now) but I do appreciate it if you let me know why I'm wrong.
Hope it helps and Thanks,
Neal
Re: filament sensor initiate auto load while printing
As I understand it the sensor stops printing when it detects no filament and when it detects jammed filament. Since it detects the lack of movement in the second case it would seem there is a programmed timer in the program or sensor. I.E. if the filament stops moving for a certain amount of TIME it assumes it is jammed and stops printing. If that is correct, and it very well may not be as I am making assumptions and have no real knowledge of how it is set up, then it may have something to do with lack of movement of the filament when the extruder is "idle" when coasting (I think that is when it kinda relieves the back pressure in the nozzle with no extruder pushing the filament) or perhaps when there is a number of moves which do not involve the extruder actually pushing filament. For instance a combination of Z-hop, coast, and position change.
I'm probably wrong and nowhere in the ballpark with this but as I understand it (or don't) is it possible that could be the problem? If not then could someone tell me why. I really don't mind being called an idiot (been carrying an ID10T card for years now) but I do appreciate it if you let me know why I'm wrong.
Hope it helps and Thanks,
Neal
That makes sense.... But if that were the case i think we would see alot more people with the same problem... This seems more like a bug or malfunction than some software design flaw...
I've used those functions (wipe... coast, Z-hop etc etc) and never had that problem and from what i see people who are struggling with this issue are reporting its doing multiple times during a print.
Re: filament sensor initiate auto load while printing
No, it does not look like an "out of filament stop" or "no filament movement" stop the log lines received by octoprint are very clear and in case of the mentioned stops he would pause, move away the head and beeping for new filament.
The printer just continued printing while attempting to load filament caused a filament blob on the nozzle which crashed the print and then he stuck in a crash loop and then octoprint disconnected after several attempts.
Maybe an improvement for new Firmware: An emergency auto hold after several crash detections: (Example: 3 crash detections in 2 minutes triggering emergency halt which moves the Z 1cm up and move the Head away from the print, start beeping and after 5 minutes cool down the nozzle and after lets say 15 minutes of no user interaction also shut down the heated bed.)
But anyway: after some days of "happy printing" (and 2 Firmware update) it's seems like the problem with the Filament sensor has been resolved 😀 .
Now I have some other problems with shifted layers when crash detection is on but this is an other story.
Solution for this case: Update the Firmware.
Thank you.
Cheers Christian