Aller au contenu principal

Erreurs système, de performance et de service

Cette page regroupe les problèmes liés aux délais d'attente de communication lors du homing, aux erreurs de minuterie 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 homing​

Message d'erreur : Communication timeout during homing, Error during homing xxx apparaissent pendant le processus de homing. Courant dans les scénarios de homing de l'axe Z avec plusieurs MCU.

Causes courantes :

  • Charge élevée sur l'hôte, avec KlipperScreen, flux de caméra, etc., fonctionnant simultanément.
  • Pendant le homing, les moteurs de plusieurs axes bougent en même temps, et les signaux de commande à fort courant se couplent aux lignes de communication CAN/USB, provoquant une interruption de la communication.
  • Réponse de communication instable des multiples MCU.
  • Problème de qualité de la ligne de communication CAN/USB ou de câblage inapproprié.

Solutions :

Opération hors tension

Avant de réorganiser le câblage 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 la terre d'alimentation, le câblage secteur ou la structure interne de l'alimentation.

  1. Éliminez d'abord les interférences électromagnétiques : vérifiez que les câbles CAN/USB sont séparés des câbles moteurs et des câbles de chauffe, en vous référant 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 homing.
  3. Vérifiez que la mise à la terre de la machine et celle du blindage sont correctes.

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

Message d'erreur : L'événement de pas que Klipper prévoyait d'envoyer au MCU est en retard par rapport à l'heure actuelle, le MCU ne peut plus exécuter ces commandes de mouvement à l'heure prévue, l'imprimante passe à l'état d'arrêt.

Loading...

Cause de l'erreur : Il ne s'agit généralement pas d'un élément de configuration fixe, mais du résultat d'une planification des mouvements du côté hôte, de la sortie des pas du MCU ou de la planification de la communication qui ne peut pas être traitée à temps. Une charge élevée sur l'hôte, une vitesse/accélération d'impression trop élevée, une subdivision de pas trop élevée, un délai de communication multi-MCU, une mauvaise qualité de communication USB/CAN, des macros ou du G-code générant un grand nombre de commandes 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 multipoint, si probe_count dans [bed_mesh] est défini sur une valeur trop grande 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 de 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 Stepper too far in past.

Scénario de stagnation après reprise de l'impression : L'erreur peut également apparaître après PAUSE / RESUME, une reprise après rupture de filament ou une reprise après coupure de courant. Le journal typique montre : après la reprise, le buffer_time de la ligne Stats chute soudainement d'environ 1s à environ 0.2s, sd_pos n'augmente presque plus (la progression de l'impression stagne), mais sysload n'est pas élevé et il n'y a pas de déconnexion du MCU. Cela indique qu'après la reprise, les commandes de mouvement n'ont pas réussi à remplir en continu le tampon de pas, l'imprimante "imprime mais ne bouge presque pas" puis passe à l'arrêt. Lors du dépannage, vérifiez en priorité si les macros de reprise/continuation (resume_gcode, start_gcode) envoient des mouvements massifs ou des commandes de rétraction anormales au moment de la reprise, et si des retransmissions de communication (bytes_retransmit en augmentation) existaient déjà avant la reprise.

Solutions :

  1. Consultez d'abord la ligne Stats avant l'erreur dans klippy.log pour confirmer s'il existe simultanément une utilisation CPU élevée, bytes_retransmit, bytes_invalid, Timer too close, une déconnexion du MCU ou une anomalie de file d'attente.
  2. Désactivez temporairement le flux de caméra, KlipperScreen, les plugins de contrôle à distance et d'autres services gourmands en ressources pour réduire la charge de l'hôte, puis testez à nouveau.
  3. Réduisez la vitesse d'impression, l'accélération et la subdivision de pas, et observez si l'erreur disparaît.
  4. Si l'erreur se produit lors d'un 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 en le réglant sur 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, la résistance de terminaison, l'ordre des fils, l'alimentation et le débit CAN du firmware.
  7. Vérifiez les macros ou le G-code en cours d'exécution avant le déclenchement de l'erreur, évitez les boucles de macros, les segments de ligne trop courts ou les scripts anormaux envoyant un grand nombre de commandes de mouvement en peu de temps.

Références de configuration associées : Présentation des macros, Directives de débogage courantes.

Arrêt du 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 élevée sur l'ordinateur inférieur, un délai d'attente de réponse de l'hôte, une vitesse d'impression trop élevée, une subdivision trop élevée, une interférence avec la synchronisation de l'horloge système ou une interférence sur la ligne de communication du MCU peuvent tous déclencher ce problème.

Scénarios récents courants :

  • M600, PAUSE, RESUME, détection de rupture de filament ou macros de changement de filament qui attendent un certain temps puis reprennent l'impression, déclenchant ensuite Timer too close.
  • EDDY / TAP / carte d'outil CAN participant au homing Z, à Z_TILT_ADJUST, QUAD_GANTRY_LEVEL ou au maillage, avec des retransmissions CAN, des lectures I2C anormales ou des pics de charge de l'hôte dans le journal.
  • Têtes multiples, nœuds CAN multiples ou hôte à faibles performances exécutant simultanément la caméra, KlipperScreen et des plugins de contrôle à distance, la marge de planification est insuffisante.

Solutions :

  1. Réduisez la subdivision des moteurs pas à pas pour diminuer la pression de traitement des impulsions du 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. Après la coupure de l'alimentation, vérifiez si le câble de communication entre le MCU et l'hôte est proche des câbles moteurs, des câbles de chauffe, du câble du lit chauffant ou du câble d'alimentation ; si nécessaire, refaites le câblage 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 confirmez que le point de mise à la terre fourni par le fabricant et l'état de la prise ; ne démontez pas vous-même l'alimentation et ne modifiez pas la terre secteur.
  6. Si le problème survient pendant la phase de homing, consultez Problème de délai d'attente lors du homing.
  7. S'il survient après M600 ou une reprise après rupture de filament, vérifiez si la macro répète PAUSE, si le capteur de rupture de filament se déclenche par erreur pendant le changement de filament, et si les noms SAVE_GCODE_STATE / RESTORE_GCODE_STATE sont cohérents.
  8. S'il survient avec EDDY TAP, l'inclinaison Z ou le nivellement du portique, référez-vous d'abord à Méthodes de débogage du mode EDDY TAP, ou suivez le Recueil de problèmes EDDY.
  9. Si le problème persiste, envisagez de reflasher le système de l'hôte ou le firmware.

Références de configuration associées : Directives de débogage courantes, Guide de homing et de calibration de direction.

Arrêt du MCU : Missed scheduling of next digital out event​

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

Cause de l'erreur : Après l'activation d'une sortie numérique telle qu'un chauffage ou un ventilateur par l'hôte Klipper, le MCU doit recevoir à temps la planification et la confirmation suivantes. Si la charge de l'hôte est trop élevée, si la planification du système est retardée, si la communication USB/CAN est instable ou si la file d'attente du bus CAN est anormale, le MCU ne reçoit pas à temps l'événement de sortie numérique suivant et passe à l'état d'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é. Commencez par vérifier la charge de l'hôte et la qualité de la communication.

Solutions :

  1. Consultez d'abord la ligne Stats avant cette erreur dans klippy.log pour confirmer s'il existe 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 le flux de caméra, KlipperScreen, les plugins de contrôle à distance ou d'autres services gourmands en ressources.
  3. Vérifiez la qualité de la communication USB/CAN ; si vous utilisez CAN, confirmez la longueur de la file d'attente CAN0, la résistance 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 la subdivision de pas, et observez si le problème disparaît.
  5. Si cela ne se produit que pendant le chauffage, vérifiez également la charge du lit chauffant, de la hotend, 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 secteur.
  6. Si le problème se produit sur une carte d'outil CAN, suivez le Dépannage des erreurs CAN pour continuer.

Références de configuration associées : Directives de débogage courantes, Réseau CAN et recherche d'ID.

Minuterie replanifiée dans le passé (Rescheduled timer in the past)​

Message d'erreur : Rescheduled timer in the past ou des avertissements similaires apparaissent dans le journal.

Cause de l'erreur : Un problème d'horloge système de l'hôte ou une charge CPU trop élevée provoquent un retard d'exécution des tâches planifiées 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 désactivation des interfaces Web inutiles, des flux de caméra, etc.
  3. Si vous fonctionnez dans 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. Référence de configuration connexe : Directives de débogage courantes.

Arrêt du MCU 'mcu' : Débordement de la file d'attente de mouvement​

Message d'erreur : MCU 'mcu' shutdown: Move queue overflow.

Cause de l'erreur : La file d'attente de mouvement du MCU est pleine, l'hôte n'a pas synchronisé à temps la planification des mouvements et l'état avec le MCU. Cela se produit souvent en cas de performances insuffisantes de l'hôte, d'un grand nombre de petits mouvements fragmentés sur une courte période, d'une incompatibilité de version entre l'hôte Klipper et le firmware du MCU, ou de logique bloquante ajoutée par le fabricant à chaque commande de mouvement (écriture synchronisée sur disque, reprise après coupure de courant, etc.).

Points de diagnostic courants :

  • Dans klippy.log, l'écart entre la version de base de Git version et Loaded MCU 'xxx' ... version est important.
  • Le journal contient des mentions de dirty, de fichiers tiers klippy/extras, de reprise après coupure de courant personnalisée par le fabricant ou de Klipper non officiel.
  • Le même fichier G-code échoue à un endroit similaire, et le modèle contient de nombreux segments de ligne courts, des supports denses, des Z-hop en spirale ou des trajectoires complexes.
  • L'hôte à faibles performances exécute simultanément une caméra, un écran, un contrôle à distance ou d'autres services gourmands en ressources.

Solutions :

  1. Consultez l'intégralité du klippy.log pour vérifier d'abord s'il n'y a pas d'erreurs plus anciennes telles que Timer too close, déconnexion CAN, bytes_invalid ou erreurs de température/TMC.
  2. Après la mise à jour de Klipper, recompilez et flashez tous les firmwares des MCU pour garantir la cohérence des versions entre l'hôte, la carte mère et la carte outil.
  3. Désactivez temporairement le flux de la caméra, KlipperScreen, les plugins de contrôle à distance et autres services gourmands, puis effectuez un nouveau test.
  4. Réduisez la vitesse d'impression, l'accélération, le micro-pas, ou diminuez la précision des courbes, la complexité des supports et la densité des segments courts dans le slicer.
  5. Si vous utilisez une reprise après coupure de courant personnalisée par le fabricant, un enregistrement automatique de hauteur ou des plugins tiers, testez d'abord avec Klipper d'origine ou en désactivant ces fonctions ; ne modifiez pas directement le code source de Klipper comme étape de routine pour les clients ordinaires.
  6. Si cela ne se produit qu'avec un fichier G-code spécifique, re-slicez le modèle et vérifiez si le slicer génère des trajectoires anormalement denses.

Référence de configuration connexe : Directives de débogage courantes, Recommandations d'approximation d'arcs.

Erreur interne stepcompress / syncemitter / flush_handler​

Message d'erreur : stepper.error: Internal error in stepcompress, stepcompress ... Invalid sequence, Error in syncemitter 'extruder' step generation, Exception in flush_handler, Flush Handler error.

Cause de l'erreur : Klipper rencontre une exception interne lors de la génération ou de la compression des impulsions de pas. Dans les cas récents de la communauté, ce type de problème est souvent associé au balayage du lit à grande vitesse, aux plugins de sonde scanner / EDDY / Cartographe, à input_shaper, aux trajectoires de mouvement complexes ou aux modifications tierces de Klipper. Cela n'est pas nécessairement dû uniquement au slicer et ne doit pas être diagnostiqué uniquement par un nouveau slice.

Solutions :

  1. Conservez l'intégralité du klippy.log, en examinant attentivement la trace Python, la commande en cours d'exécution et les lignes Stats avant et après l'erreur.
  2. Si l'erreur se produit pendant BED_MESH_CALIBRATE, QUAD_GANTRY_LEVEL ou le balayage avec un scanner, réduisez d'abord la vitesse de balayage, le nombre de points, la densité d'interpolation et les paramètres de balayage du plugin.
  3. Désactivez temporairement les scanners tiers, la régulation automatique de vitesse, les améliorations de nivellement automatique, les packs de macros ou les modifications du fabricant, et testez à nouveau avec Klipper d'origine.
  4. Après la mise à jour de Klipper, reflashez tous les firmwares des MCU et confirmez que les versions des firmwares des périphériques correspondent à celle du Klipper hôte.
  5. Si le même modèle déclenche l'erreur à plusieurs reprises, re-slicez et réduisez la densité des segments courts ; si l'erreur réapparaît de manière aléatoire après le nouveau slice, poursuivez l'investigation en examinant la charge de l'hôte, les paramètres de mouvement et la compatibilité des plugins.
  6. Si l'imprimante présente des mouvements anormaux, des pas perdus ou un risque de collision, arrêtez-la immédiatement en urgence et effectuez un nouveau référencement ; ne reprenez pas la tâche d'origine.

Référence de configuration connexe : Erreurs de mouvement, de fin de course et de nivellement, Recueil des problèmes EDDY.

Erreur interne pendant la connexion / n'a pas d'attribut​

Message d'erreur : Après la mise à jour de Klipper, le démarrage ne peut pas être complété, le journal contient Unhandled exception during connect, Internal error during connect, et la fin de la trace peut ressembler à :

AttributeError: 'MCU' object has no attribute '_serialport'

D'autres messages has no attribute, got an unexpected keyword argument ou des indications d'interface de module manquante peuvent également apparaître.

Nature de l'erreur : Ce type d'erreur indique que Klipper rencontre une exception lors de l'exécution du code Python pendant la phase d'initialisation de la connexion. Dans les cas récents de la communauté, si la trace pointe vers un module tiers klippy/extras/, il s'agit généralement d'une mise à jour des interfaces internes de Klipper alors que l'extension ou le module personnalisé du fabricant, d'une version antérieure, appelle toujours l'ancienne interface ; ce n'est généralement pas un dommage du firmware du MCU et ne doit pas être traité en premier lieu comme un problème de câble série.

Causes courantes :

  • Klipper a été mis à jour, mais les sondes tierces, les changements de filament, les packs de macros ou d'autres extensions n'ont pas été mis à jour en même temps.
  • Utilisation d'une branche Klipper personnalisée par le fabricant avec des extensions conçues uniquement pour Klipper d'origine.
  • Fichiers incomplets lors de la mise à jour d'une extension, avec d'anciens et de nouveaux fichiers Python résiduels.
  • La trace pointe en réalité vers d'autres exceptions dans les fichiers de configuration, les fichiers de variables ou les modules d'origine, et ne provient pas d'un problème de compatibilité d'extension.

Solutions :

  1. Sauvegardez l'intégralité du klippy.log, lisez la trace à partir de la première Unhandled exception during connect, notez l'exception finale et le nom du dernier fichier klippy/extras/xxx.py avant l'exception.
  2. Examinez Git version, Modified files et Untracked files au début du journal. Si le fichier en cause appartient à une extension tierce, mettez d'abord à jour cette extension vers une version compatible avec la version actuelle de Klipper, conformément à sa documentation de maintenance.
  3. Désactivez temporairement le module tiers pointé par la trace ou l'include associé, puis redémarrez pour confirmer que Klipper d'origine peut se connecter correctement. Ne flashez pas à plusieurs reprises le MCU pour résoudre une absence d'attribut Python.
  4. Si vous utilisez un Klipper personnalisé par le fabricant, utilisez la méthode de mise à jour explicitement prise en charge par ce système ; ne mélangez pas Klipper d'origine, des branches personnalisées et des extensions de versions différentes.
  5. Si la trace ne pointe que vers des fichiers Klipper d'origine, et que Modified files / Untracked files ne présentent aucune anomalie, mettez à jour vers la version stable actuelle, collectez à nouveau le journal complet et signalez à la communauté Klipper les étapes de reproduction.
  6. La rétrogradation ne doit servir qu'à confirmer brièvement un problème de compatibilité de version. La solution à long terme consiste à mettre à jour l'extension ou à supprimer le module incompatible ; ne restez pas durablement sur une version connue comme trop ancienne.

Erreur interne pendant le callback ready : Impossible d'enregistrer la variable​

Message d'erreur : Klipper passe immédiatement en shutdown après le démarrage, le journal contient les mots-clés suivants :

Unable to save variable
reactor.ReactorError: Internal error - reactor pause disabled
Unhandled exception during ready callback
Internal error during ready callback: Unable to save variable

Nature de l'erreur : Unable to save variable n'est que le résultat de l'échec de l'écriture de la variable. Dans les cas récents de la communauté, si elle apparaît en même temps que reactor pause disabled et ready callback, il s'agit généralement d'une extension tierce appelant SAVE_VARIABLE pendant la phase de callback ready de Klipper, incompatible avec le nouveau mécanisme d'écriture asynchrone ; cela ne signifie pas que le périphérique de stockage est endommagé ou que le MCU est déconnecté.

Causes courantes :

  • Après la mise à jour de Klipper, une ancienne extension tierce écrit toujours des variables de manière synchrone dans le callback de démarrage.
  • L'extension ou le module personnalisé du fabricant n'a pas été mis à jour en même temps, la trace pointe vers son fichier klippy/extras/.
  • Si le journal ne contient pas reactor pause disabled, il peut également s'agir d'un chemin de fichier de variables incorrect, d'un répertoire en lecture seule, d'un espace disque insuffisant ou d'un problème de permissions.

Solutions :

  1. Lisez la trace Python complète à partir de la première Unable to save variable dans klippy.log, notez le chemin du module tiers apparaissant en premier et le texte exact de l'exception ; ne vous contentez pas de regarder la dernière ligne de shutdown.
  2. Si reactor pause disabled et le chemin d'une extension tierce apparaissent simultanément, mettez d'abord à jour cette extension vers une version compatible avec la version actuelle de Klipper, puis redémarrez Klipper ; si l'extension n'a pas de version compatible, contactez son mainteneur.
  3. Vous pouvez temporairement désactiver l'extension tierce pointée par la trace ou l'include associé, puis effectuer un nouveau test pour confirmer que Klipper d'origine peut démarrer normalement. Ne modifiez pas directement le code source principal de Klipper comme étape de dépannage courante.
  4. Si la trace indique Permission denied, Read-only file system ou No space left on device, exécutez les commandes suivantes pour vérifier l'espace disque et les permissions du fichier de variables, puis corrigez le chemin ou les permissions réels ; n'utilisez pas chmod 777 pour élargir les permissions de répertoires non concernés.
df -h
ls -l ~/printer_data/config/
  1. La rétrogradation de Klipper ne doit être utilisée que pour une vérification de compatibilité à court terme et ne doit pas être considérée comme une solution à long terme ; une fois le problème confirmé, restaurer la version prise en charge de Klipper et mettre à jour les extensions correspondantes.

Erreur interne sur commande​

Message d'erreur : Internal error on command:"XXX", Klipper passe à l'état d'arrêt (shutdown).

Causes courantes :

  • Une macro ou une commande G-code déclenche une exception Python interne à Klipper.
  • Le fichier de configuration contient une référence de macro erronée ou une erreur de syntaxe de modèle Jinja2.
  • La version de Klipper est incompatible avec le format du fichier de configuration.
  • Des caractères spéciaux dans le nom du fichier G-code provoquent une erreur d'encodage.
  • stepcompress, syncemitter ou flush_handler signalent une erreur entraînant l'interruption de l'exécution de la commande.

Solutions :

  1. Consulter la trace Python complète sous l'erreur interne dans klippy.log.
  2. Utiliser la trace pour identifier quel fichier de configuration ou quelle macro est en cause.
  3. Les causes courantes incluent une erreur de syntaxe de modèle Jinja2 dans [gcode_macro], un paramètre [respond] manquant, ou un chemin incorrect dans [virtual_sdcard].
  4. Si l'erreur est liée à SDCARD_PRINT_FILE et mentionne ascii codec can't decode, renommer le fichier G-code en utilisant uniquement des lettres, chiffres, tirets bas ou tirets courts.
  5. Si la trace contient stepcompress, syncemitter ou flush_handler, poursuivre le dépannage en suivant la section erreur interne stepcompress / syncemitter / flush_handler.

Référence de configuration pertinente : Introduction aux macros, Notes de modification de configuration.

Impossible d'ouvrir le fichier / SD occupé​

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

Causes courantes :

  • Le fichier G-code n'existe pas, son nom a été modifié ou le téléversement est incomplet.
  • [virtual_sdcard] path pointe vers un répertoire incorrect.
  • Permissions de fichiers anormales, l'utilisateur Klipper ne peut pas lire.
  • Des caractères spéciaux dans le nom du fichier provoquent un traitement anormal du chemin par certains logiciels frontaux ou systèmes.
  • Pendant une impression ou une lecture de fichier, une commande d'ouverture, de sélection, de réinitialisation ou d'écriture de la SD virtuelle est exécutée.
  • Le répertoire source de Klipper, le répertoire de configuration ou un autre répertoire non-G-code est configuré par erreur comme [virtual_sdcard] path.

Solutions :

  1. Téléverser à nouveau le fichier G-code via l'interface Web et vérifier que le nom du fichier correspond à la commande d'impression.
  2. Vérifier que [virtual_sdcard] path pointe vers le répertoire réel de stockage des G-code.
  3. Vérifier les permissions du répertoire : ls -la ~/printer_data/gcodes/.
  4. Renommer le fichier avec des lettres, chiffres, tirets bas ou tirets courts, puis tester à nouveau.
  5. En cas de SD busy, mettre d'abord en pause ou annuler l'impression en cours et vérifier qu'aucune autre macro ne manipule le fichier SD virtuel.
  6. Ne pas définir ~/klipper, ~/printer_data/config ni un répertoire système comme répertoire de stockage des G-code.

Référence de configuration pertinente : Notes de modification de configuration.

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

Messages 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 clé de diagnostic : Can not update MCU 'xxx' config as it is shutdown n'est généralement pas la cause racine initiale, mais une erreur secondaire survenant lorsque Klipper se reconnecte ou reconfigure le MCU alors qu'il est déjà dans un état d'arrêt/erreur. Ne pas se limiter à la dernière ligne du journal ; remonter pour trouver la première erreur réelle.

Solutions :

  1. Exécuter FIRMWARE_RESTART, ou si nécessaire couper complètement l'alimentation pendant 10 secondes puis rallumer.
  2. Rechercher dans klippy.log la première erreur antérieure : shutdown, Timer too close, Lost communication, Verify heater, erreur TMC ou de température, et corriger d'abord la cause racine de l'arrêt.
  3. Pour les machines à plusieurs MCU, vérifier un par un les identifiants USB ou UUID CAN de [mcu] et [mcu xxx].
  4. Si Klipper vient d'être mis à jour, recompiler et flasher le firmware de tous les MCU.
  5. Si [mcu host] est utilisé, vérifier que le service klipper-mcu démarre correctement, puis redémarrer Klipper.
  6. Si un système Klipper préinstallé ou personnalisé est utilisé, vérifier l'intégralité des journaux et la cohérence des versions entre Klipper et le firmware du MCU.

MCU 'xxx' arrêté : demande de commande​

Message d'erreur : MCU 'xxx' shutdown: Command request.

Causes courantes :

  • La version du firmware de la carte outil CAN ne correspond pas à la version de Klipper sur l'hôte ; l'hôte a envoyé une commande non prise en charge par ce firmware.
  • Après une mise à jour de Klipper ou du système, le firmware de la carte outil n'a pas été recompilé ni flashé.
  • Des fonctionnalités non compilées dans le firmware de ce MCU sont configurées (par exemple, configuration d'EDDY / ADXL sans avoir activé I2C).

Solutions :

  1. Vérifier Loaded MCU 'xxx' ... version et Git version dans klippy.log pour confirmer la cohérence des versions.
  2. Recompiler et flasher le firmware du MCU signalé ; la méthode de flashage dépend de la documentation du produit de la carte concernée.
  3. Pour les machines à plusieurs MCU, s'assurer que tous les firmwares proviennent de la même compilation.
  4. Après le flashage, exécuter FIRMWARE_RESTART et vérifier que l'erreur ne réapparaît plus.

Vérification générale des versions : Erreur de protocole MCU

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

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

Solutions :

  1. Confirmer si un arrêt d'urgence a été déclenché manuellement ; si c'est le cas, après avoir écarté les risques, exécuter FIRMWARE_RESTART.
  2. Rechercher M112, action_emergency_stop, emergency_stop dans les macros personnalisées.
  3. Vérifier si des plugins d'interface, de contrôle à distance ou des scripts d'automatisation ont déclenché l'interface d'arrêt d'urgence par erreur.

Performances insuffisantes de l'hôte provoquant des ralentissements d'impression​

Message d'erreur : Aucune erreur visible, mais des pauses intermittentes ou une extrusion irrégulière pendant l'impression.

Solutions :

  1. Réduire la vitesse d'impression et l'accélération.
  2. Fermer les services Web inutiles, les flux de caméra, etc. sur l'hôte.
  3. Réduire probe_count et mesh_pps dans [bed_mesh].
  4. Si le slicer génère des arcs G2 / G3, consulter Recommandations d'ajustement des arcs pour ajuster ou désactiver.
  5. Si les performances de l'hôte sont réellement insuffisantes, envisager de passer à un hôte plus puissant.

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

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

Causes courantes :

  • Alimentation insuffisante de l'hôte ; les variations de charge (USB, caméra, écran, ventilateurs) pendant l'impression provoquent une coupure.
  • Lecture/écriture anormale du disque système, de la carte TF ou de l'eMMC ; journaux interrompus soudainement ou fichiers endommagés.
  • Surchauffe du CPU de l'hôte, entraînant une réduction protectrice de fréquence, un blocage ou un redémarrage.
  • Alimentation inversée via USB ou chemin d'alimentation des périphériques anormal, affectant mutuellement la carte mère, l'écran ou l'hôte.
  • Services tiers, flux de caméra, plugins d'IA ou trop de connexions Web consommant des ressources.

Méthodes de diagnostic :

Opération de coupure d'alimentation

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 les câblages, éteignez complètement l'imprimante et débranchez l'alimentation. Ne démontez pas l'alimentation et ne modifiez pas le câblage secteur.

  1. Consulter 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érifier les spécifications de l'alimentation de l'hôte, éviter les câbles avec un courant insuffisant ou une chute de tension importante.
  3. Vérifier l'état de santé du disque système ; remplacer au besoin la carte TF, l'eMMC ou réinstaller le système.
  4. Vérifier le refroidissement de l'hôte, confirmer que le ventilateur fonctionne, que le dissipateur est bien en contact et que le boîtier est ventilé.
  5. Désactiver temporairement les flux de caméra, KlipperScreen, les plugins de contrôle à distance et autres services à forte charge, puis tester l'impression.
  6. En cas de suspicion d'alimentation inversée via USB, privilégier un câble USB standard ou une solution d'isolation d'alimentation ; ne modifiez pas les câbles vous-même.

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

Messages 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 après l'annulation de l'impression.
  • Incohérence entre le nom de SAVE_GCODE_STATE NAME= et RESTORE_GCODE_STATE NAME= dans les macros personnalisées de pause/reprise.
  • Les macros de pause/reprise par défaut de Mainsail / Fluidd sont définies en double ou en conflit avec des packs de macros tiers.
  • Après un arrêt d'urgence, FIRMWARE_RESTART ou une erreur Klipper, l'état de pause d'origine a été perdu. Solution :
  1. Vérifiez l'état actuel de l'impression et n'exécutez pas RESUME alors que l'impression n'est pas en pause.
  2. Vérifiez que [pause_resume] est activé et que les macros PAUSE / RESUME / CANCEL_PRINT ne sont pas définies en double.
  3. Vérifiez que les noms SAVE_GCODE_STATE et RESTORE_GCODE_STATE dans les macros sont exactement identiques.
  4. Après une erreur Klipper ou une mise en sécurité (estop), il n'est pas recommandé de reprendre l'impression. Éliminez 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 façon répétée. Klipper redémarre automatiquement en boucle et se ferme à chaque fois en quelques secondes. Le journal peut contenir Klipper restarting too fast ou des klippy.log très courts à chaque redémarrage.

Méthode de dépannage :

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

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

  2. Si la fin du journal contient une Traceback Python, cela indique un crash dû à une erreur d'analyse de configuration ou à une exception interne.

  3. Ne vous basez pas uniquement sur Klipper restarting too fast pour déterminer la cause racine ; ce message est généralement le résultat d'un échec de relance répété par systemd. Traitez en priorité 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. Recompilez et flashez le firmware MCU.

  5. Si le journal est très court et sans erreur évidente, essayez d'identifier 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.

Unhandled exception during run​

Message d'erreur : Unhandled exception during run, l'interface affiche Printer is shutdown, le journal contient une Traceback Python.

Causes courantes :

  • Il ne s'agit pas d'un défaut matériel indépendant, mais d'une erreur générique signalée lorsque la boucle principale de Klipper capture une exception non gérée. La cause réelle doit être recherchée dans l'erreur spécifique au-dessus de la Traceback.
  • Déclencheurs courants : échec de lecture UART TMC (Unable to read tmc uart 'stepper_x' register DRV_STATUS), interruption de la communication CAN, erreur d'exécution de macro, exception de module d'extension tiers.
  • Après une mise à jour de Klipper, d'anciennes configurations ou macros peuvent être incompatibles avec les nouvelles API.
  • Environnement Python de l'hôte corrompu ou dépendances manquantes.

Solution :

  1. Ouvrez le klippy.log complet, recherchez la Traceback au-dessus de Unhandled exception during run pour trouver la première erreur réelle (comme Unable to read tmc uart, CanError, TypeError, etc.).
  2. Si la vraie erreur est un échec de communication UART TMC, vérifiez le câblage et la configuration conformément au Dépannage d'erreur TMC.
  3. En cas d'anomalie de communication CAN, vérifiez l'état du bus conformément au Dépannage d'erreur CAN.
  4. Si la Traceback pointe vers une macro ou un module d'extension, vérifiez la compatibilité de ce module avec la version actuelle de Klipper. Mettez-le à jour ou désactivez-le temporairement si nécessaire.
  5. Si cette erreur apparaît après une mise à jour de Klipper, vérifiez dans Config_Changes.md s'il y a des exigences de migration de configuration.
  6. Ne jugez pas le problème uniquement sur la ligne Unhandled exception during run ; ce n'est que l'enveloppe, la cause réelle se trouve toujours dans la Traceback.

Missed scheduling of next hard pwm event​

Message d'erreur : MCU 'mcu' shutdown: Missed scheduling of next hard pwm event.

Causes courantes :

  • Même nature que Missed scheduling of next digital out event : l'hôte n'a pas envoyé l'événement PWM à la MCU dans les délais impartis.
  • Charge CPU élevée sur l'hôte (flux de caméra, KlipperScreen, nombreux plugins fonctionnant simultanément).
  • Lors de l'utilisation d'un module laser ou d'outils PWM haute fréquence, une valeur cycle_time trop petite crée des intervalles de planification extrêmement courts.
  • Latence du bus CAN trop élevée, provoquant un dépassement du délai de transmission de l'événement.

Solution :

  1. Vérifiez la charge CPU de l'hôte. Désactivez temporairement la caméra, KlipperScreen et d'autres services non essentiels, puis testez à nouveau.
  2. Si vous utilisez un laser ou un outil PWM, augmentez la valeur de cycle_time (par exemple de 0.00002 à 0.0001).
  3. Vérifiez l'état du bus CAN pour vous assurer que tx_error et bytes_retransmit n'augmentent pas de façon continue.
  4. Testez avec un câble USB de meilleure qualité ou réduisez le débit en bauds du CAN (de 1M à 500K).
  5. Pour les hôtes à faibles performances (anciens téléphones, cartes de développement bas de gamme), il est recommandé de réduire le nombre de services exécutés simultanément.

Erreur connexe : Missed scheduling of next digital out event

Can't reset time when stepper active​

Message d'erreur : MCU 'mcu' shutdown: Can't reset time when stepper active, souvent accompagné d'un redémarrage automatique de Klipper en cours d'impression ; après le redémarrage, l'erreur TMC stepper_x failed to init: Timeout on wait for 'tmcuart_response' response peut apparaître.

Causes courantes :

  • Il ne s'agit pas d'un défaut matériel indépendant, mais d'une tentative de réinitialisation de la référence temporelle du pas moteur sur l'hôte alors que le moteur pas à pas est encore en mouvement, ce que la MCU refuse et déclenche une protection d'arrêt.
  • Le déclencheur le plus courant est un redémarrage spontané du service Klipper en cours d'impression (côté hôte) : le journal affichera Starting Klippy... juste après une ligne de statistiques Stats datant de la seconde précédente.
  • Un client ou plugin connecté via Moonraker demande de manière répétée le redémarrage du service.
  • Alimentation insuffisante, surchauffe, ou épuisement de la mémoire de l'hôte, entraînant l'arrêt puis la relance du service klipper par le système.

Solution :

  1. Ouvrez le klippy.log complet, recherchez Starting Klippy... pour confirmer si Klipper a redémarré en cours d'impression et l'intervalle de temps avec la dernière ligne de statistiques d'impression.
  2. Exécutez systemctl status klipper.service et journalctl -efu klipper pour consulter l'historique et la raison du redémarrage du service.
  3. Vérifiez les clients et plugins connectés à Moonraker (flux de caméra, plugins tiers, scripts personnalisés) pour vous assurer qu'aucun appareil ne demande le redémarrage du service ou de la machine.
  4. Vérifiez l'alimentation, la dissipation thermique et l'occupation mémoire de l'hôte. Les anciens Raspberry Pi ou cartes de développement bas de gamme exécutant simultanément une caméra et KlipperScreen peuvent être tués par le système par manque de mémoire.
  5. L'Timeout on wait for 'tmcuart_response' qui apparaît après le redémarrage est une conséquence du redémarrage, et non la cause racine. Ne commencez pas par vérifier le câblage TMC à cause de cela.

Erreurs connexes : Redémarrages répétés de Klipper、Unhandled exception during run

Loading...