[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

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