The print has stopped because the filament is jammed within the AMS or print head path.
I tried to press the button and extract the filament but it is stuck and will not move even with considerable force.
I have tried unplugging the AMS and leaving it unplugged for a few minutes and plugging it back in but it does not make a difference. Didn’t help.
I finally gave in and unplugged everything from the AMS and decoupled all of the PTF and was able to pull out the filament.
Because the print is paused, I was hoping to reload the spools and continue but now I see that the slots have question marks and have forgotten the spool colors and other info.
Possibly a faulty buffer. Ssems common recently. Mine sticks ever so often. Ive found that its important that both ptfe tube go straight into the buffer without rubbing on the sides. Especially the outgoing side with the spring.
yea, I am kinda trying to keep the two items separate. Fixing the jam, and recovering the print here. Though this seems to be solved. Just the app dialogs don’t look right.
I had a similar issue, but in my case, the typical alert of not being able to unload the filament resulted in the AMS blinking red leads. My problem was solved whilst checking the cause (not sure if it was in the buffer or the cable)
Anyway, the important is that I lost the filament info and, thus, calibration. Until you finish the print, it isn’t possible to edit the filament PA advance value.
I tried to continue the print, but after a few layers, I cancelled as the quality wasn’t acceptable. Likely, the loss of the filament pressure advance values isn’t recoverable and was the cause of the print failure, but I cannot be sure. i.e. if the value is passed to the g-code at the print beginning, there shouldn’t be any failure.
So the filament info seems to be stored in the printer when it is sent over. It continued fine once I took everything apart and solved the jamming. Its just a matter of it not communicating that info back to the apps it seems.
The filament PA (or k value) is surely stored in the printer if you use the BL calibration tool.
I suppose it may include a sort of post-processing script which adds the PA value to the gcode. I am clueless about at which stage it adds to the gcode and if it overwrites any previous values.
In my case, it was multicoloured, if that matters at all. But it is also likewise that the print quality drop relates to the cool down during the troubleshooting, which is also supported by your findings.
