Deploying to gh-pages from @ Klipper3d/klipper@7b490f3ec1 🚀

fr/Code_Overview.html

@@ -1484,16 +1484,16 @@
 <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>La classe ToolHead (dans toolhead.py) gère le "look-ahead" et suit la temporisation des actions d'impression. Le chemin du code principal pour un déplacement est : <code>ToolHead.move() -&gt; MoveQueue.add_move() -&gt; MoveQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.<ul>
+<li>The ToolHead class (in toolhead.py) handles "look-ahead" and tracks the timing of printing actions. The main codepath for a move is: <code>ToolHead.move() -&gt; LookAheadQueue.add_move() -&gt; LookAheadQueue.flush() -&gt; Move.set_junction() -&gt; ToolHead._process_moves()</code>.<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>MoveQueue.add_move() place l'objet move dans la file d'attente "look-ahead".</li>
-<li>MoveQueue.flush() détermine les vitesses de début et de fin de chaque mouvement.</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 utilise un <a href="https://en.wikipedia.org/wiki/Root-finding_algorithm">solveur itératif</a> afin de générer les délais des pas pour chaque moteur pas à pas. Pour des raisons d'efficacité, les délais d'impulsion des pas sont générés en code C. Les mouvements sont d'abord placés dans une "file d'attente de mouvements trapézoïdaux" : <code>ToolHead._process_moves() -&gt; trapq_append()</code> (dans klippy/chelper/trapq.c). Les délais de pas sont ensuite générés : <code>ToolHead._process_moves() -&gt; ToolHead._update_move_time() -&gt; MCU_Stepper.generate_steps() -&gt; itersolve_generate_steps() -&gt; itersolve_gen_steps_range()</code> (dans klippy/chelper/itersolve.c). Le but du solveur itératif est de trouver les délais de pas à partir d'une fonction calculant la position du moteur à partir du temps. Ceci est fait en "devinant" de manière répétée plusieurs délais jusqu'à ce que la formule de position du pas renvoie la position désirée du pas suivant sur le moteur. Le retour d'information produit par chaque estimation est utilisé afin d'améliorer les estimations futures, de sorte que le processus converge rapidement vers le délai souhaité. Les formules de position cinématique du moteur sont situées dans le répertoire klippy/chelper/ (par exemple, kin_cart.c, kin_corexy.c, kin_delta.c, kin_extruder.c).</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>