Deploying to gh-pages from @ Klipper3d/klipper@434770eaf9 🚀
This commit is contained in:
KevinOConnor
@@ -1499,15 +1499,16 @@ z_hop_speed: 5
|
||||
<h2 id="mode-de-sortie-du-bl-touch">Mode de sortie du BL-Touch<a class="headerlink" href="#mode-de-sortie-du-bl-touch" title="Permanent link">¶</a></h2>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Un BL-Touch V3.0 accepte le réglage d'un mode de sortie 5V ou OPEN-DRAIN, un BL-Touch V3.1 le supporte aussi et peut également le stocker dans son EEPROM interne. Si votre carte contrôleur a besoin du niveau logique haut de 5V du mode 5V, vous pouvez régler le paramètre 'set_output_mode' dans la section [bltouch] du fichier de configuration de l'imprimante sur "5V".<strong><em>N'utilisez le mode 5V que si la ligne d'entrée de votre carte contrôleur est tolérante à cette tension (5V). C'est pourquoi la configuration par défaut de ces versions de BL-Touch est le mode OPEN-DRAIN. Vous pourriez potentiellement endommager le CPU de votre carte contrôleur</em></strong></p>
|
||||
<p>Un BL-Touch V3.0 accepte le réglage d'un mode de sortie 5V ou OPEN-DRAIN, un BL-Touch V3.1 le supporte aussi et peut également le stocker dans son EEPROM interne. Si votre carte contrôleur a besoin du niveau logique haut de 5V du mode 5V, vous pouvez régler le paramètre 'set_output_mode' dans la section [bltouch] du fichier de configuration de l'imprimante sur "5V".</p>
|
||||
<p><strong><em>N'utilisez le mode 5V que si la ligne d'entrée de votre carte contrôleur est tolérante à cette tension (5V). C'est pourquoi la configuration par défaut de ces versions de BL-Touch est le mode OPEN-DRAIN. Vous pourriez potentiellement endommager le CPU de votre carte contrôleur</em></strong></p>
|
||||
<p>En résumé : Si une carte contrôleur a besoin d'un mode 5V ET qu'elle est tolérante à 5V sur sa ligne de signal d'entrée ET si</p>
|
||||
</li>
|
||||
</ul>
|
||||
<ul>
|
||||
<li>vous avez un BL-Touch Smart V3.0, vous devez utiliser le paramètre 'set_output_mode : 5V' pour assurer ce réglage à chaque démarrage, puisque la sonde ne peut pas se souvenir du réglage nécessaire.</li>
|
||||
<li>vous avez un BL-Touch Smart V3.1, vous avez le choix d'utiliser 'set_output_mode : 5V' ou de mémoriser le mode une fois pour toutes en utilisant une commande 'BLTOUCH_STORE MODE=5V' manuellement et sans plus utiliser le paramètre 'set_output_mode:'.</li>
|
||||
<li>vous avez une autre sonde : Certaines sondes ont une trace sur la carte de circuit imprimé à couper ou un cavalier à régler afin de définir (de façon permanente) le mode de sortie. Dans ce cas, omettez complètement le paramètre 'set_output_mode'.
|
||||
Si vous avez une version V3.1, n'automatisez pas ou ne répétez pas la mémorisation du mode de sortie afin d'éviter d'user l'EEPROM de la sonde. L'EEPROM du BLTouch permet environ 100.000 mises à jour. 100 mises à jour par jour représentent environ 3 ans de fonctionnement avant l'usure de la mémoire. Ainsi, le stockage du mode de sortie dans la V3.1 est conçu par le vendeur pour être une opération compliquée (le défaut d'usine étant un mode sûr OPEN DRAIN) et n'est pas adapté pour être émis de manière répétée par un trancheur, une macro ou autre, il est préférable de ne l'utiliser que lors de la première intégration de la sonde dans l'électronique de l'imprimante.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
@@ -1812,7 +1812,10 @@ adaptive_margin: 5
|
||||
</code></pre></div>
|
||||
|
||||
<ul>
|
||||
<li><code>adaptive_margin</code> <em>Default Value: 0</em> Margin (in mm) to add around the area of the bed used by the defined objects. The diagram below shows the adapted bed mesh area with an <code>adaptive_margin</code> of 5mm. The adapted mesh area (area in green) is computed as the used bed area (area in blue) plus the defined margin.<img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></li>
|
||||
<li>
|
||||
<p><code>adaptive_margin</code> <em>Default Value: 0</em> Margin (in mm) to add around the area of the bed used by the defined objects. The diagram below shows the adapted bed mesh area with an <code>adaptive_margin</code> of 5mm. The adapted mesh area (area in green) is computed as the used bed area (area in blue) plus the defined margin.</p>
|
||||
<p><img alt="adaptive_bedmesh_margin" src="img/adaptive_bed_mesh_margin.svg" /></p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>By nature, adaptive bed meshes use the objects defined by the Gcode file being printed. Therefore, it is expected that each Gcode file will generate a mesh that probes a different area of the print bed. Therefore, adapted bed meshes should not be re-used. The expectation is that a new mesh will be generated for each print if adaptive meshing is used.</p>
|
||||
<p>It is also important to consider that adaptive bed meshing is best used on machines that can normally probe the entire bed and achieve a maximum variance less than or equal to 1 layer height. Machines with mechanical issues that a full bed mesh normally compensates for may have undesirable results when attempting print moves <strong>outside</strong> of the probed area. If a full bed mesh has a variance greater than 1 layer height, caution must be taken when using adaptive bed meshes and attempting print moves outside of the meshed area.</p>
|
||||
|
||||
@@ -1481,14 +1481,15 @@ iface can0 can static
|
||||
</code></pre></div>
|
||||
|
||||
<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>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.</p>
|
||||
<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".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".</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>
|
||||
<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>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>
|
||||
<h2 id="conseils-pour-le-depannage">Conseils pour le dépannage<a class="headerlink" href="#conseils-pour-le-depannage" title="Permanent link">¶</a></h2>
|
||||
<p>Voir le document <a href="CANBUS_Troubleshooting.html">Dépannage du Bus CAN</a>.</p>
|
||||
|
||||
|
||||
@@ -1447,7 +1447,8 @@
|
||||
<p>Ce que le relecteur recherche le plus souvent :</p>
|
||||
<ol>
|
||||
<li>
|
||||
<p>La soumission est-elle exempte de défauts et est-elle prête à être déployée à grande échelle ?Les soumissionnaires sont censés tester leurs modifications avant de les soumettre. Les relecteurs recherchent les erreurs, mais ne testent pas, en général, les soumissions. Une soumission acceptée est souvent déployée sur des milliers d'imprimantes dans les quelques semaines qui suivent son acceptation. La qualité des soumissions est donc considérée comme une priorité.</p>
|
||||
<p>La soumission est-elle exempte de défauts et est-elle prête à être déployée à grande échelle ?</p>
|
||||
<p>Les soumissionnaires sont censés tester leurs modifications avant de les soumettre. Les relecteurs recherchent les erreurs, mais ne testent pas, en général, les soumissions. Une soumission acceptée est souvent déployée sur des milliers d'imprimantes dans les quelques semaines qui suivent son acceptation. La qualité des soumissions est donc considérée comme une priorité.</p>
|
||||
<p>Le dépôt GitHub principal de <a href="https://github.com/Klipper3d/klipper">Klipper3d/klipper</a> n'accepte pas les travaux expérimentaux. Les auteurs doivent effectuer les expérimentations, le débogage et les tests dans leurs propres dépôts. Le serveur <a href="Contact.html">Klipper Discourse</a> est un bon endroit pour faire connaître les nouveaux travaux et trouver des utilisateurs désireux de fournir des commentaires concrets.</p>
|
||||
<p>Les soumissions doivent réussir tous les <a href="Debugging.html">tests de régression</a>.</p>
|
||||
<p>Lorsqu'ils corrigent un défaut dans le code, les soumissionnaires doivent avoir une compréhension générale de la cause fondamentale de ce défaut, et la correction doit cibler cette seule cause fondamentale.</p>
|
||||
@@ -1456,7 +1457,8 @@
|
||||
<p>Les mises à jour de la documentation ne doivent pas indiquer qu'il s'agit d'un "travail en cours".</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>La demande apporte-t-elle un avantage "à fort impact" à des utilisateurs du monde réel effectuant des tâches du monde réel ?Les relecteurs doivent identifier, au moins dans leur propre esprit, à peu près "qui est le public cible", une échelle approximative de "la taille de ce public", le "bénéfice" qu'ils obtiendront, comment le "bénéfice est mesuré", et les "résultats de ces tests de mesure". Dans la plupart des cas, ces éléments sont évidents pour l'auteur et l'examinateur, et ne sont pas explicitement mentionnés lors d'un examen.</p>
|
||||
<p>La demande apporte-t-elle un avantage "à fort impact" à des utilisateurs du monde réel effectuant des tâches du monde réel ?</p>
|
||||
<p>Les relecteurs doivent identifier, au moins dans leur propre esprit, à peu près "qui est le public cible", une échelle approximative de "la taille de ce public", le "bénéfice" qu'ils obtiendront, comment le "bénéfice est mesuré", et les "résultats de ces tests de mesure". Dans la plupart des cas, ces éléments sont évidents pour l'auteur et l'examinateur, et ne sont pas explicitement mentionnés lors d'un examen.</p>
|
||||
<p>Les soumissions à la branche principale de Klipper doivent avoir un public cible important. En règle générale, les soumissions doivent cibler une base d'au moins 100 utilisateurs du monde réel.</p>
|
||||
<p>Si un relecteur demande des détails sur les "avantages" d'une proposition, ne considérez pas cela comme une critique. Être capable de comprendre les avantages concrets d'un changement est une partie naturelle d'un examen.</p>
|
||||
<p>Lorsque l'on discute des avantages, il est préférable de parler de "faits et de mesures". En général, les évaluateurs ne cherchent pas des réponses du type "quelqu'un pourrait trouver l'option X utile", ni des réponses du type "cette soumission ajoute une fonctionnalité que le micrologiciel X met en œuvre". Au lieu de cela, il est généralement préférable de discuter des détails sur la façon dont l'amélioration de la qualité a été mesurée et quels étaient les résultats de ces mesures - par exemple, "les tests sur les imprimantes Acme X1000 montrent des coins améliorés comme on le voit sur l'image ...", ou par exemple "le temps d'impression de l'objet X du monde réel sur une imprimante Foomatic X900 est passé de 4 heures à 3,5 heures". Il est entendu que les tests de ce type peuvent prendre beaucoup de temps et d'efforts. Certaines des fonctionnalités les plus remarquables de Klipper ont nécessité des mois de discussion, de re-travail, de tests et de documentation avant d'être intégrées dans la branche principale.</p>
|
||||
@@ -1466,17 +1468,18 @@
|
||||
<p>Les nouveaux modules, les nouvelles options et les nouveaux paramètres ne doivent pas offrir des fonctionnalités similaires à celles des modules existants - si les différences sont arbitraires, il est préférable d'utiliser le système existant ou de remanier le code existant.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Le droit d'auteur de la soumission est-il clair, non gracieux et compatible ?Les nouveaux fichiers C et Python doivent comporter une déclaration de copyright sans ambiguïté. Voir les fichiers existants pour le format préféré. Il est déconseillé de déclarer un droit d'auteur sur un fichier existant lorsque l'on apporte des modifications mineures à ce fichier.</p>
|
||||
<p>Le droit d'auteur de la soumission est-il clair, non gracieux et compatible ?</p>
|
||||
<p>Les nouveaux fichiers C et Python doivent comporter une déclaration de copyright sans ambiguïté. Voir les fichiers existants pour le format préféré. Il est déconseillé de déclarer un droit d'auteur sur un fichier existant lorsque l'on apporte des modifications mineures à ce fichier.</p>
|
||||
<p>Le code provenant de sources tierces doit être compatible avec la licence Klipper (GNU GPLv3). Les ajouts importants de code tiers doivent être ajoutés au répertoire <code>lib/</code> (et suivre le format décrit dans <a href="https://github.com/Klipper3d/klipper/blob/master/lib/README">lib/README</a>).</p>
|
||||
<p>Les soumissionnaires doivent fournir une <a href="#format-of-commit-messages">ligne Signed-off-by</a> en utilisant leur nom réel complet. Elle indique que le soumissionnaire est d'accord avec le <a href="developer-certificate-of-origin">certificat d'origine du développeur</a>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>La soumission suit-elle les directives spécifiées dans la documentation de Klipper ?En particulier, le code doit suivre les directives de <Code_Overview.md> et les fichiers de configuration doivent suivre les directives de <Example_Configs.md>.</p>
|
||||
<p>La soumission suit-elle les directives spécifiées dans la documentation de Klipper ?</p>
|
||||
<p>En particulier, le code doit suivre les directives de <Code_Overview.md> et les fichiers de configuration doivent suivre les directives de <Example_Configs.md>.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>La documentation de Klipper est-elle mise à jour pour refléter les nouveaux changements ?Au minimum, la documentation de référence doit être mise à jour avec les modifications correspondantes du code :</p>
|
||||
</li>
|
||||
</ol>
|
||||
<p>La documentation de Klipper est-elle mise à jour pour refléter les nouveaux changements ?</p>
|
||||
<p>Au minimum, la documentation de référence doit être mise à jour avec les modifications correspondantes du code :</p>
|
||||
<ul>
|
||||
<li>Toutes les commandes et tous les paramètres de commande doivent être documentés dans <G-Codes.md>.</li>
|
||||
<li>Tous les modules destinés aux utilisateurs et leurs paramètres de configuration doivent être documentés dans <Config_Reference.md>.</li>
|
||||
@@ -1484,10 +1487,13 @@
|
||||
<li>Tous les nouveaux "webhooks" et leurs paramètres doivent être documentés dans <API_Server.md>.</li>
|
||||
<li>Toute modification qui apporte un changement non rétrocompatible à une commande ou à un paramètre du fichier de configuration doit être documentée dans <Config_Changes.md>.</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Les nouveaux documents doivent être ajoutés à <Overview.md> et être ajoutés à l'index du site web <a href="https://github.com/Klipper3d/klipper/blob/master/docs/_klipper3d/mkdocs.yml">docs/_klipper3d/mkdocs.yml</a>.</p>
|
||||
<ol>
|
||||
<li>
|
||||
<p>Les commits sont-ils bien formés, abordent-ils un seul sujet par commit, et sont-ils indépendants ?Les messages de validation doivent suivre le <a href="#format-of-commit-messages">format préféré</a>.</p>
|
||||
<p>Les commits sont-ils bien formés, abordent-ils un seul sujet par commit, et sont-ils indépendants ?</p>
|
||||
<p>Les messages de validation doivent suivre le <a href="#format-of-commit-messages">format préféré</a>.</p>
|
||||
<p>Les commits ne doivent pas avoir de conflit de fusion. Les nouveaux ajouts à la branche maîtresse de Klipper sont toujours effectués via un "rebase" ou un "squash and rebase". Il n'est généralement pas nécessaire pour les soumissionnaires de fusionner à nouveau leur soumission à chaque mise à jour du dépôt maître de Klipper. Cependant, s'il y a un conflit de fusion, il est recommandé aux soumissionnaires d'utiliser <code>git rebase</code> pour résoudre le conflit.</p>
|
||||
<p>Chaque validation doit porter sur un seul changement de haut niveau. Les changements importants doivent être décomposés en plusieurs commits indépendants. Chaque livraison doit se suffire à elle-même pour que des outils comme <code>git bisect</code> et <code>git revert</code> fonctionnent de manière fiable.</p>
|
||||
<p>Les modifications des espaces blancs ne doivent pas être mélangées avec les modifications fonctionnelles. En général, les changements gratuits d'espace blanc ne sont pas acceptés, sauf s'ils proviennent du "propriétaire" établi du code en cours de modification.</p>
|
||||
|
||||
@@ -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() -> _process_commands() -> cmd_G1()</code>. Finalement, la classe ToolHead est invoquée pour exécuter la demande réelle : <code>cmd_G1() -> 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() -> LookAheadQueue.add_move() -> LookAheadQueue.flush() -> Move.set_junction() -> 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() -> LookAheadQueue.add_move() -> LookAheadQueue.flush() -> Move.set_junction() -> 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() -> 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() -> trapq_append()</code> (in klippy/chelper/trapq.c). The step times are then generated: <code>ToolHead._process_moves() -> ToolHead._advance_move_time() -> ToolHead._advance_flush_time() -> MCU_Stepper.generate_steps() -> itersolve_generate_steps() -> 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() -> 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() -> 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() -> 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">¶</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>
|
||||
|
||||
@@ -1621,16 +1621,17 @@
|
||||
<li>Si vous avez déjà ajouté la section <code>[input_shaper]</code> au fichier printer.cfg, exécutez la commande <code>SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0</code>. Si vous obtenez l'erreur "Unknown command", vous pouvez l'ignorer - pour le moment - et continuer les mesures.</li>
|
||||
<li>Exécutez la commande : <code>TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5</code> Dans la pratique, nous essayons de rendre la résonance plus prononcée en définissant différentes valeurs élevées pour l'accélération. Cette commande augmentera l'accélération tous les 5 mm à partir de 1500 mm/sec² : 1500 mm/sec², 2000 mm/sec², 2500 mm/sec² et ainsi de suite jusqu'à 7000 mm/sec² pour la dernière bande.</li>
|
||||
<li>Imprimez le modèle de test tranché avec les paramètres indiqués.</li>
|
||||
<li>Vous pouvez arrêter l'impression avant la fin si la résonance est clairement visible et si vous constatez que l'accélération devient trop forte pour votre imprimante (par exemple, l'imprimante tremble trop ou commence à sauter des pas).</li>
|
||||
<li>
|
||||
<p>Vous pouvez arrêter l'impression avant la fin si la résonance est clairement visible et si vous constatez que l'accélération devient trop forte pour votre imprimante (par exemple, l'imprimante tremble trop ou commence à sauter des pas).</p>
|
||||
<ol>
|
||||
<li>Utilisez les marques X et Y à l'arrière du modèle comme référence. Les mesures du côté avec la marque X doivent être utilisées pour la <em>configuration</em> de l'axe X, et les mesures du côté avec la marque Y pour la configuration de l'axe Y. Mesurez la distance <em>D</em> (en mm) entre plusieurs oscillations sur la partie de la pièce avec la marque X, près des encoches et en sautant de préférence la ou les deux premières oscillations. Pour mesurer plus facilement la distance entre les oscillations, marquez d'abord les oscillations, puis mesurez la distance entre les marques avec une règle ou un pied à coulisse :|<img alt="Marques de résonances" src="img/ringing-mark.jpg" />|<img alt="Mesure de la résonance" src="img/ringing-measure.jpg" />|</li>
|
||||
<li>Comptez le nombre d'oscillations <em>N</em> correspondant à la distance mesurée <em>D</em>. Si vous ne savez pas comment compter les oscillations, reportez-vous à l'image ci-dessus, qui montre <em>N</em> = 6 oscillations.</li>
|
||||
<p>Utilisez les marques X et Y à l'arrière du modèle comme référence. Les mesures du côté avec la marque X doivent être utilisées pour la <em>configuration</em> de l'axe X, et les mesures du côté avec la marque Y pour la configuration de l'axe Y. Mesurez la distance <em>D</em> (en mm) entre plusieurs oscillations sur la partie de la pièce avec la marque X, près des encoches et en sautant de préférence la ou les deux premières oscillations. Pour mesurer plus facilement la distance entre les oscillations, marquez d'abord les oscillations, puis mesurez la distance entre les marques avec une règle ou un pied à coulisse :</p>
|
||||
<p>|<img alt="Marques de résonances" src="img/ringing-mark.jpg" />|<img alt="Mesure de la résonance" src="img/ringing-measure.jpg" />|</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Comptez le nombre d'oscillations <em>N</em> correspondant à la distance mesurée <em>D</em>. Si vous ne savez pas comment compter les oscillations, reportez-vous à l'image ci-dessus, qui montre <em>N</em> = 6 oscillations.</p>
|
||||
</li>
|
||||
<li>Calculez la fréquence de résonance de l'axe X : <em>V</em> · <em>N</em> / <em>D</em> (Hz), où <em>V</em> est la vitesse des périmètres extérieurs (mm/s). Pour l'exemple ci-dessus, nous avons marqué 6 oscillations (N) sur une distance de 12,14 mm (D), et le test a été imprimé à une vitesse de 100 mm/s (V), donc la fréquence est 100 * 6 / 12,14 ≈ 49,4 Hz.</li>
|
||||
<li>Faites (8) - (10) pour la marque Y également.</li>
|
||||
</ol>
|
||||
</li>
|
||||
</ol>
|
||||
<p>Notez que la résonance sur l'impression de test devrait suivre les encoches courbées de la pièce, comme dans l'image ci-dessus. Si ce n'est pas le cas, alors ce défaut n'est pas vraiment une résonance et a probablement une origine différente - soit mécanique, soit un problème d'extrudeuse. Ce problème doit être résolu avant d'activer et de régler les input shapers.</p>
|
||||
<p>Si les mesures ne sont pas fiables parce que, par exemple, la distance entre les oscillations n'est pas régulière, cela peut signifier que l'imprimante a plusieurs fréquences de résonance sur le même axe. On peut essayer de suivre le processus de réglage décrit dans la section <a href="#unreliable-measurements-of-ringing-frequencies">Mesures peu fiables des fréquences de résonance</a> à la place et obtenir quand même une amélioration grâce à l'input shaping.</p>
|
||||
<p>La fréquence de résonance peut dépendre de la position du modèle sur le plateau et de la hauteur Z, <em>surtout sur les imprimantes delta</em> ; vous pouvez vérifier si vous observez des différences de fréquences à différentes positions le long des côtés du modèle de test et à différentes hauteurs. Si c'est le cas, vous pouvez calculer les fréquences de résonance moyennes sur les axes X et Y.</p>
|
||||
|
||||
@@ -2012,7 +2012,10 @@
|
||||
<h2 id="exclude_object">exclude_object<a class="headerlink" href="#exclude_object" title="Permanent link">¶</a></h2>
|
||||
<p>Les informations suivantes sont disponibles dans l'objet <a href="Exclude_Object.html">exclude_object</a> :</p>
|
||||
<ul>
|
||||
<li><code>objects</code> : Un tableau des objets connus tel que fourni par la commande <code>EXCLUDE_OBJECT_DEFINE</code>. Il s'agit des mêmes informations fournies par la commande <code>EXCLUDE_OBJECT VERBOSE=1</code>. Les champs <code>center</code> et <code>polygon</code> ne seront présents que s'ils sont fournis dans l'original <code>EXCLUDE_OBJECT_DEFINE</code>Voici un exemple JSON :</li>
|
||||
<li>
|
||||
<p><code>objects</code> : Un tableau des objets connus tel que fourni par la commande <code>EXCLUDE_OBJECT_DEFINE</code>. Il s'agit des mêmes informations fournies par la commande <code>EXCLUDE_OBJECT VERBOSE=1</code>. Les champs <code>center</code> et <code>polygon</code> ne seront présents que s'ils sont fournis dans l'original <code>EXCLUDE_OBJECT_DEFINE</code></p>
|
||||
<p>Voici un exemple JSON :</p>
|
||||
</li>
|
||||
</ul>
|
||||
<div class="highlight"><pre><span></span><code>[
|
||||
{
|
||||
|
||||
Binary file not shown.
File diff suppressed because one or more lines are too long
106
fr/sitemap.xml
106
fr/sitemap.xml
@@ -2,267 +2,267 @@
|
||||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2024-05-05</lastmod>
|
||||
<lastmod>2024-05-06</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
</urlset>
|
||||
Binary file not shown.
Reference in New Issue
Block a user