Jump to content
Sign in to follow this  

Very short pauzes occuring when printing to fast

Recommended Posts

Posted · Very short pauzes occuring when printing to fast

I am using my printer to print at 40mm/sec. However, when I try to print faster the printer (Marlin, RepRap) automatically seems to take a short pause at the furthest point tot the left, recht, bottom en top of the print. Is this a GCode reading problem or is there another software. Would using a SD-Card solve the problem?


Share this post

Link to post
Share on other sites
Posted · Very short pauzes occuring when printing to fast

Are these corners rounded? If there are more than 12 or so segments in the curve at the corner then that is your problem - you really want to limit the number of segments that Marlin has to navigate to less than 12 for every 20mm or so as if you don't it has to slow down and be prepared to stop within 12 gcode commands. Also check your acceleration and jerk settings. Why? Well...

gcodes move the printer in line segments. For example a circle might be 20 line segments. Before marlin and sprinter we had acceleration only and the head would come to a complete stop at each vertex of the circle. This was incredibly slow. This was because at the vertex the acceleration change is instantaneous so you have infinite jerk (accleration is derivative of velocity, jerk is derivative of acceleration). The fix was to introduce a "sprinter jerk" or "marlin jerk" term that is in mm/sec (not mm/sec/sec/sec) which is the allowed instantaneous velocity change at a given point. For ultimakers with it's extremely light weight print head we use 20 for the jerk setting and typically 5000 for the acceleration setting. For a rep rap printer it's more like 5mm/sec for jerk and 1000 for acceleration.

Anyway Marlin runs on a very weak computer that can only look ahead about 12 gcode commands and as it is moving quickly printing a circle it has to be ready to slow down or even stop at the end of the current string of gcodes because it doesn't know what's coming up on the 13th command (may be a stop and retract). So it has to go pretty slow. As long as the next 12 gcodes (line segments) take you far enough Marlin knows it can slow down in time but if there are 12 line segments in the rounded corner of a cube for example it might have to slow to 5mm/sec for those corners which visually appears as a complete stop.

Alternatively USB could be saturated. But the fix is the same - reduce the number of triangles in your STL file. Here is a guide to reducing them for very large STL files (meshlab is free):




Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Our picks

    • Survey: Understanding your workflow
      Interact with future concepts and aim to collect your feedback and opinion. In particular, if this would/could be a welcome addition to your 3D printing workflow. Interested?
      • 0 replies
    • Coronavirus: Let's do our part
      Through this post I would like to further explain what we are doing, and what you could be doing. 
      Our efforts consist of 2 layers. First; connect medical institutions and hospitals to (local) 3D Printing hubs to help them print parts of which a 3D model already exists. And second, contribute to design the necessary part and then have it printed via a (local) 3D printing hub. Experts are available from within Ultimaker and from within our network of 3D printing experts.
        • Like
      • 46 replies
  • Create New...

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!