🔖 Version 2.1.3-b2

_data/marlin.yml

@@ -25,11 +25,11 @@ downloads:
 
 betas:
   -
-    version: 2.1.3-b1
-    description: Marlin 2.1.3 beta 1
+    version: 2.1.3-b2
+    description: Marlin 2.1.3 beta 2
     extra: Major new release currently in public beta testing
-    file: 2.1.3-b1.zip
-    config: release-2.1.3-b1
+    file: 2.1.3-b2.zip
+    config: release-2.1.3-b2
 
 nightlies:
   -

_development/code_structure.md

@@ -211,7 +211,7 @@ In its most basic form, a motion command goes through this flow:
 
 1. A movement command specifies a destination position and a nominal feedrate that it would like to achieve. The actual speed will depend on how fast the machine can accelerate and how far the machine will move before it has to change direction.
 2. Marlin only does linear moves at the level of the Planner, so commands like `G2`/`G3`/`G5` are converted into several small linear segments. The same goes for Delta and SCARA kinematics and leveled moves. So at this stage Marlin may generate several smaller segments and add them to the Planner Queue.
-3. The machine can't instantly go from a full-stop to a fast move rate, nor can it just instantly stop, so all moves need to be accelerated or decelerated to the requested feedrate. As each move goes into the queue we do a "lookahead" over the entire queue to determine each block's achievable start and end speeds. Acceleration can be linear or slightly curved.
+3. The machine can't instantly go to the target feedrate, so all moves must be accelerated or decelerated over some period of time to minimize jerk and judder. As each move goes into the queue the Planner does a "lookahead" over the entire queue to determine the start and end speed for each block. Acceleration can be linear or slightly curved.
 One problem you might encounter is "juddering" on curves. This is caused by small segments completing so quickly that the Planner queue gets emptied out. As a result the machine is forced to decelerate to the minimal "jerk" speed. Marlin can throttle the UI and/or slow down moves to try and prevent this, but it's not always enough. The simple solution is to configure your slicer to produce longer segments on curves, or to use `G2`/`G3` arcs.
 4. The Stepper ISR is a high priority interrupt routine that obediently fetches and processes the Planner queue until there are no more segments in the queue. Since it produces the actual STEP signals to the stepper motors it may need to run as often as 40,000 times or more per second.
 In practice we want to run it as often as possible because this improves timing and reduces "aliasing" (i.e., rounding). The Stepper ISR uses the clever and fast [Bresenham line algorithm](//en.wikipedia.org/wiki/Bresenham's_line_algorithm) to coordinate the timing of STEP signals. This algorithm benefits from finer resolution, so we get more accurate timing by running the Stepper ISR "as often as possible."