Deploying to gh-pages from @ Klipper3d/klipper@9323a5dfe2 🚀

2025-07-17 00:06:19 +00:00
parent efffd67cc9
commit 0ba73903e0
78 changed files with 3767 additions and 567 deletions
--- a/fr/API_Server.html
+++ b/fr/API_Server.html
@@ -1181,6 +1181,13 @@
    load_cell/dump_force
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probedump_taps" class="md-nav__link">
+    load_cell_probe/dump_taps
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -1711,6 +1718,13 @@
    load_cell/dump_force
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probedump_taps" class="md-nav__link">
+    load_cell_probe/dump_taps
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -1871,6 +1885,19 @@ gcode:
 <p>This endpoint is used to subscribe to force data produced by a load_cell. Using this endpoint may increase Klipper's system load.</p>
 <p>A request may look like: <code>{"id": 123, "method":"load_cell/dump_force", "params": {"sensor": "load_cell", "response_template": {}}}</code> and might return: <code>{"id": 123,"result":{"header":["time", "force (g)", "counts", "tare_counts"]}}</code> and might later produce asynchronous messages such as: <code>{"params":{"data":[[3292.432935, 40.65, 562534, -234467]]}}</code></p>
 <p>Le champ "en-tête" dans la réponse initiale à la requête est utilisé pour décrire les champs présents dans les réponses "données" ultérieures.</p>
+<h3 id="load_cell_probedump_taps">load_cell_probe/dump_taps<a class="headerlink" href="#load_cell_probedump_taps" title="Permanent link">&para;</a></h3>
+<p>This endpoint is used to subscribe to details of probing "tap" events. Using this endpoint may increase Klipper's system load.</p>
+<p>A request may look like: <code>{"id": 123, "method":"load_cell/dump_force", "params": {"sensor": "load_cell", "response_template": {}}}</code> and might return: <code>{"id": 123,"result":{"header":["probe_tap_event"]}}</code> and might later produce asynchronous messages such as:</p>
+<div class="highlight"><pre><span></span><code>{&quot;params&quot;:{&quot;tap&quot;:&#39;{
+   &quot;time&quot;: [118032.28039, 118032.2834, ...],
+   &quot;force&quot;: [-459.4213119680034, -458.1640702543264, ...],
+}}}
+</code></pre></div>
+
+<p>This data can be used to render:</p>
+<ul>
+<li>The time/force graph</li>
+</ul>
 <h3 id="pause_resumecancel">pause_resume/cancel<a class="headerlink" href="#pause_resumecancel" title="Permanent link">&para;</a></h3>
 <p>Ce point final est similaire à l'exécution de la commande G-Code "PRINT_CANCEL". Par exemple : <code>{"id": 123, "method": "pause_resume/cancel"}</code></p>
 <p>Comme pour le point de terminaison "gcode/script", ce point de terminaison ne se termine qu'après la fin de toutes les commandes G-Code en attente.</p>
--- a/fr/Bed_Mesh.html
+++ b/fr/Bed_Mesh.html
@@ -2083,7 +2083,7 @@ scan_overshoot: 8
 <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 | scan | rapid_scan] \ [&lt;probe_parameter&gt;=&lt;value&gt;] [&lt;mesh_parameter&gt;=&lt;value&gt;] [ADAPTIVE=[0|1] \ [ADAPTIVE_MARGIN=&lt;value&gt;]</code> <em>Default Profile: default</em> <em>Default Method: automatic if a probe is detected, otherwise manual</em>  <em>Default Adaptive: 0</em>  <em>Default Adaptive Margin: 0</em></p>
 <p>Lance la procédure de palpage de l'étalonnage du maillage du lit.</p>
-<p>The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. The <code>METHOD</code> parameter takes one of the following values:</p>
+<p>The mesh will be immediately ready to use when the command completes and saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. The <code>METHOD</code> parameter takes one of the following values:</p>
 <ul>
 <li><code>METHOD=manual</code>: enables manual probing using the nozzle and the paper test</li>
 <li><code>METHOD=automatic</code>: Automatic (standard) probing. This is the default.</li>
@@ -2123,6 +2123,7 @@ scan_overshoot: 8
 <p>Tout autre profil enregistré peut être supprimé de la même manière, en remplaçant <em>default</em> par le nom du profil que vous souhaitez supprimer.</p>
 <h4 id="chargement-du-profil-par-defaut">Chargement du profil par défaut<a class="headerlink" href="#chargement-du-profil-par-defaut" title="Permanent link">&para;</a></h4>
 <p>Les versions précédentes de <code>bed_mesh</code> chargeaient toujours le profil nommé <em>default</em> au démarrage s'il était présent. Ce comportement a été supprimé afin de permettre à l'utilisateur de déterminer quand un profil est chargé. Si un utilisateur souhaite charger le profil par défaut, il est recommandé d'ajouter <code>BED_MESH_PROFILE LOAD=default</code> à sa macro <code>START_PRINT</code> ou à la configuration "Start G-Code" de son trancheur, selon ce qui est applicable.</p>
+<p>Note that this is not required if a new mesh is generated with <code>BED_MESH_CALIBRATE</code> in the <code>START_PRINT</code> macro or the slicer's "Start G-Code" and may produce unexpected results, especially with adaptive meshing.</p>
 <p>Alternativement, l'ancien comportement de chargement d'un profil au démarrage peut être restauré avec un <code>[delayed_gcode]</code> :</p>
 <div class="highlight"><pre><span></span><code><span class="k">[delayed_gcode bed_mesh_init]</span>
 <span class="na">initial_duration</span><span class="o">:</span><span class="w"> </span><span class="s">.01</span>
--- a/fr/Benchmarks.html
+++ b/fr/Benchmarks.html
@@ -1174,6 +1174,13 @@
    Test du taux de pas sur STM32G0B1
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
+    STM32G4 step rate benchmark
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -1613,6 +1620,13 @@
    Test du taux de pas sur STM32G0B1
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#stm32g4-step-rate-benchmark" class="md-nav__link">
+    STM32G4 step rate benchmark
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -2040,6 +2054,34 @@ finalize_config crc=0
 </tr>
 </tbody>
 </table>
+<h3 id="stm32g4-step-rate-benchmark">STM32G4 step rate benchmark<a class="headerlink" href="#stm32g4-step-rate-benchmark" title="Permanent link">&para;</a></h3>
+<p>The following configuration sequence is used on the STM32G431:</p>
+<div class="highlight"><pre><span></span><code>allocate_oids count=3
+config_stepper oid=0 step_pin=PA0 dir_pin=PB5 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=17
+finalize_config crc=0
+</code></pre></div>
+
+<p>The test was last run on commit <code>cfa48fe3</code> with gcc version <code>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</code>.</p>
+<table>
+<thead>
+<tr>
+<th>stm32g431</th>
+<th>ticks</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td>1 moteur pas à pas</td>
+<td>47</td>
+</tr>
+<tr>
+<td>3 moteurs pas à pas</td>
+<td>208</td>
+</tr>
+</tbody>
+</table>
 <h3 id="test-du-taux-de-pas-sur-lpc176x">Test du taux de pas sur LPC176x<a class="headerlink" href="#test-du-taux-de-pas-sur-lpc176x" title="Permanent link">&para;</a></h3>
 <p>La séquence de configuration suivante est utilisée sur le LPC176x :</p>
 <div class="highlight"><pre><span></span><code>allocate_oids count=3
@@ -2252,7 +2294,7 @@ finalize_config crc=0
 </tr>
 </tbody>
 </table>
-<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 5 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
+<p>(*) Note that the reported rp2040 ticks are relative to a 12Mhz scheduling timer and do not correspond to its 200Mhz internal ARM processing rate. It is expected that 3 scheduling ticks corresponds to ~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM core cycles.</p>
 <h3 id="test-du-taux-de-pas-pour-le-mcu-linux">Test du taux de pas pour le MCU Linux<a class="headerlink" href="#test-du-taux-de-pas-pour-le-mcu-linux" title="Permanent link">&para;</a></h3>
 <p>La séquence de configuration suivante est utilisée sur un Raspberry Pi :</p>
 <div class="highlight"><pre><span></span><code>allocate_oids count=3
@@ -2289,7 +2331,8 @@ get_uptime
 </code></pre></div>

 <p>Une fois le test terminé, déterminez la différence entre les horloges signalées dans les deux messages de réponse "uptime". Le nombre total de commandes par seconde est alors <code>100000 * mcu_frequency / clock_diff</code>.</p>
-<p>Notez que ce test peut saturer la capacité USB/CPU d'un Raspberry Pi. En cas d'exécution sur un Raspberry Pi, Beaglebone ou un ordinateur hôte similaire, augmentez le délai (par exemple, <code>DELAY {clock + 20*freq} get_uptime</code>). Le cas échéant, les tests de performances ci-dessous concernent console.py exécuté sur une machine de bureau avec l'appareil connecté via un concentrateur à haut débit.</p>
+<p>The USB tests may exceed the CPU capacity of a Raspberry Pi. If running on a Raspberry Pi, Beaglebone, or similar host computer then increase the delay (eg, <code>DELAY {clock + 20*freq} get_uptime</code>). Where applicable, the benchmarks below are with console.py running on a desktop class machine with the device connected via a super-speed hub.</p>
+<p>The CAN bus tests may saturate the USB host controller of a Raspberry Pi (when testing via a standard gs_usb USB to CAN bus adapter). Where applicable, the CAN bus benchmarks below are with console.py running on a desktop class machine with a USB to CAN bus adapter connected via a super-speed USB hub.</p>
 <table>
 <thead>
 <tr>
@@ -2301,12 +2344,6 @@ get_uptime
 </thead>
 <tbody>
 <tr>
-<td>stm32f042 (CAN)</td>
-<td>18K</td>
-<td>c105adc8</td>
-<td>arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1</td>
-</tr>
-<tr>
 <td>atmega2560 (serial)</td>
 <td>23K</td>
 <td>b161a69e</td>
@@ -2319,6 +2356,12 @@ get_uptime
 <td>arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0</td>
 </tr>
 <tr>
+<td>rp2350 (CAN)</td>
+<td>59K</td>
+<td>17b8ce4c</td>
+<td>arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0</td>
+</tr>
+<tr>
 <td>at90usb1286 (USB)</td>
 <td>75K</td>
 <td>01d2183f</td>
--- a/fr/CANBUS.html
+++ b/fr/CANBUS.html
@@ -1543,12 +1543,7 @@ iface can0 can static

 <ul>
 <li>Le « pont mcu » n'est pas en fait sur le bus CAN. Les messages entrant et sortant du bridge mcu ne seront pas vus par les autres adaptateurs présents sur le bus CAN.</li>
-<li>
-<p>La bande passante disponible pour tous les appareils du bus CAN (et du bridge mcu) est limitée par la fréquence de bus CAN. Par conséquent, il est recommandé d'utiliser une fréquence de bus CAN de 1000000 lors de l'utilisation du mode "USB to CAN bus bridge".</p>
-<p>Même à une fréquence de bus CAN de 1000000, il peut ne pas y avoir assez de bande passante pour exécuter un test <code>SHAPER_CALIBRATE</code> si les deux steppers XY et l'accéléromètre communiquent tous par une seule interface "USB to CAN bus".</p>
-</li>
-</ul>
-<ul>
+<li>La bande passante disponible pour tous les appareils du bus CAN (et du bridge mcu) est limitée par la fréquence de bus CAN. Par conséquent, il est recommandé d'utiliser une fréquence de bus CAN de 1000000 lors de l'utilisation du mode "USB to CAN bus bridge".</li>
 <li>It is only valid to use USB to CAN bridge mode if there is a functioning CAN bus with at least one other node available (in addition to the bridge node itself). Use a standard USB configuration if the goal is to communicate only with the single USB device. Using USB to CAN bridge mode without a fully functioning CAN bus (including terminating resistors and an additional node) may result in sporadic errors even when communicating with the bridge node.</li>
 <li>Une carte de pont USB à CAN n'apparaîtra pas en tant que périphérique série USB, elle ne s'affichera pas lors de l'execution de la commande <code>ls /dev/serial/by-id</code>, et elle ne peut pas être configurée dans le fichier Klipper avec un paramètre <code>serial:</code>. La carte pont apparaît comme un « adaptateur CAN USB » et est configuré dans le printer.cfg en tant que <a href="#configuring-klipper">Nœud CAN</a>.</li>
 </ul>
--- a/fr/Code_Overview.html
+++ b/fr/Code_Overview.html
@@ -1577,6 +1577,7 @@
 </ul>
 </li>
 <li>S'il y a une erreur dans la configuration de l'utilisateur, assurez-vous de la signaler pendant les phases <code>load_config()</code> ou "connect event". Utilisez soit <code>raise config.error("mon erreur")</code> soit <code>raise printer.config_error("mon erreur")</code> pour signaler l'erreur.</li>
+<li>Do not store a reference to the <code>config</code> object in a class member variable (nor in any similar location that may persist past initial module loading). The <code>config</code> object is a reference to a "config loading phase" class and it is not valid to invoke its methods after the "config loading phase" has completed.</li>
 <li>Utilisez le module "pins" pour configurer une broche sur un micro-contrôleur. Ceci est typiquement fait avec quelque chose de similaire à <code>printer.lookup_object("pins").setup_pin("pwm", config.get("my_pin"))</code>. L'objet retourné peut alors être commandé au moment de l'exécution.</li>
 <li>Si l'objet imprimante définit une méthode <code>get_status()</code>, le module peut exporter des <a href="Status_Reference.html">informations d'état</a> via des <a href="Command_Templates.html">macros</a> et via le <a href="API_Server.html">serveur API</a>. La méthode <code>get_status()</code> doit retourner un dictionnaire Python dont les clés sont des chaînes de caractères et les valeurs des entiers, des flottants, des chaînes de caractères, des listes, des dictionnaires, True, False ou None. Les tuples (et les tuples nommés) peuvent également être utilisés (ils apparaissent comme des listes lorsqu'on y accède via le serveur API). Les listes et les dictionnaires exportés doivent être traités comme "immuables" - si leur contenu change, un nouvel objet doit être renvoyé par <code>get_status()</code>, sinon le serveur API ne détectera pas ces changements.</li>
 <li>Si le module doit accéder à la temporisation du système ou à des descripteurs de fichiers externes, utilisez <code>printer.get_reactor()</code> pour obtenir l'accès à la classe globale "event reactor". Cette classe de réacteur permet de programmer des temporisations, d'attendre des entrées sur des descripteurs de fichiers, et d'"endormir" le code hôte.</li>
--- a/fr/Config_Reference.html
+++ b/fr/Config_Reference.html
@@ -657,6 +657,13 @@
    Cinématique du treuil à câble
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#generic-cartesian-kinematics" class="md-nav__link">
+    Generic Cartesian Kinematics
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -1714,6 +1721,13 @@
      </ul>
    </nav>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    [load_cell_probe]
+  </a>
+  
 </li>
        
      </ul>
@@ -2793,6 +2807,13 @@
    Cinématique du treuil à câble
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#generic-cartesian-kinematics" class="md-nav__link">
+    Generic Cartesian Kinematics
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -3850,6 +3871,13 @@
      </ul>
    </nav>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    [load_cell_probe]
+  </a>
+  
 </li>
        
      </ul>
@@ -4027,8 +4055,9 @@ serial :
 <div class="highlight"><pre><span></span><code>[printer]
 kinematics:
 #   The type of printer in use. This option may be one of: cartesian,
-#   corexy, corexz, hybrid_corexy, hybrid_corexz, rotary_delta, delta,
-#   deltesian, polar, winch, or none. This parameter must be specified.
+#   corexy, corexz, hybrid_corexy, hybrid_corexz, generic_cartesian,
+#   rotary_delta, delta, deltesian, polar, winch, or none.
+#   This parameter must be specified.
 max_velocity:
 #   Maximum velocity (in mm/s) of the toolhead (relative to the
 #   print). This parameter must be specified.
@@ -4536,6 +4565,123 @@ anchor_z:
 #    Ces paramètres doivent être fournis.
 </code></pre></div>

+<h3 id="generic-cartesian-kinematics">Generic Cartesian Kinematics<a class="headerlink" href="#generic-cartesian-kinematics" title="Permanent link">&para;</a></h3>
+<p>See <a href="https://github.com/Klipper3d/klipper/blob/master/config/example-generic-caretesian.cfg">example-generic-cartesian.cfg</a> for an example generic Cartesian kinematics config file.</p>
+<p>This printer kinematic class allows a user to define in a pretty flexible manner an arbitrary Cartesian-style kinematics. In principle, the regular cartesian, corexy, hybrid_corexy can be defined this way too. However, more importantly, various otherwise unsupported kinematics such as inverted hybrid_corexy or corexyuv can be defined using this kinematic.</p>
+<p>Notably, the definition of a generic Cartesian kinematic deviates significantly from the other kinematic types. It follows the following convention: a user defines a set of carriages with certain range of motion that can move independently from each other (they should move over the Cartesian axes X, Y, and Z, hence the name of the kinematic) and corresponding endstops that allow the firmware to determine the position of carriages during homing, as well as a set of steppers that move those carriages. The <code>[printer]</code> section must specify the kinematic and other printer-level settings same as the regular Cartesian kinematic:</p>
+<div class="highlight"><pre><span></span><code>[printer]
+kinematics: generic_cartesian
+max_velocity:
+max_accel:
+#minimum_cruise_ratio:
+#square_corner_velocity:
+#max_accel_to_decel:
+#max_z_velocity:
+#max_z_accel:
+</code></pre></div>
+
+<p>Then a user must define the following three carriages: <code>[carriage x]</code>, <code>[carriage y]</code>, and <code>[carriage z]</code>, e.g.</p>
+<div class="highlight"><pre><span></span><code>[carriage x]
+endstop_pin:
+#   Endstop switch detection pin. If this endstop pin is on a
+#   different mcu than the stepper motor(s) moving this carriage,
+#   then it enables &quot;multi-mcu homing&quot;. This parameter must be provided.
+#position_min: 0
+#   Minimum valid distance (in mm) the user may command the carriage to
+#   move to.  The default is 0mm.
+position_endstop:
+#   Location of the endstop (in mm). This parameter must be provided.
+position_max:
+#   Maximum valid distance (in mm) the user may command the stepper to
+#   move to. This parameter must be provided.
+#homing_speed: 5.0
+#   Maximum velocity (in mm/s) of the carriage when homing. The default
+#   is 5mm/s.
+#homing_retract_dist: 5.0
+#   Distance to backoff (in mm) before homing a second time during
+#   homing. Set this to zero to disable the second home. The default
+#   is 5mm.
+#homing_retract_speed:
+#   Speed to use on the retract move after homing in case this should
+#   be different from the homing speed, which is the default for this
+#   parameter
+#second_homing_speed:
+#   Velocity (in mm/s) of the carriage when performing the second home.
+#   The default is homing_speed/2.
+#homing_positive_dir:
+#   If true, homing will cause the carriage to move in a positive
+#   direction (away from zero); if false, home towards zero. It is
+#   better to use the default than to specify this parameter. The
+#   default is true if position_endstop is near position_max and false
+#   if near position_min.
+</code></pre></div>
+
+<p>Afterwards, a user specifies the stepper motors that move these carriages, for instance</p>
+<div class="highlight"><pre><span></span><code>[stepper my_stepper]
+carriages:
+#   A string describing the carriages the stepper moves. All defined
+#   carriages can be specified here, as well as their linear combinations,
+#   e.g. x, x+y, y-0.5*z, x-z, etc. This parameter must be provided.
+step_pin:
+dir_pin:
+enable_pin:
+rotation_distance:
+microsteps:
+#full_steps_per_rotation: 200
+#gear_ratio:
+#step_pulse_duration:
+</code></pre></div>
+
+<p>See <a href="#stepper">stepper</a> section for more information on the regular stepper parameters. The <code>carriages</code> parameter defines how the stepper affects the motion of the carriages. For example, <code>x+y</code> indicates that the motion of the stepper in the positive direction by the distance <code>d</code> moves the carriages <code>x</code> and <code>y</code> by the same distance <code>d</code> in the positive direction, while <code>x-0.5*y</code> means the motion of the stepper in the positive direction by the distance <code>d</code> moves the carriage <code>x</code> by the distance <code>d</code> in the positive direction, but the carriage <code>y</code> will travel distance <code>d/2</code> in the negative direction.</p>
+<p>More than a single stepper motor can be defined to drive the same axis or belt. For example, on a CoreXY AWD setups two motors driving the same belt can be defined as</p>
+<div class="highlight"><pre><span></span><code>[carriage x]
+endstop_pin: ...
+...
+
+[carriage y]
+endstop_pin: ...
+...
+
+[stepper a0]
+carriages: x-y
+step_pin: ...
+dir_pin: ...
+enable_pin: ...
+rotation_distance: ...
+...
+
+[stepper a1]
+carriages: x-y
+step_pin: ...
+dir_pin: ...
+enable_pin: ...
+rotation_distance: ...
+...
+</code></pre></div>
+
+<p>with <code>a0</code> and <code>a1</code> steppers having their own control pins, but sharing the same <code>carriages</code> and corresponding endstops.</p>
+<p>There are situations when a user wants to have more than one endstop per axis. Examples of such configurations include Y axis driven by two independent stepper motors with belts attached to both ends of the X beam, with effectively two carriages on Y axis each having an independent endstop, and multi-stepper Z axis with each stepper having its own endstop (not to be confused with the configurations with multiple Z motors but only a single endstop). These configurations can be declared by specifying additional carriage(s) with their endstops:</p>
+<div class="highlight"><pre><span></span><code>[extra_carriage my_carriage]
+primary_carriage:
+#   The name of the primary carriage this carriage corresponds to.
+#   It also effectively defines the axis the carriage moves over.
+#   This parameter must be provided.
+endstop_pin:
+#   Endstop switch detection pin. This parameter must be provided.
+</code></pre></div>
+
+<p>and the corresponding stepper motors, for example:</p>
+<div class="highlight"><pre><span></span><code>[extra_carriage y1]
+primary_carriage: y
+endstop_pin: ...
+
+[stepper sy1]
+carriages: y1
+...
+</code></pre></div>
+
+<p>Notably, an <code>[extra_carriage]</code> does not define parameters such as <code>position_min</code>, <code>position_max</code>, and <code>position_endstop</code>, but instead inherits them from the specified <code>primary_carriage</code>, thus sharing the same range of motion with the primary carriage.</p>
+<p>For the references on how to configure IDEX setups, see the <a href="#dual-carriage">dual carriage</a> section.</p>
 <h3 id="aucune-cinematique">Aucune cinématique<a class="headerlink" href="#aucune-cinematique" title="Permanent link">&para;</a></h3>
 <p>Il est possible de définir une cinématique particulière "aucune (none)" pour désactiver le support cinématique dans Klipper. Cela peut être utile pour contrôler des périphériques qui ne sont pas des imprimantes 3D typiques ou encore à des fins de débogage.</p>
 <div class="highlight"><pre><span></span><code>[printer]
@@ -5752,9 +5898,9 @@ calibrate_x: ...
 </code></pre></div>

 <h3 id="dual_carriage">[dual_carriage]<a class="headerlink" href="#dual_carriage" title="Permanent link">&para;</a></h3>
-<p>Support for cartesian and hybrid_corexy/z printers with dual carriages on a single axis. The carriage mode can be set via the SET_DUAL_CARRIAGE extended g-code command. For example, "SET_DUAL_CARRIAGE CARRIAGE=1" command will activate the carriage defined in this section (CARRIAGE=0 will return activation to the primary carriage). Dual carriage support is typically combined with extra extruders - the SET_DUAL_CARRIAGE command is often called at the same time as the ACTIVATE_EXTRUDER command. Be sure to park the carriages during deactivation. Note that during G28 homing, typically the primary carriage is homed first followed by the carriage defined in the <code>[dual_carriage]</code> config section. However, the <code>[dual_carriage]</code> carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a <code>position_endstop</code> greater than the primary carriage, or if both carriages home in a negative direction and the <code>[dual_carriage]</code> carriage has a <code>position_endstop</code> less than the primary carriage.</p>
+<p>Support for cartesian, generic_cartesian and hybrid_corexy/z printers with dual carriages on a single axis. The carriage mode can be set via the SET_DUAL_CARRIAGE extended g-code command. For example, "SET_DUAL_CARRIAGE CARRIAGE=1" command will activate the carriage defined in this section (CARRIAGE=0 will return activation to the primary carriage). Dual carriage support is typically combined with extra extruders - the SET_DUAL_CARRIAGE command is often called at the same time as the ACTIVATE_EXTRUDER command. Be sure to park the carriages during deactivation. Note that during G28 homing, typically the primary carriage is homed first followed by the carriage defined in the <code>[dual_carriage]</code> config section. However, the <code>[dual_carriage]</code> carriage will be homed first if both carriages home in a positive direction and the [dual_carriage] carriage has a <code>position_endstop</code> greater than the primary carriage, or if both carriages home in a negative direction and the <code>[dual_carriage]</code> carriage has a <code>position_endstop</code> less than the primary carriage.</p>
 <p>En outre, on pourrait utiliser les commandes "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" ou "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" pour activer le mode copie ou miroir du double chariot, auquel cas il suivra le mouvement du chariot 0 en conséquence. Ces commandes peuvent être utilisées pour imprimer deux pièces simultanément - soit deux pièces identiques (en mode COPY) ou des pièces miroirs (en mode MIRROR). Notez que les modes COPY et MIRROR nécessitent également la configuration appropriée de l'extrudeur sur le double chariot, qui peut généralement être atteint avec "SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=exedual_carriage_extruderю" ou une commande similaire.</p>
-<p>Voir <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> pour un exemple de configuration.</p>
+<p>See <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-idex.cfg">sample-idex.cfg</a> for an example configuration with a regular Cartesian kinematic.</p>
 <div class="highlight"><pre><span></span><code>[dual_carriage]
 axis:
 #   The axis this extra carriage is on (either x or y). This parameter
@@ -5766,7 +5912,7 @@ axis:
 #   error. If safe_distance is not provided, it will be inferred from
 #   position_min and position_max for the dual and primary carriages. If set
 #   to 0 (or safe_distance is unset and position_min and position_max are
-#   identical for the primary and dual carraiges), the carriages proximity
+#   identical for the primary and dual carriages), the carriages proximity
 #   checks will be disabled.
 #step_pin:
 #dir_pin:
@@ -5780,6 +5926,65 @@ axis:
 #   See the &quot;stepper&quot; section for the definition of the above parameters.
 </code></pre></div>

+<p>For an example of dual carriage configuration with <code>generic_cartesian</code> kinematic, see the following configuration <a href="https://github.com/Klipper3d/klipper/blob/master/config/example-generic-caretesian.cfg">sample</a>. Please note that in this case the <code>[dual_carriage]</code> configuration deviates from the configuration described above:</p>
+<div class="highlight"><pre><span></span><code>[dual_carriage my_dc_carriage]
+primary_carriage:
+#   Defines the matching primary carriage of this dual carriage and
+#   the corresponding IDEX axis. Valid choices are x, y, z.
+#   This parameter must be provided.
+#safe_distance:
+#   The minimum distance (in mm) to enforce between the dual and the primary
+#   carriages. If a G-Code command is executed that will bring the carriages
+#   closer than the specified limit, such a command will be rejected with an
+#   error. If safe_distance is not provided, it will be inferred from
+#   position_min and position_max for the dual and primary carriages. If set
+#   to 0 (or safe_distance is unset and position_min and position_max are
+#   identical for the primary and dual carriages), the carriages proximity
+#   checks will be disabled.
+endstop_pin:
+#position_min:
+position_endstop:
+position_max:
+#homing_speed:
+#homing_retract_dist:
+#homing_retract_speed:
+#second_homing_speed:
+#homing_positive_dir:
+...
+</code></pre></div>
+
+<p>Refer to <a href="#generic-cartesian">generic cartesian</a> section for more information on the regular <code>carriage</code> parameters.</p>
+<p>Then a user must define one or more stepper motors moving the dual carriage (and other carriages as appropriate), for instance</p>
+<div class="highlight"><pre><span></span><code>[carriage x]
+...
+
+[carriage y]
+...
+
+[dual_carriage u]
+primary_carriage: x
+...
+
+[stepper dc_stepper]
+carriages: u-y
+...
+</code></pre></div>
+
+<p><code>[dual_carriage]</code> requires special configuration for the input shaper. In general, it is necessary to run input shaper calibration twice - for the <code>dual_carriage</code> and its <code>primary_carriage</code> for the axis they share. Then the input shaper can be configured as follows, assuming the example above:</p>
+<div class="highlight"><pre><span></span><code>[input_shaper]
+# Intentionally empty
+
+[delayed_gcode init_shaper]
+initial_duration: 0.1
+gcode:
+  SET_DUAL_CARRIAGE CARRIAGE=u
+  SET_INPUT_SHAPER SHAPER_TYPE_X=&lt;dual_carriage_x_shaper&gt; SHAPER_FREQ_X=&lt;dual_carriage_x_freq&gt; SHAPER_TYPE_Y=&lt;y_shaper&gt; SHAPER_FREQ_Y=&lt;y_freq&gt;
+  SET_DUAL_CARRIAGE CARRIAGE=x
+  SET_INPUT_SHAPER SHAPER_TYPE_X=&lt;primary_carriage_x_shaper&gt; SHAPER_FREQ_X=&lt;primary_carriage_x_freq&gt; SHAPER_TYPE_Y=&lt;y_shaper&gt; SHAPER_FREQ_Y=&lt;y_freq&gt;
+</code></pre></div>
+
+<p>Note that <code>SHAPER_TYPE_Y</code> and <code>SHAPER_FREQ_Y</code> must be the same in both commands in this case, since the same motors drive Y axis when either of the <code>x</code> and <code>u</code> carriages are active.</p>
+<p>It is worth noting that <code>generic_cartesian</code> kinematic can support two dual carriages for X and Y axes. For reference, see for instance a <a href="https://github.com/Klipper3d/klipper/blob/master/config/sample-corexyuv.cfg">sample</a> of CoreXYUV configuration.</p>
 <h3 id="extruder_stepper">[extruder_stepper]<a class="headerlink" href="#extruder_stepper" title="Permanent link">&para;</a></h3>
 <p>Support pour des moteurs supplémentaires synchronisés avec le mouvement d'une extrudeuse (on peut définir un nombre quelconque de sections avec un préfixe "extruder_stepper").</p>
 <p>Voir la <a href="G-Codes.html#extruder">référence des commandes</a> pour plus d'informations.</p>
@@ -5800,25 +6005,32 @@ extruder:
 <h3 id="manual_stepper">[manual_stepper]<a class="headerlink" href="#manual_stepper" title="Permanent link">&para;</a></h3>
 <p>Pilotes de moteur manuels (on peut définir un nombre quelconque de sections avec le préfixe "manual_stepper"). Ce sont des pilotes de moteur contrôlés par la commande g-code MANUAL_STEPPER. Par exemple "MANUAL_STEPPER STEPPER=my_stepper MOVE=10 SPEED=5". Voir le fichier <a href="G-Codes.html#manual_stepper">G-Codes</a> pour une description de la commande MANUAL_STEPPER. Les pilotes de moteur ne sont pas connectés à la cinématique normale de l'imprimante.</p>
 <div class="highlight"><pre><span></span><code>[manual_stepper my_stepper]
-#step_pin :
-#dir_pin :
-#enable_pin :
-#microsteps :
-#rotation_distance :
-#    Voir la section &quot;stepper&quot; pour une description de ces paramètres.
-#velocity :
-#    Définit la vitesse par défaut (en mm/s) pour le pilote moteur. Cette valeur
-#    sera utilisée si une commande MANUAL_STEPPER ne spécifie pas de paramètre SPEED
-#    La valeur par défaut est 5mm/s.
-#accel
-#    Définit l&#39;accélération par défaut (en mm/s^2) pour le pilote moteur Une
-#    accélération de zéro n&#39;entraînera aucune accélération. Cette valeur
-#    sera utilisée si une commande MANUAL_STEPPER ne spécifie pas de
-#    paramètre ACCEL. La valeur par défaut est zéro.
-#endstop_pin :
-#    Broche de détection de l&#39;interrupteur de fin de course. Si elle est spécifiée, on peut effectuer
-#    des &quot;mouvements de retour à l&#39;origine&quot; en ajoutant un paramètre STOP_ON_ENDSTOP aux
-#    commandes de mouvement MANUAL_STEPPER.
+#step_pin:
+#dir_pin:
+#enable_pin:
+#microsteps:
+#rotation_distance:
+#   See the &quot;stepper&quot; section for a description of these parameters.
+#velocity:
+#   Set the default velocity (in mm/s) for the stepper. This value
+#   will be used if a MANUAL_STEPPER command does not specify a SPEED
+#   parameter. The default is 5mm/s.
+#accel:
+#   Set the default acceleration (in mm/s^2) for the stepper. An
+#   acceleration of zero will result in no acceleration. This value
+#   will be used if a MANUAL_STEPPER command does not specify an ACCEL
+#   parameter. The default is zero.
+#endstop_pin:
+#   Endstop switch detection pin. If specified, then one may perform
+#   &quot;homing moves&quot; by adding a STOP_ON_ENDSTOP parameter to
+#   MANUAL_STEPPER movement commands.
+#position_min:
+#position_max:
+#   The minimum and maximum position the stepper can be commanded to
+#   move to. If specified then one may not command the stepper to move
+#   past the given position. Note that these limits do not prevent
+#   setting an arbitrary position with the `MANUAL_STEPPER
+#   SET_POSITION=x` command. The default is to not enforce a limit.
 </code></pre></div>

 <h2 id="elements-chauffants-et-capteurs-personnalises">Éléments chauffants et capteurs personnalisés<a class="headerlink" href="#elements-chauffants-et-capteurs-personnalises" title="Permanent link">&para;</a></h2>
@@ -7977,6 +8189,63 @@ data_ready_pin:
 #   and &#39;analog_supply&#39;. Default is &#39;internal&#39;.
 </code></pre></div>

+<h3 id="load_cell_probe">[load_cell_probe]<a class="headerlink" href="#load_cell_probe" title="Permanent link">&para;</a></h3>
+<p>Load Cell Probe. This combines the functionality of a [probe] and a [load_cell].</p>
+<div class="highlight"><pre><span></span><code>[load_cell_probe]
+sensor_type:
+#   This must be one of the supported bulk ADC sensor types and support
+#   load cell endstops on the mcu.
+#counts_per_gram:
+#reference_tare_counts:
+#sensor_orientation:
+#   These parameters must be configured before the probe will operate.
+#   See the [load_cell] section for further details.
+#force_safety_limit: 2000
+#   The safe limit for probing force relative to the reference_tare_counts on
+#   the load_cell. The default is +/-2Kg.
+#trigger_force: 75.0
+#   The force that the probe will trigger at. 75g is the default.
+#drift_filter_cutoff_frequency: 0.8
+#   Enable optional continuous taring while homing &amp; probing to reject drift.
+#   The value is a frequency, in Hz, below which drift will be ignored. This
+#   option requires the SciPy library. Default: None
+#drift_filter_delay: 2
+#   The delay, or &#39;order&#39;, of the drift filter. This controls the number of
+#   samples required to make a trigger detection. Can be 1 or 2, the default
+#   is 2.
+#buzz_filter_cutoff_frequency: 100.0
+#   The value is a frequency, in Hz, above which high frequency noise in the
+#   load cell will be igfiltered outnored. This option requires the SciPy
+#   library. Default: None
+#buzz_filter_delay: 2
+#   The delay, or &#39;order&#39;, of the buzz filter. This controle the number of
+#   samples required to make a trigger detection. Can be 1 or 2, the default
+#   is 2.
+#notch_filter_frequencies: 50, 60
+#   1 or 2 frequencies, in Hz, to filter out of the load cell data. This is
+#   intended to reject power line noise. This option requires the SciPy
+#   library.  Default: None
+#notch_filter_quality: 2.0
+#   Controls how narrow the range of frequencies are that the notch filter
+#   removes. Larger numbers produce a narrower filter. Minimum value is 0.5 and
+#   maximum is 3.0. Default: 2.0
+#tare_time:
+#   The rime in seconds used for taring the load_cell before each probe. The
+#   default value is: 4 / 60 = 0.066. This collects samples from 4 cycles of
+#   60Hz mains power to cancel power line noise.
+#z_offset:
+#speed:
+#samples:
+#sample_retract_dist:
+#lift_speed:
+#samples_result:
+#samples_tolerance:
+#samples_tolerance_retries:
+#activate_gcode:
+#deactivate_gcode:
+#   See the &quot;[probe]&quot; section for a description of the above parameters.
+</code></pre></div>
+
 <h2 id="support-materiel-specifique-a-une-carte">Support matériel spécifique à une carte<a class="headerlink" href="#support-materiel-specifique-a-une-carte" title="Permanent link">&para;</a></h2>
 <h3 id="sx1509">[sx1509]<a class="headerlink" href="#sx1509" title="Permanent link">&para;</a></h3>
 <p>Configuration d'un expandeur SX1509 I2C vers GPIO. En raison du délai encouru par la communication I2C, vous ne devez PAS utiliser les broches du SX1509 comme activation du moteur pas à pas, pas ou direction ou toute autre broche nécessitant un changement de bit rapide. Il est préférable de les utiliser comme sorties numériques statiques ou contrôlées par gcode ou comme broches hardware-pwm pour des ventilateurs par exemple. On peut définir un nombre quelconque de sections avec un préfixe "sx1509". Chaque expandeur fournit un ensemble de 16 broches (sx1509_my_sx1509:PIN_0 à sx1509_my_sx1509:PIN_15) pouvant être utilisées dans la configuration de l'imprimante.</p>
--- a/fr/Features.html
+++ b/fr/Features.html
@@ -1541,6 +1541,11 @@
 <td>2507K</td>
 </tr>
 <tr>
+<td>STM32G431</td>
+<td>3617K</td>
+<td>2452K</td>
+</tr>
+<tr>
 <td>STM32F407</td>
 <td>3652K</td>
 <td>2459K</td>
--- a/fr/G-Codes.html
+++ b/fr/G-Codes.html
@@ -1484,6 +1484,26 @@
      </ul>
    </nav>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#generic_cartesian" class="md-nav__link">
+    [generic_cartesian]
+  </a>
+  
+    <nav class="md-nav" aria-label="[generic_cartesian]">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#set_stepper_carriages" class="md-nav__link">
+    SET_STEPPER_CARRIAGES
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
        
          <li class="md-nav__item">
@@ -1682,6 +1702,27 @@
    LOAD_CELL_READ load_cell="name"
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    [load_cell_probe]
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_test_tap" class="md-nav__link">
+    LOAD_CELL_TEST_TAP
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load-cell-command-extensions" class="md-nav__link">
+    Load Cell Command Extensions
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -3780,6 +3821,26 @@
      </ul>
    </nav>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#generic_cartesian" class="md-nav__link">
+    [generic_cartesian]
+  </a>
+  
+    <nav class="md-nav" aria-label="[generic_cartesian]">
+      <ul class="md-nav__list">
+        
+          <li class="md-nav__item">
+  <a href="#set_stepper_carriages" class="md-nav__link">
+    SET_STEPPER_CARRIAGES
+  </a>
+  
+</li>
+        
+      </ul>
+    </nav>
+  
 </li>
        
          <li class="md-nav__item">
@@ -3978,6 +4039,27 @@
    LOAD_CELL_READ load_cell="name"
  </a>
  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    [load_cell_probe]
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load_cell_test_tap" class="md-nav__link">
+    LOAD_CELL_TEST_TAP
+  </a>
+  
+</li>
+        
+          <li class="md-nav__item">
+  <a href="#load-cell-command-extensions" class="md-nav__link">
+    Load Cell Command Extensions
+  </a>
+  
 </li>
        
          <li class="md-nav__item">
@@ -4909,7 +4991,7 @@ section</a> is enabled.</p>
 <h3 id="bed_mesh">[bed_mesh]<a class="headerlink" href="#bed_mesh" title="Permanent link">&para;</a></h3>
 <p>Les commandes suivantes sont disponibles lorsque la section <a href="Config_Reference.html#bed_mesh">configuration de bed_mesh</a> est activée (voir également le <a href="Bed_Mesh.html">guide de bed_mesh</a>).</p>
 <h4 id="bed_mesh_calibrate">BED_MESH_CALIBRATE<a class="headerlink" href="#bed_mesh_calibrate" title="Permanent link">&para;</a></h4>
-<p><code>BED_MESH_CALIBRATE [PROFILE=&lt;name&gt;] [METHOD=manual] [HORIZONTAL_MOVE_Z=&lt;value&gt;] [&lt;probe_parameter&gt;=&lt;value&gt;] [&lt;mesh_parameter&gt;=&lt;value&gt;] [ADAPTIVE=1] [ADAPTIVE_MARGIN=&lt;value&gt;]</code>: This command probes the bed using generated points specified by the parameters in the config. After probing, a mesh is generated and z-movement is adjusted according to the mesh. The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. See the PROBE command for details on the optional probe parameters. If METHOD=manual is specified then the manual probing tool is activated - see the MANUAL_PROBE command above for details on the additional commands available while this tool is active. The optional <code>HORIZONTAL_MOVE_Z</code> value overrides the <code>horizontal_move_z</code> option specified in the config file. If ADAPTIVE=1 is specified then the objects defined by the Gcode file being printed will be used to define the probed area. The optional <code>ADAPTIVE_MARGIN</code> value overrides the <code>adaptive_margin</code> option specified in the config file.</p>
+<p><code>BED_MESH_CALIBRATE [PROFILE=&lt;name&gt;] [METHOD=manual] [HORIZONTAL_MOVE_Z=&lt;value&gt;] [&lt;probe_parameter&gt;=&lt;value&gt;] [&lt;mesh_parameter&gt;=&lt;value&gt;] [ADAPTIVE=1] [ADAPTIVE_MARGIN=&lt;value&gt;]</code>: This command probes the bed using generated points specified by the parameters in the config. After probing, a mesh is generated and z-movement is adjusted according to the mesh. The mesh is immediately active after successful completion of <code>BED_MESH_CALIBRATE</code>. The mesh will be saved into a profile specified by the <code>PROFILE</code> parameter, or <code>default</code> if unspecified. If ADAPTIVE=1 is specified then the profile name will begin with <code>adaptive-</code> and should not be saved for reuse. See the PROBE command for details on the optional probe parameters. If METHOD=manual is specified then the manual probing tool is activated - see the MANUAL_PROBE command above for details on the additional commands available while this tool is active. The optional <code>HORIZONTAL_MOVE_Z</code> value overrides the <code>horizontal_move_z</code> option specified in the config file. If ADAPTIVE=1 is specified then the objects defined by the Gcode file being printed will be used to define the probed area. The optional <code>ADAPTIVE_MARGIN</code> value overrides the <code>adaptive_margin</code> option specified in the config file.</p>
 <h4 id="bed_mesh_output">BED_MESH_OUTPUT<a class="headerlink" href="#bed_mesh_output" title="Permanent link">&para;</a></h4>
 <p><code>BED_MESH_OUTPUT PGP=[&lt;0:1&gt;]</code> : Cette commande écrit les valeurs z palpées actuelles et les valeurs de maillage actuelles sur le terminal. Si PGP=1 est spécifié, les coordonnées X, Y générées par bed_mesh, ainsi que leurs indices associés, seront envoyés au terminal.</p>
 <h4 id="bed_mesh_map">BED_MESH_MAP<a class="headerlink" href="#bed_mesh_map" title="Permanent link">&para;</a></h4>
@@ -4965,7 +5047,7 @@ section</a> is enabled.</p>
 <h3 id="dual_carriage">[dual_carriage]<a class="headerlink" href="#dual_carriage" title="Permanent link">&para;</a></h3>
 <p>La commande suivante est disponible lorsque la section <a href="Config_Reference.html#dual_carriage">config dual_carriage</a> est activée.</p>
 <h4 id="set_dual_carriage">SET_DUAL_CARRIAGE<a class="headerlink" href="#set_dual_carriage" title="Permanent link">&para;</a></h4>
-<p><code>SET_DUAL_CARRIAGE CARRIAGE=[0|1] [MODE=[PRIMARY|COPY|MIRROR]]</code>: This command will change the mode of the specified carriage. If no <code>MODE</code> is provided it defaults to <code>PRIMARY</code>. Setting the mode to <code>PRIMARY</code> deactivates the other carriage and makes the specified carriage execute subsequent G-Code commands as-is. <code>COPY</code> and <code>MIRROR</code> modes are supported only for <code>CARRIAGE=1</code>. When set to either of these modes, carriage 1 will then track the subsequent moves of the carriage 0 and either copy relative movements of it (in <code>COPY</code> mode) or execute them in the opposite (mirror) direction (in <code>MIRROR</code> mode).</p>
+<p><code>SET_DUAL_CARRIAGE CARRIAGE=&lt;carriage&gt; [MODE=[PRIMARY|COPY|MIRROR]]</code>: This command will change the mode of the specified carriage. If no <code>MODE</code> is provided it defaults to <code>PRIMARY</code>. <code>&lt;carriage&gt;</code> must reference a defined primary or dual carriage for <code>generic_cartesian</code> kinematics or be 0 (for primary carriage) or 1 (for dual carriage) for all other kinematics supporting IDEX. Setting the mode to <code>PRIMARY</code> deactivates the other carriage and makes the specified carriage execute subsequent G-Code commands as-is. <code>COPY</code> and <code>MIRROR</code> modes are supported only for dual carriages. When set to either of these modes, dual carriage will then track the subsequent moves of its primary carriage and either copy relative movements of it (in <code>COPY</code> mode) or execute them in the opposite (mirror) direction (in <code>MIRROR</code> mode).</p>
 <h4 id="save_dual_carriage_state">SAVE_DUAL_CARRIAGE_STATE<a class="headerlink" href="#save_dual_carriage_state" title="Permanent link">&para;</a></h4>
 <p><code>SAVE_DUAL_CARRIAGE_STATE [NAME=&lt;state_name&gt;]</code>: Save the current positions of the dual carriages and their modes. Saving and restoring DUAL_CARRIAGE state can be useful in scripts and macros, as well as in homing routine overrides. If NAME is provided it allows one to name the saved state to the given string. If NAME is not provided it defaults to "default".</p>
 <h4 id="restore_dual_carriage_state">RESTORE_DUAL_CARRIAGE_STATE<a class="headerlink" href="#restore_dual_carriage_state" title="Permanent link">&para;</a></h4>
@@ -5068,6 +5150,13 @@ section</a> is enabled.</p>
 <p><code>SAVE_GCODE_STATE [NAME=&lt;nom_de_l'état&gt;]</code> : Sauvegarde l'état actuel de l'analyse des coordonnées du g-code. La sauvegarde et le rétablissement de l'état du g-code sont utiles dans les scripts et les macros. Cette commande enregistre le mode actuel de coordonnées absolues en g-code (G90/G91), le mode d'extrusion absolue (M82/M83), l'origine (G92), le décalage (SET_GCODE_OFFSET), la priorité de vitesse (M220), la priorité d'extrusion (M221), la vitesse de déplacement, la position XYZ actuelle et la position relative de l'extrudeuse "E". Si NOM est fourni, cela permet de nommer l'état sauvegardé avec la chaîne de caractères donnée. Si le NOM n'est pas fourni, la valeur par défaut est "default".</p>
 <h4 id="restore_gcode_state">RESTORE_GCODE_STATE<a class="headerlink" href="#restore_gcode_state" title="Permanent link">&para;</a></h4>
 <p><code>RESTORE_GCODE_STATE [NAME=&lt;nom_de_l'état&gt;] [MOVE=1 [MOVE_SPEED=&lt;speed&gt;]]</code> : Restaure un état précédemment sauvegardé via SAVE_GCODE_STATE. Si "MOVE=1" est spécifié, un déplacement de la tête d'outil sera effectué pour revenir à la position XYZ précédente. Si "MOVE_SPEED" est spécifié, alors le déplacement de la tête d'outil sera effectué avec la vitesse donnée (en mm/s) ; sinon, le déplacement de la tête d'outil utilisera la vitesse du G-Code restauré.</p>
+<h3 id="generic_cartesian">[generic_cartesian]<a class="headerlink" href="#generic_cartesian" title="Permanent link">&para;</a></h3>
+<p>The commands in this section become automatically available when <code>kinematics: generic_cartesian</code> is specified as the printer kinematics.</p>
+<h4 id="set_stepper_carriages">SET_STEPPER_CARRIAGES<a class="headerlink" href="#set_stepper_carriages" title="Permanent link">&para;</a></h4>
+<p><code>SET_STEPPER_CARRIAGES STEPPER=&lt;stepper_name&gt; CARRIAGES=&lt;carriages&gt; [DISABLE_CHECKS=[0|1]]</code>: Set or update the stepper carriages. <code>&lt;stepper_name&gt;</code> must reference an existing stepper defined in <code>printer.cfg</code>, and <code>&lt;carriages&gt;</code> describes the carriages the stepper moves. See <a href="Config_Reference.html#generic-cartesian-kinematics">Generic Cartesian Kinematics</a> for a more detailed overview of the <code>carriages</code> parameter in the stepper configuration section. Note that it is only possible to change the coefficients or signs of the carriages with this command, but a user cannot add or remove the carriages that the stepper controls.</p>
+<p><code>SET_STEPPER_CARRIAGES</code> is an advanced tool, and the user is advised to exercise an extreme caution using it, since specifying incorrect configuration may physically damage the printer.</p>
+<p>Note that <code>SET_STEPPER_CARRIAGES</code> performs certain internal validations of the new printer kinematics after the change. Keep in mind that if it detects an issue, it may leave printer kinematics in an invalid state. This means that if <code>SET_STEPPER_CARRIAGES</code> reports an error, it is unsafe to issue other GCode commands, and the user must inspect the error message and either fix the problem, or manually restore the previous stepper(s) configuration.</p>
+<p>Since <code>SET_STEPPER_CARRIAGES</code> can update a configuration of a single stepper at a time, some sequences of changes can lead to invalid intermediate kinematic configurations, even if the final configuration is valid. In such cases a user can pass <code>DISABLE_CHECKS=1</code> parameters to all but the last command to disable intermediate checks. For example, if <code>stepper a</code> and <code>stepper b</code> initially have <code>x-y</code> and <code>x+y</code> carriages correspondingly, then the following sequence of commands will let a user effectively swap the carriage controls: <code>SET_STEPPER_CARRIAGES STEPPER=a CARRIAGES=x+y DISABLE_CHECKS=1</code> and <code>SET_STEPPER_CARRIAGES STEPPER=b CARRIAGES=x-y</code>, while still validating the final kinematics state.</p>
 <h3 id="hall_filament_width_sensor">[hall_filament_width_sensor]<a class="headerlink" href="#hall_filament_width_sensor" title="Permanent link">&para;</a></h3>
 <p>Les commandes suivantes sont disponibles lorsque la section de configuration <a href="Config_Reference.html#tsl1401cl_filament_width_sensor">tsl1401cl filament width sensor</a> ou <a href="Config_Reference. md#hall_filament_width_sensor">hall filament width sensor</a> est activée (voir également <a href="TSL1401CL_Filament_Width_Sensor.html">TSLl401CL Filament Width Sensor</a> et <a href="Hall_Filament_Width_Sensor.html">Hall Filament Width Sensor</a>) :</p>
 <h4 id="query_filament_width">QUERY_FILAMENT_WIDTH<a class="headerlink" href="#query_filament_width" title="Permanent link">&para;</a></h4>
@@ -5119,9 +5208,30 @@ section</a> is enabled.</p>
 </ol>
 <p>You can cancel the calibration process at any time with <code>ABORT</code>.</p>
 <h3 id="load_cell_tare">LOAD_CELL_TARE<a class="headerlink" href="#load_cell_tare" title="Permanent link">&para;</a></h3>
-<p><code>LOAD_CELL_TARE [LOAD_CELL=&lt;config_name&gt;]</code>: This works just like the tare button on digital scale. It sets the current raw reading of the load cell to be the zero point reference value. The response is the percentage of the sensors range that was read and the raw value in counts.</p>
+<p><code>LOAD_CELL_TARE [LOAD_CELL=&lt;config_name&gt;]</code>: This works just like the tare button on digital scale. It sets the current raw reading of the load cell to be the zero point reference value. The response is the percentage of the sensors range that was read and the raw value in counts. If the load cell is calibrated a force in grams is also reported.</p>
 <h3 id="load_cell_read-load_cellname">LOAD_CELL_READ load_cell="name"<a class="headerlink" href="#load_cell_read-load_cellname" title="Permanent link">&para;</a></h3>
 <p><code>LOAD_CELL_READ [LOAD_CELL=&lt;config_name&gt;]</code>: This command takes a reading from the load cell. The response is the percentage of the sensors range that was read and the raw value in counts. If the load cell is calibrated a force in grams is also reported.</p>
+<h3 id="load_cell_probe">[load_cell_probe]<a class="headerlink" href="#load_cell_probe" title="Permanent link">&para;</a></h3>
+<p>The following commands are enabled if a <a href="Config_Reference.html#load_cell_probe">load_cell config section</a> has been enabled.</p>
+<h3 id="load_cell_test_tap">LOAD_CELL_TEST_TAP<a class="headerlink" href="#load_cell_test_tap" title="Permanent link">&para;</a></h3>
+<p><code>LOAD_CELL_TEST_TAP [TAPS=&lt;taps&gt;] [TIMEOUT=&lt;timeout&gt;]</code>: Run a testing routine that reports taps on the load cell. The toolhead will not move but the load cell probe will sense taps just as if it was probing. This can be used as a sanity check to make sure that the probe works. This tool replaces QUERY_ENDSTOPS and QUERY_PROBE for load cell probes.</p>
+<ul>
+<li><code>TAPS</code>: the number of taps the tool expects</li>
+<li><code>TIMEOOUT</code>: the time, in seconds, that the tool waits for each tab before aborting.</li>
+</ul>
+<h3 id="load-cell-command-extensions">Load Cell Command Extensions<a class="headerlink" href="#load-cell-command-extensions" title="Permanent link">&para;</a></h3>
+<p>Commands that perform probes, such as <a href="#probe"><code>PROBE</code></a>, <a href="#probe_accuracy"><code>PROBE_ACCURACY</code></a>, <a href="#bed_mesh_calibrate"><code>BED_MESH_CALIBRATE</code></a> etc. will accept additional parameters if a <code>[load_cell_probe]</code> is defined. The parameters override the corresponding settings from the <a href="Config_Reference.html#load_cell_probe"><code>[load_cell_probe]</code></a> configuration:</p>
+<ul>
+<li><code>FORCE_SAFETY_LIMIT=&lt;grams&gt;</code></li>
+<li><code>TRIGGER_FORCE=&lt;grams&gt;</code></li>
+<li><code>DRIFT_FILTER_CUTOFF_FREQUENCY=&lt;frequency_hz&gt;</code></li>
+<li><code>DRIFT_FILTER_DELAY=&lt;1|2&gt;</code></li>
+<li><code>BUZZ_FILTER_CUTOFF_FREQUENCY=&lt;frequency_hz&gt;</code></li>
+<li><code>BUZZ_FILTER_DELAY=&lt;1|2&gt;</code></li>
+<li><code>NOTCH_FILTER_FREQUENCIES=&lt;list of frequency_hz&gt;</code></li>
+<li><code>NOTCH_FILTER_QUALITY=&lt;quality&gt;</code></li>
+<li><code>TARE_TIME=&lt;seconds&gt;</code></li>
+</ul>
 <h3 id="manual_probe">[manual_probe]<a class="headerlink" href="#manual_probe" title="Permanent link">&para;</a></h3>
 <p>Le module manual_probe est automatiquement chargé.</p>
 <h4 id="manual_probe_1">MANUAL_PROBE<a class="headerlink" href="#manual_probe_1" title="Permanent link">&para;</a></h4>
@@ -5139,6 +5249,7 @@ section</a> is enabled.</p>
 <p>La commande suivante est disponible lorsqu'une section <a href="Config_Reference.html#manual_stepper">manual_stepper config</a> est activée.</p>
 <h4 id="manual_stepper_1">MANUAL_STEPPER<a class="headerlink" href="#manual_stepper_1" title="Permanent link">&para;</a></h4>
 <p><code>MANUAL_STEPPER STEPPER=nom_du_config [ENABLE=[0|1]]] [SET_POSITION=&lt;pos&gt;] [SPEED=&lt;speed&gt;] [ACCEL=&lt;accel&gt;] [MOVE=&lt;pos&gt; [STOP_ON_ENDSTOP=[1|2|-1|-2]] [SYNC=0]]</code> : Cette commande modifie l'état du stepper. Utilisez le paramètre ENABLE pour activer/désactiver le stepper. Utilisez le paramètre SET_POSITION pour forcer le moteur pas à pas à penser qu'il se trouve à la position donnée. Utilisez le paramètre MOVE pour déplacer vers la position donnée. Si SPEED et/ou ACCEL sont spécifiés, les valeurs données seront utilisées à la place de celles par défaut issues du fichier de configuration. Si un ACCEL de zéro est spécifié, aucune accélération ne sera effectuée. Si STOP_ON_ENDSTOP=1 est spécifié, le déplacement se terminera prématurément si la fin de course est déclenchée (utilisez STOP_ON_ENDSTOP=2 pour terminer le déplacement sans erreur même si la fin de course n'est pas déclenchée, utilisez -1 ou -2 pour s'arrêter lorsque la fin de course n'est pas déclenchée). Normalement, les futures commandes G-Code seront programmées pour être exécutées après la fin du déplacement de la commande de pas, mais si un déplacement manuel de la commande de pas utilise SYNC=0, les futures commandes de déplacement G-Code peuvent être exécutées en parallèle avec le déplacement de la commande de pas.</p>
+<p><code>MANUAL_STEPPER STEPPER=config_name GCODE_AXIS=[A-Z] [LIMIT_VELOCITY=&lt;velocity&gt;] [LIMIT_ACCEL=&lt;accel&gt;] [INSTANTANEOUS_CORNER_VELOCITY=&lt;velocity&gt;]</code>: If the <code>GCODE_AXIS</code> parameter is specified then it configures the stepper motor as an extra axis on <code>G1</code> move commands. For example, if one were to issue a <code>MANUAL_STEPPER ... GCODE_AXIS=R</code> command then one could issue commands like <code>G1 X10 Y20 R30</code> to move the stepper motor. The resulting moves will occur synchronously with the associated toolhead xyz movements. If the motor is associated with a <code>GCODE_AXIS</code> then one may no longer issue movements using the above <code>MANUAL_STEPPER</code> command - one may unregister the stepper with a <code>MANUAL_STEPPER ... GCODE_AXIS=</code> command to resume manual control of the motor. The <code>LIMIT_VELOCITY</code> and <code>LIMIT_ACCEL</code> parameters allow one to reduce the speed of <code>G1</code> moves if those moves would result in a velocity or acceleration above the specified limits. The <code>INSTANTANEOUS_CORNER_VELOCITY</code> specifies the maximum instantaneous velocity change (in mm/s) of the motor during the junction of two moves (the default is 1mm/s).</p>
 <h3 id="mcp4018">[mcp4018]<a class="headerlink" href="#mcp4018" title="Permanent link">&para;</a></h3>
 <p>La commande suivante est disponible lorsqu'une section <a href="Config_Reference.html#mcp4018">mcp4018 config</a> est activée.</p>
 <h4 id="set_digipot">SET_DIGIPOT<a class="headerlink" href="#set_digipot" title="Permanent link">&para;</a></h4>
--- a/fr/Installation.html
+++ b/fr/Installation.html
@@ -1522,6 +1522,12 @@ make menuconfig
 <p>It's common for each printer to have its own unique serial port name. This unique name will be used when flashing the micro-controller. It's possible there may be multiple lines in the above output - if so, choose the line corresponding to the micro-controller. If many items are listed and the choice is ambiguous, unplug the board and run the command again, the missing item will be your print board(see the <a href="FAQ.html#wheres-my-serial-port">FAQ</a> for more information).</p>
 <p>For common micro-controllers with STM32 or clone chips, LPC chips and others, it is usual that these need an initial Klipper flash via SD card.</p>
 <p>When flashing with this method, it is important to make sure that the print board is not connected with USB to the host, due to some boards being able to feed power back to the board and stopping a flash from occurring.</p>
+<p>Please note, that most print boards that use SD cards for flash will implement some kind of flash loop protection for when the sd card is left in place. There are two common methods:</p>
+<p>Filename Change Required (usually "stock" print boards):</p>
+<p>These boards require the firmware file to have a different name each time you flash (for example, firmware1.bin, firmware2.bin, etc.). If you reuse the same filename, the board may ignore it and not update.</p>
+<p>Automatic File Renaming (usually aftermarket print boards:</p>
+<p>Other boards allow using the same filename, commonly firmware.bin, but after flashing, the board renames the file to firmware.cur. This helps indicate the firmware was successfully flashed and prevents it from flashing again on the next startup.</p>
+<p>Before flashing, make sure to check which behavior your board follows.</p>
 <p>For common micro-controllers using Atmega chips, for example the 2560, the code can be flashed with something similar to:</p>
 <div class="highlight"><pre><span></span><code>sudo service klipper stop
 make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
--- a/fr/Load_Cell.html
+++ b/fr/Load_Cell.html
@@ -1556,6 +1556,162 @@ Total capacity: +/- 29.14Kg
 <div class="highlight"><pre><span></span><code>{% set tare_counts = printer.load_cell.tare_counts %}
 </code></pre></div>

+<h1 id="load-cell-probes">Load Cell Probes<a class="headerlink" href="#load-cell-probes" title="Permanent link">&para;</a></h1>
+<h2 id="related-documentation_1">Related Documentation<a class="headerlink" href="#related-documentation_1" title="Permanent link">&para;</a></h2>
+<ul>
+<li><a href="Config_Reference.html#load_cell_probe">load_cell_probe Config Reference</a></li>
+<li><a href="G-Codes.html#load_cell_probe">load_cell_probe G-Code Commands</a></li>
+<li><a href="Status_Reference.html#load_cell_probe">load_cell_probe Statuc Reference</a></li>
+</ul>
+<h2 id="load-cell-probe-safety">Load Cell Probe Safety<a class="headerlink" href="#load-cell-probe-safety" title="Permanent link">&para;</a></h2>
+<p>Because load cells are a direct nozzle contact probe there is a risk of damage to your printer if too much force is used. The load cell probing system includes a number of safety checks that try to keep your machine safe from excessive force to the toolhead. It's important to understand what they are and how they work as you can defeat most of them with poorly chosen config values.</p>
+<h4 id="calibration-check">Calibration Check<a class="headerlink" href="#calibration-check" title="Permanent link">&para;</a></h4>
+<p>Every time a homing move starts, load_cell_probe checks that the load_cell is calibrated. If not it will stop the move with an error: <code>!! Load Cell not calibrated</code>.</p>
+<h4 id="counts_per_gram"><code>counts_per_gram</code><a class="headerlink" href="#counts_per_gram" title="Permanent link">&para;</a></h4>
+<p>This setting is used to convert raw sensor counts into grams. All the safety limits are in gram units for your convenience. If the <code>counts_per_gram</code> setting is not accurate you can easily exceed the safe force on the toolhead. You should never guess this value. Use <code>LOAD_CELL_CALIBRATE</code> to find your load cells actual <code>counts_per_gram</code>.</p>
+<h4 id="trigger_force"><code>trigger_force</code><a class="headerlink" href="#trigger_force" title="Permanent link">&para;</a></h4>
+<p>This is the force in grams that triggers the endstop to halt the homing move. When a homing move starts the endstop tares itself with the current reading from the load cell. <code>trigger_force</code> is measured from that tare value. There is always some overshoot of this value when the probe collides with the bed, so be conservative. e.g. a setting of 100g could result in 350g of peak force before the toolhead stops. This overshoot will increase with faster probing <code>speed</code>, a low ADC sample rate or <a href="Multi_MCU_Homing.html">multi MCU homing</a>.</p>
+<h4 id="reference_tare_counts"><code>reference_tare_counts</code><a class="headerlink" href="#reference_tare_counts" title="Permanent link">&para;</a></h4>
+<p>This is the baseline tare value that is set by <code>LOAD_CELL_CALIBRATE</code>. This value works with <code>force_safety_limit</code> to limit the maximum force on the toolhead.</p>
+<h4 id="force_safety_limit"><code>force_safety_limit</code><a class="headerlink" href="#force_safety_limit" title="Permanent link">&para;</a></h4>
+<p>This is the maximum absolute force, relative to <code>reference_tare_counts</code>, that the probe will allow while homing or probing. If the MCU sees this force exceeded it will shut down the printer with the error <code>!! Load cell endstop: too much force!</code>. There are a number of ways this can be triggered:</p>
+<p>The first risk this protects against is picking too large of a value for <code>drift_filter_cutoff_frequency</code>. This can cause the drift filter to filter out a probe event and continue the homing move. If this happens the <code>force_safety_limit</code> acts as a backup protection.</p>
+<p>The second problem is probing repeatedly in one place. Klipper does not retract the probe when doing a single <code>PROBE</code> command. This can result in force applied to the toolhead at the end of a probing cycle. Because external forces can vary greatly between probing locations, <code>load_cell_probe</code> performs a tare before beginning each probe. If you repeat the <code>PROBE</code> command, load_cell_probe will tare the endstop at the current force. Multiple cycles of this will result in ever-increasing force on the toolhead. <code>force_safety_limit</code> stops this cycle from running out of control.</p>
+<p>Another way this run-away can happen is damage to a strain gauge. If the metal part is permanently bent it wil change the <code>reference_tare_counts</code> of the device. This puts the starting tare value much closer to the limit making it more likely to be violated. You want to be notified if this is happening because your hardware has been permanently damaged.</p>
+<p>The final way this can be triggered is due to temperature changes. If your strain gauges are heated their <code>reference_tare_counts</code> may be very different at ambient temperature vs operating temperature. In this case you may need to increase the <code>force_safety_limit</code> to allow for thermal changes.</p>
+<h4 id="load-cell-endstop-watchdog-task">Load Cell Endstop Watchdog Task<a class="headerlink" href="#load-cell-endstop-watchdog-task" title="Permanent link">&para;</a></h4>
+<p>When homing the load_cell_endstop starts a task on the MCU to trac measurements arriving from the sensor. If the sensor fails to send measurements for 2 sample periods the watchdog will shut down the printer with an error <code>!! LoadCell Endstop timed out waiting on ADC data</code>.</p>
+<p>If this happens, the most likely cause is a fault from the ADC. Inadequate grounding of your printer can be the root cause. The frame, power supply case and pint bed should all be connected to ground. You may need to ground the frame in multiple places. Anodized aluminum extrusions do not conduct electricity well. You might need to sand the area where the grounding wire is attached to make good electrical contact.</p>
+<h2 id="load-cell-probe-setup">Load Cell Probe Setup<a class="headerlink" href="#load-cell-probe-setup" title="Permanent link">&para;</a></h2>
+<p>This section covers the process for commissioning a load cell probe.</p>
+<h3 id="verify-the-load-cell-first">Verify the Load Cell First<a class="headerlink" href="#verify-the-load-cell-first" title="Permanent link">&para;</a></h3>
+<p>A <code>[load_cell_probe]</code> is also a <code>[load_cell]</code> and G-code commands related to <code>[load_cell]</code> work with <code>[load_cell_probe]</code>. Before attempting to use a load cell probe, follow the directions for <a href="Load_Cell.html#calibrating-a-load-cell">calibrating the load cell</a> with <code>CALIBRATE_LOAD_CELL</code> and checking its operation with <code>LOAD_CELL_DIAGNOSTIC</code>.</p>
+<h3 id="verify-probe-operation-with-load_cell_test_tap">Verify Probe Operation With LOAD_CELL_TEST_TAP<a class="headerlink" href="#verify-probe-operation-with-load_cell_test_tap" title="Permanent link">&para;</a></h3>
+<p>Use the command <code>LOAD_CELL_TEST_TAP</code> to test the operation of the load cell probe before actually trying to probe with it. This command detects taps, just like the PROBE command, but it does not move the z axis. By default, it listens for 3 taps before ending the test. You have 30 seconds to do each tap, if no taps are detected the command will time out.</p>
+<p>If this test fails, check your configuration and <code>LOAD_CELL_DIAGNOSTIC</code> carefully to look for issues.</p>
+<p>Load cell probes don't support the <code>QUERY_ENDSTOPS</code> or <code>QUERY_PROBE</code> commands. Use <code>LOAD_CELL_TEST_TAP</code> for testing functionality before probing.</p>
+<h3 id="homing-macros">Homing Macros<a class="headerlink" href="#homing-macros" title="Permanent link">&para;</a></h3>
+<p>Load cell probe is not an endstop and doesn't support <code>endstop: prove:z_virtual_endstop</code>. For the time being you'll need to configure your z axis with an MCU pin as its endstop. You won't actually be using the pin but for the time being you have to configure something.</p>
+<p>To home the axis with just the probe you need to set up a custom homing macro. This requires setting up <a href="Config_Reference.html#homing_override">homing_override</a>.</p>
+<p>Here is a simple macro that can accomplish this. Note that the <code>_HOME_Z_FROM_LAST_PROBE</code> macro has to be separate because of the way macros work. The sub-call is needed so that the <code>_HOME_Z_FROM_LAST_PROBE</code> macro can see the result of the probe in <code>printer.probe.last_z_result</code>.</p>
+<div class="highlight"><pre><span></span><code>[gcode_macro _HOME_Z_FROM_LAST_PROBE]
+gcode:
+<span class="w">    </span>{% set z_probed = printer.probe.last_z_result %}
+<span class="w">    </span>{% set z_position = printer.toolhead.position[2] %}
+<span class="w">    </span>{% set z_actual = z_position - z_probed %}
+<span class="w">    </span>SET_KINEMATIC_POSITION Z={z_actual}
+
+[gcode_macro _HOME_Z]
+gcode:
+<span class="w">    </span>SET_GCODE_OFFSET Z=0  # load cell probes dont need a Z offset
+<span class="w">    </span># position toolhead for homing Z, edit for your printers size
+<span class="w">    </span>#G90  # absolute move
+<span class="w">    </span>#G1 Y50 X50 F{5 * 60}  # move to X/Y position for homing
+
+<span class="w">    </span># soft home the z axis to its limit so it can be moved:
+<span class="w">    </span>SET_KINEMATIC_POSITION Z={printer.toolhead.axis_maximum[2]}
+
+<span class="w">    </span># Fast approach and tap
+<span class="w">    </span>PROBE PROBE_SPEED={5 * 60}  # override the speed for faster homing
+<span class="w">    </span>_HOME_Z_FROM_LAST_PROBE
+
+<span class="w">    </span># lift z to 2mm
+<span class="w">    </span>G91  # relative move
+<span class="w">    </span>G1 Z2 F{5 * 60}
+
+<span class="w">    </span># probe at standard speed
+<span class="w">    </span>PROBE
+<span class="w">    </span>_HOME_Z_FROM_LAST_PROBE
+
+<span class="w">    </span># lift z to 10mm for clearance
+<span class="w">    </span>G91  # relative move
+<span class="w">    </span>G1 Z10 F{5 * 60}
+</code></pre></div>
+
+<h3 id="suggested-probing-temperature">Suggested Probing Temperature<a class="headerlink" href="#suggested-probing-temperature" title="Permanent link">&para;</a></h3>
+<p>Currently, we suggest keeping the nozzle temperature below the level that causes the filament to ooze while homing and probing. 140C is a good starting point. This temperature is also low enough not to scar PEI build surfaces.</p>
+<p>Fouling of the nozzle and the print bed due to oozing filament is the #1 source of probing error with the load cell probe. Klipper does not yet have a universal way to detect poor quality taps due to filament ooze. The existing code may decide that a tap is valid when it is of poor quality. Classifying these poor quality taps is an area of active research.</p>
+<p>Klipper also lacks support for re-locating a probe point if the location has become fouled by filament ooze. Modules like <code>quad_gantry_level</code> will repeatedly probe the same coordinates even if a probe previously failed there.</p>
+<p>Give the above it is strongly suggested not to probe at printing temperatures.</p>
+<h3 id="hot-nozzle-protection">Hot Nozzle Protection<a class="headerlink" href="#hot-nozzle-protection" title="Permanent link">&para;</a></h3>
+<p>The Voron project has a great macro for protecting your print surface from the hot nozzle. See <a href="https://github.com/VoronDesign/Voron-Tap/blob/main/config/tap_klipper_instructions.md">Voron Tap's
+<code>activate_gcode</code></a></p>
+<p>It is highly suggested to add something like this to your config.</p>
+<h3 id="nozzle-cleaning">Nozzle Cleaning<a class="headerlink" href="#nozzle-cleaning" title="Permanent link">&para;</a></h3>
+<p>Before probing the nozzle should be clean. You could do this manually before every print. You can also implement a nozzle scrubber and automate the process. Here is a suggested sequence:</p>
+<ol>
+<li>Wait for the nozzle to heat up to probing temp (e.g. <code>M109 S140</code>)</li>
+<li>Home the machine (<code>G28</code>)</li>
+<li>Scrub the nozzle on a brush</li>
+<li>Heat soak the print bed</li>
+<li>Perform probing tasks: QGL, bed mesh etc.</li>
+</ol>
+<h3 id="temperature-compensation-for-nozzle-growth">Temperature Compensation for Nozzle Growth<a class="headerlink" href="#temperature-compensation-for-nozzle-growth" title="Permanent link">&para;</a></h3>
+<p>If you are probing at a safe temperature, the nozzle will expand after heating to printing temperatures. This will cause the nozzle to get longer and closer to the print surface. You can compensate for this with <a href="Config_Reference.html#z_thermal_adjust">[z_thermal_adjust]</a>. This adjustment will work across a range of printing temperatures from PLA to PC.</p>
+<h4 id="calculating-the-temp_coeff-for-z_thermal_adjust">Calculating the <code>temp_coeff</code> for <code>[z_thermal_adjust]</code><a class="headerlink" href="#calculating-the-temp_coeff-for-z_thermal_adjust" title="Permanent link">&para;</a></h4>
+<p>The easiest way to do this is to measure at 2 different temperatures. Ideally these should be the upper and lower limits of the printing temperature range. E.g. 180C and 290C. You can perform a <code>PROBE_ACCURACY</code> at both temperatures and then calculate the difference of the <code>average z</code> at both.</p>
+<p>The adjustment value is the change in nozzle length divided by the change in temperature. e.g.</p>
+<div class="highlight"><pre><span></span><code>temp_coeff = -0.05 / (290 - 180) = -0.00045455
+</code></pre></div>
+
+<p>The expected result is a negative number. Positive values for <code>temp_coeff</code> move the nozzle closer to the bed and negative values move it further away. Expect to have to move the nozzle further away as it gets longer when hot.</p>
+<h4 id="configure-z_thermal_adjust">Configure <code>[z_thermal_adjust]</code><a class="headerlink" href="#configure-z_thermal_adjust" title="Permanent link">&para;</a></h4>
+<p>Set up z_thermal_adjust to reference the <code>extruder</code> as the source of temperature data. E.g.:</p>
+<div class="highlight"><pre><span></span><code>[z_thermal_adjust nozzle]
+temp_coeff=-0.00045455
+sensor_type: temperature_combined
+sensor_list: extruder
+combination_method: max
+min_temp: 0
+max_temp: 400
+max_z_adjustment: 0.1
+</code></pre></div>
+
+<h2 id="continuous-tare-filters-for-toolhead-load-cells">Continuous Tare Filters for Toolhead Load Cells<a class="headerlink" href="#continuous-tare-filters-for-toolhead-load-cells" title="Permanent link">&para;</a></h2>
+<p>Klipper implements a configurable IIR filter on the MCU to provide continuous tareing of the load cell while probing. Continuous taring means the 0 value moves with drift caused by external factors like bowden tubes and thermal changes. This is aimed at toolhead sensors and moving beds that experience lots of external forces that change while probing.</p>
+<h3 id="installing-scipy">Installing SciPy<a class="headerlink" href="#installing-scipy" title="Permanent link">&para;</a></h3>
+<p>The filtering code uses the excellent <a href="https://scipy.org/">SciPy</a> library to compute the filter coefficients based on the values your enter into the config.</p>
+<p>Pre-compiled SciPi builds are available for Python 3 on 32 bit Raspberry Pi systems. 32 bit + Python 3 is strongly recommended because it will streamline your installation experience. It does work with Python 2 but installation can take 30+ minutes and require installing additional tools.</p>
+<div class="highlight"><pre><span></span><code>~/klippy-env/bin/pip<span class="w"> </span>install<span class="w"> </span>scipy
+</code></pre></div>
+
+<h3 id="filter-workbench">Filter Workbench<a class="headerlink" href="#filter-workbench" title="Permanent link">&para;</a></h3>
+<p>The filter parameters should be selected based on drift seen on the printer during normal operation. A Jupyter notebook is provided in scripts, <a href="https://github.com/Klipper3d/klipper/blob/master/scripts/filter_workbench.ipynb">filter_workbench.ipynb</a>, to perform a detailed investigation with real captured data and FFTs.</p>
+<h3 id="filtering-suggestions">Filtering Suggestions<a class="headerlink" href="#filtering-suggestions" title="Permanent link">&para;</a></h3>
+<p>For those just trying to get a filter working follow these suggestions:</p>
+<ul>
+<li>The only essential option is <code>drift_filter_cutoff_frequency</code>. A conservative starting value is <code>0.5</code>Hz. Prusa shipped the MK4 with a setting of <code>0.8</code>Hz and the XL with <code>11.2</code>Hz. This is probably a safe range to experiment with. This value should be increased only until normal drift due to bowden tube force is eliminated. Setting this value too high will result in slow triggering and excess force going through the toolhead.</li>
+<li>Keep <code>trigger_force</code> low. The default is <code>75</code>g. The drift filter keeps the internal grams value very close to 0 so a large trigger force is not needed.</li>
+<li>Keep <code>force_safety_limit</code> to a conservative value. The default value is 2Kg and should keep your toolhead safe while experimenting. If you hit this limit the <code>drift_filter_cutoff_frequency</code> value may be too high.</li>
+</ul>
+<h2 id="suggestions-for-load-cell-tool-boards">Suggestions for Load Cell Tool Boards<a class="headerlink" href="#suggestions-for-load-cell-tool-boards" title="Permanent link">&para;</a></h2>
+<p>This section covers suggestions for those developing toolhead boards that want to support [load_cell_probe]</p>
+<h3 id="adc-sensor-selection-board-development-hints">ADC Sensor Selection &amp; Board Development Hints<a class="headerlink" href="#adc-sensor-selection-board-development-hints" title="Permanent link">&para;</a></h3>
+<p>Ideally a sensor would meet these criteria:</p>
+<ul>
+<li>At least 24 bits wide</li>
+<li>Use SPI communications</li>
+<li>Has a pin can be used to indicate sample ready without SPI communications. This is often called the "data ready" or "DRDY" pin. Checking a pin is much faster than running an SPI query.</li>
+<li>Has a programmable gain amplifier gain setting of 128. This should eliminate the need for a separate amplifier.</li>
+<li>Indicates via SPI if the sensor has been reset. Detecting resets avoids timing errors in homing and using noisy data at startup. It can also help users track down wiring and grounding issues.</li>
+<li>A selectable sample rate between 350Hz and 2Khz. Very high sample rates don't turn out to be beneficial in our 3D printers because they produce so much noise when moving fast. Sample rates below 250Hz will require slower probing speeds. They also increase the force on the toolhead due to longer delays between measurements. E.g. a 500Hz sensor moving at 5mm/s has the same safety factor as a 100Hz sensor moving at only 1mm/s.</li>
+<li>If designing for under-bed applications, and you want to sense multiple load cells, use a chip that can sample all of its inputs simultaneously. Multiplex ADCs that require switching channels have a settling of several samples after each channel switch making them unsuitable for probing applications.</li>
+</ul>
+<p>Implementing support for a new sensor chip is not particularly difficult with Klipper's <code>bulk_sensor</code> and <code>load_cell_endstop</code> infrastructure.</p>
+<h3 id="5v-power-filtering">5V Power Filtering<a class="headerlink" href="#5v-power-filtering" title="Permanent link">&para;</a></h3>
+<p>It is strongly suggested to use larger capacitors than specified by the ADC chip manufacturer. ADC chips are usually targeted at low noise environments, like battery powered devices. Sensor manufacturers suggested application notes generally assume a quiet power supply. Treat their suggested capacitor values as minimums.</p>
+<p>3D printers put huge amounts of noise onto the 5V bus and this can ruin the sensor's accuracy. Test the sensor on the board with a typical 3D printer power supply and active stepper drivers before deciding on smoothing capacitor sizes.</p>
+<h3 id="grounding-ground-planes">Grounding &amp; Ground Planes<a class="headerlink" href="#grounding-ground-planes" title="Permanent link">&para;</a></h3>
+<p>Analog ADC chips contain components that are very vulnerable to noise and ESD. A large ground plane on the first board layer under the chip can help with noise. Keep the chip away from power sections and DC to DC converters. The board should have proper grounding back to the DC supply.</p>
+<h3 id="hx711-and-hx717-notes">HX711 and HX717 Notes<a class="headerlink" href="#hx711-and-hx717-notes" title="Permanent link">&para;</a></h3>
+<p>This sensor is popular because of its low cost and availability in the supply chain. However, this is a sensor with some drawbacks:</p>
+<ul>
+<li>The HX71x sensors use bit-bang communication which has a high overhead on the MCU. Using a sensor that communicates via SPI would save resources on the tool board's CPU.</li>
+<li>The HX71x lacks a way to communicate reset events to the MCU. Klipper detects resets with a timing heuristic but this is not ideal. Resets indicate a problem with wiring or grounding.</li>
+<li>For probing applications the HX717 version is strongly preferred because of its higher sample rate (320 vs 80). Probing speed on the HX711 should be limited to less than 2mm/s.</li>
+<li>The sample rate on the HX71x cannot be set from klipper's config. If you have the 10SPS version of the sensor (which is widely distributed) it needs to be physically re-wired to run at 80SPS.</li>
+</ul>
+
              
            </article>
          </div>
--- a/fr/Status_Reference.html
+++ b/fr/Status_Reference.html
@@ -1008,6 +1008,13 @@
    load_cell
  </a>
  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    load_cell_probe
+  </a>
+  
 </li>
      
        <li class="md-nav__item">
@@ -1867,6 +1874,13 @@
    load_cell
  </a>
  
+</li>
+      
+        <li class="md-nav__item">
+  <a href="#load_cell_probe" class="md-nav__link">
+    load_cell_probe
+  </a>
+  
 </li>
      
        <li class="md-nav__item">
@@ -2254,6 +2268,14 @@
 <li>'min_force_g': The minimum force in grams, over the last polling period.</li>
 <li>'max_force_g': The maximum force in grams, over the last polling period.</li>
 </ul>
+<h2 id="load_cell_probe">load_cell_probe<a class="headerlink" href="#load_cell_probe" title="Permanent link">&para;</a></h2>
+<p>The following information is available for <code>[load_cell_probe]</code>:</p>
+<ul>
+<li>all items from <a href="Status_Reference.html#load_cell">load_cell</a></li>
+<li>all items from <a href="Status_Reference.html#probe">probe</a></li>
+<li>'endstop_tare_counts': the load cell probe keeps a tare value independent of the load cell. This re-set at the start of each probe.</li>
+<li>'last_trigger_time': timestamp of the last homing trigger</li>
+</ul>
 <h2 id="manual_probe">manual_probe<a class="headerlink" href="#manual_probe" title="Permanent link">&para;</a></h2>
 <p>Les informations suivantes sont disponibles dans l'objet <code>manual_probe</code> :</p>
 <ul>
@@ -2402,6 +2424,10 @@
 <li><code>carriage_0</code>: The mode of the carriage 0. Possible values are: "INACTIVE" and "PRIMARY".</li>
 <li><code>carriage_1</code>: The mode of the carriage 1. Possible values are: "INACTIVE", "PRIMARY", "COPY", and "MIRROR".</li>
 </ul>
+<p>On a <code>generic_cartesian</code> kinematic, the following information is available in <code>dual_carriage</code>:</p>
+<ul>
+<li><code>carriages["&lt;carriage&gt;"]</code>: The mode of the carriage <code>&lt;carriage&gt;</code>. Possible values are "INACTIVE" and "PRIMARY" for the primary carriage and "INACTIVE", "PRIMARY", "COPY", and "MIRROR" for the dual carriage.</li>
+</ul>
 <h2 id="virtual_sdcard">virtual_sdcard<a class="headerlink" href="#virtual_sdcard" title="Permanent link">&para;</a></h2>
 <p>Les informations suivantes sont disponibles dans l'objet <a href="Config_Reference.html#virtual_sdcard">virtual_sdcard</a> :</p>
 <ul>
--- a/fr/_klipper3d/pycache/mkdocs_hooks.cpython-38.pyc
+++ b/fr/_klipper3d/pycache/mkdocs_hooks.cpython-38.pyc
--- a/fr/search/search_index.json
+++ b/fr/search/search_index.json
--- a/fr/sitemap.xml
+++ b/fr/sitemap.xml
@@ -2,282 +2,282 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
    <url>
         <loc>None</loc>
-         <lastmod>2025-07-16</lastmod>
+         <lastmod>2025-07-17</lastmod>
         <changefreq>daily</changefreq>
    </url>
 </urlset>
--- a/fr/sitemap.xml.gz
+++ b/fr/sitemap.xml.gz