Cura: Print Quality issues

[dertbv]

Application version
Release 4.7

Platform
OSX

Printer
(Which printer was selected in Cura?)SV01 running klipper

Reproduction steps

1. Printed standard benchy compared to standard benchy in 4.6.2
2. confirmed all settings are identical between old software and new

Screenshot(s)
Image on left is 4.6.2 image on right 4.7

Actual results
alot more stringing and blobs on the bow.

Expected results
at least as good as old software.

Log file
(See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)

4.7 cura.log
4.6.2 cura.log
Additional information
(Extra information relevant to the issue.)

[nallath]

It's very likely because of a bug caused by a speed improvement in the profile reading (since I see those issues in the log)

You can check the solutions on https://github.com/Ultimaker/Cura/issues/8235 and https://github.com/Ultimaker/Cura/issues/8230 Could you validate if these solutions for you work?

Unfortunately, this wasn't caught by the BETA, and we weren't even aware that the syntax was being used by some people.

[dertbv]

If this is related to octolapse i have completely removed the settings and still show the blobbing on 4.7. i have done a comparison of 4.6.2 and 4.7 with and with out octolapse and the issue still remains. 4.6.2 prints near flawless while 4.7 does not even come close. pictures are with out octolapse settings using the same profile. Left is 4.6.2 right is 4.7. both were printed this morning
\

[Tikiman777]

Running into the same issue with the z seam blobs on the bow of the Benchy. Not using octoprint at all. I imported my profiles from 4.6.2 into 4.7, and the quality has changed significantly.

[Ghostkeeper]

You erased the "Project file" header from the bug template. Please submit a project file here where it's going wrong. It's very relevant here.

SV01 is a new printer profile in Cura 4.7. How could you slice with that profile in Cura 4.6.2? The relevant part of which profiles were loaded is sadly cut off from the snippet of the 4.6.2 log you posted. Perhaps you could submit the log file just after running 4.6.2?

Your 4.7 log file contains a number of errors that could be the result of modding Cura. It complains about the support_bottom_enable setting not existing, while it does exist in the normal Cura distribution. This could be the result of having an = symbol in the start or end g-code; something that's fixed in 4.7.1 now. If you had submitted a project file and this is the issue, we can provide you with a workaround.

You say that all of the slicing settings are the same, but they are not. Here is a diff from what I've gathered from your log file:
diff-to-4.7.txt
Aside from a number of irrelevant settings, the Z hop is disabled in 4.7 which could be causing this sort of issue.

When looking at issues like this, we obviously can't reproduce your print, not without the same filament and the same printer, and I don't have every filament and printer in the world around. So if there is something wrong with the g-code that Cura produces, we'll need to know what is wrong with the toolpath, not what is wrong with the print.

[dertbv]

SV01 is a new printer profile in Cura 4.7. I had created the profile by hand.

Your 4.7 log file contains a number of errors that could be the result of modding Cura. It complains about the support_bottom_enable setting not existing, while it does exist in the normal Cura distribution. This could be the result of having an = symbol in the start or end g-code; something that's fixed in 4.7.1 now. If you had submitted a project file and this is the issue, we can provide you with a workaround. Start and End Gcodes are START_PRINT and END_PRINT, what i d find interesting is when the profile was brought over it removed my retraction settings as shown in your diff. I have placed back the settings

4.6cura.log
4.7cura.log

renamed to TXT files to allow attachment
4.6.2 .curaprofile.txt
4.7.curaprofile.txt

**

You say that all of the slicing settings are the same, but they are not. Here is a diff from what I've gathered from your log file:
diff-to-4.7.txt
Aside from a number of irrelevant settings, the Z hop is disabled in 4.7 which could be causing this sort of issue. Z Hop is disabled in 4.6.2 and enabled in 4.7. I have disabled it to see if it made a difference. it did not.

When looking at issues like this, we obviously can't reproduce your print, not without the same filament and the same printer, and I don't have every filament and printer in the world around. So if there is something wrong with the g-code that Cura produces, we'll need to know what is wrong with the toolpath, not what is wrong with the print. I understand how hard this is. i appreciate the effort. I have wiped both log files and created new ones from scratch. I have also pasted the cura profiles for you to look at from each.

[Ghostkeeper]

I had created the profile by hand.

Something is broken with it. Maybe the file names are the same as the new files that were added for SV01 in 4.7? That could cause print quality profiles like this, because it can give a mixture of setting values from multiple profiles.

renamed to TXT files to allow attachment
4.6.2 .curaprofile.txt
4.7.curaprofile.txt

Those .curaprofile files are not project files. You can create a project file by going to File -> Save in 4.6 (or File -> Save project in 4.7, but just a file from 4.6 should be enough). These files don't show changes to the start g-code or end g-code because they are seen as changes to the printer itself.

[dertbv]

here is the file you requested renamed with txt to upload

4.6.2project.3mf.txt

[Ghostkeeper]

Hmm, I don't see any significant differences between 4.6.2 and 4.7 when I slice that project file with an added 3DBenchy. The resolution is slightly higher in 4.7 and more consistent. Maybe that would cause buffer underruns, but that would manifest as blips, not stringing.

It's still retracting and retracting the same. Speeds and flows are the same as far as I can see. I wouldn't know why one of them gives stringing but the other not. Unless your SV01.def.json in 4.6 is different than mine (I copied mine from the 4.7 release).

[Ghostkeeper]

You didn't happen to print the stringing print on a very hot day or something?

[dertbv]

they were printed one after another multiple times during the same day. I am using the same json file as you. not sure buffer over runs would apply as i am running klipper. so it looks like it is more klipper related? not sure how since the settings are the same. I am at a loss myself. Can you send me a copy of the GCODE you created with your settings and i can do a test of that. However i have run out of the filament i was using so i will need to load up a new spool. i will also do another side by comparison with a new spool of filament once i get it dialed in.

[dertbv]

ok i have dialed in the new spool. i deleted all settings from both 4.6.2 and 4.7 this caused me to have to re add the printer in 4.7 as a new install. then i imported my settings profile. I no longer have any stringing in the 4.7 print, however i still have the blobbing on the front hull as in the pictured above. I am now using a black filament so they are harder to see but they are there. It appears doing the upgrade from 4.6.2 to 4.7 something is not caring over correctly causing the massive stringing. now i am just looking at the blobbing issue. and yes i attempted to print the new filament with 4.7 before i blew away all settings and had the stringing.

[gluap]

I'm watching this issue because I thought I might have seen something similar (only the blobbing, not the stringing though) when upgrading to cura 4.7 on my ender 3 (which also runs klipper).

@dertbv do you still have the klippy.log files from a failed print? (and even better also a succsessful one)? Octoklipper keeps a few of those around and allows you to analyze them, it can for instance give indications for or against a buffer underrun scenario. Unfortunately my octoklipper does not have the logs from the the print where I thought I had observed the issue any more. A quick log analyzer can be found in the Klipper tab in octoprint (called "performance graph").

[dertbv]

Here you go

[gluap]

@dertbv I would suggest to also keep the log file itsself around for future inspection.

Most graphs for severe buffer issues people post seem to show a larger values for "host buffer" for a longer time intervals than you show. On the other hand spikes might also be filtered out because you are zooming at a long time interval (or my lacking knowledge of interpreting the graphs that i gathered from scrolling through the klipper issues doesn't allow me to interpret it correctly). I can't help out with much detail what to read from the graphs myself but I know that this is the go-to-logfile to diagnose buffer underrun issues so it will make sense to keep the graph and the logfile around. Especially since @Ghostkeeper mentions

The resolution is slightly higher in 4.7 and more consistent. Maybe that would cause buffer underruns, but that would manifest as blips, not stringing.

Which I think describes what you observe and what seems to have been an issue for people printing with klipper/octoprint in the past.

There is anecdotal evidence for it appearing as a result of cura version updates:
https://www.reddit.com/r/klippers/comments/gf304z/is_it_common_for_klipper_prints_to_pause_like/

Or discussed on the klipper issue tracker for instance here:
https://github.com/KevinOConnor/klipper/issues/2792

"virtual sd" seems to be widely considered a fix but doesn't explain why this should suddenly happen with a new cura version for a model that was fine in the previous version.

[Ghostkeeper]

The algorithm to reduce the model resolution was reworked in Cura 4.7 and we've seen some differences. On the whole the new resolution seems to be about the same (within 10% margin). But it could be that for some models it changed more. If this is a problem, it would be fixed by slightly increasing the Maximum Deviation or Maximum Resolution settings.

[dertbv]

i tried changing the max deviation to .05 last night with no change. Current settings for max resolution is .5, what would you suggest these settings to try?

I am not seeing the pauses that are referred to in the previous post however i am going to try the virtual sd setting for klipper.

[dertbv]

i tried changing the max deviation to .05 last night with no change. Current settings for max resolution is .5, what would you suggest these settings to try?

I am not seeing the pauses that are referred to in the previous post however i am going to try the virtual sd setting for klipper.

I have tried the Virtual Serial settings and still showing the issue.

[Ghostkeeper]

The resolution of the g-code is limited by both the Maximum Resolution and Maximum Deviation. You've tried adjusting the Maximum Deviation, but not the Maximum Resolution, so that could still be causing the problem. How about 0.75mm?

It's pretty much impossible to debug this issue for us unless we know what's really wrong with the g-code that Cura is generating. Is there a G1 that has too much extrusion, or stuff like that. After the firmware interprets this g-code there are too many variables for me to reliably guess what could be causing your print quality problems.

[dertbv]

Tried adjusting to .75 still showing the same issue.

[Greathouse2005]

Im having the same issue and when printed in 4.6 the issue is gone... it affect all of my printers 5 in total... all with the same files sliced for that printer.... and then redone with 4.6... they look like pure poop. everything else is great with dimision and all just the blobes... looks like seams but they aren't....

windows
ender 5 pluses and ender 5s
all with sky 1.4 turbo tms 2209s uart

[Sebazzz]

Blobs seem to be related to #8372 and #8321

[nallath]

Closing this as a duplicate of #8321