Marlin: Printer slow down during printing circles

[ViktorSari]

Hi all,
During printing my printer slows down or even stops while printing circles or curves. The effect increases, as the nominal size of the circle decreases (ex. with radii of 10 it just slows down, with radii of 3mm it stops and produces strange noise during printing). The resulting feature is hardly approximate a circle and there is blobs along the circumference, also step-loss occurs. I've already excluded every possible mechanical (like backlash, lubrication, etc.) or electrical source (driver/soldering, etc. problems), the machine has been calibrated with professional measurement tools and every part of it is a CNC machined metal or industrial grade part.
Machine type: experimental cartesian printer
Controller: MKS Gen V1.4
Marlin: RC7
Host: MatterControl
Motors driven at 1/8 microstepping with DRV8825.
Common motion settings:
Speed: 260 mm/s, Acceleration: 12 000 mm/s^2, "Jerk": 50 mm/s
Auto-bed leveling enabled, max X/Y frequency has been set to 30.000 (Hz?) and buffer value (I don't remember it's exact name) also have been tried with different values (4,8,16,32).

Some ideas/thoughts:

• The machine itself has been design to this motion setting and lowering the motion setting (speed set to 60, acc 5000 and jerk to 20) do not solve the issue.
• Several things from this forum (Fix SLOWDOWN, possibly #5908 for example) have been tried without any effect.
• I have strong feeling that this issue might have a firmware related source.
• Lines and other linear features printed well even at high motion settings without any problem.
• Different baudrates also have tried without any significant impact.
• Changing (increasing) the buffer value made this issue even worse .

I think this is a kind of a computational capacity problem or a possible bug. Could you please recommend settings that could have possible impact on this issue? Any ideas are welcome. I'm really thank you for your kind help!

[FHeilmann]

What are you using to supply g-code to the printer? If you're using an old rpi for example, it may not be able to keep up. Same with an old SD card. Try different methods of supplying the g-code.

Also, with your motion settings, you are probably coming close to the limit of the 8-bit platform, especially when you have advanced stuff like bed leveling enabled which adds a lot of computational overhead. You may have to start looking at the 32-bit platforms.

[ViktorSari]

I'm using USB connection with a good quality cable and the g-code is produced by Cura (use of SD card not possible). The bed has been adjusted very fine, there is only maximal 0.1 mm z difference in a 200x200 table, so the Z not used very often.

[FHeilmann]

Whether or not your bed is level or not does not matter computation wise, since the overhead inside the firmware whether or not to perform corrections still exists.

Slowdown in circles is not uncommon, almost to the point of being normal. Stopping, of course is a no-go. If your bed really is that level, try turning bed leveling off and use a sufficiently large first layer (e.g. 0.3mm) and see if the issue persists. You can also try and play with the #ENSURE_SMOOTH_MOVES parameter in the advanced configuration or, alternatively, compile your firmware without an LCD (if you have one) to test whether the LCD is impacting your high-speed print too much.

[ViktorSari]

FHeilmann, I'm really appreciate your help! Thank you very much! I'll try this #ensure_smooth_moves setting (I'll come back after I have any results). I'm not using LCD. IF you have any other ideas, please feel free to share!

[oysteinkrog]

If the gcode produced is too big/complex, marlin may not be able to keep up and the whole printer will slow down. Having this happen with e.g. circles is a known problem.
Many slicers have an option to reduce the level of detail, this option is meant to avoid the problem where you have a _lot_ of complexity in the model, beyond what is needed. By dropping a bit of detail you can ensure there is no slowdown, and it should not affect quality.

[ViktorSari]

oysteinkrog, I've used a gear model form thingiverse (small bevel gear from here: http://www.thingiverse.com/thing:11836) and also printed out in other 3d printer, nearly the same (low) motion settings. In that case there were no significant slowdown, however this other pinter uses much older version of Marlin (form 2015).

[brainscan]

I would look into using sd card rather than USB cables if at all possible as it makes a huge difference to speed and quality, especially on complex models.

[Sebastianv650]

@FHeilmann @VictorSari, there is no #ensure_smooth_moves anymore as the main problem with graphical LCD was solved.
As @oysteinkrog stated above, I'm also quite sure it's due to too many segments generated by the slicer. When printing arcs and circles at high speed (and worst case is over USB) it's esential to have a slicer with some kind of resolution control. If there is no, you might end up with millions of 0.00001mm moves flooding Marlin.
To give a number as an example, I'm using a value of 0.02mm in Slic3r. But even 0.01mm would be better than nothing.

An older version of Marlin could act different as the big portions of the planner code (acceleration and so on) has changed and there is also a minimum steps / segment setting that can affect the print speed in this case.

[Bob-the-Kuhn]

He's running RC7. Any idea if RCBugFix is better?

[Sebastianv650]

There are some small optimizations in the planner code to return earlier when the move is too short, I think that was after RC7. At least it's worth a try.

[fiveangle]

I've been testing diff configs to try and isolate a similar issue I see on my Printrbot Simple Metal but haven't had time to narrow down yet. On stock (ancient) Printrbot FW I see smoother curves but on RC7+unified ISR serial timer patches with linear adv enabled I see the massive slow down in arcs.

I need to reconfigure my printer so I can print from SD card in order to determine if this is serial host control issue or not, but this is very much an issue that needs to be root caused and resolved (hopefully it's not due to the unified timer change), but life has just gotten in the way preventing progress.

[Bob-the-Kuhn]

Marlin now supports G2 & G3 arc commands. Can the slicers be configured to use them?

[Sebastianv650]

@fiveangle don't compare another FW against Marlin with enabled LIN_ADVANCE in terms of speed! This feature adds quite some load to the processor, in all cases this will limit the max. possible speed in short moves. Just a question of processing power..
If you compare them, make sure the enabled features are simmilar, or you end up doing a drag race between a racing car and a road train ;-)

@Bob-the-Kuhn I don't know of a slicer that is able to use this commands yet. The problem is the detection of arcs based on stl files. And in the end, it should be slower than using normal G1 moves at the same resolution because the G2/3 has to calculate the points at the "weak" 16Mhz CPU.

[ViktorSari]

Hi all,

I've tried several things according to your recommendations without any significant impact on stuttering. I've tried the followings:

• turn-off autobed-leveling : no effect
• enable "ensure_smooth_moves": no effect
• changing jerk: no effect
• using SD is not possible, but I've also tried different baudrates: no effect.
• I've tried different model with circles: stuttering disappeared, however in terminal singificantly less G01 streamed to the 3D printer.
• I've tried different slicer and also, lower STL resolution: no effect.
• I've tried different settings (very low speed/acc/jerk): no effect.
• I've tried to print with different (better) laptop: stuttering decreased significantly but still present.
  (*autobed-leveling was off during testing)

(!!!!) I've tried the same model with same setting with a different (better) computer on an older 3D printer with older Marlin versions (from 2015) and the stuttering disappeared! I've used nearly "same" high speed (100 mm/s). On terminal a lots of G01 streamed but there were no stuttering or even a small halt during printing.

In my understanding this might be a kind of bug in RC7 and it present during arc movement and no relation to speed and the above mentioned things (I'm a mechanical engineer and have only a very limited understanding of how the firmware handle the streamed G codes).

[bobc]

@ViktorSari can post a sample gcode file somewhere that reproduces the problem?

Lots of small steps is a worst case scenario for a controller, when the duration of the move comes close to the processing overhead of the comms and firmware. Smoothieware also had a problem with this case.

[ViktorSari]

@bobc: Sorry, ATM I'm not able to post it, but the gcode has been generated by Cura with MatterControl. You can find the corresponding file here: http://www.thingiverse.com/thing:10955
I've used 0.2 layer height.
The controller's type with stuttering is MKS Gen 1.4
The older one is: RAMPS 1.4

[bobc]

@ViktorSari There are a dozen files there, please can you say which one(s) ?

[ViktorSari]

@bobc The file name is "gear_hypoid_left.stl"; for the material please search: "Spiral bevel gear".

[Sebastianv650]

@ViktorSari most of your above mentioned points will not affect the computation speed in a magnitude to see it in print speed. Also the stl resolution is a guarantie for a lower resolution output of the slicer. Therefore to be sure, the only way is to set a resolution in the slicer itself.

If someone provide the problematic gcode, I can do some analysis.

[ViktorSari]

@Sebastianv650: please rename the file from .txt to .amf (this is the file extension what the Matter Control creates). I'm pretty sure there no any problem with the G code itself. Thank you for your kind help!

gear_hypoid_left (1).txt

[Sebastianv650]

I don't know the amf file type well, but as far as I know it's a format for saving stl and other part information, no gcode relevant information.
I also can't open it in Slic3r.

According to that you should be able to export to gcode:
http://wiki.mattercontrol.com/File_export_options

[ViktorSari]

@Sebastianv650 I've attached the gcode to this comment. Hopefully it will work, but please note: this has been successfully printed on other printer without any problems, so there should be no problem with the slice or the gcode (please rename the .txt to .gcode)
gear_hypoid_left.txt

[Sebastianv650]

This is the first gcode file I have ever seen containing lines with G1 but no further data..
We can throw away the short move idea, your code only contains X and Y coordinates with 2 digits behind the point, therefore the shortest move is 0.01mm.
I noticed this is a vase mode print, but against the rules I know with more than 1 perimeter and even a top infill. But when you say it works on other printers I will believe that.

So the only thing that ads extra load is the 3D move calculation, but the same happens on every printer with active bed leveling. Can I see your Configuration.h file? Maybe there is something helpful in it.

[Sebastianv650]

I tried to air print it: It prints very slow, I think due to F1200 values in the code. Wrong slicing settings? After replacing them with 12000 it's fast - I would say it runs as fast as my jerk allows it..

[bobc]

At the end of the gcode file, there are the slicer settings:

; external_perimeter_speed = 20
; perimeter_speed = 20

which corresponds to F1200. I would try again with different settings.

On a side note, are there any bench tests designed to test short moves?

[ViktorSari]

@bobc and @Sebastianv650 I'm sorry, I think I've been posted the wrong gcode. I've attached a new one(s), with following remark: one is generated by Matterslice (MC) and printed out perfectly with ~160 mm/s (12.000 mm/s^2 acc, and 40 jerk) the other one produces stuttering and generated by Cura.
The infill was 0 at both cases.
GCODE_CURA.txt
GCODE_MC.txt

[FHeilmann]

Well from the file sizes alone you can tell that cura performs A LOT more G-Code (pretty much twice as much) as Matterslice does. Probably, matterslice approximates arcs with fewer linear segments than cura does, resulting in less commands, which in turn gives your controller more time to perform the individual moves.

Thats why MC does not stutter, while cura does.

edit: to back this theory up: The skirt in MC has about 110 lines of G-Code, while the cura skirt has about 420 lines

[ViktorSari]

@FHeilmann Thank you for your comment. Yes, that's obvious; but please note: the code generated by Cura has been used without stuttering on older printer with older Marlin (nearly same high speed). The arc movement done by Cura uses finer resolution with the linear interpolation (G1), but this cannot be the reason itself for stuttering, there should be something in the firmware that manage this. I would really appreciate if anybody have a knowledge about what kind of firmware setting could affect this.

[Sebastianv650]

I have no definite answer I can give, in the end it's all about calculation speed.
To give some very rough (outdated) numbers, I did some calculation somwhere last year: The planner was able calculate about 300 blocks per second. With a given print speed of 40mm/s and my step/mm settings, this means that an average block shouldn't be shorter than 0.25mm or the buffer would start to drain.

Again, this will not be valid for current RCBugFix as there was quite some optimizaion work done, especialy the LCD update is now much faster leaving more time for the planner. But you might get a feeling with this that you can't expect to run 200mm/s around a smooth arc.

I see you are still using RC7, maybe you could test again with RCBugFix?
Comparing against Marlin 1.0 is problematic because a lot has changed also in the planner. The complete acceleration thing and so on has changed, and I never measured before and after speed as far as I remeber.

[ViktorSari]

@Sebastianv650 Thank you for your suggestions I'll try it @ the weekend.

[ViktorSari]

@Sebastianv650 I've flashed the latest RCBugfix to my MKS, however printing with Cura still produces stuttering movement (printing with MatterSlice works perfectly, but someway causes step loss at the Y, therefore I've switched back to RC7, maybe this is a bug). I've tried a lot of parameter, but unfortunately I'm not familiar the settings that set the parameters for G-code processing. I have a strong suggestions, that the problem is caused by the higher numbers of segments that Cura made, but again, I have no idea what could change this from the Firmware side.
Could anybody please make a short description how the Marlin "eats" g-codes when a higher number of lines defines a movement? I'm also interested, what kind of parameters could affect this. Kind regards.

[bobc]

Can you try increasing the value of MIN_STEPS_PER_SEGMENT in Configuration_adv.h ? That is really the only parameter which affects the rate of GCode processing in the firmware.

I've been trying to create some test data, but I have to generate GCode directly to get consistent data, which makes it a bit hard to use. The test data prints a cylinder with an increasing number of segments in each layer, and I observe some stuttering as the segment rate goes up, but I believe that is due to the serial link becoming saturated (I'm running it at 115200).

[Sebastianv650]

As bobc wrote, MIN_STEPS_PER_SEGMENT is the value that might bring you the most benefit.
But this will never be as good as a slicer with resolution control, because even if the move gets combined with next one due to the minimum segment steps it has to be transmitted over serial first and this takes time.

[rubdos]

I think I have a related one, and I filmed it

I am printing these vibration dampers using Slic3r and Pronterface, on a Thinkpad T61p (so the controller is quite capable; the CPU doesn't go above 30%).

I'm on the 1.1.x branch, last updated last Thursday (18th of May).

[Sebastianv650]

Can you upload your configuration and configuration_adv,h files please.
Given the sound (which is more easy to follow than a video sometimes), it might be due to low jerk and acceleration settings in this case. As far as I can hear/see it in the video, the printer is slowing down already when approaching the corners, which would mean the motion planner calculated that as a maximum cornering speed.

[rubdos]

I manually had set my jerk to 35mm/s. Most curves in other parts went a lot quicker. Could this be to having too high resolution, so that Marlin cannot interpolate?

[Sebastianv650]

Might also be possible. But without configs and gcode file, it's only guessing ;)
In Slic3r, you can set the resolution in Print settings -> Advanced -> Resolution. I usualy use 0.02mm, but even 0.01 would be better than nothing. If this setting is 0 and your .stl has one million of points on an arc, Slicer will generate one million points on the arc..

[ProfDrYoMan]

Resolution in slic3r-dev is gone. It is not what you expect. It is a filter to filter out structures that are smaller than what you input.

Look here: https://github.com/alexrj/Slic3r/issues/3888

[Sebastianv650]

I'm using Prusa Slic3r, where it's still available. It's exactly what I expect, I used it a lot during Marlin serial tests. :)
To see what it does, load a simple cylinder and watch the 3D preview closely with resolution 0 (no simplification), 0.05 and 0.2. It controls the maximum allowed deviation between real stl shape and the print path. Therefore, it controls the resolution of the gcode file.

Removing this very useful option just because some people doesn't understand what is is and how to use it is a sad decision in my eyes..

[matguy87]

Hi, I think I'm having a very similar problem and I think its caused by my gcode buffer not being able to keep up.... I just recently hooked up a pi zero w with octopi to my printer via the USB connection and recently switched from Slic3r to Cura because of horrible blobbing issues whenever there were a ton of retracts in my print(Cura has the coast setting) and has been printing way better than Slic3r but I've been noticing it having issues with small holes and small patterns were I see the buffer of the printer drop down to the very low even zero at times and the print speed slows down dramatically with a lot of stuttering... it defintely seems like either there are simply too many small changes too quickly or my pi zero w can't send then information fast enough.

Does anybody have any idea how to get this better in Cura? I tried searching for something similar to the minimum resolution option which some people have mentioned in Slic3r but couldn't find anything... or is there a way to send information faster with my pi zero?

[matguy87]

Also, I know in Slic3r they have a speed for small circles which you can set really low which I also think helps with the issue... anything like this in Cura?

[krisrok]

searched quite a bit for it and found mesh resolution is now editable in cura: https://github.com/Ultimaker/CuraEngine/pull/657