Deploying to gh-pages from @ Klipper3d/klipper@434770eaf9 🚀

fr/Code_Overview.html

@@ -1484,21 +1484,23 @@
 <p>Un mouvement typique de l'imprimante commence lorsqu'une commande "G1" est envoyée à l'hôte Klippy et se termine lorsque les impulsions de pas correspondantes sont produites sur le micro-contrôleur. Cette section décrit le flux du code d'une commande de déplacement typique. Le document <a href="Kinematics.html">cinématiques</a> fournit des informations supplémentaires sur la mécanique des mouvements.</p>
 <ul>
 <li>Le traitement d'une commande de déplacement commence dans gcode.py. Le but de gcode.py est de traduire le G-code en appels internes. Une commande G1 invoquera cmd_G1() dans klippy/extras/gcode_move.py. Le code gcode_move.py gère les changements d'origine (par exemple, G92), les changements de positions relatives et absolues (par exemple, G90), et les changements d'unités (par exemple, F6000=100mm/s). Le chemin du code pour un déplacement est : <code>_process_data() -&gt; _process_commands() -&gt; cmd_G1()</code>. Finalement, la classe ToolHead est invoquée pour exécuter la demande réelle : <code>cmd_G1() -&gt; ToolHead.move()</code></li>
-<li>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks the timing of printing actions. The main codepath for a move is: <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.<ul>
+<li>
+<p>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks the timing of printing actions. The main codepath for a move is: <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.</p>
+<ul>
 <li>ToolHead.move() crée un objet Move() avec les paramètres du déplacement (dans l'espace cartésien et en unités de secondes et de millimètres).</li>
 <li>La classe cinématique a la possibilité de vérifier chaque mouvement (<code>ToolHead.move() -&gt; kin.check_move()</code>). Les classes cinématiques sont situées dans le répertoire klippy/kinematics/. Le code check_move() peut lever une erreur si le déplacement n'est pas valide. Si check_move() se termine avec succès, alors la cinématique sous-jacente doit être capable de gérer le déplacement.</li>
 <li>LookAheadQueue.add_move() places the move object on the "look-ahead" queue.</li>
 <li>LookAheadQueue.flush() determines the start and end velocities of each move.</li>
 <li>Move.set_junction() implémente le "générateur de trapèze" sur un mouvement. Le "générateur de trapèze" divise chaque mouvement en trois parties : une phase d'accélération constante, suivie d'une phase de vitesse constante, puis d'une phase de décélération constante. Chaque déplacement contient ces trois phases dans cet ordre, certaines phases pouvant être de durée nulle.</li>
 <li>Lorsque ToolHead._process_moves() est appelé, tout ce qui concerne le déplacement est connu : sa position de départ, sa position d'arrivée, son accélération, sa vitesse de départ/de croisière/de fin, et la distance parcourue pendant l'accélération/la croisière/la décélération. Toutes ces informations sont stockées dans la classe Move() et sont dans l'espace cartésien en unités de millimètres et de secondes.</li>
-</ul>
-</li>
 <li>Klipper uses an <a href="https://en.wikipedia.org/wiki/Root-finding_algorithm">iterative solver</a> to generate the step times for each stepper. For efficiency reasons, the stepper pulse times are generated in C code. The moves are first placed on a "trapezoid motion queue": <code>ToolHead._process_moves() -&gt; trapq_append()</code> (in klippy/chelper/trapq.c). The step times are then generated: <code>ToolHead._process_moves() -&gt; ToolHead._advance_move_time() -&gt; ToolHead._advance_flush_time() -&gt; MCU_Stepper.generate_steps() -&gt; itersolve_generate_steps() -&gt; itersolve_gen_steps_range()</code> (in klippy/chelper/itersolve.c). The goal of the iterative solver is to find step times given a function that calculates a stepper position from a time. This is done by repeatedly "guessing" various times until the stepper position formula returns the desired position of the next step on the stepper. The feedback produced from each guess is used to improve future guesses so that the process rapidly converges to the desired time. The kinematic stepper position formulas are located in the klippy/chelper/ directory (eg, kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c).</li>
 <li>Notez que l'extrudeuse est gérée dans sa propre classe cinématique : <code>ToolHead._process_moves() -&gt; PrinterExtruder.move()</code>. Puisque la classe Move() spécifie le délai exact du mouvement et que les impulsions de pas sont envoyées au micro-contrôleur avec un timing spécifique, les mouvements du moteur produits par la classe de l'extrudeuse seront synchronisés avec le mouvement de la tête même si le code est séparé.</li>
 <li>Après que le solveur itératif ait calculé les délais de pas, ils sont ajoutés à un tableau : <code>itersolve_gen_steps_range() -&gt; stepcompress_append()</code> (dans klippy/chelper/stepcompress.c). Le tableau (struct stepcompress.queue) stocke les durées correspondantes du compteur d'horloge du micro-contrôleur pour chaque étape. Ici, la valeur du "compteur d'horloge du micro-contrôleur" correspond directement au compteur matériel du micro-contrôleur - elle est relative à la dernière mise sous tension du micro-contrôleur.</li>
 <li>La prochaine étape majeure est de compresser les étapes : <code>stepcompress_flush() -&gt; compress_bisect_add()</code> (dans klippy/chelper/stepcompress.c). Ce code génère et encode une série de commandes "queue_step" du micro-contrôleur correspondant à la liste des durées de pas du moteur construite à l'étape précédente. Ces commandes "queue_step" sont ensuite mises en file d'attente, hiérarchisées et envoyées au micro-contrôleur (via stepcompress.c:steppersync et serialqueue.c:serialqueue).</li>
 <li>Le traitement des commandes queue_step sur le micro-contrôleur commence dans src/command.c qui analyse la commande et appelle <code>command_queue_step()</code>. Le code command_queue_step() (dans src/stepper.c) ajoute simplement les paramètres de chaque commande queue_step à une file d'attente par moteur. En fonctionnement normal, la commande queue_step est analysée et mise en file d'attente au moins 100ms avant le moment de son premier pas. Enfin, la génération des événements de pas du moteur est faite dans <code>stepper_event()</code>. Elle est appelée depuis l'interruption du compteur matériel à l'heure prévue du premier pas. Le code stepper_event() génère une impulsion de pas et se reprogramme ensuite pour s'exécuter au moment de l'impulsion de pas suivante pour les paramètres queue_step donnés. Les paramètres pour chaque commande queue_step sont "interval", "count", et "add". A un haut niveau, stepper_event() exécute la commande suivante, 'count' fois : <code>do_step() ; next_wake_time = last_wake_time + interval ; interval += add;</code></li>
 </ul>
+</li>
+</ul>
 <p>Ce qui précède peut sembler beaucoup de complexité pour l'exécution d'un mouvement. Cependant, les seules parties vraiment intéressantes se trouvent dans les classes ToolHead et kinematic. C'est cette partie du code qui précise les mouvements et leurs durées. Les autres parties du traitement sont essentiellement de la communication et de la plomberie.</p>
 <h2 id="ajout-dun-module-hote">Ajout d'un module hôte<a class="headerlink" href="#ajout-dun-module-hote" title="Permanent link">&para;</a></h2>
 <p>Le code hôte de Klippy a une capacité de chargement dynamique de modules. Si une section de configuration nommée "[mon_module]" est trouvée dans le fichier de configuration de l'imprimante, le logiciel tentera automatiquement de charger le module python klippy/extras/mon_module.py . Ce système de modules est la méthode préférée pour ajouter de nouvelles fonctionnalités à Klipper.</p>