Slicer creates an additional clearly perceptible and visible Z seam #7326
Comments
|
I think this has something to do with pressure equalizer. When it's off, flow change is abrupt, so it creates an additional "seam". When it's one, speed is weird, which again creates another seam worse than scarf.
Scarf speed seems to override the equalized speed. |
|
Same here. Bambulab A1. 2.1.1 scarf was tuned after much trial and error. Nothing changed on 2.2.0. All variables look the same in preview. Flow was the only one that looked a bit off.
|
|
I'm having the same effect on my macbook on 2.2 but fine on 2.1 (windows) |
|
Me too |
|
Yep, same here |
|
Today I've found out that in 2.2.0 you need to activate "Retract on layerchange", "Wipe while retracting" and a wipe distance of about 0.8mm to make scarf seams look as they did in 2.1.1 where activating "Wipe while retracting" made it look worse. |
|
However, your suggested settings are already activated by default in my printer profile. |
I had it deactivated in the previous releases since it used to work much better without but now it seems to work only when it's activated. I'll post an example when I get to my printer. |
|
This is what it looks like, now that I've reenabled "retract on layer change" and "wipe while retracting" with 1mm wipe distance. On 2.1.1 I had to disable wipe to achieve a comparable result. |
|
Could it be Z-Hop? #7380 |
|
Now even "Wipe while retracting" stopped working for me. Don't know why. |
|
Seems to be caused by the priming (unretract) before starting the scarf slope. The length is mathematically calculated perfectly as it is equal to the retraction length but it seems that during retraction a very small amount of already printed material from the end of the previous line gets also sucked back into the nozzle and thus is pushed out again at the beginning of the next line. This amount is so small that it does not matter too much when the next line is drawn with the same vertical thickness as the previous one (the configured layer height) but since the nozzle starts the next line very closely positioned over the previous layer when the scarf seam is applied, this unintentionally carried and unretracted extra material produces the blob since it has to expand far more in horizontal direction due to the very small gap between nozzle and the layer below. This is a hypothesis that I have put forward while testing different configurations and the only one that produced perfect scarf seam was outer/inner wall printing order, no infill and NO retraction during layer change. This way the nozzle moved without retraction from the end of the previous layers inner wall to the next layers outer wall scarf seam start. |
|
I seem to be following the right path because configuring a negative "extra length on restart" value in the printer settings or via the setting overrides in the filament settings thus effectively reextruding less distance then was retracted improves the situation. I just wonder why it seemed to work perfectly before v2.2.0? I've tested all this using PCTG filament. It may of course behave differently when using eg. PLA. |
|
What currently works best for me with scarf seam is, inner/outer wall printing order and "retract on layer change" disabled but you have to ensure that if the layer change happens inside the same object that the "travel distance threshold" is configured high enough to not force retraction. |
|
@shyblower what kind of values are you using for the negative extra length and travel distance threshold? I got a very interesting/bad result with -1 and 1. Basically the entire scarf area just didn't print. |
|
@begna112 Just a tiny fraction of the retraction length. About -0.1 maybe a little less (down to maybe -0.2). It's very dependent on the filament and other factors. I've tested it on a quite viscous PCTG. With PLA maybe a value of -0.05 will be sufficient. I've just used it to get proof for my hypotheses. If you set it too high you will get massive unterextrusion at the start of a line and it will look like your example. I personally wouldn't use it in production and would try to solve it by ensuring inner/outer wall printing order, disabling "retract on layer change" and adjusting the "travel distance threshold" until it is higher than the maximum distance the nozzle will travel through air within each single object on the plate. You can determine this by activating the display of "travels" and "unretracts" in the layer preview after slicing, watching out for unretracts after travel moves within the object and adjusting the threshold length to at least the distance of the longest travel move that shows an "unretract" at its destination. |
|
Prusaslicer creates good scarfs though with identical setings, so I think this is a bug |
|
@xantrk I couldn't find an obvious bug in the generated g-code. The unretracted length is exactly what was retracted before and since it works when I prevent retraction and unretraction the hypotheses I put forward in one of my previous comments might be the reason. What I can do is to compare the generated g-code to what PrusaSlicer and OrcaSlicer 2.1.1, which obviously also didn't expose the issue, produce and if I can spot differences, which is what I will do when I find some spare time for doing so. |
|
So I've been able to confirm your results, @shyblower. Sunlu PLA+, X1C, .4 high flow nozzle, inner outer inner. I've found that setting the negative extra length to half the line width size (.42mm/2 = .21mm) gives nearly perfect results on outer walls. However, with scarf seam enabled for inner walls, this leads to noticeable gaps. Notably, my pressure advance is also .2, so it's possible that's the value it corresponds to, not line width.
(Without retraction and deretraction, I'm getting stringing that I otherwise wouldn't, but that makes sense.) Disabling scarf seam gaps seems to mostly negate the inner scarf issue and lead to better quality. Almost imperceptible seam without flash enabled and barely able to feel it.
Caveats:
|
|
@begna112 you only have to deactivate "retract on layer change", the retraction length should of course not be touched. |
Yes, I know. But for non-scarf seams, retracting on layer change results in best quality and 0 stringing for my filament and printer. Just a caveat for my tuning that others might also have. |
|
This is my test print with scarf joint seams activated. So, there is Z movement simultaneously with X and Y movement, and this scar almost completely disappeared. |
|
Im having the exact issue with scarf turned on. but while trying to figure out why i noticed something weird. the bulge ISNT the seam, its a move before the actual seam. ill try and explain. if you look at pic 1 i have pointed out the 2 lines. the nice smooth one is the actual seam, the huge raised one is from the nozzle diving into the part before it starts the line. i watched the nozzle do this on the print that's how i noticed it. in the slicer pics you can see for layer 335 @ 71.00. when the nozzle goes to start the line it dips down to 70.800 then ramps up to 71.000. this dip into 70.800 is what causes the big blob. it then completes the entire 71.00 circle. when it goes to start the 71.200 line it dips back down to 71.00 and makes the blob. oddly, it ONLY does this on the outer walls. not the inner. when i turn scarf off, this goes away and i get a perfect seam. this is only something recent because i've printed a lot of cylinder objects and none have ever had this with scarf before. i hope i explained this well enough to be helpful.
|
|
@AngryMammoth I've already found the git commit that's responsible for the mess. This commit tries to fix the bug where the nozzle moves through already printed stuff when it's traveling to the starting point of a scarf seam, but obviously does it improperly. |
|
@shyblower could you link it? Would be interesting to see. |
Avoid collisions with previous extrusions in the same layer when moving Z down in an XYZ move. This happens for example when starting a scarf joint after another perimeter was already printed. Fixes #7191 Co-authored-by: SoftFever <[email protected]>
|
But this is a different problem than what I described. |
|
What I showed is not that the nozzle travels through the printed material, but instead travels upwards on the spot. |
|
@dodox1 yes and exactly this is accidentally caused by the commit I've linked, but only when a sloped or spiral z-hop is done. I'm currently trying to fixing it in my own OrcaSlicer fork and will post a pull request here if I'm successful. |
|
@dodox1 It doesn't seem to become easy for me, though, to combine x,y and z travel to the scarf seam starting point in a downwards sloped movement and also prevent the nozzle from moving through already printed stuff. |
|
@dodox1 and there is still the problem, I've mentioned somewhere above, where obviously some molten filament from the previous line end gets accidentally sucked in during retraction which is spit out again at the beginning of a new line. This is not so obvious when a normal line is printed, because of the relatively large cross section compared to the start of a scarf seem line. |
|
I have also been experiencing this problem. I don't think it's due to retraction, totally if at all. I was able to reduce it by increasing jerk settings, then increasing seam gap. This is obviously the wrong solution, but it seems more likely to be something like oozing mid-retraction, and the extra volume escaping during un-retraction. retraction, in my experience, doesn't "suck" as much as it simply relieves pressure. I am confident this bug is why "outer first" is suddenly a preferred way to print like this, and what I have been forced to use, as anything else triggers the "fix" that tries making the nozzle go down a layer safely. I have an old CR-10S, and I can confirm it's happening, even with a bowden tube, and I even made a new firmware to test pressure advance, to no avail- it doesn't seem to be that, either. Interestingly, if it was just a retraction/unretraction issue, I imagine a bowden tube setup would be getting different results, but I'm seeing a very distinct, uniform bulge at the beginning of the scarf, just like a P1S. until this is solved, is perhaps the best option to rollback to 2.1.1? the 2.1.1 version, however, has a number of incompatibilities with other features... for now, scarf seam users might be best off using the 2.2 RC version. the full release had the change in its changelog, and the biggest change otherwise I can tell is the new PA calibration pattern. as for a correct way to move the nozzle down, it should begin tracing along the perimeter it's about to start printing, and then dip down along it to the intended scarf joint start without slowing. This would solve several issues;
but I might be missing something here. |
|
I just did a small battery of tests. Even with an entire millimeter of extra advance after a retract, it did nothing much. cf6d9c7 is clearly the issue, as version 2.2.0-RC produces perfect results on my 7 year old CR-10S with custom firmware. Pressure advance had no major effect on it, nor did any retraction settings or wipes, but going to version 2.2.0 release version causes the issue again. If you use scarf seams, use the release candidate for now as a workaround. I don't find any changes between the release candidate and full release compelling enough to justify broken scarf joint seams for most users. |
|
@nubnubbud I'm also quite sure it is this fix that introduced the difference in behavior between 2.2.0 and 2.1.1. When the nozzle leaves the end of a line for a travel move to the next line then a tiny bit of molten filament stays on the nozzle tip, even if it did a wipe movement before lifting off (I've observed that when the nozzle leaves an object for another wipe moves are often carried out in the opposite direction than the line was drawn, effectively gliding over still molten material). Retraction also might have sucked in a fraction of the still molten plastic underneath it, as I've already suggested somewhere above. When z-hop is done before starting the scarf slope e.g. when you print outer/inner wall order or "retract on layer change" is off and z hop height is greater then zero and also with with the fix in cf6d9c7 in any case, the nozzle is moved to the scarf slope start position in a safe distance above the previous layer and then lowered down to the start z position which is with the default of 10 scarf steps one tenth of the layer height. This flattens out the tiny drop of filament and expands it horizontally creating a blob which consequentially leads to the scar like seam. Without the above mentioned fix when your wall order is inner/outer then the nozzle gets dragged through the already printed layer because the the scarf slope starts, as described above, at a lower position than the layer height. During this the molten remnants from the previous line get completely wiped of the nozzle and no blob is produced. Also the above mentioned fix for the nozzle being dragged through the layer is not properly implemented since it only works correctly for legacy z hops but not for sloped or spiraled ones. |
|
@shyblower I disagree. I was printing tiny dense rollers, and watching. there is no room for anything under the nozzle. I don't use z-hop or anything like that, and wiping didn't affect it either. it seemed that the nozzle just stayed there, extruding or oozing or pushing out a little from a de-retraction for a moment, before starting the scarf seam from a dead stop. I never mentioned z-hops for a reason, they were never a consideration in my testing, and my suggestion did not include or consider them. if your printer is properly calibrated and your profiles are well made, z-hops should do pretty much nothing, as they exist to fight oozing and stringing from machines that don't have accurate extrusion or can't accommodate material oozing. My solution was only to make sure, that no matter what, the scarf seam began in the middle of a continuous movement along a perimeter that was guaranteed not to have any extrusion, therefore eliminating the need for advanced algorithms, z-hop mechanics, and changes to the travel code altogether. Keep It Simple Stupid. |
|
@nubnubbud then it's the additional molten filament, that gets sucked in by retraction from the still liquid end of the line and is reproduced during unretraction. That's why I could reduce the issue with a tine negative extra prime length. |
|
@shyblower ah, perhaps. I still find that suspect, but I use a bowden, so for me retraction is all about eliminating pressure in the bowden tube and eliminating oozing right at a travel. Maybe that's why you would use z-hop and I can't- for me, because mine can only reduce the residual bend inside the bowden tube, not z-hopping is how I eliminate stringing, but a faster, less spring-like reaction might allow yours to actually suck. (...in the good way.) regardless of the mechanism (though I suspect it's something along the lines of "it begins extruding for the scarf joint too early because of pressure advance taking effect before the scarf joint sets extrusion to almost nothing" or "it should be de-retracting as the move starts, not before") we can agree that it's extruding when it shouldn't, and it's because of that change, but we're not sure why. |
|
@nubnubbud and the reason why it worked so well for many people in 2.1.1 because of the issue of the nozzle being dragged through the previous layer in certain configurations which effectively cleaned the nozzle and might even have pulled out the remnants of the slightly sucked in material of.the previous line end. That's why it works again when I remove the above mentioned fix for this which is implemented in 2.2.0, and is not working correctly anyway when used with sloped or spiralled z hop. |
|
@shyblower Do you know if prusaslicer implementation is similar? That works perfecty |
|
@xantrk if PrusSlicer uses the same Implementation it's probably still working because they haven't tried to fix or even still not recognized the nozzle getting dragged through the previous layer issue. |
|
@shyblower Nice work on the tracing and investigation! Have you made any progress on the fix by any chance? Meanwhile, I pull the PR's author @fritzw in the discussion |
|
Interesting, and good detective work. I also noticed this but I didn't think to go back and check if it could have something to do with my fix. Just reverting the fix seems to be a good solution for small models, but for larger models with multiple separate perimeters (think e.g. a filament spool with cutouts in the side wall), the original behavior causes major collisions and even print failures, as the nozzle drags through the previously printed perimeters with quite some force. At least on my printer. Maybe a proper solution would be to do the downward move slightly inside the model (on the second or third outermost perimeter) next to the spot where the scarf seam should start. This would wipe the tiny blob on the second perimeter instead of the outer one, hopefully reducing the effect. Maybe additionally offsetting the move-down point 2-3 mm "backwards" (i.e. tracing the perimeter it is about to print like @nubnubbud suggested) could also help by reducing the sharp corner at the start of the scarf compared to just moving the move-down point inwards orthogonally. I hope that explanation makes sense... However, that would be a significantly more complex solution, and would require some edge case handling to make sure the move-down point is always inside the model. For example for thin walls which consist just of the outer perimeter. Not sure how a good wipe solution for such thing walls would look like. Is there a visible difference between 2.1.1 and 2.2.0 for a part that consists just of one outer perimeter (e.g. a 40 x 0.9 x 10 mm box)? |
|
@SoftFever I fear that the reason why scarf-seam used to work so well before the (with sloped and spiral z-hop not correctly working) fix for preventing the nozzle to move through already printed parts of the current layer was the fact that the nozzle did move through printed part effective wiping off the small amount of excess material it most probably picked up while leaving the end of the previous line. As I mentioned above, the reason why this tiny amount becomes so prominently visible like a scar in this situation is imho the low layer height at the start of the scarf seams slope. Honestly I've still not figured out a correct and generally applicable way of how to solve this. What I did for my own use cases, is to remove the fix and return to the previous behavior, where the nozzle moved through printed parts and disable "retract on layer change" which in turn prevents z-hopping in this situation. This of course only has the desired wiping effect with inner/outer wall order. |
|
@fritzw Well, I had several ideas. I'm not sure about the exact toolpath the code makes, but I imagine it could be turned from one angled line, to two lines- a normal travel, and a diagonal path for the last few millimeters. that's a hack though, and just lets it always be treated like it would be on small models, which works perfectly, if for a reason we don't quite know- I'm not sure it's wiping. but I keep reiterating- I really am unsure of where the extra material is coming from (and why I keep grilling Shyblower on being sure something is the case without experiments), and unlike the others, I'm not willing to guess exactly why more filament comes out by the time the nozzle has begun the ramp. it could be;
and probably some others. |
|
@fritzw @shyblower would the wipe inside before external perimeter help here? It lowers z and unretracts 1 nozzle width inside the model, then moves to the outer perimeter and starts printing. This wipes the nozzle inside the model before moving externally. |
|
This option here: #3287 |
@igiannakas Nice, that sounds like what I tried to describe. Do you know how this implementation handles features that consist only of two outer perimeters (i.e. one perimeter loop)? |
I think if I recall correctly, it will not execute for a single wall perimeter - take a look here: #3616 |
|
@igiannakas, @fritzw Yes, sounds definitely like what both of us were suggesting. I'll have to try it. |
|
@igiannakas, @fritzw, @SoftFever Unfortunately "Wipe before external loop" does not help, in fact it looks the same as if done with "correct" z-hjopping and I believe I know why. Take a look at the attached picture and you will see. I tried this with my build where I've removed the z-hop fix so that the nozzle moves through the layer as in 2.1.1. Upper: no wipe before external loop Imho it works in the upper example because the nozzle moves directly in a slope down to the start of the scarf thus effectively wiping the nozzle and starting the scarf without having to move down the nozzle in a vertical move directly over the starting point, thus not squashing any filament remnants into a blob. In the lower example, with "Wipe before external loop" activated, it does the backwards wipe move, collecting material from the still liquid end of the line, carrying it in a straight horizontal line above the scarf start, lowering the nozzle vertically and thus squashing the tiny bit of collected molten filament into a rather large blob, because of the very low height of the first scarf segment.
|
|
What’s puzzling me is how large that blob is. What does the seam look like without scarf? |
Is there an existing issue for this problem?
OrcaSlicer Version
2.2.0
Operating System (OS)
Linux
OS Version
Linux Mint 21.3 Virgina
Additional system information
No response
Printer
Bambu Lab P1S
How to reproduce
slice and print the file with "scarf joint seam (beta) is enabled
Actual results
slice and print the file with "scarf joint seam (beta) is enabled, an additional clearly perceptible and visible Z-seam is printed
with version 2.1.1 the additional clearly perceptible and visible Z-seam is not present
Expected results
No clearly perceptible and visible Z-seam at this position
Project file & Debug log uploads
test_v2-2-0.zip
Checklist of files to include
Anything else?
The text was updated successfully, but these errors were encountered: