Deploying to gh-pages from @ DangerKlippers/danger-klipper@261da3c 🚀

404.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="/img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

API_Server.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Axis_Twist_Compensation.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

BLTouch.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Beaglebone.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Bed_Level.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Bed_Mesh.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 
@@ -682,6 +682,13 @@
     Faulty Regions
   </a>
 
+</li>
+
+          <li class="md-nav__item">
+  <a href="#adaptive-meshes" class="md-nav__link">
+    Adaptive Meshes
+  </a>
+
 </li>
 
       </ul>
@@ -1504,6 +1511,13 @@
     Faulty Regions
   </a>
 
+</li>
+
+          <li class="md-nav__item">
+  <a href="#adaptive-meshes" class="md-nav__link">
+    Adaptive Meshes
+  </a>
+
 </li>
 
       </ul>
@@ -1725,7 +1739,7 @@ <h3 id="mesh-interpolation">Mesh Interpolation<a class="headerlink" href="#mesh-
   integer pair, and also may be specified a single integer that is applied
   to both axes.  In this example there are 4 segments along the X axis
   and 2 segments along the Y axis.  This evaluates to 8 interpolated
-  points along X, 6 interpolated points along Y, which results in a 13x8
+  points along X, 6 interpolated points along Y, which results in a 13x9
   mesh.  Note that if mesh_pps is set to 0 then mesh interpolation is
   disabled and the probed matrix will be sampled directly.</li>
 </ul>
@@ -1938,12 +1952,59 @@ <h3 id="faulty-regions">Faulty Regions<a class="headerlink" href="#faulty-region
 in the sample config above.  The replacement points and their coordinates
 are identified in green.</p>
 <p><img alt="bedmesh_interpolated" src="img/bedmesh_faulty_regions.svg" /></p>
+<h3 id="adaptive-meshes">Adaptive Meshes<a class="headerlink" href="#adaptive-meshes" title="Permanent link">&para;</a></h3>
+<p>Adaptive bed meshing is a way to speed up the bed mesh generation by only probing
+the area of the bed used by the objects being printed. When used, the method will
+automatically adjust the mesh parameters based on the area occupied by the defined
+print objects.</p>
+<p>The adapted mesh area will be computed from the area defined by the boundaries of all
+the defined print objects so it covers every object, including any margins defined in
+the configuration. After the area is computed, the number of probe points will be
+scaled down based on the ratio of the default mesh area and the adapted mesh area. To
+illustrate this consider the following example:</p>
+<p>For a 150mmx150mm bed with <code>mesh_min</code> set to <code>25,25</code> and <code>mesh_max</code> set to <code>125,125</code>,
+the default mesh area is a 100mmx100mm square. An adapted mesh area of <code>50,50</code>
+means a ratio of <code>0.5x0.5</code> between the adapted area and default mesh area.</p>
+<p>If the <code>bed_mesh</code> configuration specified <code>probe_count</code> as <code>7x7</code>, the adapted bed
+mesh will use 4x4 probe points (7 * 0.5 rounded up).</p>
+<p><img alt="adaptive_bedmesh" src="img/adaptive_bed_mesh.svg" /></p>
+<div class="highlight"><pre><span></span><code>[bed_mesh]
+speed: 120
+horizontal_move_z: 5
+mesh_min: 35, 6
+mesh_max: 240, 198
+probe_count: 5, 3
+adaptive_margin: 5
+</code></pre></div>
+
+<ul>
+<li>
+<p><code>adaptive_margin</code> <br>
+  <em>Default Value: 0</em> <br>
+  Margin (in mm) to add around the area of the bed used by the defined objects. The diagram
+  below shows the adapted bed mesh area with an <code>adaptive_margin</code> of 5mm. The adapted mesh
+  area (area in green) is computed as the used bed area (area in blue) plus the defined margin.</p>
+<p><img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></p>
+</li>
+</ul>
+<p>By nature, adaptive bed meshes use the objects defined by the Gcode file being printed.
+Therefore, it is expected that each Gcode file will generate a mesh that probes a different
+area of the print bed. Therefore, adapted bed meshes should not be re-used. The expectation
+is that a new mesh will be generated for each print if adaptive meshing is used.</p>
+<p>It is also important to consider that adaptive bed meshing is best used on machines that can
+normally probe the entire bed and achieve a maximum variance less than or equal to 1 layer
+height. Machines with mechanical issues that a full bed mesh normally compensates for may
+have undesirable results when attempting print moves <strong>outside</strong> of the probed area. If a
+full bed mesh has a variance greater than 1 layer height, caution must be taken when using
+adaptive bed meshes and attempting print moves outside of the meshed area.</p>
 <h2 id="bed-mesh-gcodes">Bed Mesh Gcodes<a class="headerlink" href="#bed-mesh-gcodes" title="Permanent link">&para;</a></h2>
 <h3 id="calibration">Calibration<a class="headerlink" href="#calibration" title="Permanent link">&para;</a></h3>
 <p><code>BED_MESH_CALIBRATE PROFILE=&lt;name&gt; METHOD=[manual | automatic] [&lt;probe_parameter&gt;=&lt;value&gt;]
- [&lt;mesh_parameter&gt;=&lt;value&gt;]</code><br>
+ [&lt;mesh_parameter&gt;=&lt;value&gt;] [ADAPTIVE=[0|1] [ADAPTIVE_MARGIN=&lt;value&gt;]</code><br>
 <em>Default Profile:  default</em><br>
-<em>Default Method:  automatic if a probe is detected, otherwise manual</em></p>
+<em>Default Method:  automatic if a probe is detected, otherwise manual</em> <br>
+<em>Default Adaptive: 0</em> <br>
+<em>Default Adaptive Margin: 0</em></p>
 <p>Initiates the probing procedure for Bed Mesh Calibration.</p>
 <p>The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter,
 or <code>default</code> if unspecified. If <code>METHOD=manual</code> is selected then manual probing
@@ -1966,6 +2027,8 @@ <h3 id="calibration">Calibration<a class="headerlink" href="#calibration" title=
 </li>
 <li>All beds:<ul>
 <li><code>ALGORITHM</code></li>
+<li><code>ADAPTIVE</code></li>
+<li><code>ADAPTIVE_MARGIN</code></li>
 </ul>
 </li>
 </ul>

Benchmarks.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Bootloader_Entry.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Bootloaders.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

CANBUS.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

CANBUS_Troubleshooting.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

CANBUS_protocol.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

CONTRIBUTING.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Code_Overview.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 
@@ -1532,8 +1532,9 @@ <h2 id="code-flow-of-a-move-command">Code flow of a move command<a class="header
 <ul>
 <li>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks
   the timing of printing actions. The main codepath for a move is:
-  <code>ToolHead.move() -&gt; MoveQueue.add_move() -&gt; MoveQueue.flush() -&gt;
-  Move.set_junction() -&gt; ToolHead._process_moves()</code>.<ul>
+  <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt;
+  LookAheadQueue.flush() -&gt; Move.set_junction() -&gt;
+  ToolHead._process_moves()</code>.<ul>
 <li>ToolHead.move() creates a Move() object with the parameters of the
 move (in cartesian space and in units of seconds and millimeters).</li>
 <li>The kinematics class is given the opportunity to audit each move
@@ -1542,10 +1543,10 @@ <h2 id="code-flow-of-a-move-command">Code flow of a move command<a class="header
 may raise an error if the move is not valid. If check_move()
 completes successfully then the underlying kinematics must be able
 to handle the move.</li>
-<li>MoveQueue.add_move() places the move object on the "look-ahead"
-queue.</li>
-<li>MoveQueue.flush() determines the start and end velocities of each
-move.</li>
+<li>LookAheadQueue.add_move() places the move object on the
+"look-ahead" queue.</li>
+<li>LookAheadQueue.flush() determines the start and end velocities of
+each move.</li>
 <li>Move.set_junction() implements the "trapezoid generator" on a
 move. The "trapezoid generator" breaks every move into three parts:
 a constant acceleration phase, followed by a constant velocity
@@ -1569,17 +1570,18 @@ <h2 id="code-flow-of-a-move-command">Code flow of a move command<a class="header
   placed on a "trapezoid motion queue": <code>ToolHead._process_moves() -&gt;
   trapq_append()</code> (in klippy/chelper/trapq.c). The step times are then
   generated: <code>ToolHead._process_moves() -&gt;
-  ToolHead._update_move_time() -&gt; MCU_Stepper.generate_steps() -&gt;
-  itersolve_generate_steps() -&gt; itersolve_gen_steps_range()</code> (in
-  klippy/chelper/itersolve.c). The goal of the iterative solver is to
-  find step times given a function that calculates a stepper position
-  from a time. This is done by repeatedly "guessing" various times
-  until the stepper position formula returns the desired position of
-  the next step on the stepper. The feedback produced from each guess
-  is used to improve future guesses so that the process rapidly
-  converges to the desired time. The kinematic stepper position
-  formulas are located in the klippy/chelper/ directory (eg,
-  kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c).</li>
+  ToolHead._advance_move_time() -&gt; ToolHead._advance_flush_time() -&gt;
+  MCU_Stepper.generate_steps() -&gt; itersolve_generate_steps() -&gt;
+  itersolve_gen_steps_range()</code> (in klippy/chelper/itersolve.c). The
+  goal of the iterative solver is to find step times given a function
+  that calculates a stepper position from a time. This is done by
+  repeatedly "guessing" various times until the stepper position
+  formula returns the desired position of the next step on the
+  stepper. The feedback produced from each guess is used to improve
+  future guesses so that the process rapidly converges to the desired
+  time. The kinematic stepper position formulas are located in the
+  klippy/chelper/ directory (eg, kin_cart.c, kin_corexy.c,
+  kin_delta.c, kin_extruder.c).</li>
 </ul>
 <ul>
 <li>Note that the extruder is handled in its own kinematic class:

Command_Templates.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 

Config_Changes.html

@@ -9,7 +9,7 @@
 
 
       <link rel="icon" href="img/favicon.ico">
-      <meta name="generator" content="mkdocs-1.2.3, mkdocs-material-8.1.3">
+      <meta name="generator" content="mkdocs-1.2.4, mkdocs-material-8.1.3">
 
 
 
@@ -1307,6 +1307,16 @@ <h1 id="configuration-changes">Configuration Changes<a class="headerlink" href="
 document when upgrading the Klipper software.</p>
 <p>All dates in this document are approximate.</p>
 <h2 id="changes">Changes<a class="headerlink" href="#changes" title="Permanent link">&para;</a></h2>
+<p>20240123: The output_pin SET_PIN CYCLE_TIME parameter has been
+removed. Use the new
+<a href="Config_Reference.html#pwm_cycle_time">pwm_cycle_time</a> module if it is
+necessary to dynamically change a pwm pin's cycle time.</p>
+<p>20240123: The output_pin <code>maximum_mcu_duration</code> parameter is
+deprecated. Use a <a href="Config_Reference.html#pwm_tool">pwm_tool config section</a>
+instead. The option will be removed in the near future.</p>
+<p>20240123: The output_pin <code>static_value</code> parameter is deprecated.
+Replace with <code>value</code> and <code>shutdown_value</code> parameters.  The option will
+be removed in the near future.</p>
 <p>20231216: The <code>[hall_filament_width_sensor]</code> is changed to trigger filament runout
 when the thickness of the filament exceeds <code>max_diameter</code>. The maximum diameter
 defaults to <code>default_nominal_filament_diameter + max_difference</code>. See