Aller au contenu principal

Erreurs de système, de performance et de service

Cette page regroupe les problèmes liés aux délais de communication, aux erreurs de temporisation MCU, aux performances de l'hôte, au flashage du firmware et au démarrage du service Klipper.

Problème de délai d'attente lors du référencement​

Message d'erreur : Communication timeout during homing, Error during homing xxx apparaît pendant le référencement. Courant lors du référencement de l'axe Z avec plusieurs MCU.

Causes courantes :

  • Charge excessive sur l'hôte, exécution simultanée de KlipperScreen, flux de caméra, etc.
  • Mouvement simultané de plusieurs moteurs d'axe pendant le référencement, le courant de forte intensité interfère avec les lignes de communication CAN/USB, provoquant une interruption de la communication.
  • Réponse de communication instable des MCU multiples.
  • Problème de qualité des câbles CAN/USB ou de routage inapproprié.

Solutions :

Opération hors tension

Avant de réorganiser le routage des câbles CAN/USB, de vérifier le blindage ou la mise à la terre, éteignez complètement l'imprimante et débranchez l'alimentation. Ne modifiez pas vous-même le fil de terre de l'alimentation, le câblage secteur ou la structure interne de l'alimentation.

  1. Excluez d'abord les interférences électromagnétiques : vérifiez si les câbles CAN/USB sont séparés des câbles moteur et de chauffage. Reportez-vous aux étapes de dépannage des interférences dans Configuration du réseau CAN et recherche d'ID.
  2. Essayez d'ajuster le paramètre de délai d'attente TRSYNC_TIMEOUT ou de désactiver temporairement KlipperScreen. Voir Problème de délai d'attente lors du référencement.
  3. Vérifiez la mise à la terre de la machine et celle du blindage.

Arrêt MCU 'mcu' : Stepper too far in past​

Message d'erreur : L'événement pas à pas dépasse la plage de temps traitable par la MCU, l'imprimante passe en état d'arrêt.

Loading...

Scénario de référence : Cette erreur n'est pas nécessairement causée par la configuration du lit. La cause réelle doit être déterminée en combinant le klippy.log et l'opération en cours. Lors d'un maillage multipoint, si probe_count dans [bed_mesh] est trop grand et que mesh_pps est élevé, des données de grille trop denses peuvent être générées, augmentant la charge de calcul et de planification des mouvements de l'hôte.

Solutions :

  1. Si l'erreur se produit pendant un maillage multipoint, réduisez d'abord probe_count dans [bed_mesh], par exemple à 7,7 ou 9,9 pour tester.
  2. Si mesh_pps est configuré avec une valeur élevée, réduisez-la ou supprimez-la, par exemple en définissant mesh_pps: 2,2.
  3. Enregistrez la configuration et redémarrez Klipper, puis réexécutez l'opération qui a précédé l'erreur.
  4. Si l'erreur persiste, vérifiez la charge de l'hôte, la vitesse d'impression, l'accélération, la qualité de la communication et les macros ou G-codes en cours d'exécution.

Configuration associée : Présentation des macros, Directives de débogage courantes.

Arrêt MCU 'mcu' : Timer too close​

Message d'erreur : La minuterie MCU est trop proche, provoquant un délai d'attente système.

Loading...

Cause de l'erreur : Une charge de traitement trop élevée sur le microcontrôleur, un délai de réponse de l'hôte, une vitesse d'impression trop élevée, une micro-pas trop élevée, une interférence de synchronisation de l'horloge système ou une interférence sur la ligne de communication MCU peuvent tous déclencher ce problème.

Solutions :

  1. Réduisez la micro-pas du moteur pas à pas pour diminuer la charge de traitement d'impulsions de la MCU.
  2. Réduisez la vitesse d'impression et l'accélération et observez si le problème disparaît.
  3. Vérifiez la charge de l'hôte, l'alimentation et la qualité de la communication USB/CAN.
  4. Hors tension, vérifiez si le câble de communication entre la MCU et l'hôte est proche des câbles moteur, de chauffage, du lit chauffant ou des câbles d'alimentation. Re-câblez ou remplacez par un câble blindé si nécessaire.
  5. Lors de la vérification de la mise à la terre de la machine, confirmez uniquement l'état des points de mise à la terre fournis par le fabricant et des prises. Ne démontez pas l'alimentation et ne modifiez pas le fil de terre secteur vous-même.
  6. Si le problème se produit pendant la phase de référencement, reportez-vous à Problème de délai d'attente lors du référencement.
  7. Si le problème persiste, envisagez de reflasher le système de l'hôte ou le firmware.

Configuration associée : Directives de débogage courantes, Guide de référencement et d'étalonnage de la direction.

Temporisateur reprogrammé dans le passé​

Message d'erreur : Rescheduled timer in the past ou un avertissement similaire apparaît dans le journal.

Cause de l'erreur : Problème d'horloge système de l'hôte ou charge CPU trop élevée, entraînant une exécution réelle de la tâche programmée en retard par rapport à l'heure prévue.

Solutions :

  1. Si la synchronisation NTP est activée, désactivez-la temporairement pour tester.
  2. Réduisez la charge des autres services exécutés sur l'hôte, comme la fermeture des interfaces Web inutiles, des flux de caméra, etc.
  3. Si vous utilisez une machine virtuelle, envisagez de migrer vers une machine physique ou d'utiliser une source d'horloge plus stable.
  4. Vérifiez l'utilisation du CPU de l'hôte : utilisez htop pour voir si le processus klippy a une occupation CPU anormale.

Configuration associée : Directives de débogage courantes.

Erreur interne sur commande​

Message d'erreur : Internal error on command:"XXX", Klipper passe en état d'arrêt.

Causes courantes :

  • Une macro ou une commande G-code a déclenché une exception Python interne à Klipper.
  • Une référence de macro incorrecte ou une erreur de syntaxe de modèle Jinja2 dans le fichier de configuration.
  • Incompatibilité de version de Klipper avec le format du fichier de configuration.
  • Le nom du fichier G-code contient des caractères spéciaux provoquant une erreur de codage.

Solutions :

  1. Consultez la trace Python complète sous l'erreur interne dans klippy.log.
  2. Utilisez la trace pour identifier quel fichier de configuration ou macro est à l'origine du problème.
  3. Les causes courantes incluent des erreurs de syntaxe de modèle Jinja2 dans [gcode_macro], l'absence de configuration [respond], ou un chemin [virtual_sdcard] incorrect.
  4. Si l'erreur est liée à SDCARD_PRINT_FILE et indique ascii codec can't decode, renommez le fichier G-code en utilisant uniquement des lettres anglaises, des chiffres, des underscores ou des tirets.

Configuration associée : Présentation des macros, Explication des modifications de configuration.

Impossible d'ouvrir le fichier​

Message d'erreur : Unable to open file lors de la tentative d'impression d'un fichier.

Causes courantes :

  • Le fichier G-code n'existe pas, son nom a été modifié ou le téléchargement est incomplet.
  • Le [virtual_sdcard] path pointe vers un répertoire incorrect.
  • Problème de permissions de fichier, l'utilisateur Klipper ne peut pas lire.
  • Le nom du fichier contient des caractères spéciaux, ce qui perturbe le traitement du chemin par certaines interfaces ou systèmes.

Solutions :

  1. Retéléchargez le fichier G-code depuis l'interface Web et vérifiez que le nom correspond à la commande d'impression.
  2. Vérifiez que [virtual_sdcard] path pointe vers le répertoire réel contenant les G-codes.
  3. Vérifiez les permissions du répertoire : ls -la ~/printer_data/gcodes/.
  4. Renommez le fichier en utilisant uniquement des lettres anglaises, des chiffres, des underscores ou des tirets, puis testez à nouveau.

Configuration associée : Explication des modifications de configuration.

Le CRC MCU ne correspond pas à la config / Impossible de mettre à jour la config MCU​

Message d'erreur : MCU 'xxx' CRC does not match config, Can not update MCU 'xxx' config as it is shutdown, Unable to configure MCU 'xxx'.

Solutions :

  1. Exécutez FIRMWARE_RESTART, si nécessaire, mettez la machine hors tension pendant 10 secondes, puis remettez-la sous tension.
  2. Recherchez la première erreur apparue plus tôt dans klippy.log et corrigez la cause racine de l'arrêt.
  3. Pour une machine multi-MCU, vérifiez individuellement les ID USB ou les UUID CAN pour [mcu], [mcu xxx].
  4. Si Klipper vient d'être mis à jour, recompilez et flashez le firmware de tous les MCU.

Arrêt dû à la commande M112 / demande webhooks​

Message d'erreur : Shutdown due to M112 command ou Shutdown due to webhooks request.

Solutions :

  1. Confirmez si un arrêt d'urgence a été déclenché manuellement ; si c'est le cas, après avoir éliminé le risque, exécutez FIRMWARE_RESTART.
  2. Recherchez M112, action_emergency_stop, emergency_stop dans les macros personnalisées.
  3. Vérifiez si l'interface avant, le plugin de contrôle à distance ou le script d'automatisation déclenchent accidentellement l'interface d'arrêt d'urgence.

Bégaiement d'impression dû à des performances insuffisantes de l'hôte​

Message d'erreur : Aucune erreur évidente, mais des pauses intermittentes et une extrusion irrégulière se produisent pendant l'impression.

Solutions :

  1. Réduisez la vitesse d'impression et l'accélération.
  2. Désactivez les services Web inutiles, les flux de caméra, etc., sur l'hôte.
  3. Réduisez probe_count et mesh_pps dans [bed_mesh].
  4. Si les performances de l'hôte sont vraiment insuffisantes, envisagez de le remplacer par un modèle plus puissant.

Redémarrage répété de Klipper (Klippy not connected clignotant)​

Message d'erreur : Mainsail / Fluidd affiche Klippy not connected de manière répétée, Klipper redémarre constamment et se ferme en quelques secondes. Le journal peut montrer Klipper restarting too fast ou chaque klippy.log de redémarrage est très court.

Méthode de diagnostic :

  1. Vérifiez d'abord la fin du fichier journal pour identifier la raison de la dernière sortie :

    tail -100 ~/printer_data/logs/klippy.log

  2. Si la fin du journal est une trace Python, cela indique un crash dû à une analyse de configuration ou une exception interne.

  3. Ne vous fiez pas uniquement à Klipper restarting too fast pour déterminer la cause racine ; il s'agit généralement du résultat de tentatives de relance infructueuses par systemd. Traitez d'abord la première erreur réelle dans klippy.log.

  4. Si la fin du journal affiche MCU Protocol error, Unknown command, etc., cela indique une incompatibilité de version du firmware ; vous devez recompiler et flasher le firmware MCU.

  5. Si le journal est très court et sans erreur évidente, essayez de localiser le problème en utilisant une configuration minimale par dichotomie.

  6. Vérifiez s'il y a des références circulaires dans les fichiers include.

Loading...