[bugfix-1.1.x] Still having issues with bleeding corners

[ikarisan]

Since Marlin 1.1.8 (bugfix-1.1.x) I have issues with printing 90° corners. One day the problems were gone but now they are back again. As far as I remember I placed an bug report a few month ago...

Setup:

• Marlin bugfix-1.1.x (05.Feb.2018)
• MKS Gen 1.4
• Anet AM8

TMC2130 on X, Y and Z Current: 700mA for X/Y, 650mA for E LinAdv: 75.0

As you can see at the photos, the most of my 90° corners are bleeding out.... As reference I have a photo of an STL that was printed a few weeks ago.

And now the "old" results:

Configuration.zip

[thinkyhead]

Try re-tuning your linear advance K value.

[thinkyhead]

Also, try #9379

[ikarisan]

Closer look.....

[Sebastianv650]

I was using an early version of Marlin 1.1 a very long time with my LIN_ADVANCE, and as with your old pictures I had no problem. Since I upgraded to 1.7 or 1.8 because I wanted to test a change to the planner I also got random problems. I never found the reason, there was no real change to the planner since 1.1 but new Marlin versions are definitly not playing nice with LIN_ADVANCE any more. That was the final thing that lead to my decision creating a new and better version. All I can offer at the moment is try my new (alpha? beta?) version @thinkyhead linked to, or stay with your older working one until I got it to some gold status.

Maybe something is disturbing the ISRs too much.. Which version was the one which worked for you until the upgrade now?

[ikarisan]

@thinkyhead and @Sebastianv650 : What I can say is, that it seems not be a LIN_ADVANCE problem. Printing with K=0, K=50 and K=95 always produces these "nice" corners. And as you can see, not every layer is affected and most of the time only specific corners are having these distortions while the others are prefect. And there are always bulges near the next 90° corner. Is K=0 really the same as a not defined LIN_ADVANCE macro, as mentioned in the configuration_adv.h file? I guess not, because the are many #if ENABLED(LIN_ADVANCE) and #if DISABLED(LIN_ADVANCE) code blocks within the planner.cpp and stepper.cpp files.

The last version that worked?! Hmmmmm... 1.1.6 worked with the stock Anet A8 board and the MKS1.4, together with A4988 drivers. And some bugfix-1.1.x (based on 1.1.8) versions worked, while the final 1.1.8 didn't. The problem is that I didn't make a note of the GIT hash that worked for me. I thought that the problem has been solved but now it's there... again. :(

[ikarisan]

Update: Disabled LIN_ADVANCE and the result is still the same :(

[Athemis]

Do you use a heated bed? I suddenly had similar defects on my prints as you showed above and they happened to coincide with cycling the bed on and off during the print. Turned out to be the stepper motors picking up some noise from the headbed switching on and off. All defects were gone when I switched off the heatbed. What ultimately solved the issue for me was switching the heatbed control from bang-bang mode to PID.

[thinkyhead]

is K=0 really the same as a not defined LIN_ADVANCE macro?

Yes, it is. LIN_ADVANCE is essentially a shift or compression of the timing of E moves relative to the other axes. When K is set to 0 the timing of E steps is proportional to the other axes, just as with LIN_ADVANCE not compiled-in.

[ikarisan]

@Athemis I am using PID for both, bed and nozzle.

@thinkyhead Okay. :) But even with the latest version (acb4dba7cd0b33da41bc148d1361ac407816d173) my 90° corners are still having these blobs. :(

[slingel]

Running the same setup as ikarisan, same problem. Noticed right away when I migrated from the Anet board. Played with linear advance on/off and acceleration and jerk. Does not help at all. I'm not getting the ripple effect though.

[FreeLuck]

Same problem, in particular the last 6 closing layers.

Setup: Marlin bugfix-1.1.x (18 Feb 2018) Linear advance OFF For bed and nozzle I'm using PID Anet v1-5 board Anet A8

[thinkyhead]

I'm thinking hard about it, but the solution hasn't come yet. Marlin did get some changes to its acceleration, jerk, and block chaining code in recent months, but nothing too grave. And this effect is very subtle. At best we might try reverting these portions of the code and see what changes. I hesitate to float any further theories without deeper testing.

[monotype-darren]

I've seen the same thing with 1.1.8. I rolled back to 1.1.5 and the problem is gone.

[ikarisan]

@FreeLuck and @slingel Thanks! And I thought I am the only one :) @monotype-darren Do you use an Anet A(M)8 printer, too? For me, rolling back to 1.1.6 helped.

@thinkyhead What portions of code you are talking about? I would test a "special" branch if it will work with my current UBL and the TMC2130 drivers.

[monotype-darren]

@ikarisan Actually, I noticed the problem on a Creality CR10. I hit the problem when printing some in-place parts. Joints were fusing in spots in v1.1.8 where they didn't in v1.1.5. At first I thought it was overextruding, but extruder calibration was spot on. Rolled back to v1.1.5 and all was good again. Thinking maybe hardware specific, took a different machine to v1.1.8 and had the same issue. Looked closer at the prints and noticed the bulging corners.

[Sebastianv650]

So we have 3 appearance of the problem, but I'm not convinced all have the same problem. Let's see..

@FreeLuck: How many solid top layers this print had? @monotype-darren: Do you have a detail picture compaing the two FW versions?

At all three (@ikarisan), can you provide an as simple as possible gcode which triggeres the problem? For example a 20x20x10 test cube without any infill and a single perimeter would do the trick? Do you have some sort of bed leveling enabled?

Why I'm not convinced, but might be wrong:

• @FreeLuck print looks good except the top layers. If the amount of affected layers equals the amount of solid top infill layers, I would blame slicer settings.
• @ikarisan print looks like prints I got from Cura. The reason was that Cura decided to change the print direction from clockwise to counter clockwise in some pattern. Due to pressure differences, the start and end of a line will always look slightly different and when the slicer switches the print direction so that start and end will be placed above each other you get that pattern..

[thinkyhead]

@Sebastianv650 — With these things appearing after 1.1.5 or 1.1.6 I'm getting the feeling it's due to changes in the block chaining code. There were a couple of pretty interesting ones. I would like to try reverting those and post a branch for testing.

[FreeLuck]

@Sebastianv650 The cube has 6 closing layers but I do not think it is the slicer (Simplify3D) because with the original firmware I had no problems, there are several changes to now with bowden but otherwise the print is very good and I do not see why only those layer I should have some problems. I have not tried previous versions of Marlin for other bugs, corrected in bugfixes, but this is confirmed by the other users that with 1.1.5 or 1.1.6 this problem does not exist. The cube is printed with bowden: PLA 200C°, layer 0.2 100mm/s, first layer 25-30mm/s, travel 120mm/s and leveled bed 3dtouch at 60C °.

Other test with same setting but only 2 top/bottom layer same problem.

While the Mistral fan print the problem is not noticed, some imperfection due to my fault for the support :), same speed, layer 0.15, 8 layer top/bottom.

This problem is a bit strange and particular... :(

[Sebastianv650]

@thinkyhead yes, everthing bringing us forward is good.

@FreeLuck I think I'm able to "solve" the problem. Please provide the gcode from the faulty cube and I'm very sure I can point out the lines of gcode creating this visual artefact. If not, I'm fine to be wrong and I will continue the search, but I have a strong feeling..

[FreeLuck]

@Sebastianv650 Great, I hope your feeling is right. Here is the gcode of the faulty cube Testcube20mm.zip

[Sebastianv650]

Just as expected: The cooling logic of your slicer is causing this artefact. Your note about printing at 100mm/s gave me the hint. You requested 100mm/s, but your cooling settings are not allowing for that speed. So the slicer is slowing down the speeds to stay above some specified layer time. While this is fine in genereral, it's not if you want a flawless finish in your test cube and similar small parts. During the layers with infill, the slicer has to slow down the speed a lot, alternating between a perimeter speed of 28 and 24mm/s depending on the infill orientation on every second layer. As soon as the solid top layers are started, the slicer will turn up the speed as there is more infill which needs time to cooling is not a big issue any more in terms of layer time. So the perimeter speed jumps to 61mm/s.

You can visualize the speeds using http://gcode.ws/ or http://www.gcodeanalyser.com/.

As this print speed needs much higher pressure changes during cornering, it results in bleeding corners (especialy on bowdens). Your fan duct is not visibly affected as it's cross section area of filled filament is much more constant.

So it's not Marlins fault.

I'm looking forward to see more gcodes of affected prints from other users ;)

[thinkyhead]

So it's not Marlins fault.

This brings me tears of joy if proved true. But then we have @VanessaE's micro-stuttering to look at too.

[FreeLuck]

Just as expected: The cooling logic of your slicer is causing this artefact. Your note about printing at 100mm/s gave me the hint. You requested 100mm/s, but your cooling settings are not allowing for that speed. So the slicer is slowing down the speeds to stay above some specified layer time. While this is fine in genereral, it's not if you want a flawless finish in your test cube and similar small parts. During the layers with infill, the slicer has to slow down the speed a lot, alternating between a perimeter speed of 28 and 24mm/s depending on the infill orientation on every second layer. As soon as the solid top layers are started, the slicer will turn up the speed as there is more infill which needs time to cooling is not a big issue any more in terms of layer time. So the perimeter speed jumps to 61mm/s. As this print speed needs much higher pressure changes during cornering, it results in bleeding corners (especialy on bowdens). Your fan duct is not visibly affected as it's cross section area of filled filament is much more constant.

Ah ok, thanks. Is this problem created for high speed by any slicer? Eventually I have to start studying Linear Advance so that I can solve and print these details at 100mm/s without problems.

[ikarisan]

I printed three 20x20x10 cuboid with no infill. The first one was printed with one shell, the second one with two shells and the third one with three shells. The one with the single shell looks nice. The one with two shells shows some bleeding corners. And on the "three shell cube" you can see them very well. Since the speed of printing three shells is almost constant, it can't be the reason for our/my problem. And for me it makes no difference whether I use S3d or Slic3r. All objects are printed from the inside to the outside. (The result is the same if I print from the outside to the inside)

I used this files (They make use of LinAdv1.5!) Edge_test.zip

And these are the results:

One shell

Two shells

Three shells

I also noticed that there are artifacts on one side of the object, right in the middle of the outer wall. These artifacts are exactly as high as the configured UBL fade hight (5mm). It is very hard to take a photo.

@Sebastianv650 When you think that it is not Marlins fault, why did it work with Marlin <=1.1.6 for all of us while it is no longer working with any newer version?

[peekpt]

I updated from older K to the new K of 2.0.x bugfix and I'm having blobs in the transition of slow -> fast in the test pattern. Although I find the calibration transition Fast->Slow (right side) ok, the transition Slow->Fast (left side) has a blob.

=======o================= 0.8 .....slow....|.........fast.......|.....slow

[Sebastianv650]

@peekpt please create a new issue as this one is handling a problem which is also present with disabled LIN_ADVANCE. We don't want to create a "post all your print problems here"-thread ;)

@ikarisan the reason why you see no bleeding edge with a single perimeter and more with increasing perimeters is that there is always a tiny bit of too much material in the edges on your prints. With one perimeter, this tiny amount will about 50% on the inside of the edge and 50% and the outside, so it's not noticeable. However if you ad more and more perimeters, every next perimeter can only add up to the outside due to the inner perimeter creating a wall for the molten filament. As the error is adding up, it gets visible. And there is another factor which adds to the first one: Cooling logic, once more. The single perimeter wall is printed at 8.7mm/s where you will have nearly 0 pressure effects at all. The speed increases with perimeter count up to 31.5mm/s on the 3 perimeter cube. At this speed, the pressure effects are not incredible but at least much higher than on 8mm/s. To get a real comparison, you would have to print all 3 models with a fixed speed.

The artefact on the last picture is very likely due to a mesh boundary on this location. It is basicaly the same as cornering on a print, maybe due to a low Z jerk value. That's something we could or should look into, and I think it's also what @thinkyhead mentioned with

But then we have @VanessaE's micro-stuttering to look at too.

@thinkyhead if you had something different in mind, please point me on it.

When you think that it is not Marlins fault, why did it work with Marlin <=1.1.6 for all of us while it is no longer working with any newer version?

Because it wouldn't be the first issue where Marlin was the guilty one at first look, but on a second one something else changed in the same time which was causing the issue. You see, the samples where we have pictures and gcodes are easy to explain up to now.

The initial problem with the z-shifting pattern is still unsolved, but I hope to see gcode also from this one? In the end we need to track the problem down systematically. So the best way is to:

• find a gcode file causing the issue from the first post here.
• Switching between the two FW versions disable bed leveling first to see if it's related to this as we already had a visual artefact in your last picture.
• At this point we should now if it's due to bed leveling (LIN_ADVANCE was ruled out earlier), so I would like to see old and new config files together with the affected gcode. Than it's time to see if it's reproduceable on my printer, which would make debuging much easier.

[ikarisan]

@Sebastianv650 Okay, I made a new 3 shell cube with disabled speed control. I don't know how it is called in the English version of S3D, but a near translation seems to be "speed suspension" and can be found under the "Speeds" tab. Now the outer shell is printed with 36mm/s (40% of 90mm/s) and the two inner shells are printed with 90mm/s. As expected, the result is the same.. :(

With regard to the artifact, I have noticed the following when printing at higher speed than 8mm/s. Every time the nozzle reaches the location of the artifact the movement stops for approx. 0.5s and then continues at full speed. And as soon as the UBL fade hight has been reached, the shells are printed without any interruption.

[thinkyhead]

@thinkyhead if you had something different in mind, please point me on it.

The artifact up to the fade height is interesting. That is the period of time when (with leveling on) the Z axis will be moving during the print. Above that height the Z axis stays stationary. The movement of the Z axis may drag some material with it. Some small artifacts should be expected. Try increasing the Z fade height to 10mm and see if the artifacts are reduced. They should still exist, but be less prominent.

[FreeLuck]

I also printed a test cube with 3 shells (Linear advance OFF) and with a speed between 20mm/s and about 10mm/s for the outer perimeter the print is much better. I can confirm what was said by @Sebastianv650, in fact the second layer the slicer has calculated a much higher speed of 60mm/s and the angle bleeds.

Testcubo3shells.zip

@ikarisan I do not know if I say something useless, but do you have the correct value of the multimeter extruder? I have it on 80-85% for more precise prints. Also I noticed that from version 1.1.7 the file configuration.h of Anet A8 the steps for mm of the extruder are 100 instead of 95, I would not like this could be the difference between the versions that leads to the problem. I set my value by 96 steps for mm.

[VanessaE]

I dunno about the bleeding corners @ikarisan is getting, but @Sebastianv650 here's a couple of data points you might find useful for the documentation (a table of examples would be a good idea). On my direct-fed, geared (47:9) extruder, with 32-tooth hob gear, the teeth of which need sharpened, feeding into a genuine J-head v8 (72 mm from filament-gear contact point to the tip of the nozzle):

• Atomic Bright White 1.72 mm PLA, 210-215°C, 60 mm/s on coarse features such as interior perimeters and sparse infill, 30 mm/s on fine details such as exterior perimeters and top surfaces, does well with an acceleration of 1000 mm/s², X/Y jerk of 20 and K of about 0.11. Nice and gentle. :stuck_out_tongue:

• Atomic Bright White 1.72 mm PETG, 240°C, 30 mm/s coarse, 15 mm/s fine, acceleration = 1500 mm/s², ~~X/Y jerk = 5, K = 1.00. Kinda surprises me that it needs to be so high on a non-bowden setup, but then, PETG is quite different from PLA. EDIT: Jerk of 5 may have produced a decent seam, but it resulted in poor quality everything else when I threw a calibration object like ctrl-v v3 at it.~~ EDIT of edit, PETG is tricky. I still am not sure what to use for good settings.

This is with layer/part cooling active, ~~E jerk at 5.0~~, Z jerk at 0.3, 0.5 mm line width, and 0.2 mm layers, bilinear bed leveling enabled, with fade disabled, for all tests.

Still need to fine-tune for each filament color, but this should make for a good starting point.

Something of note: I normally keep X/Y jerk at 20, but at that setting, having K higher than about 0.18-0.2 causes large slowdowns on curves, and pretty extreme extruder activity, rendering as a sort of micro-blobbing along the length of the curve at every vertex due to the frequent extruder reversals, and it seems like the original user-intended speed of the curve affects that. I wonder if what @ikarisan is seeing in his more recent post with the green part is less-severe a variation on this?

[peekpt]

Sorry for the low input but I can confirm that I was using an older fw 1.1.x bugfix, then I updated my printer to 2.0.x bugfix and despite the noise I was having extremely good corners with that older K. I tried to tune new K pattern and find the perfect extruded line and notice although the fast->slow transition was ok, the slow->fast transition had a strange blob in every calibration lines. IMO a strange pause/lag in occurring in that transition, when it changes acceleration from slow to fast. Exactly what is happening to the pictures that has been posted. In the corners, the travel movement slows down, changes direction and starts to accelerate. In the middle of the process makes that strange blob.

[sidbyron]

I have the issue with disabled LIN_ADVANCE. In Marlin 1.1.6 I was working fine with Stock Anet mainboard really really it' was working like a charm but when I upgraded with RAMPS with DRV8825 the issue appeared. I was thinking in the beginning that it was related with current of the drivers but no. I tunned many times and the issue still there. I searched many times in all internet by google and all people says that simplify have some issue about this. The question here is Why was it working fine with S3D and Marlin 1.1.6 and stock mainboard? Why is working bad after upgrade? I tested with cura and the print looks like better. Anyway I tested with 1.1.8 version too and the issue is more visible. I can't believe in the theory of decrease speed 'cause with mainboard and 1.1.6 I was printing fine at 0.2mm heigth layer and 60m/s of speed. What do you think? Do I need to activate LIN_ADVANCE?.

I'm using Bowden extruder with E3D volcano.

[ikarisan]

@FreeLuck Yes, my extruder and all other axis are calibrated very well. :)

[Sebastianv650]

@VanessaE Thanks for the input, maybe you can add the distance between hobbed bolt and the heat brake. The relevant parameters for K should be:

• Material kind and filament diameter for the spring constant
• Distance between hobbed bolt and heat brake for the length of the spring
• Extrusion temperature and nozzle size, giving the needed force for extrusion.

@peekpt please check again without LA enabled. This issue is related to artefacts that happen also without LA, if we mix things we will never find the reason.

@sidbyron LIN_ADVANCE should only be enabled if you don't have other unsolved problems.

I'm trying not to lose the overview here. Therefore let's create a table, to be extended:

Users, confirmed artefact without LA	uses bed leveling
@ikarisan	X

So @all please provide a picture of your artefact and if you use bed leveling. Picture with old FW and one with new FW version is best if you see a difference after an upgrade. Be sure to use the identical gcode then. At the moment I can see only a problem with bed leveling and segmented moves. And don't enable LA as long as you have other open problems :wink:

[ikarisan]

@thinkyhead I increased the fading high to 10mm and now the artifacts are 10mm in high. But they are not reduced. :(

[VanessaE]

@Sebastianv650 I added the hob-to-nozzle distance to my post, but be aware that I'm still trying to find a good balance for PETG.

[Sebastianv650]

@ikarisan as expected for me. @thinkyhead when bed leveling splits a move into segments, they are added instantly to the buffer one after the other like normal G1 moves isn't it? If so, and if this splitting calculation isn't taking too much time, I'm thinking about some z-jerk related issue. Is there a way to get the mesh height map of some users, so I could create a gcode which does G1 moves along a path which would be simmilar to the the one created by the mesh of ikarisan? I don't see another way to find the reason without tons of try and error than to reproduce this and look at the values created by the planner..

[AnHardt]

As far i can see the strange artefact vanishing above fade height must be a change in z-direction at a mesh split. If it is a change in z-direction z-jerk is involved and a slowdown to zero of the other axes.

Somewhen this year we simplified the calculation of the maximum corner speed - this may be involved. The grbl way to calculate this seems to be even better than what we did last year - but needs some weeks/month to be propper implement and be ripe.

[sidbyron]

@Sebastianv650 Im using autoleveling function with capacitive sensor.

Sorry for the last 2 pictures I was tired because it doesn't matter what quality trying to print I always had the same issue so I had many fu*****ing calibration cubes trying to fix this issue... you know...

Here is the last comparision between 1.1.6 and 1.1.8 with RAMPS.

In the next print I didn't have the issue (with anet mainboard and Marlin 1.1.6) :

[monotype-darren]

Sorry for taking a while to add my details.

I broke my print down to a small sample that I think exhibits the problem I'm seeing. I've setup the print with the Z seam at a specific location. I think this accentuates the problem.

All settings between the two versions are the same (jerk, accel, e-steps). Both are using Linear bed leveling. Same machine (Original CR-10). Same gcode (sliced in S3D 4.01, attached as test-frame.zip). Prints were done about 30 minutes from one another.

test-frame.zip

[Sebastianv650]

Users, confirmed artefact without LA	uses bed leveling	Artefact due to
@ikarisan	X	Shows up with 1.1.8, not in 1.1.6
@monotype-darren	X	Shows up with 1.1.8, not in 1.1.5

@monotype-darren Is it possible to disable bed leveling for a testprint with 1.1.8 using this gcode again? I guess the problem is gone then?

@sidbyron I'm not sure if your issue is the same as the one others here have, as your one started within 1.1.6 with a hardware change. All other people here report 1.1.6 as a working version. I tend so seek a hardware problem in this case.

[monotype-darren]

@Sebastianv650 Yeah, it is a tiny print. I can make it work without bed leveling. I'll update in a bit.

[monotype-darren]

@Sebastianv650 Ok, I edited the gcode and replaced the G29 with an M420 S0. The results are identical to with bed leveling enabled. I suspect you may want me to actually disable bed leveling in the firmware build and try that. I'm not sure how I'd go about that though as I'm using the sensor as the endstop and it stops well shy of the bed. If that's what you're looking for, do you have suggestions for conducting the test?

[Sebastianv650]

As far as I know M420 S0 equals bed leveling disabled so the test should be valid. That's intresting, as this one is the first bed leveling independent one.

I'm sorry to say I have no real idea how to go further at the moment. I will think about it.

[Sebastianv650]

Maybe some of you want to try my PR #9914, I'm not sure if it also fixes the bed leveling jerks but maybe..

[sidbyron]

I think the issue is simplify here is the probe. I did a test after but I dismiss 'cause I lost the calibration cube printed with Cura.

I'd used simplify for 2 years without any issue until upgrade my hardware with Ramps it's something wierd really because @Sebastianv650 told me that it is a hardware issue and I think no. Why? I checked all even now and changed belts, I played with vRef of drivers and I tested with A4988. I did everything. Well now I tired of this and it's incredible that Simplify is expensive slicer and it has this issue.

For 3 days I worked hard to solve the issue really I tunned all settings with marlin but I always got the same issue. With 1.1.6 the issue seems to be less visible and with 1.1.8 is more visible anyway (with both dirvers A4988 and DR8825). I played with all my settings of Simplify 3D but in my mind I was repeating "Why do I need change some settings if I was working fine? oh hell!" but I did it always with the same result.

Today I tested with Cura again and I put the same speed, same layer height 0.2mm here the retraction speed I left in 25mm/s and That's all here is the printed cube:

I think there are a incompatibility with Marlin firmware (latest versions) with the latest version of simplify 3D (4.0 and 4.0.1)

Obviusly I know with the latest changes I need tunning some a little my speed and jerk and play with some settings with the fantastic free software = Cura.

What do you think?

Regards.

[peekpt]

I know that this is nothing to do with L.Adv. but If you guys do a K-factor pattern test, you will see the issue fast. What I was getting, with an old 1.x.x firmware, in the slow/fast transition (the left one), was a large to thin stretching on the filament until stabilizes along the rest of the line.continuing the test until the point it disappears in the other lines and find my K. Now I'm using 2.x.x and I get like a blob on that transition.

[Sebastianv650]

@sidbyron I'm not sure if incompatibility is the right word, as a Slicer only generates gcode and Marlin reads gcode. So if both side are handling gcodes within the specs, there is no possible error. If one side doesn't respect specs, it's just broken and will not work at all. But I don't think Simplify has such a basic fault. Do you compared the gcode created by Simplify vs Cura? The difference at an affected layer should be clearly visible.

@peekpt do you did a test with the 2.0 bugfix as from today? The reverse planner was broken, the fix was merged 13h ago.

[peekpt]

@Sebastianv650 I just updated to the latest 2.0.x bug fix and it's fixed! Spot on! the blobs disappeared in the K test and the corners are sharp on the prints ! Great work guys!

[sidbyron]

@Sebastianv650 today I'll check that.