Print artifacts due to controller not keeping up:

[cjs 34]

From testing the Ultimaker 3 seems to have problems with high poly stl files. Such files result in g-code files created by cura with lots of really small moves. 

A lot a small moves mean that the main computer needs to send many command to the motion controller in a short time. If the motion controller has run out of commands the print head will stop until it gets a new command. Such small stop can relate to print artifacts. 

A possible solution would be to implement the G2/G3 for arch as this would mean fewer commands -> no short stops. There has been a request for cura a long while ago: https://github.com/Ultimaker/CuraEngine/issues/429 

 

Attached the stl files I used for testing. I always printed three at a time to not have cooling issues. I also did set the speeds to be all equal. 

cylinder-resolution_fine.stl

cylinder-resolution_coarse.stl

[WesleyE 14]

I did not have time to check the stl's, its on my list. There is indeed an limit to how many gcode you can send in a short period. While short bursts of small segments will work perfectly, prolonged periods of small segments can cause buffer underruns.

 

There is an 'Experimental Setting' called Maximum Resolution you can use, but it will enforce the limit on the whole model. This might be ok when you are printing cylinders, but not on organic models.

[kmanstudios 1,120]

On 3/18/2018 at 8:41 PM, cjs said:

From testing the Ultimaker 3 seems to have problems with high poly stl files.

I would beg to differ as almost all of my files are very freakin' huge.

 

On 3/18/2018 at 8:41 PM, cjs said:

Such files result in g-code files created by cura with lots of really small moves.

I will be posting some pics of this issue as well that work well. But I have found orientation of models and placement on the buildplate plays into it.

 

On 3/18/2018 at 8:41 PM, cjs said:

If the motion controller has run out of commands the print head will stop until it gets a new command.

I have not noticed this in my time with the printer. I rarely go out and the printers are in my main room and I sleep about 15 feet from the printers and can hear them whirring away with only a delay at the change of nozzles. But, I will be a bit more on the look out for that.

 

I will have to look at the models you provided. but I print really crazy organic stuff and it truly is large both in buildplate volume as well as files size and do not find any real issues. And when I say large and detailed, 6 - 9 days at a time for many of them.

[kmanstudios 1,120]

This would be an example closer to what you are testing on the printer.

 

I will be printing this tomorrow night.

UM3E_TightStuff.stl

 

Edit:

Added this too:

HighVertexCouint.STL

Edited March 20, 2018 by kmanstudios

[cjs 34]

9 hours ago, WesleyE said:

I did not have time to check the stl's, its on my list.

Thank you @WesleyE 

A bit more information for you to replicate the issue:

I changed all wall print speeds to 40mm/s

Printing one cylinder shows slight artifacts, but it will only show if you print at least two cylinders. 

 

9 hours ago, WesleyE said:

There is indeed an limit to how many gcode you can send in a short period. While short bursts of small segments will work perfectly, prolonged periods of small segments can cause buffer underruns.

May the use of G2/G3 commands be a solution? It sounds like it, but I haven't really seen people using it with 3d printing. 

 

9 hours ago, WesleyE said:

There is an 'Experimental Setting' called Maximum Resolution you can use, but it will enforce the limit on the whole model. This might be ok when you are printing cylinders, but not on organic models.

Thanks for the tip! I will do some testing with the setting and report back. 

 

9 hours ago, kmanstudios said:

I would beg to differ as almost all of my files are very freakin' huge.

Maybe I did simplify my statement to much. I only saw a print artifact and did some test prints to troubleshoot/diagnose the problem. The result was that g-code with lots of little lines at a print speed of 40mm/s causes print artifacts which are probably caused by buffer underruns.  High poly stl files are likely to produce such short files. 

 

9 hours ago, kmanstudios said:

I have not noticed this in my time with the printer. I rarely go out and the printers are in my main room and I sleep about 15 feet from the printers and can hear them whirring away with only a delay at the change of nozzles. But, I will be a bit more on the look out for that.

It's really hard to notice as only a short stop, probably just a fraction of a second, can cause artifacts. 

Will be testing if I can see the print head stop with a slow motion camera 

 

 @kmanstudios you are printing really interesting looking pieces! 

[kmanstudios 1,120]

I am not doubting that the gcode may be doing what you say. What I do not see on my prints are artifacts due to this. Other issues yes, usually operator error, like orientation of prints, etc. But, not artifacting with the weirdness I print. And that stuff is tight with loads of triangles and large files.

[cjs 34]

5 hours ago, kmanstudios said:

What I do not see on my prints are artifacts due to this.

Normal print profiles don't show artifacts as the wall print speed is rather slow at 30mm/s. It starts to show if you change the wall speed to 40mm/s. 

[Marco_TvM 34]

As @WesleyE mentioned, there is a chance of buffer underruns happening when lots of small gcode is being generated.

If this happens, it would be interesting to see the numbers.

For this, you can use the URL HTTP://<printer_ip>/api/v1/debug/marlin/errors which shows you a number of statistics of the serial protocol used by Marlin.

If the planner_buffer_empty increases dramatically, this indeed means a buffer underrun.

[kmanstudios 1,120]

I am using the defaults for the most part, which in my opinion, have surprisingly high speeds. Theses are the PLA speeds I am referring to. For example, I just finished a mechanical print (VS my usual weird oganicy kinda stuff) at the usual 0.15mm default and other than a spot with support issues (Support nozzle needed cleaning and did not print a good support at that time...very lace like) I do not see artifacts.

 

Now, I will be posting pics of this and other things at a later time, and I would remind you that I may not know what I am speaking of by way of understanding. I am pretty sure I do, but, when new pics come up, I am always open for critique on appearance. Some things I do on purpose, but when I do mechanical prints, I want clean surfaces.

[cjs 34]

Well I don't know if you have tested it yourself at Ultimaker HQ @Marco_TvM and @WesleyE ?! 

I finally got to do some testing in this regard and this are the results. 

As @Marco_TvM suggested I used the marlin errors Page and could spot a dramatic increase (+40.000) of the planner_buffer_empty statistic and resends did go up to 5. 

The black filament color isn't ideal for photos but I think the difference can be spotted. (Left= high resolution stl; Right= Medium resolution both @40mm/s ) 

The artifacts are reduced with Cura 3.3 Beta as the Maximum resolution is increased by 0.03mm, but are still prominent. 

[cjs 34]

On 26.3.2018 at 3:49 PM, kmanstudios said:

have surprisingly high speeds

Well ... actually they are rather slow and on the save side. Please do have a look at the specific speeds for the features. You will notice that only the infill is printed at the so called print speed. The walls are normally reduced to approx. 1/3 of the print speed.