SERIOUS PROBLEM WITH "GAP FILL"  

  RSS
rogerinhawaii
(@rogerinhawaii)
Trusted Member

A couple of months ago I started having problems in which the gears in the print head that push the filament through the hot end were clicking. They would rotate a bit in the correct direction but then snap back, making the clicking sound, and no filament was actually coming out of the nozzle. I had a lot of ruined prints because of that. On many cases the filament would get completely stuck in the print head and I had to disassemble the print head in order to clear the filament out of the PTFE tube. I've had to disassmble the print head five times so far, other times I was able to do a successful UnLoad / Load of the filament. The removed filament always looked like this, with a big blob of hard filament on the end and little tendrils of filament coming off of that:

These problems started when I had run out of filament and had to order new PRUSA filament. PRUSA didn't have the same silver filament that I had been using (the type that comes with the original kit) so I ordered the Gentlemen's Grey filament instead. That's when the problems started. I ordered four reels and have had the same problems with two of the reels (ID 26a1b0c7 and ID 390a3b30). I couldn't know for sure but is sure seemed like it might be due to the filaments, a bad batch perhaps?

But the problems kept arising. At one point I was printing a model that I had printed successfully a dozen times before (before the new filament) but now using the new filament and the print failed, four minutes before the end of a 3 1/2 hour print. Normally the top part of the print looks like this:

 

But this time it looked like this, after the print had failed with the clicking/clogging of the filament. This is a very closeup of the very top of the model.

I tried printing it again but it FAILED AGAIN, and AT THE VERY SAME LOCATION IN THE PRINT.

What the heck was going on???

I went back to the STL file for the part and loaded it into the PRUSA Slicer, using the scroll bar on the right to look at the various layers. Most of them look just fine, nothing unusual:

 

But then, right at the point in the print where the clicking/clogging problem happened, I see something a bit  unusual. There's a white line of filament. It's where the normal lines of filament don't quite meet and the white indicates a "Gap Fill". 

It's only a little bit of gap fill, but each subsequent layer, on up to the top, there's additional gap fills.

I'm thinking, Could THAT be the cause of the problems? So I use the Expert Mode in the PRUSA Slicer to set the Gap Fill Speed to zero, which basically tells it NOT to do any actual gap filling operations when printing. Using that NEW, "no gap fill" version of the GCode file I print the model again.

AND IT WORKS!!! No clicking, no clogging, no failure of the filament to extrude. A fully successful print.

I continue on with my work. When I'm creating a new STL file and passing it through the Slicer I make sure to have the Gap Fill Speed set to 0, and it works. One in a while I forget to set the Gap Fill Speed to 0 and the print fails.

TOO SLOW : NO FILAMENT FEED???

It APPEARS to me that when it's doing a Gap Fill operation during a print it moves the print head much more slowly AND it attempts to feed the filament much more slowly (by rotating the gears much more slowly) since it's trying to fill a very narrow space and needs much less filament going into it. And it APPEARS to me that the decreased speed results in a gap INSIDE the hot end, near the bottom end of the PTFE tube, maybe with some filament dribbling out of the nozzle, and that inside gap results in the filament inside the end of the PTFE tube to quickly solidify, making a clog that the gears then can't push out.

ONE OTHER ISSUE

The print failures that I've been encountering so far have generally been because the model has very thin walls and in some locations the front and back of the wall leaves a bit of a gap. In those cases the Slicer (with the default Gap Filling Speed value) correctly tries to put filament in those gaps. HOWEVER, I recently made a model that, again, has very thin walls but that actually has NO gaps. Nevertheless, for the very first layer, the one smack dab down on the plate, the Slicer seems to spread apart the walls and automatically creates a gap.

Here's what the model looks like, just thin walls.

 

And here's the first layer, WITH GAPS!!!

Why does the Slicer spread the filament a bit on the first layer, thereby introducing gaps?

IS IT THE FILAMENT???

So, the BIG QUESTION:     IS IT THE FILAMENT?

Or is it something else?

I'm attaching the GCode file for that last one (the one where the first layer has those gaps and the printer will indeed try to fill them in with filament) in case someone would like to give it a try with some other filament or also with the PRUSA Gentemen's Grey filament. Mine fails (with clicking sounds from the gears and no filament coming out of the nozzle)  right after it lays down the first layer and is going back to try to fill in the gaps.

AND ONE MORE THING

I was doing ANOTHER print, from a model that I had just created but which I had NOT set the Gap Filling Speed to 0, and it started clicking. I quickly paused the print and noticed that the target nozzle TEMP was 210. Te actual temp was a bit lower since it had started to cool down. But why was the target temp set at 210? For my PLA prints it's ALWAYS 215? When I started this print it was 215. Why would it get set lower during the print? Is it because it was trying to do a Gap Fill operation, with slower speeds, slower extrusion? Could that CONTRIBUTE to the clicking/clogging problem?

Posted : 08/07/2020 8:12 pm
bobstro
(@bobstro)
Illustrious Member

Can you zip and attach the project 3MF file with your settings?

My notes and disclaimers on 3D printing and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan...
Posted : 08/07/2020 8:30 pm
Neophyl
(@neophyl)
Noble Member

The gapfill is probably causing your print to do more retractions.   One thing I always try when extruder cloggs happen is to actually reduce the amount of retraction.  I calibrate my filaments normally anyway and I always turn off retract on layer change and normally have 0.2-0.4mm retraction.  Its very rare to get a clogg.  I think I've had one in the last year and that was down to some really cheap silk filament.  It wouldnt even print without clogging a 0.6mm nozzle.

The other thing with clogging is heat creep.  When it gets warmer the cooling efficiency of the air cooled hotend gets less and it can become marginal.  When  you combine this with a lot of printing with lots of retractions and a slow print speeds the heat can creep up more and lead to more cloggs.  Think about it the system produces a certain amount of heat, the fan removes most of that, the filament that is printed also removes a lot of it from the system.  When you air cooling is reduced due to warm temps and the filament isnt being printed quickly then heat isnt being removed as quickly.  Combine all these factors together and you get issues.  Most of them go away in the winter.

One other thing to note is that  Prusament should be printed hotter than the pla that comes with the printer (if they are still sending the Plasty Madec filament out with new printers).  The temp on the website lists 215 as print temp and your screen cap is showing 210.

Another thing is that the wispy  multiple ends like that I've only seen on silk filaments and I always print though at 220-230 depending on the filament so I would encourage you to try a temperature with each filament.  Some brands of filaments are just more difficult to print with than others as different manufacturers use different blends of plastic and they can vary by colour even within a brand as the colourants can effect performance too.

Posted : 08/07/2020 11:17 pm
rogerinhawaii
(@rogerinhawaii)
Trusted Member

@neophyl

Thank you for replying to my post with some very insightful comments.

When I encountered the issue on my tall, thin model where the symptoms occurred at the very top, I did notice that the print head was quickly jogging up and down as it encountered numerous short Gap Filling operations and I, too, thought that maybe the whole problem was in that fast jogging motion, somehow interfering with the flow of filament. But then I printed that other model, which is just a series of concentric rings with gaps going around with every ring. There is NO jogging of the print head during those operations. The print head is  just moving smoothly around the ring attempting to fill in the gap, yet it still has the clicking/clogging,failing to deposit filament problem. SO I had to discount the jogging idea as the cause of the problem and just attribute it to a failure of the printer to handle those gaps, not being able to handle such slow movements and such reduced filament extrusion rates.

I now only have the one batch of filament reels, namely the PRUSA Gentlemen's Grey, so I can't do a comparison with any other filament to see if it's related to the type, brand, color of filament.

I live in Hawaii so, yeah, it gets warmer here in summer, but actually not that much warmer than winter. Plus, I didn't have this issue last summer, even though I don't have air conditioning in my apartment and rely on the "Trade Winds" for any cooling. 🙂 So I"m thinkongit's likely NOT due to differences in temperature. SO I "m still thinking it's basically the batch of filament that I've got that's causing the problems.

As for my comment about 215 versus 210 temperature. I wasn't aware of this until the other day, but I now know that it uses the 215 temp for the first layers and 210 for the rest. There's even some settings for that in the settings options in PRUSA Slicer. [ sigh ] Just so many details to know about. 🙁

Anyway, I at least have an APPROACH, of setting the Gap Filling Speed to zero that seems to avoid the issue.

Posted : 10/07/2020 10:08 pm
rogerinhawaii
(@rogerinhawaii)
Trusted Member

 [ sigh] And once again, ...

I completed a four hour print of a model quite similar to the tall thin one noted above. No Gaps to fill. Gap Fill Speed set to 0 just in case. And it went perfectly fine. No problems.

As soon as it was done I started up a print of the exact same model, using the exact same GCode file. It got about halfway done and, Click/Clog Filament extrusion failure. Just little dribs and drabs of filament leaking out.

 

This is getting really frustrating. I can never know when it's going to fail. Hours and hours of printing wasted.

Posted : 11/07/2020 4:37 am
rogerinhawaii
(@rogerinhawaii)
Trusted Member

Oh, c'mon, now. I ran the same print and it failed again, but at a DIFFERENT point in the print, about half an inch higher than before. The previous print is behind, the new print in front of it.

I Unloaded the filament and it looks like this...

Posted : 11/07/2020 7:02 am
rogerinhawaii
(@rogerinhawaii)
Trusted Member

I just noticed something (else) odd. I was working on a model in Fusion 360, exported it out as an STL file, then opened that STL file in PRUSA Slicer. I selected Expert Mode, Print Settings, Speed and attempted to change the Gap Fill (speed) setting from its default 40 to make it 0, so that the PRUSA Printer wouldn't even try to fill any gaps. 

 

I deleted the default value of "40" in the field and entered "0". I hit the ENTER key and it left the field but reverted the value back to 40! I tried again, but used the TAB key to exit the field. Again it reverted to 40. I tried a bunch of times and, all of a sudden, it ACCEPTED the zero. 

What the heck???

I suspect that it's possible with those prior two prints (using the same GCode file) that I had ATTEMPTED to change that field to zero but didn't notice that it actually didn't accept it, so that it was still trying to do gap fills in the area where it failed.

Could someone else please give that a try, try to change the Gap Fill field to zero, and see if you encounter any difficulty in having it accept it? Ad see if you can figure out what you actually have to do to get it to accept it?

Posted : 11/07/2020 7:30 am
Neophyl
(@neophyl)
Noble Member

The confirm 0 by hitting enter is a known issue in slicer. Happens all over the place in previous versions and the devs have been trying to get them all. Might be worth adding that specific one to one of the issues on github.  Might even be a regression as it seems to be linked to the libraries used for the UI. 

Posted : 11/07/2020 8:19 am
peter.m26
(@peter-m26)
Honorable Member

If I change to 0 it stays zero.

I am using an older version in linux as a app image, PrusaSlicer-2.0.0+linux64-201905201652.AppImage

Posted : 11/07/2020 6:33 pm
rogerinhawaii
(@rogerinhawaii)
Trusted Member

@neophyl

Yikes! A known issue that hasn't been corrected? The PRUSA Slicer is likely used by nearly 100% of their customers, and it doesn't work properly??

Posted : 11/07/2020 8:49 pm
bobstro
(@bobstro)
Illustrious Member
Posted by: @rogerinhawaii

Yikes! A known issue that hasn't been corrected? The PRUSA Slicer is likely used by nearly 100% of their customers, and it doesn't work properly??

It's working properly on MacOS. Perhaps your experience is not universal?

 

My notes and disclaimers on 3D printing and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan...
Posted : 11/07/2020 9:21 pm
rogerinhawaii
(@rogerinhawaii)
Trusted Member

@bobstro

So, we now have feedback that it works on Linux and MacOS (at least for older versions). I run it on Windows. Even if it's not "nearly 100%" of users, it's still an issue, and apparently a "known issue". It really ought to be corrected.

I'm just finding it to be very frustrating to be using software like PRUSA Slicer and Fusion 360, major software packages, and way too often encountering problems that I spend huge amounts of time tracking down, only to find that it is indeed a problem in the software package itself.

 

/end rant

Posted : 11/07/2020 10:25 pm
bobstro
(@bobstro)
Illustrious Member
Posted by: @rogerinhawaii

[...] So, we now have feedback that it works on Linux and MacOS (at least for older versions). I run it on Windows. Even if it's not "nearly 100%" of users, it's still an issue, and apparently a "known issue". It really ought to be corrected.

PrusaSlicer is based on Slic3r, one of main slicers to come out of the early days of the hobby. Initially just a fork, Prusa has since converted the bulk of the code from PERL to C++, a major undertaking. They've done a lot of work on the interface, but as you note, there are still a few burrs. They have, however, made a huge amount of improvements to the point that PrusaSlicer has emerged as one of the best slicers, blowing away the nearest commercial ($150) competition. So yes, there are problems and yes, they are annoying but the software is by and large usable.

If you encounter actual problems, the most helpful thing you can do is take a look at the Prusa github site and see if there is an existing issue that matches yours. If so, add some notes that might be helpful for verifying the problem. If not, open a new issue to be tracked. There's no need to go down the path of hyperbole and rants. 

FWIW, Cura also has quite a bit of user interface weirdness, particularly when scrolling.

 

My notes and disclaimers on 3D printing and miscellaneous other tech projects
He is intelligent, but not experienced. His pattern indicates two dimensional thinking. -- Spock in Star Trek: The Wrath of Khan...
Posted : 11/07/2020 11:00 pm
rick.m12
(@rick-m12)
Trusted Member
Posted by: @rogerinhawaii

I just noticed something (else) odd. I was working on a model in Fusion 360, exported it out as an STL file, then opened that STL file in PRUSA Slicer. I selected Expert Mode, Print Settings, Speed and attempted to change the Gap Fill (speed) setting from its default 40 to make it 0, so that the PRUSA Printer wouldn't even try to fill any gaps. 

 

I deleted the default value of "40" in the field and entered "0". I hit the ENTER key and it left the field but reverted the value back to 40! I tried again, but used the TAB key to exit the field. Again it reverted to 40. I tried a bunch of times and, all of a sudden, it ACCEPTED the zero. 

What the heck???

I suspect that it's possible with those prior two prints (using the same GCode file) that I had ATTEMPTED to change that field to zero but didn't notice that it actually didn't accept it, so that it was still trying to do gap fills in the area where it failed.

Could someone else please give that a try, try to change the Gap Fill field to zero, and see if you encounter any difficulty in having it accept it? Ad see if you can figure out what you actually have to do to get it to accept it?

Open your g-code file with a text editor like notepad or textedit. At the end of the file you’ll find a bunch of comments that show all of the PS settings used to create that g-code file. Do a search for “gap” and see what the setting was.

Posted : 13/07/2020 2:45 am
rick.m12
(@rick-m12)
Trusted Member
Posted by: @bobstro
Posted by: @rogerinhawaii

[...] So, we now have feedback that it works on Linux and MacOS (at least for older versions). I run it on Windows. Even if it's not "nearly 100%" of users, it's still an issue, and apparently a "known issue". It really ought to be corrected.

PrusaSlicer is based on Slic3r, one of main slicers to come out of the early days of the hobby. Initially just a fork, Prusa has since converted the bulk of the code from PERL to C++, a major undertaking. They've done a lot of work on the interface, but as you note, there are still a few burrs. They have, however, made a huge amount of improvements to the point that PrusaSlicer has emerged as one of the best slicers, blowing away the nearest commercial ($150) competition. So yes, there are problems and yes, they are annoying but the software is by and large usable.

If you encounter actual problems, the most helpful thing you can do is take a look at the Prusa github site and see if there is an existing issue that matches yours. If so, add some notes that might be helpful for verifying the problem. If not, open a new issue to be tracked. There's no need to go down the path of hyperbole and rants. 

FWIW, Cura also has quite a bit of user interface weirdness, particularly when scrolling.

 

I suspect the main focus when they hire programmers is that they know how to work on the deep guts of the slicer. That’s the part that does the heavy lifting to create the g-code. Skills in developing the pretty user interface are not as high on the list of requirements. 

Posted : 13/07/2020 2:50 am
rogerinhawaii
(@rogerinhawaii)
Trusted Member

@rick-m12

You noted:

I suspect the main focus when they hire programmers is that they know how to work on the deep guts of the slicer. That’s the part that does the heavy lifting to create the g-code. Skills in developing the pretty user interface are not as high on the list of requirements. 

I suspect you're right. My own "specialty" was user interface design on a bunch of products. But there's a lot of programmers who don't give a damn about that. They just want their neat algorithms and slickly designed databases to work. I just want the user to actually be able to USE the program in the easiest way possible.

I was invited to join a medical device startup a while back. The rest of the team all concentrated on getting the core functionality working way down in the guts of the product. I kept bringing up issues like, "How is the user actually going to use this thing? How is he going to make sense of the data it provides?". I developed some prototypes of how it would be run from a smartphone, a prototype that got great reviews from some potential users.  I was eventually let go because "I didn't fit in with the team". Ummm, it's intended to be a product. Maybe give some thought as to whether customers will actually want to use this and be able to use it effectively. All the cool high tech doesn't result in a viable, financially successful product if they can't make good use of it. Right? 

Sorry, ... off topic.

Posted : 13/07/2020 4:19 am
Neophyl
(@neophyl)
Noble Member

There were a lot of user issues with fields changing back around v2.1.x  for example this one https://github.com/prusa3d/PrusaSlicer/issues/2758

If you have new ones then they really need to be added to github as Bob suggests.  While they may have got most of them it may be one missed or it could be a regression issue in the current version.  

Posted : 13/07/2020 7:20 am
rogerinhawaii
(@rogerinhawaii)
Trusted Member

Another update.

It took four attempts but I was finally able to get one of my tall, thin prints to print successfully. It kept failing at about the same, but not the exact same, location in the print, each after several hours of printing. The failure would always be that suddenly no filament was being extruded and the gears that push the filament through would snap back and make a clicking sound. On the final "successful" print it got to about the same location where the prior fails had occurred and, once again the filament failed to extrude and it started to click, BUT I was sitting there watching it and was able to do a Pause. I then did a filament UnLoad followed by a filament Load and a Resume and it successfully completed the print. I had caught it in time.

You can see the layer where it failed but I was able to pause and get it going again. But looking closely at the print it SEEMS as if the layers were possibly getting thinner and thinner as it approached the final failure layer. It certainly is creating a less and less smooth surface as it goes up. This flat surface is exactly perpendicular to the print bed, i.e. exactly vertical, so its surface should be pretty darn smooth. In fact, in similar prints with a vertical surface like this I get nice smooth surfaces, but not this time. Is that possible, that the layers are getting thinner? Maybe something increasingly clogging the nozzle or pathway down to the nozzle until it just totally clogs and stops the filament completely? Maybe some microscopic residue in the filament itself that builds up in the hot end over time?

Posted : 14/07/2020 3:31 am
yisesa1781
(@yisesa1781)
New Member

@neophyl

Yeah new forks have been added, they are working good

Posted : 14/07/2020 6:33 am
Share:

Please Login or Register