Uneven lines during printing; but vase mode printing is good

[DrinkWater 1]

Hi. Just came here and haven't found anything similar.

So I'm having this weird surface on printing in regular mode. But printing in Vase Mode shows that there's no issues with hardware (printer is ok, anyway).

 

In this example it is black PLA at 190 deg, printing speeds are 40 - 70 mms (tried different, doesn't matter). Straight lines are better. The issue seems to be in inconsistent movement during printing. I can see it with eyes, the nozzle moves by the even arc, movement should be consistent because there's no deviations, model is cylindrical (using 3MF files, no insane triangles like in STL). Anyway, at random places nozzle moves faster than in other places. No consistency or correlation with geometry. No dependency on printing settings; only in vase mode it prints nicely and evenly.

 

Printer: Ender 3 Pro with SKR Mini 1.2 DIP + 2208 UART; TFT24. PLA at 190 deg.

Cura 4.6.1

 

First photo - issue; second photo - example of vase mode.

[gr5 2,172]

I don't know much about the ender3 but it uses Marlin firmware and these types of printers (like Ultimaker printers) have typically either an 8 or 16 line gcode buffer.  They have to plan the next 8 or 16 steps constantly as it's printing because if the very next gcode is a sharp corner the printer needs to be able to come to almost a complete stop without violating the acceleration criterea.

 

So if there are too many points (say 1 every 0.1mm) then it will print slow.  And then in areas where there are fewer points/gcodes the printer will speed up.

 

Look at your sliced model in PREVIEW mode and step through the lines (horizontal slider - not vertical!!!) as they are being printed.  In some places where your printer slows down - are there more points closer together?  If so you may have to fix this in your CAD export step.  Or you can import your model in meshlab to see what you CAD did and you can reduce the polygons a bit - maybe have the polygons at least 2mm across for the most part:

http://www.shapeways.com/tutorials/polygon_reduction_with_meshlab

 

Of course this doesn't completely explain why vase mode is better.  Still - looking in PREVIEW mode should give you some hints as to the problem.

[DrinkWater 1]

2 minutes ago, gr5 said:

Look at your sliced model in PREVIEW mode and step through the lines as they are being drawn.  In some places where your printer slows down - are there more points closer together?

I would understand if there was any geometry deviation. But there is no deviation and inconsistency in geometry. It is circular walls. Also model exported in 3MF to avoid ugly triangulation with STL. I suspect that neither Cura or Marlin 2 supports arcs so it's still getting split into direct lines. By 3MF I'm just trying to minimize amount of splitting it into lines.

 

I suspect that it's not the point of bad model and bad triangulation. It's made in SolidWorks, so it's not a mesh.

I saw posts about something similar caused by a bug in Cura 4.7 (that's why I didn't update), but I'm using 4.6.1 and this effect is not that pronounced.

 

Attaching screenshot of speed in Cura. Looks even.

 

I don't understand why vase mode prints perfectly. If there's issue with gcode line buffer, it would affect vase mode too - during 1 full line it have to have more than 16 lines considering it's a circle, not a rectangle.

[GregValiant 1,251]

Enable Acceleration control at 500 and Jerk control at 20.

If your acceleration setting is too high (or not turned on) the printer can't keep up and gets herky-jerky going around radii.  I've found the max for circles to be 500 on my Ender 3Pro.  Jerk settings below 20 aren't as smooth.

With the acceleration control at 500 it will have a significant impact on the overall print speed but it should smooth things out.

You are right in that neither Marlin nor Cura support true arcs or circles.  G2 and G3 commands simply make a bunch of short lines out of the circumference.   They do it in one line of code instead of a couple hundred but in the end there isn't any real difference.

[gr5 2,172]

>Attaching screenshot of speed in Cura. Looks even.

Of course the speed isn't changing in cura.  What's more important is if the lines are equal length.  If there are groups where the movement is shorter then it will likely slow down there.

[DrinkWater 1]

9 hours ago, GregValiant said:

Enable Acceleration control at 500 and Jerk control at 20

Thanks for suggestion. Tried now. Doesn't affect the issue, but didn't make anything worse. Previously I tried jerks at different numbers but not 20 (tried from 6 to 12). 50 mms.

 

I want to make it print as good as vase mode. And the only visual difference will be z-seam. Would be great.

Edited October 16, 2020 by DrinkWater

[GregValiant 1,251]

If you'll post the model file here we'll give it a slice.  My Ender has the silent board, Marlin 1.1.8, and I'll slice with Cura 4.7.  Other than the main board my printer is much the same as yours.

[DrinkWater 1]

10 minutes ago, GregValiant said:

If you'll post the model file here we'll give it a slice.  My Ender has the silent board, Marlin 1.1.8, and I'll slice with Cura 4.7.  Other than the main board my printer is much the same as yours.

I'm using this one.

 

Did they fix the main bug in 4.7?

 

BTW, what is the best format to use for Cura? Does it only support STL and 3MF?

112.3MF

Edited October 16, 2020 by DrinkWater

[GregValiant 1,251]

10 feet of filament left on a roll isn't good for anything except testing.  But it comes in real handy for testing.

So before I ran out of filament -

My Bottom line - .6 line width looks really good. (but I couldn't maintain 50mm/sec and had to run at 90%).

With coasting on - Z seams were ugly.

Line width of .36 for the walls - OK but Z seams weren't a lot better.

 

This shot is with line width at .4  and you can see that there are mesh moves to fill the gap between the 2 outer walls.

 

 

This is with the line width at .36.  Cura can now use an inner wall line down the middle between the outer walls  resulting in much smoother movement.

 

 

 

At .6 line width it's a simple double wall.

 

This is with .4 line width on the left and .36 line width on the right

 

This one came out really well at .4 line width and .6 line width for walls.  Z seam could be better, but all-in-all pretty good.

 

 

 

112G.3mf

[DrinkWater 1]

52 minutes ago, GregValiant said:

This shot is with line width at .4  and you can see that there are mesh moves to fill the gap between the 2 outer walls.

I was using 2 walls of 0.4 mm so for in and out surfaces it made 3 walls total at that area, without filling it with linear movement.

 

I didn't expect someone to print it and figure out the issue. Thanks for helping with this investigation. 

 

I can't use 0.6 outer line for all the prints. And I remember that it was working without this issue earlier. There's a lot of things that can be different in your and my settings and I don't know which to check.

[GregValiant 1,251]

Like I say, when I get just a few feet of filament left on a roll I use it to help me understand these kind of things.  It's better than just throwing it away.  Cura is complicated.  Everything effects everything.  The only way to get to know it is to practice.  @gr5 has been doing this way longer than I have.  Maybe he'll have a different take on it.

In the mean time - your belts are good and snug?  No wiggle room on the X or Y carriages?

 

Cura supports quite a few different formats.  In the Open File dialog check the dropdown that says "all supported files" and you'll see the list.

[DrinkWater 1]

4 minutes ago, GregValiant said:

In the mean time - your belts are good and snug?  No wiggle room on the X or Y carriages?

No such issues. I checked it recently. And also I didn't change anything related to belts, motors and rails with wheels between now and when it was printing without this issue.

 

Right now I'll try to build the firmware for this board and see if it changes anything. Excluding things step by step. It's weird that it prints vase mode and direct lines in regular mode properly.

[gr5 2,172]

So in Cura if you slice the part exactly how you did it when you had a problem - then go to "file" and "save" it will save the model and also the printer settings (machine settings) and also the cura profile and also the changes to the profile (aka settings).  It also saves if you scaled the part, moved the part, rotated the part.  If you place multiple parts that's all saved also.  All into a single file (extension is .3mf but it's not just a model).

 

That way you can post it here and other people like Greg and print with the exact same settings or just change one thing and tell you the one thing they changed.

 

[gr5 2,172]

Greg could do that also - do a "file" "save..." so @DrinkWater can see all the settings.

[DrinkWater 1]

Ok, I checked other suspect and figured out that my pre-built firmware for the printer was really garbage. I was trying to do that before but just now made it work. Meantime I was figuring out why vase mode has no issues. That's why I suspected Cura. My bad.

Thank you gr5 and GregValian. I asked these questions in other places but nobody gave me anything even close except here.

 

Also I found out that when you use TFT24/35/whatever screen, it processes the g-code and sends commands instead of letting the board process it (unless you stick SD card into the board instead of the screen). And constant connection and data transfer has own issues - it makes main board choke on commands and skip movements if the path is very detailed (many points per mm). This is why direct lines show no issues.

So apparently Marlin devs trying to fix that, as I heard from random rumors. And they might succeed, since latest Marlin 2 don't show this problem for me. But I still will print from on-board SD slot instead of on-screen one.

 

Here's comparison after flashing proper firmware with fresh Marlin 2. Models a bit different but it doesn't matter.

Since I shared testing model file, it is lens hood for Sony 50 1.8 OSS lens and compatible. Just in case.

[GregValiant 1,251]

Much nicer.  And thanks for getting back with what you found.

 

"...it makes main board choke on commands and skip movements if the path is very detailed (many points per mm)"

 

And that is why any remote hosting is difficult to do.  I guess Octoprint does a fair job.  Cura and PrintRun not so much.  The transmission speed of the data (Lines of GCODE / second) has to vary according to how long a particular print head move takes.  When the SD is in the printer slot, the Printer/Planner just grabs another line of gcode when it needs it.  It doesn't have to wait, and it doesn't get over-run.

 

Your adapter got me thinking...I just took a look at my microscope thinking it would be nice to take photos of what I see in there.  It's binocular though.  Nuts.

Edited October 18, 2020 by GregValiant

[harryb 0]

Hi there, ive just come across this article and im having the exact same issue, basically are you saying that the problem was the linewidth of the print model, ofc im printing something different but when i use vase mode it looks perfect!

 

 

 

[gr5 2,172]

In vase mode it makes only one pass.  The movement is much simpler.  So the patterns on the surface are simpler (smoother).  Very few parts can be printed in vase mode.  They have no top to them (like a cup or base) and be mostly hollow.

 

I guess the basic problem is that the width of the thing you are printing is never going to be perfectly consistent so sometimes (for example) cura needs say 2 passes and sometimes 3 passes.  So it has to go back and fill in certain parts.  No matter how perfect you make it in CAD, all curves are converted to lines and so in tiny spots the distance between the lines change enough for cura to decide to go back and fill some spots in.

 

Any part that *can* be printed in vase mode (again - none of the last 1000 parts that I have printed) *should* be printed in vase mode.

[harryb 0]

Right ok thanks for taking the time to explain this to me, im gonna try and modify the line width and report back.