Aller au contenu principal

Erreurs de système, de performance et de service

Cette page traite des problèmes liés aux délais de communication, aux erreurs de temporisation du 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 apparaissent pendant le référencement. Ceci est courant lors du référencement de l'axe Z avec plusieurs MCU.

Causes courantes :

  • Charge élevée sur l'hôte, due à l'exécution simultanée de KlipperScreen, de flux de caméra, etc.
  • Mouvement simultané de plusieurs axes moteur lors du référencement ; le courant élevé des signaux d'entraînement se couple aux lignes de communication CAN/USB, provoquant une interruption de la communication.
  • Réponse de communication instable de plusieurs MCU.
  • Mauvaise qualité des lignes de communication CAN/USB ou routage inapproprié.

Solutions :

Intervention 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 électrique. Ne modifiez pas vous-même le fil de terre, le câblage secteur ou la structure interne de l'alimentation.

  1. Exclure d'abord les interférences électromagnétiques : Vérifiez si les câbles CAN/USB sont séparés des câbles moteur et des câbles de chauffe. Référez-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 pour plus de détails.
  3. Vérifiez la mise à la terre de la machine et du blindage.

Arrêt du MCU 'mcu' : Stepper trop en retard​

Message d'erreur : L'événement de pas que Klipper a planifié d'envoyer au MCU est en retard par rapport à l'heure actuelle. Le MCU ne peut plus exécuter ces instructions de mouvement comme prévu, et l'imprimante passe en état d'arrêt.

Loading...

Cause de l'erreur : Cela n'est généralement pas dû à un élément de configuration fixe, mais plutôt à l'incapacité de la planification des mouvements côté hôte, de la sortie des pas du MCU ou de la planification de la communication à suivre le rythme. Une charge élevée sur l'hôte, une vitesse/accélération d'impression trop élevée, une micro-pas trop élevé, un délai de communication multi-MCU, une mauvaise qualité de la communication USB/CAN, ou des macros/G-code générant un grand nombre d'instructions de mouvement en peu de temps peuvent tous déclencher ce problème.

Scénario de référence : Lors de l'exécution d'un maillage de lit multipoint, si probe_count dans [bed_mesh] est trop grand et qu'un mesh_pps élevé est également configuré, des données de maillage trop denses peuvent être générées, augmentant la charge de calcul et de planification des mouvements sur l'hôte. Ce n'est qu'un scénario courant ; même sans maillage, d'autres situations entraînant une charge système ou un délai de communication élevé peuvent provoquer l'erreur Stepper too far in past.

Solutions :

  1. Consultez d'abord les lignes Stats dans klippy.log juste avant l'erreur pour confirmer s'il y a simultanément une utilisation élevée du CPU, bytes_retransmit, bytes_invalid, Timer too close, une déconnexion du MCU ou une anomalie de file d'attente.
  2. Désactivez temporairement les flux de caméra, KlipperScreen, les plugins de contrôle à distance et autres services gourmands pour réduire la charge sur l'hôte, puis testez à nouveau.
  3. Réduisez la vitesse d'impression, l'accélération et le micro-pas, et observez si l'erreur disparaît.
  4. Si l'erreur se produit lors du maillage multipoint, réduisez probe_count dans [bed_mesh], par exemple à 7,7 ou 9,9 pour tester.
  5. Si un mesh_pps élevé est configuré, réduisez-le ou supprimez-le, par exemple mesh_pps: 2,2.
  6. Vérifiez la qualité de la communication USB/CAN ; si vous utilisez CAN, confirmez la longueur de la file d'attente, les résistances de terminaison, l'ordre des fils, l'alimentation et le débit CAN du firmware.
  7. Examinez les macros ou G-code exécutés avant le déclenchement de l'erreur pour éviter les boucles de macros, les segments de ligne trop denses ou les scripts anormaux envoyant un grand nombre de commandes de mouvement en peu de temps.

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

Arrêt du MCU 'mcu' : Temporisateur trop proche​

Message d'erreur : La temporisation du MCU est trop proche, ce qui entraîne un délai d'attente du système.

Loading...

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

Solutions :

  1. Réduisez le micro-pas du moteur pas à pas pour diminuer la pression de traitement des impulsions sur le MCU.
  2. Réduisez la vitesse d'impression et l'accélération pour voir si le problème disparaît.
  3. Vérifiez la charge de l'hôte, l'alimentation électrique et la qualité de la communication USB/CAN.
  4. Après avoir coupé l'alimentation, vérifiez si le câble de communication entre le MCU et l'hôte est proche des câbles moteur, de chauffe, du lit chauffant ou des câbles d'alimentation. Si nécessaire, refaites le routage ou remplacez-le par un câble de communication blindé.
  5. Lors de la vérification de la mise à la terre de la machine, ne vérifiez que le point de terre et l'état de la prise fournis par le fabricant. Ne démontez pas l'alimentation et ne modifiez pas le fil de terre secteur.
  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 ou le firmware de l'hôte.

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

Arrêt du MCU : Événement de sortie numérique suivant manqué​

Message d'erreur : MCU 'xxx' shutdown: Missed scheduling of next digital out event.

Cause de l'erreur : Après que l'hôte Klipper a activé des sorties numériques telles que des chauffages ou des ventilateurs, le MCU doit recevoir la planification et la confirmation suivantes à temps. Si la charge de l'hôte est trop élevée, la planification du système est retardée, la communication USB/CAN est instable ou la file d'attente du bus CAN est anormale, le MCU ne reçoit pas l'événement de sortie numérique suivant à temps, ce qui entraîne un arrêt.

Attention

Cette erreur est liée à la planification de la sortie du chauffage. Ne contournez pas l'erreur en désactivant la protection de température, en désactivant verify_heater ou en supprimant les configurations de sécurité. Résolvez d'abord la charge de l'hôte et la qualité de la communication.

Solutions :

  1. Consultez d'abord les lignes Stats dans klippy.log juste avant cette erreur pour confirmer s'il y a simultanément bytes_retransmit, bytes_invalid, Timer too close ou des enregistrements de déconnexion du MCU.
  2. Réduisez la charge de l'hôte, désactivez temporairement les flux de caméra, KlipperScreen, les plugins de contrôle à distance et autres services gourmands.
  3. Vérifiez la qualité de la communication USB/CAN ; si vous utilisez CAN, confirmez la longueur de la file d'attente CAN0, les résistances de terminaison, l'ordre des fils, l'alimentation et le débit CAN du firmware.
  4. Réduisez la vitesse d'impression, l'accélération et le micro-pas, et observez si le problème disparaît.
  5. Si l'erreur ne se produit que pendant le chauffage, vérifiez également la charge du lit chauffant, de la cartouche chauffante, des ventilateurs et de l'alimentation. Ne démontez pas vous-même l'alimentation et ne vérifiez pas le câblage haute tension du lit chauffant secteur.
  6. Si le problème se produit sur une carte outil CAN, suivez les instructions de Dépannage des erreurs CAN pour continuer.

Configuration associée : Directives de débogage courantes, Réseau CAN et recherche d'ID.

Temporisateur reprogrammé dans le passé​

Message d'erreur : Le journal contient Rescheduled timer in the past ou un avertissement similaire.

Cause de l'erreur : Problème d'horloge système de l'hôte ou charge CPU trop élevée, ce qui fait que l'exécution réelle de la tâche planifiée est 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 utilisation anormale du CPU.

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

Erreur interne sur la 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 erronée ou une erreur de syntaxe du modèle Jinja2 dans le fichier de configuration.
  • Incompatibilité entre la version de Klipper et 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 le traceback Python complet sous l'erreur interne dans klippy.log.
  2. À l'aide du traceback, identifiez quel fichier de configuration ou macro est à l'origine du problème.
  3. Les causes courantes incluent des erreurs de syntaxe du modèle Jinja2 dans [gcode_macro], une configuration [respond] manquante 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, Instructions de modification de la configuration.

Impossible d'ouvrir le fichier / SD occupée​

Message d'erreur : Lors de l'impression d'un fichier, Unable to open file, Unable to get file list, SD busy, SD write not supported, SDCARD_RESET_FILE cannot be run from the sdcard apparaissent.

Causes courantes :

  • Le fichier G-code n'existe pas, son nom a été modifié ou le téléchargement n'est pas terminé.
  • Le [virtual_sdcard] path pointe vers un répertoire incorrect.
  • Les permissions du fichier sont anormales, l'utilisateur Klipper ne peut pas le lire.
  • Le nom du fichier contient des caractères spéciaux, ce qui provoque un problème de traitement par certaines interfaces frontales ou chemins système.
  • Une commande d'ouverture, de sélection, de réinitialisation ou d'écriture sur la carte SD virtuelle est exécutée alors qu'un fichier est en cours d'impression ou de lecture.
  • Le répertoire source de Klipper, le répertoire de configuration ou un autre répertoire non G-code est défini par erreur comme [virtual_sdcard] path.

Solutions :

  1. Re-téléchargez le fichier G-code via l'interface Web et confirmez que le nom du fichier correspond à la commande d'impression.
  2. Vérifiez que [virtual_sdcard] path pointe vers le répertoire réel contenant les G-code.
  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.
  5. Si le message SD busy apparaît, mettez d'abord l'impression en pause ou annulez-la, et confirmez qu'aucune autre macro n'est en train de manipuler le fichier de la carte SD virtuelle.
  6. Ne définissez pas ~/klipper, ~/printer_data/config ou des répertoires système comme répertoire de stockage des G-code.

Configuration associée : Instructions de modification de la configuration.

Le CRC du MCU ne correspond pas à la configuration / Impossible de mettre à jour la configuration du 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'.

Point crucial pour le diagnostic : Can not update MCU 'xxx' config as it is shutdown n'est généralement pas la cause première, mais une erreur ultérieure qui se produit lorsque Klipper tente de se reconnecter ou de reconfigurer le MCU alors qu'il est déjà en état d'arrêt/erreur. Lors du dépannage, ne regardez pas seulement la dernière ligne du journal ; remontez pour trouver la première véritable erreur.

Solutions :

  1. Exécutez FIRMWARE_RESTART et, si nécessaire, mettez la machine hors tension pendant 10 secondes, puis rallumez-la.
  2. Recherchez la première occurrence de shutdown, Timer too close, Lost communication, Verify heater, d'erreur TMC ou de température dans klippy.log et corrigez la cause racine qui a provoqué l'arrêt.
  3. Pour les machines avec plusieurs MCU, vérifiez un par un les ID USB ou UUID CAN des sections [mcu], [mcu xxx].
  4. Si vous venez de mettre à jour Klipper, recompilez et flashez le firmware de tous les MCU.
  5. Si vous utilisez [mcu host], vérifiez que le service klipper-mcu a démarré correctement, puis redémarrez Klipper.
  6. Si vous utilisez un système Klipper préinstallé ou personnalisé, assurez-vous que le journal est complet et que les versions du firmware Klipper et MCU sont cohérentes.

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

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

Solutions :

  1. Confirmez si quelqu'un a appuyé sur l'arrêt d'urgence ; si c'est le cas, après avoir exclu tout risque, exécutez FIRMWARE_RESTART.
  2. Recherchez M112, action_emergency_stop, emergency_stop dans vos macros personnalisées.
  3. Vérifiez si l'interface frontale, les plugins de contrôle à distance ou les scripts automatisés ont déclenché accidentellement l'interface d'arrêt d'urgence.

Performances insuffisantes de l'hôte entraînant un bégaiement d'impression​

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 le slicer produit des arcs G2 / G3, reportez-vous aux Recommandations sur l'ajustement des arcs pour les ajuster ou les désactiver.
  5. Si les performances de l'hôte sont vraiment insuffisantes, envisagez de passer à un hôte plus performant.

Redémarrage anormal de l'hôte / Plantage système​

Message d'erreur : Klipper/Moonraker se déconnecte soudainement pendant l'impression, klippy.log s'interrompt brusquement sans cause d'arrêt claire ; après la reconnexion de Mainsail/Fluidd, l'hôte ou Klipper a redémarré.

Causes courantes :

  • Alimentation insuffisante de l'hôte ; les variations de charge de l'USB, de la caméra, de l'écran ou du ventilateur pendant l'impression provoquent une coupure de courant.
  • Écriture/lecture anormale du disque système, de la carte TF ou de l'eMMC ; le journal s'interrompt soudainement ou le fichier est corrompu.
  • Surchauffe du CPU de l'hôte, entraînant une réduction de fréquence, un blocage ou un redémarrage protecteur du système.
  • Alimentation inverse via USB ou chemin d'alimentation des périphériques anormal, entraînant des interférences mutuelles entre la carte mère, l'écran ou l'hôte.
  • Services tiers, flux de caméra, plugins AI ou trop de connexions Web consommant des ressources.

Méthodes de dépannage :

Intervention hors tension

Avant de vérifier le câble d'alimentation de l'hôte, les câbles USB, les câbles d'écran, les câbles de ventilateur ou de réorganiser le routage, éteignez complètement l'imprimante et débranchez l'alimentation électrique. Ne démontez pas l'alimentation et ne modifiez pas le câblage secteur.

  1. Consultez d'abord klippy.log, moonraker.log et les journaux système pour déterminer s'il s'agit d'une erreur Klipper ou d'un redémarrage complet de l'hôte.
  2. Vérifiez les spécifications d'alimentation de l'hôte, évitez d'utiliser des câbles d'alimentation avec un courant insuffisant ou une chute de tension importante.
  3. Vérifiez l'état de santé du disque système, remplacez la carte TF, l'eMMC si nécessaire, ou reflashez le système.
  4. Vérifiez le refroidissement de l'hôte, assurez-vous que le ventilateur fonctionne, que le dissipateur thermique est en contact et que le boîtier est ventilé.
  5. Désactivez temporairement les flux de caméra, KlipperScreen, les plugins de contrôle à distance et autres services à forte charge, puis testez l'impression.
  6. Si vous suspectez une alimentation inverse via USB, privilégiez le remplacement par un câble USB prêt à l'emploi ou une solution de connexion avec isolation de l'alimentation. Les utilisateurs ordinaires ne doivent pas modifier les câbles eux-mêmes.

Indications de pause, de reprise et de sauvegarde d'état​

Message d'erreur : Print already paused, Print is not paused, resume aborted, Unknown g-code state: PAUSE_STATE.

Causes courantes :

  • Exécution répétée de PAUSE, ou exécution de RESUME alors que l'impression a déjà été annulée.
  • Incohérence de nom entre SAVE_GCODE_STATE NAME= et RESTORE_GCODE_STATE NAME= dans les macros de pause/reprise personnalisées.
  • Double définition ou conflit logique entre les macros de pause/reprise par défaut de Mainsail/Fluidd et les macros provenant de paquets tiers.
  • L'état de pause d'origine a été perdu après un arrêt d'urgence, FIRMWARE_RESTART ou une erreur Klipper.

Solutions :

  1. Confirmez l'état actuel de l'impression ; n'exécutez pas RESUME si elle n'est pas en pause.
  2. Vérifiez si [pause_resume] est activé et si les macros PAUSE / RESUME / CANCEL_PRINT sont définies plusieurs fois.
  3. Vérifiez que les noms dans SAVE_GCODE_STATE et RESTORE_GCODE_STATE dans vos macros correspondent exactement.
  4. Après une erreur Klipper ou un arrêt d'urgence, il n'est pas recommandé de reprendre l'impression. Éliminez d'abord les risques, puis recommencez.

Redémarrages répétés 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 automatiquement en continu et se ferme en quelques secondes à chaque fois. Le journal peut montrer Klipper restarting too fast ou chaque klippy.log de redémarrage est très court.

Méthodes de dépannage :

  1. Consultez d'abord la fin du fichier journal pour confirmer la raison de la dernière fermeture :

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

  2. Si la fin du journal est un traceback 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 identifier la cause racine ; il s'agit généralement du résultat d'échecs répétés de lancement par systemd. Traitez en priorité la première véritable erreur dans klippy.log.

  4. Si la fin du journal affiche MCU Protocol error, Unknown command, etc., cela signifie une incompatibilité de version du firmware. Recompilez et flashez le firmware du MCU.

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

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

Loading...