Marlin: [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.

[ikarisan]

@sidbyron I cannot confirm this. The results with S3D and Slic3r are the same or very similar.
@Sebastianv650 Has the corrections also been implemented in version bugfix-1.1.x?

[Sebastianv650]

Yes it has.

[monotype-darren]

@Sebastianv650 I pulled, built and flashed the bugfix-1.1.x branch and, unfortunately, it does not appear to fix the issue I am seeing.

[ikarisan]

This is what I get with the new version. :(

But the fading height artifact seems to be gone. O.o

[Sebastianv650]

@ikarisan well I wouldn't call it a perfect print but at least I can't see an obvious bug in it.

But the fading height artifact seems to be gone. O.o

Proves that my PR works.

[ikarisan]

That's a point of view. ;)
If I look at the top right and left corner, they are still far away from the 90° corners I got with 1.1.6. :)

[thinkyhead]

I'm pleased to see Sebastian's change addressed some of the issue. I've been printing with the latest code and have had great results.

If I look at the top right and left corner, they are still far away from the 90° corners I got with 1.1.6

Definitely there is some kind of difference there if your corners are still bleeding. A straight-up comparison of the current planner (assuming it's something in Planner and not in Stepper) to the 1.1.6 planner might be instructive. But I think we'll get farther by trying some tests with reverted code portions to see if anything improves.

One thing we changed along the way was the Jerk calculation, borrowing from the Prusa MK2 fork, but I'm pretty sure that was some time before Marlin 1.1.6. As a first test, we can try reverting that small block of code and see if it makes any difference. Note that when we made that change, it changed the meaning of the Jerk values (possibly in the direction of more true) so it was required to reduce them by 1/2 to get similar results to the previous code.

Anyway, I've got a few other issues to follow up on, but then I'll see about making a branch (or two) with small reversions for testing.

[peekpt]

At least the blob issue is gone on the K test... Do a K test and check if you got this blob yet

[Sebastianv650]

A straight-up comparison of the current planner (assuming it's something in Planner and not in Stepper) to the 1.1.6 planner might be instructive.

That's on my list for today. Hope I find something.

One thing we changed along the way was the Jerk calculation, borrowing from the Prusa MK2 fork, but I'm pretty sure that was some time before Marlin 1.1.6.

Yes it was well before 1.1.6, I checked that already.

[Sebastianv650]

@ikarisan, @thinkyhead there are only two changes in the planner between 1.1.6 and today where I could imagine a changed behaviour:

• the reverse planner was changed (void Planner::reverse_pass)
• and inside Planner::_buffer_steps the code for v_exit, which is part of the jerk calculation, might have changed. Maybe it's the same meaning but different coding, I wasn't checking to detailed for now.

@ikarisan you might see if replacing the reverse_pass inside planner.cpp with the following old code reverts the prints to the old style:

void Planner::reverse_pass() {

  if (movesplanned() > 3) {

    block_t* block[3] = { NULL, NULL, NULL };

    // Make a local copy of block_buffer_tail, because the interrupt can alter it
    // Is a critical section REALLY needed for a single byte change?
    //CRITICAL_SECTION_START;
    uint8_t tail = block_buffer_tail;
    //CRITICAL_SECTION_END

    uint8_t b = BLOCK_MOD(block_buffer_head - 3);
    while (b != tail) {
      //if (block[0] && TEST(block[0]->flag, BLOCK_BIT_START_FROM_FULL_HALT)) break;
      b = prev_block_index(b);
      block[2] = block[1];
      block[1] = block[0];
      block[0] = &block_buffer[b];
      reverse_pass_kernel(block[1], block[2]);

    }                    
  }
}

[ikarisan]

@Sebastianv650 Give me some hours. At the moment I am printing an "USB stick holder", which will take 3h to finish... :D

[ikarisan]

@Sebastianv650 Okay, I compiled and flashed "the old code" but I am still having this "bleeding edge" issues. :( Do I have to reset the EEPROM? Sorry, at the moment I don't have time to test all the variations, because for the last two weeks, I've had a cold and I am still not completely healthy yet. :/ But maybe the problem is one we are not thinking about.... :(

[Sebastianv650]

It's always good to rewrite the EEPROM, but it shouldn't be necessary as the default values you entered inside the config files will be used when the EEPROM version is not valid for the Marlin version you tested.

Then there is no relevant change inside the planner between the two versions. I checked the second option v_exit mentioned before and the behaviour is identical. I can also check stepper.cpp tomorow, but I'm quite sure that beyond LIN_ADVANCE there will be no relevant changes.

[Sebastianv650]

Thinking about it again, I had an idea:
Replace the line in planner.cpp

block->entry_speed = TEST(TIMSK1, OCIE1A) ? MINIMUM_PLANNER_SPEED : min(vmax_junction, v_allowable);

by

block->entry_speed = min(vmax_junction, v_allowable);

Also use the old code from above, but change

if (movesplanned() > 3) {

to

if (false) {

This is only for this particular test print! It will restore the behaviour of the planner regarding the final speed of a move. Basicaly it's adding an error, but it might fix your "problem". If so, I can explain it.

[sidbyron]

Today I madre another test and the problem is start points with Simplify 3D but I don't understand why this problem begin after upgrade. I need to investigate more but when I put "Choose start point..." the problem solved and all is fine.
Someone who has the problem with Simplify 3D can test it ? I solved with the next parameter:

Anyway I need to play more with the setting for understand how it works.

@ikarisan can you test it?

Regards.

[Sebastianv650]

I guess the difference is: Does the end or start point joins a Z-move or not.
I can only repeat myself, if you check the gcode between Cura and Simplify from the test cubes, you might see the difference. Or a gcode with and without using the Simplify setting you described.

When @ikarisan finds time and health to redo his test cube with the proposed changes, we will know it for sure. Or not and we have to continue the search, of course ;)

[sidbyron]

Here is it @Sebastianv650

xyzCalibration_cube_OptimizeStartpoints.gcode.txt
xyzCalibration_cube_ManualStartpoints.gcode.txt

[monotype-darren]

@Sebastianv650 Just another datapoint - my issue was unaffected by the revert of Planner::reverse_pass(). It is also unaffected by your later idea (forcing conditional assignment of entry_speed and skipping the moves_planned conditional block).

[Sebastianv650]

@sidbyron are you sure you print is fine with this setting or is it just aligning all the seams and therefore it juts looks better. Because that's all which is changed according to your files, and your pictures are only showing the Cura cube from the side without seam..

[ikarisan]

@sidbyron Okay... this is very very strange! I set the startpoint to X0 / Y500 (This Y point is located far outside the bed) and generated a new GCODE for my 3 shell cube. The result is nearly perfect! One corner is a little bit too big, but it is 100 times better than before! Random position and optimized position is still producing these ugly corners.

20x20x10_strange_start_point.zip

@Sebastianv650 I will test your code tomorrow.

[Sebastianv650]

Can somebody provide close up pictures from alligned seam and random seam edges?

[sidbyron]

@Sebastianv650 give me some minutes I'll do it. Let me search the best angle.

[ikarisan]

The only corner that shows some bleeding is the one that is approached first (the top left one).

[sidbyron]

@Sebastianv650

As you can see in the left picture you can see the bleeding corners when Random or optimized option is used. For some strange reason if you see the picture you will see that some parts have bleeding all others are fine. About this workaround not fix the problem at all becuase I think the startpoints is in the middle of the printing but we cannot see because is covered by infill material (it's only an idea).

[sidbyron]

I swear the steps and the extrusion multiplier are fine. I used the same for both prints.

[Sebastianv650]

That's not what I'm looking for. The seam is the start/stop point of a line path. The seam is what's causing the "blobls" in your prints with optimized start points. But they will be also there on your manual print, just at some other locations. If you take a picture of each edge (not the surfaces), it should be visible. The gcode you uploaded shows that the start/stop point is also on one edge in the manual mode.

[sidbyron]

@Sebastianv650 but why is it more visible with 1.1.8 ? I hadn't tested yet because I need to print some parts urgently. But with 1.1.8 the print is worse.

[Sebastianv650]

I'm not sure if I can find an answer for that without having a printer which shows the problem in front of me. I'm now at the point at which I only can repeat thinkyhead: Picking commits between your last good version and 1.1.8 until the problem apears would help. Maybe going in 1 month steps first to find a first switching point, then take a commit in the middle of the found last-good and first bad and so on until you can state the problematic one.

I know this is time consuming and I'm open for other advises.

[VanessaE]

I just noticed today that M900 Kxxxx in a gcode file is no longer garnering a "K factor set to..." reply from the firmware (or whatever the text was), even though it's enabled in the config. I'm at commit dcd2fa92919a6cf23d1762bd2b2461c95544bf4b.

[koenkooi]

I'm not sure if I can find an answer for that without having a printer which shows the problem in front of me. I'm now at the point at which I only can repeat thinkyhead: Picking commits between your last good version and 1.1.8 until the problem apears would help. Maybe going in 1 month steps first to find a first switching point, then take a commit in the middle of the found last-good and first bad and so on until you can state the problematic one.

I know this is time consuming and I'm open for other advises.

The search pattern can be automated with 'git bisect', see the 'binary search' section here:
https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git

[Sebastianv650]

@VanessaE this was done by thinkyhead by intention. All gcode commands shouldn't give a feedback to keep serial traffic low expect no parameter is given. M900 without K.. will result in the message.

[VanessaE]

Ok, sounds fair, though tbh I wouldn't have minded seeing such replies from some other commands as well (such as M851)

[ikarisan]

@Sebastianv650 Shall I still test your idea with entry_speed and movesplanned? Or are you satisfied with the attempt @monotype-darren made?

[Sebastianv650]

Well, all you can do is continue testing, also see: https://github.com/MarlinFirmware/Marlin/issues/9494#issuecomment-371616769

As long as nobody has further ideas.

[thinkyhead]

Ok, sounds fair, though tbh I wouldn't have minded seeing such replies from some other commands as well (such as M851)

As Marlin has grown there's been a haphazard mixture of commands that echo back, commands that require a parameter to get the current value, and commands that report their current value when given with no parameters. The last is the most common, and most fitting to the original design intent.

As a hound for consistency, in my view it's got to be either _all setters_ echo back or _no setters_ echo back, and I don't think I'm prepared to change all setters to echo back at this time.

[VanessaE]

Well, maybe some day. It's just paranoia, I guess. :smile: Kind of a "Huh. Nothing obvious happened. Did that command even work?" thing.

[Sebastianv650]

@VanessaE I asked him the same question. So, yes, but on the other hand a unique behaviour is always better than some commands doing it different than others. A second point for having no response is that slicers often make extensive use of some commands like M204, to set acceleration depending on what's printed (perimeter, infill, ..). So all the responses are flooding the serial window, hinding maybe important informations between the lines.

[VanessaE]

True. Maybe such responses could be a debug option in the future.

[thinkyhead]

Maybe such responses could be a debug option in the future.

This would be a good use of the INFO debug flag which is barely used at all right now.

[ikarisan]

The more I deal with the problem, the more confused I am. :(

What I can you for sure is that neither the first modifications in planner.cpp nor the second one (https://github.com/MarlinFirmware/Marlin/issues/9494#issuecomment-371276231) changed anything.

But I can say, that S3Ds GCODE files with "random start points" are ALWAYS producing these "nice" corners. But, and now it's starting to go crazy, the problems from the beginning are gone resp. much less noticeable with "speed optimized" or "Y500 custom" start points. That doesn't mean that they are gone. The XYZ cube is still useless as long as you don't sand the edges down for 0.2mm. :(

[sidbyron]

Sorry guys I was testing with a lot of time and I different settings but I was thinking to make a reservation with Simplify 3D 3.1.1 with my original profile and it looks better. I test the same profile with simplify 4.0.0 and it looks again bleeding corners. Here is the picture.

What do you think?

[ikarisan]

What I think is that the result should always be the same or very similar.
Your left cube shows a kind of these bleeding corners every "five millimeters" while the right cube shows a continuous disturbance. But I think it will help "someone" if you post your two GCODE files.

[sidbyron]

I solved my issue. Well first I read about lost steps for DRV8825 so I activated fast decay mode well in the process to make this I dedicated to check every part of my printer but the root cause of all this problem was the belt. I dismiss the belt because when I upgraded main board for marlin I changed for the new one but probably it was defective anyway I was thought all this day about this..." Change the belt" why? Because the lastest printed cube I did it with Slic3r but the print still no perfect so I check every layer and I saw that all layers are missaligned so I changed the belt again and now it's working fine. I have to make fine tune but now I can print nice.

[sidbyron]

I'd tested with simplify at this moment and I give up with simplify (F*ng simplify have always the same issue Oozing control). I'll use Slic3r or Cura it's working better and free. hahaha thank you all

[ikarisan]

@sidbyron I'm glad it works for you now. I've had the opposite experience. With Slic3r, I can't even get the first layer right. But for both (S3D and Slic3r) my results >layer2 are still the same. :(

[georgedorn]

This didn't seem to have any resolutions. @ikarisan, did you eventually find a fix? I'm suffering from the problem now, and can't enable linear advance due to having on-board TMC2208s in legacy mode...

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.