[BUG] Firmware 3.9.0-RC1 print quality degradation compared to 3.8.1

[nikkolade]

Printer type - MK3S Printer firmware version- 3.9.0-RC1 MMU Upgrade - MMU2S **MMU upgrade firmware version 1.0.6

Describe the bug

Print source: https://www.thingiverse.com/thing:3494496 and explicitly: https://www.thingiverse.com/download:6386081

While printing the above STL sliced with PrusaSlicer 2.20-RC2 and using PETG material works just fine when using the MK3S firmware 3.8.1 (build result on the left), the very same gcode results an awful quality after the printer was upgraded to 3.9.0-RC1 (end result on the right). Please, see the attached picture.

To Reproduce Upgrade firmware MK3S firmware to 3.9.0-RC1 and print the above mentioned STL file.

Expected behavior The print quality should not degrade, compared to previous firmware version.

[wavexx]

Could you post the 3mf file saved by PrusaSlicer using the same settings you used to print it? Also posting the gcode itself would help so we can have a look.

[nikkolade]

Sure, here is the 3mf file.

3mf.zip

[nikkolade]

And the gcode gcode.zip

[vintagepc]

Hm... have you tried re-calibrating your linear advance K-value with 3.9.0? I'm not saying the default shouldn't work fine, but I'm curious whether calibrating for the 1.5 K-value makes the issue go away.

[nikkolade]

No, I haven't. What is the proper way to run the linear advance calibration ? My printer is currently busy for the next 12 hours, but I can certainly try this out after it's idle again.

[leptun]

You can find instructions on what Linear advance is and how to calibrate it here: https://marlinfw.org/docs/features/lin_advance.html You are looking for LA 1.5.

[vintagepc]

FWIW, I hadn't paid it much mind but since you are also using PETG... I've noticed my PETG prints are also a little sloppier in terms of strings, sags and zits, but nowhere near the picture levels of bad. I initially ascribed it to wet filament but a fresh roll last night didn't show any improvement, so there may be something to this issue. I'll also try running an LA1.5 calibration for PETG next time I load it up. PLA's been fine so far.

[DRracer]

@nikkolade thanks for reporting, this is a serious issue and we must solve it before the 3.9 final goes out. Could you please do the LA15 calibration test as @leptun proposed? We are especially interested in the "correct" K-factor you get (a photo of the whole print sheet with calibration lines will be great).

[nikkolade]

calibration.zip

I don't know what is the problem with this particular calibration, as I only increased the temp to 210C and changed some filenames, but for some reason the included gcode crashes the printer right after the initial bed calibration. Therefore I was unable to print anything with this test. I tried a few times from octoprint and from SD-card, didn't matter at all.

[vintagepc]

I used that code/page recently for flex, so the gcode should be okay.

I see you have an MMU. There's a known bug if you try to extrude with IR=1 and FINDA=0, or a runout detected with a "?" on the screen for the filament. (Fix is pending merge)

Try doing a load to nozzle first if you haven't already done so - the gcode does not have the MMU single mode Tx/Tc commands that prompt filament selection.

[leptun]

@nikkolade Just tried the gcode on a MK2.5S without MMU and there was no crash. It is as @vintagepc said.

[nikkolade]

Yes, manually loading to nozzle first allowed the test to be executed. Of course the PLA-filament I used is clear, so the end result is slightly difficult to see. I can certainly run it again with for example white PLA or some PETG if needed.

[leptun]

The calibration is technically filament specific, so you might want to use the orange PETG for the calibration.

[vintagepc]

Also, you're going to want to run a lot narrower range. Your 0.1 line is already showing overextrusion at the start of the fast section, and it just gets worse. Try something like 0 to 0.2 with 0.02 steps instead. (I think the default range of up to 2 is targeted at bowden setups, which require much higher K values) What you're looking at here are the transitions from slow to fast and back again - ideally you should have some that are too fat at the start of the fast segment, and some that are too fat at the end, to show you've got some values on either side of the correct one. You want the most uniform line you can get, it should not be possible to see where the fast travel part starts and ends.

Hope that helps clarify what you're looking at. You might need a few cycles to narrow down the right range of values to test.

[nikkolade]

Ok, yet another test result. Any tuning suggestions after this ? Although, the numbers are somewhat missing, this one is in the range of 0 -> 0.2 as suggested.

[DRracer]

@nikkolade looking at your calibration print I'd say the best K factor is 0.08. S far we've been using 0.12 AFAIK. Now please take your g-code and search for: M900 K45 ; Filament gcode Change it to: M900 K0.08

Save and run a few centimeters of your container print to see if there is any difference. We'll be doing similar tests at Prusa HQ tomorrow.

[vintagepc]

.08 looks pretty good to me - Edit your custom filament g-code for the orange PETG and change the K value for the M900 command, e.g. M900 K0.08

Then try your original print again (be careful you don't revert the K change if you re-open the 3MF file!)

You can probably skip doing the whole print and just cut out a chunk of it or stop a few cm in where the issue would have manifested itself Edit: Aha, ninja'd by @DRracer :-)

[nikkolade]

Ok, I'll let the printer try again with the modified gcode. Let's see if the end result is equal to FW 3.8.1 this time. I'll let you know latest in the morning.

[Panayiotis-git]

I would definitely use a smooth PEI sheet to determine the K factor. :smile:

[nikkolade]

Ok, the K0.08 value modification improved the end result a lot!

[vintagepc]

Interesting, and good to know. I'm guessing that's Prusament PETG?

I'll spot check my Overture (AKA former Amazon) PETG tonight and see if I get a similar value or if it's closer to 0.12.

[DRracer]

@nikkolade interesting result, please let the print finish if possible for detailed comparison with the one printed with FW 3.8.1 Btw. how old is your nozzle - i.e. how much filament did go through (roughly)? @vintagepc please do a LA15 calibration on your machine too @wavexx @leptun FYI

[vintagepc]

Will do. Current print is finishing in about 20 minutes. Will post pictures of the plate.

[vintagepc]

Results are in. For me, PLA @ 210C (red) comes in best at 0.04, PETG@235 (black) also at 0.08.

I do have a Skelestruder but the gear->nozzle distance isn't as different from stock as it used to be; the 3S revision shortened that a bit; so my values might be a smidgen lower than expected. (FWIW I was running 20 for PLA and 35 for PETG in LA1.0, but those were not calibrated at all and just going off a generic comment that I could drop the Mk3 values by ~10. )

[nikkolade]

The print is now complete and there seems to be still a big difference with the latest 3.9.0-RC1 and the older 3.8.1 versions. The print looks much better from the front after the K-value change. However, the lefthand side of the print is still much more worse than the other sides.

The filament is Prusa PETG, not prusament. All my filaments have been dried every once in a while, so they are not wet. The printer itself is originally of MK3 model and it has been delivered on December 2018. It has not been used heavily though as there has been occasionally months between the prints. I quess 3-4 complete rolls and half a dozen non-empty rolls.

.

[DRracer]

@nikkolade oh, this is interesting - it looks like some error is being accumulated after those many retractions. @wavexx what do you think?

[vintagepc]

I don't think that's K value related anymore. The parts that are not clean (esp. right under the thicker bands) all have a very "melty" look to them, like there is not enough cooling. Notice how it "shrinks" inwards instead of just being extra ooze attached to the exterior of the part like previously. This seems even more likely given the front of the print is reasonable and the sides have issues

@nikkolade Has your filament been sitting out in the open for a while? PETG absorbs moisture and that can produce symptoms like we are still seeing. How much time elapsed between the print you made on 3.8.1 and the reprint with the RC firmware?

[nikkolade]

I did the two prints after each other, ~8h difference. The latter one was using the FW 3.8.1 and the same roll of PETG, so the FW3.8.1 print should have had the quality issues, if it would be caused by moisture in the filament.

I have a food drier and this particular roll has been dried 2 days ago. After drying, the filaments are kept in a ikea samla plastic box that has been "sealed", together with silica gel pouches (a lot of them, also recently dried).

I bet that I can print again one of these containers with the older 3.8.1 and using the same filament roll and they will still look good.

[leptun]

@wavexx Does LA1.5 slow down acceleration even when just Z and E moves are done? Maybe these are slower with LA1.5 compared to LA1.0 which didn't take Ejerk into account.

[vintagepc]

I'll give part of the print a go today on my own setup to see whether I also have the same artifacts even with a corrected K-value. It won't be completely conclusive but very informative as to whether it's heat related.

Edit: Hooboy, this print is a good retraction torture test.... :-)

[vintagepc]

Print still in progress, but quality is indeed abysmal. Part of the problem is the thin vertical sections flex quite a bit, which also results in uneven sides and stringiness. Will edit in a picture when it finishes. I am experimenting with tuning cooling/temps to see if I can get an improvement.

[vintagepc]

Update: I think this is indeed compounded by a cooling issue. Not sure why that would have changed from 3.8 to 3.9 though.

I printed a shorter part but the results are similar. It looks like the worst parts of the print for me are those that are shielded somewhat by other print parts, whereas the best ones are most exposed to the cooling fan airstream. Part as printed on the bed:

I made tuning adjustments as the print progressed: -> No changes until halfway up the first course of spindles -> Dialled back temp to 230 (from 235), increased fan setting to 110 (from 76) halfway up the first stage -> For the second stage of spindles, I dialled up the fan to 200, flow to 95%

Picture of the cooling duct:

Additional part photos:

[wavexx]

It always looked like a cooling issue to me more than LA itself, but given a higher K factor will lead to slower jerk the issues are probably connected. These thin features will overheat quickly.

The gcode is resliced already at E-jerk=4.5, which looks good. Did you change it yourself? I also see Tx/Tc gcodes which I didn't see before.

To respond also to @leptun, any move which is not involving extrusion is not changed by LA (so wipes/jumps shouldn't be affected).

For the stock Prusament Orange I do use K=0.12 at the default temperature of 250C. For the "Prusa clear PETG" which I use at 240C ("generic pet" profile) I've set up a K=0.13 even. It depends a bit.

I'd love to try this, but I'm currently restricted in movement for this covid19 thing, so huuh, it's a bit hard to test stuff. I don't have PETG at the moment :/

I'd try two thing out of my mind:

• reduce retraction length: the default is 0.8, I'd go for 0.5. I know it sounds counter-intuitive, but if the LA factor is properly tuned there's generally a lot less pressure left at the end of the extrusion. Some retraction is still needed to avoid ooze, but reducing it will reduce the time spent on small features like these.

• bump E-jerk even higher. In machine-limits, in "maximum jerk E" try to increase to something much higher, like 8. This is not a solution in itself, but it will increase acceleration overall which is useful to see if results in an appreciable difference.

[vintagepc]

reduce retraction length: the default is 0.8, I'd go for 0.5. I know it sounds counter-intuitive, but if the LA factor is properly tuned there's generally a lot less pressure left at the end of the extrusion. Some retraction is still needed to avoid ooze, but reducing it will reduce the time spent on small features like these.

FWIW my default retraction is 0.4. I'll up the E-jerk in the .gcode file and reprint to see what happens. Also, I had similar strings and crap on larger full-bed prints where localized part heating should not have been an issue.

[Kachidoki2807]

Not sure how it can help, but I just gave a try to the K-factor calibration with Stratasys Blue ABS-M30. I got the best result at 0.04 on a MK3s.

[nikkolade]

As I happened to have some use for an additional silica gel container, I printed with the same original PETG filament roll & FW 3.8.1 the following items (75mm size this time) and the end result is very good in my opinion. There is certainly some tuning to be done for the upcoming FW version before it will produce the same quality out of the box.

[vintagepc]

No improvement changing the E-jerk to 8.

I had a go at trying to back out LA1.5 from the current RC to confirm if it is the origin of the difference. Alas this introduces a few compile errors I'm not easily able to resolve without slogging through the history of those changes.

[wavexx]

On Thu, Mar 19 2020, vintagepc wrote:

I had a go at trying to back out LA1.5 from the current RC to confirm if it is the origin of the difference. Alas this introduces a few compile errors I'm not easily able to resolve without slogging through the history of those changes.

You can set K0 to disable LA completely. This will generate some overextrusion on the corners, but this would help determining if LA can be the source of the issue

[vintagepc]

Well, the simplest solution... :tada:

Anyway, print in progress. Looking good so far...

[vintagepc]

Well, I think these pictures speak for themselves. (I cut off just a segment to speed up the testing)

[wavexx]

Is this comparable to 3.8.1 all-else being equal?

[vintagepc]

I don't have a 3.8.1 reference to compare it to but it looks very much like the OP's 3.8.1 print in terms of stringing/quality. Slicing settings are identical to the lower half of my other print; only difference here is M900 K0 instead of K0.08

If it's beneficial I can compile 3.8.1 for my printer and try the same g-code tomorrow. (Can't use official release as 3.8.1 doesn't have #2306 and my setup seemed to hit that last time I flashed back.)

[wavexx]

I'm going to try to reproduce the issue (or at least try to see if I can notice a difference) using regular PLA. At this point it's either still too much e-jerk influence or there is some odd overextrusion going on that hopefully I should be able to spot with PLA

[vintagepc]

That sounds quite possible - Observing the previous prints most of the stringing and junk is from PETG that has crept up the sides of the nozzle and is being dragged around partially sticking to fresh bits that get laid down.

[wavexx]

Indeed, once some petg starts sticking to the sides of the nozzle it's going to stick it everywhere until a long extrusion cleans it all up (in this case the rings)

[vintagepc]

Yeah, and that's with a Ni-plated nozzle too, so it strings off in chunks more easily than brass.

Overextrusion certainly explains the meltiness, since if you're adding extra plastic, you also add more heat that needs removing - which is why cranking up the fan helped quite a bit. The test part wasn't flexing nearly as much while the spindles were printing.

Edit - if you don't have PETG and PLA doesn't reproduce it... maybe flex, if you have some? I was having terrible issues getting a clean print out of that too... which, in retrospect could be related to the same issue, since one of the things I tried was setting up an LA value... https://forum.prusaprinters.org/forum/original-prusa-i3-mk3s-mk3-how-do-i-print-this-printing-help/suggestions-for-printing-this-in-flex/#post-200217

Don't hesitate to let me know if you need me to test anything. I'm also stuck at home and have an ample stash of filament. :-)

[leptun]

In the early days of the LA1.5 for the Mk3 I also notices some cases where overextrusion would occur. It’s mostly with really small segments. The place I encountered it was with some infill that was filling a small gap between perimeters on the first layer. This kind of overextrusion will most likely cause degradation in quality. Please note that it manifested a long time ago and the issue is probably fixed in this case, Also, I was testing Simplify3D for this.

I also think that the “corners” of a solid infill (when it finishes and makes smaller segments) got worse with LA1.5. This is a recent print, so it's the latest LA1.5 implementation. (colored with blue in the picture):

[leptun]

@wavexx Was the K0 compatibility issue fixed or does it still lock to one value or another? It would be best if all these tests were done without this kind of issue since it would most likely create false results with calibrations.

[wavexx]

@wavexx Was the K0 compatibility issue fixed or does it still lock to one value or another? It would be best if all these tests were done without this kind of issue since it would most likely create false results with calibrations.

Is there an explicit # for this issue? I opted to use K-1 as a manual "reset". The reset is still done between SD prints, and I would love to implement "print timers" to have an extra hook to reset stuff between prints when using a host (see https://github.com/prusa3d/PrusaSlicer/issues/3724)

K0 still disables LA, but without the mode reset. The reason is that slicer++ (supermerill's fork) allows to customize the K factor by fill-type, so for example you can decide to disable LA during infill. Resetting the mode on K0 could introduce random swaps during the print, which I think is worse.

[leptun]

If the gcode starts with a K0 and then swithches to another value, will the compatibility be locked because of K0 or will it switch accordingly when K0.01 (LA1.5) or K5 (LA1.0) are seen later?