Regression on 2.2.0 causing underextrusion

[philip-soerensen]

Is there an existing issue for this problem?

• I have searched the existing issues

OrcaSlicer Version

2.2.0

Operating System (OS)

Linux

OS Version

Arch Linux

Additional system information

No response

Printer

Ankermake M5C

How to reproduce

0. Start with an install of Orcaslicer 2.2.0
1. Setup an Ankermake M5C with 0.4mm nozzle using the unmodified preset profile
2. Choose a preset filament profile (confirmed for "Anker Generic PLA+" and "Anker Generic PETG")
3. Slice any model (defect is most apparent in prints with many starts and stops such as ones with fine separate structures)
4. Send the gcode to the printer through any method and print

Actual results

Serious defects, similar to under extrusion, appear whenever the extrusion restarts after travel.
After some millimetres or centimetres, the normal flow appears to restart, but the first few mm will be barely extruded if at all. This ruins the print quality to the point of breaking, although the print may still complete.

Expected results

A nice print without defects, as seen in V2.1.1.

Project file & Debug log uploads

Project file:
project_file.zip

I don't think there is anything interesting in the log since nothing is visibly wrong in the slicer, only in the printed object.
Nevertheless, it is attached here:
debug_Sun_Dec_01_22_09_38_31951.log.0.zip

Checklist of files to include

• Log file
• Project file

Anything else?

The problem is specific to V2.2.0. The problem is resolved by using V2.1.1 with the same settings (as far as I can tell). Here is a comparison with a test print done on the two versions where the regression is clearly visible in the V2.2.0 version:

Here is a closeup on a bigger print showing the defect in more detail:

The problem has been reported by other users (also printing on Ankermake M5C as far as I know) and I have reproduced the behaviour with a fresh install of Orcaslicer on a completely different computer. I have also confirmed that it appears with several different filaments (both PLA+ and PETG). The fact that the prints are perfect when sliced with V2.1.1 or with any other slicer confirms that there is nothing wrong with either the filament or the printer itself.

[staal54a]

Have you tried looking through the resulting gcode files for the same object from both versions to see if there is any noticeable difference in some of the extrusion values being used? The only other step I would recommend is to definitively go in and verify if there are any settings differences between the profiles in the different versions via side by side comparison of the settings.

I tried to recreate with your steps in each of the versions called out using one of the retraction tests with the four square columns and didn't see anything that would majorly jump out in the gcode to me but I also don't have an M5C so I couldn't print them.

The main reason I'm potentially interested in this ticket is it sounds like there could be some overlap with this ticket related to wide seam gaps: #6378

The issues with restarting after retraction seams to be a common theme between these two bugs so it may be somewhat related.

[Xelinor]

@SoftFever it looks like a change was put in here:

296b234

Why was this change made? Those settings are not what was intended and validated with the rest of the profile, and I suspect this is what is causing the regression.

I haven't had time to check against other settings, so maybe there's other changes too?

[philip-soerensen]

I have just confirmed that regression was caused by the change highlighted by Xelinor above.
Print quality is restored by going to the printer settings -> motion ability menu and setting everything back to the v2.1.1 values.

Here you can see the settings that caused the problem:

[philip-soerensen]

By the way, staal54a, we discovered the changed settings because you prompted me to put the gcode through a diff tool. So, thanks for your comment! Unfortunately, this seems to be isolated to the Ankermake profiles, so I guess it won't help you with the issue you quoted, although the symptoms are similar.

[robertbaker]

The M5 doesn't have this problem.
Compare the values yourself in anker's studio by adding a M5 and looking at the values compared to the M5C. I provided screenshots showing the values in Anker's Studio 1.5.24 (latest as of writing)

M5:

M5C:

M5:

M5C:

M5:

M5C:

M5:

M5C:

[robertbaker]

https://github.com/ankermake/AnkerMake-PrusaSlicer-Release/blob/main/AnkerStudio/resources/profiles/Anker-ini/AnkerMake%20base/base.ini

[Xelinor]

@SoftFever it looks like a change was put in here:
296b234
Why was this change made? Those settings are not what was intended and validated with the rest of the profile, and I suspect this is what is causing the regression.
I haven't had time to check against other settings, so maybe there's other changes too?

This change was made because it didn't match the latest values provided in AMS.

This issue does not happen on the M5. reverting the values would artificially limit the M5 just to fix the M5C. Not sure why the M5C has an issue since both values are the same between the 2 in anker's slicer. Which makes me think this change exposed a different problem with the M5C.

Your assumption is that it limits the M5, which is incorrect. The M5 ignores a lot of gcode commands that the M5c does not, which is what is actually going on here. Anker does a lot behind the scenes with that machine that amounts to a lot of smoke and mirrors, like putting in artificially high jerk limits. If you actually do Jerk testing with the machines, like I have, you will find that the belt tension can't handle those settings and it needs to be set lower, which is one of the things I did when I overhauled the settings in Orca a while back. We did a LOT of testing and validation when we came to those settings, and we did it on both the M5 and the M5c. The M5c accepts quite a few standard marlin commands that the M5 ignores, which IS what is happening here.

In the end, changing it to what Anker claims is the machine limit doesn't really make sense anyway. The M5 is limited by its hot end.

The M5's volumetric flow rate, at best, is around 18mm³/s. You can get it higher by printing well over the tolerances of the material you are printing, but you will suffer in ability to retract material and so print quality basically goes to hell. At 18mm³/s, you are NEVER hitting anywhere close to the machine limits Anker claims the M5 can go to in those limits, so it simply didn't make sense to bring them along.