Skip to main content

Computing Junction Deviation for Marlin Firmware

  As part of developing my own 3D printer firmware, I also keep an eye on what is happening in other firmware.  One feature that is causing confusion in the Marlin community is the junction deviation setting.  Up until recently, Marlin used the jerk method (hence forth referred to as "archaic jerk") it inherited from Grbl for computing corning speed (junction velocity).  With the option now in Marlin to use junction deviation instead of jerk, there are many people who want to know what are good settings for junction deviation to insure they get reasonable movement while printing.  In this post I will give an equation for converting the jerk values into junction deviation and my derivation of this equation.

I will not rehash what junction deviation is in this post, so anyone interested in learning more about it should refer to these two links:,739819

For those who are only here for the end results, here is the equation to compute junction deviation:

A typical Cartesian machine might have a jerk setting of 9mm/s and a printing acceleration of 1500mm/s^2.  Plugging these numbers into the above equation goes like this:

So for this example the junction deviation would be set to 0.022 and the configuration_adv.h file would look like this:

// Use Junction Deviation instead of traditional Jerk Limiting
  #define JUNCTION_DEVIATION_MM 0.022 // (mm) distance from real junction edge

The smaller the junction deviation number, the more the machine will slow down when encountering corners.  Making this number too small may slow down the print speed and cause over extrusion in the corners.  Making the number larger will increase the speed at which the machine traverses corners.  Setting this number too high may cause vibrations in the mechanism that produce ringing in the print surface or in extreme cases a stepper motor to loose position.

If you only came here for the basic equation, you do not need to read any further.  For those who would like to learn where the above equation came from, keep on reading.

To setup this problem, we are going to imagine a situation where the printer traverses two moves that are at right angles to each other:

This is a convenient situation as it is the case where one axis suddenly stops moving, and the other axis suddenly starts moving.  When using the archaic jerk functionality the first axis will decelerate down to the the jerk velocity in the corner and then instantly stop, at the same moment the second axis will suddenly jump up to the jerk velocity in its direction and accelerate back up to printing speed.  To simplify this, we can say that with a 90 degree corner, the junction velocity is the same as the jerk setting. (note: this is not the case for any junction that is not 90 deg).

Next we can take that same corner move and add the virtual arc that junction deviation uses to compute the junction velocity:

In the above picture d represents the junction deviation and R is the radius of the virtual arc.

Using the Pythagorean theorem and a little algebra and we get this relationship between R and d:


Next we take the equation for radial acceleration and solve for the radius:


If we combine equations 1 and 2 above we find the following:

In this situation, the radial acceleration is the same as the printing acceleration and the junction velocity is the same as the archaic jerk setting.  Substituting these in, we get the final equation:

Using this equation will allow someone who is migrating from the archaic jerk to junction deviation to start with settings that are very close to each other without excessive experimentation or testing.

Please let me know if you have any questions.



  1. Wow that singular diagram of what Junction Deviation is makes the whole thing make so much more sense.


  2. Thanks Philip. Perfect explanation

  3. Great work. If I can give some constructive feedback, you probably shouldn't call jerk a velocity.. it really isn't. At least if correctly implemented in the firmware, it would be a limit to the change in acceleration over the change in time in mm/sec^3. Calling it a velocity isn't really right, its a bound on how quickly you can change acceleration (not how quickly you can accelerate).

    1. In Marlin, the units for jerk are mm/s, as such it is a velocity. In my opinion Marlin abuses the term Jerk as it is not the same as classic kinematic jerk (rate of change of acceleration). In Marlin, jerk is used to limit the rate of change of velocity when starting, stopping or changing direction.

  4. Great explanation. What would the G-code be to define a custom junction deviation in your start code?


      M205 J0.022

  5. Hi, how does one find out if JD is active or not? Thanks

  6. Quick question. The jerk setting can be done in the firmware. On the acceleration spped, are you refering tonthe slicer setting or the max accel setting in the firmware?

    1. This question depends, on what you exactly want to set the firmware setting to....

      If your "firmware's" combo of Jerk and acceleration works fine, I'd calculate the firmware "default" setting from that values.
      If you want the default setting to be "same" or say similar to what you observe while printing with your slicers setting, I'd calculate from those settings.
      (Hope I am understandable).
      Or in other words:
      My printer e.g. a acceleration of 5000mm/s^2 is the absolute mechanical limit and may already cause step losses.
      4500 mm/s^2 acceleration is where I have a safe distance from that, but have vibrations from the "hard braking".
      4000 mm/s^2 is where I can acceptably travel and vibrations caused are acceptable small, if a print starts imediately after the travel.
      3600 mm/s^2 is where I am able to have a acceptable "printed" corner.
      3200 mm/s^2 is where I print and get "in my view" nice results on classic jerk.
      1800 mm/s^2 is where my slicer suggests print accel and uses, if I don't modify it.
      So I did set the Value resulting from 4000 mm/s^2 as the firmwares "default" and started testing at the value resulting from 1.800 mm/s^2 for the "best" value to be used in the startcode

  7. Thank you very much for this information, it's always fascinating to see how these firmware implementations affect print quality. I know it may have been a while since you've been back to this post, but theoretically since we have this equation with variables of known value we can solve this to find the Jerk setting. However, since Jerk would be commented out to allow for use of Juction Deviation how can it be used in the equation to find Junction Deviation? Since its not a set or known value that we give to the printer, the actual Junction Deviation value cannot be calculated unless there is some hidden Jerk setting that we need to find, otherwise we just arbitrarily define the value in the firmware. Am I missing something or is the equation somewhat misleading, and rather we actually need to do (like with Linear Advance) calibration tests to find the best range of values for Junction Deviation?

    1. This equation was intended to help people transitioning from known good jerk settings to JD. Regardless of how you get your starting number, real world test prints are the best way to determine the "right" final value.

  8. On my creality 4.2.2 it makes no difference.. I have accleration at 1500mm/s/s and setting jd to various values from 1 all the way down to 0.001 makes no difference to the right angle corners in a cube..

    Any ideas anyone!


Post a Comment

Popular posts from this blog

Introduction to Kynetic CNC

  This project started as a result of the the wildly successful Teensy 3.5/3.6 kickstarter .  At the time I was amazed by the specifications of these microcontrollers and thought, "With all of that processing power, could I create from the ground up a completely new 32bit 3D print engine that would improve upon the capabilities of the current 8 bit printer controllers?"  Soon after that, I started making notes about how I would do motion control if not limited by the power of the processor.   After two years of part time work on this project (I have a full time job and full time family),  I'm now ready to discuss the details and where it is going.

Extra Smooth Moves

  In an effort to provide a no compromises motion controller, one major milestone is converting the trajectory planner and motion control from constant acceleration to minimum jerk.  For simplicities sake, the original Kynetic motion controller was done as constant acceleration.  I have now completed the work to make it use the much smoother minimum jerk algorithm.