Random M600 calls that are not in gcode
I'm having a pretty weird issue here that I can't diagnose or troubleshoot at this point.
I was printing a model yesterday via SD card. The gcode did not have any pauses or filament swaps in it, but I planned on doing manual filament swaps periodically during the job using the LCD menu. I swapped the color successfully 3 times, but after the 3rd swap, the machine would pause and ask for a filament change every few minutes. This happened 3 times before I just gave up and assumed that the gcode had been somehow corrupted. The next morning, I tried printing the same model with no swapping. It got partway through the first layer and then asked for a filament swap again. I tried printing a different file that was already on the SD card and it also stopped for a filament change. The amount of gcode that printed before the swap was significantly different. From there, I tried slicing a completely different model, even installing the newest version of Slic3r (I was using the previous release) just to be sure. This job also randomly paused. I reflashed the firmware, and the same problem happened. As a last effort, I connected via USB and served gcode from Pronterface. Same problem. Pronterface reported that an M600 call had been made:
The progress should be updated on the printer now: M117 6.49% Est 0:11:21
The progress should be updated on the printer now: M117 8.39% Est 0:11:09
echo:Enqueing to the front: "G1 E-3 F200"
echo:Enqueing to the front: "G1 E3 F200"
echo:Enqueing to the front: "M600"
echo:busy: processing
echo:busy: paused for user
echo:busy: paused for user
I'm at my wits end. The printer is unusable even though everything seems to be functioning perfectly otherwise. I really don't want to have to replace the entire RAMBO because of this. Is there a way to completely wipe the board and start from scratch?
Re: Random M600 calls that are not in gcode
If you haven't tried it yet, do a factory reset.
Factory reset can be used during troubleshooting to wipe configuration data from the device's memory in a quick and easy way.
More info here:
https://help.prusa3d.com/l/en/article/SYvbQ66IXF-factory-reset
-Kevin
Re: Random M600 calls that are not in gcode
Thanks, that's good to know. Someone else pointed out that the filament sensor might be the culprit. Didn't think about the fact that when the sensor doesn't detect filament, it likely uses M600 to do the swap. I turned off the sensor and am printing now. All of this started happening when I started printing with a new roll of filament that I had not printed with before: 3D Solutech Black PLA. It's shinier on the roll than the previous black I was using. I'm hoping this is it.
Re: Random M600 calls that are not in gcode
Looks like it was the filament sensor. 3D Solutech PLA has a similar issue to what some users are reporting about black PETG.
Re: Random M600 calls that are not in gcode
Hi Jangus
Shiny filament seems to cause false filament out responses.
which seem like M600 events.
do you have the latest firmware loaded, as Prusa have been making tweeks to the filament sensor routines.
regards Joan
I try to make safe suggestions,You should understand the context and ensure you are happy that they are safe before attempting to apply my suggestions, what you do, is YOUR responsibility. Location Halifax UK