Aller au contenu principal

Erreurs 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 pendant le référencement. Courant lors du référencement de l'axe Z avec plusieurs MCU.

Causes courantes :

  • Charge élevée de l'hôte due à l'exécution simultanée de KlipperScreen, du flux de la caméra, etc.
  • Mouvement simultané de plusieurs moteurs lors du référencement, dont le courant élevé se couple aux lignes de communication CAN/USB, provoquant une interruption de la communication.
  • Réponse de communication instable de plusieurs MCU.
  • Problème de qualité des lignes de communication CAN/USB ou de leur cheminement.

Solutions :

Opération hors tension

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

  1. Éliminez 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 chauffants. 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 le blindage.

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

Message d'erreur : Les événements de pas d'avancement que Klipper prévoit d'envoyer à la MCU sont en retard par rapport à l'heure actuelle. La MCU ne peut pas exécuter ces commandes de mouvement à l'heure prévue, ce qui entraîne un arrêt de l'imprimante.

Loading...

Cause de l'erreur : Cela n'est généralement pas dû à un paramètre de configuration fixe, mais résulte d'une incapacité de la planification des mouvements de l'hôte, de la sortie des pas de la MCU ou de la planification de la communication à suivre le rythme. Une charge élevée de 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 communication USB/CAN, ou des macros/commandes G générant un grand nombre de commandes de mouvement en peu de temps peuvent déclencher ce problème.

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

Scénario de stagnation après reprise d'impression : L'erreur peut également apparaître après des commandes PAUSE / RESUME, une reprise après rupture de filament ou une reprise après coupure de courant. Le journal typique montre que buffer_time dans la ligne Stats chute d'environ 1s à environ 0.2s après la reprise, sd_pos n'augmente quasiment plus (progression d'impression stagnante), mais sysload n'est pas élevé et aucune MCU n'est déconnectée. Cela indique que les commandes de mouvement n'ont pas pu remplir le tampon de pas après la reprise, l'imprimante "a commencé à imprimer mais a à peine bougé" avant de s'arrêter. Lors du dépannage, concentrez-vous sur la vérification des macros de reprise/reprise (resume_gcode, start_gcode) pour voir si elles envoient des mouvements ou des rétractions anormalement importants au moment de la reprise, et s'il y avait déjà des retransmissions de communication (bytes_retransmit en augmentation) avant la reprise.

Solutions :

  1. Consultez d'abord les lignes Stats avant l'erreur dans klippy.log pour confirmer s'il y a simultanément une utilisation élevée du CPU, bytes_retransmit, bytes_invalid, Timer too close, une déconnexion de la MCU ou une anomalie de file d'attente.
  2. Désactivez temporairement le flux de la caméra, KlipperScreen, les plugins de contrôle à distance et autres services très gourmands pour réduire la charge de 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 pendant le nivellement du lit multipoint, réduisez probe_count dans [bed_mesh], par exemple en le passant à 7,7 ou 9,9 pour tester.
  5. Si mesh_pps est configuré trop haut, réduisez-le ou supprimez cette configuration, par exemple en utilisant 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, le câblage, l'alimentation électrique et le débit CAN du firmware.
  7. Vérifiez les macros ou les commandes G en cours d'exécution avant le déclenchement de l'erreur, en évitant 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.

Références de configuration connexes : Introduction aux macros, Directives de débogage courantes.

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

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

Loading...

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

Scénarios courants récents :

  • Exécution de M600, PAUSE, RESUME, ou attente après une macro de détection de rupture de filament ou de changement de filament, suivie du déclenchement de Timer too close.
  • Lorsque EDDY / TAP / la carte d'outils CAN participe au référencement Z, Z_TILT_ADJUST, QUAD_GANTRY_LEVEL ou au nivellement du lit, le journal montre simultanément des retransmissions CAN, des lectures I2C anormales ou des pics de charge de l'hôte.
  • Avec plusieurs têtes d'outils, plusieurs nœuds CAN ou un hôte de faible performance exécutant simultanément la caméra, KlipperScreen, des plugins de contrôle à distance, la marge de planification est insuffisante.

Solutions :

  1. Réduisez le micro-pas du moteur pas à pas pour diminuer la pression de traitement des impulsions de la MCU.
  2. Réduisez la vitesse d'impression et l'accélération pour observer 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 les lignes de communication entre la MCU et l'hôte sont proches des câbles moteur, des câbles chauffants, des câbles du lit chauffant ou des câbles d'alimentation. Si nécessaire, refaites le cheminement ou remplacez-les par des câbles de communication blindés.
  5. Lors de la vérification de la mise à la terre de la machine, confirmez uniquement l'état des points de mise à la terre et des prises fournis par le fabricant. Ne démontez pas vous-même 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, référez-vous à Problème de délai d'attente lors du référencement.
  7. Si le problème 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. Si le problème survient avec EDDY TAP, l'inclinaison Z ou le nivellement du portique, référez-vous d'abord à Méthode de débogage du mode EDDY TAP.
  9. Si le problème persiste, envisagez de reflasher le système de l'hôte ou le firmware.

Références de configuration connexes : Directives de débogage courantes, Guide de référencement et d'étalonnage de direction.

Arrêt 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 que l'hôte Klipper a activé une sortie numérique (chauffage, ventilateur, etc.), la MCU doit recevoir la planification et la confirmation suivantes à temps. Si la charge de l'hôte est trop élevée, si la planification système est retardée, si la communication USB/CAN est instable, ou si la file d'attente du bus CAN est anormale, la MCU ne reçoit pas l'événement de sortie numérique suivant à temps, ce qui provoque 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é. Commencez par dépanner la charge de l'hôte et la qualité de la communication.

Solutions :

  1. Consultez d'abord les lignes Stats précédant cette erreur dans klippy.log pour confirmer s'il y a simultanément bytes_retransmit, bytes_invalid, Timer too close ou des enregistrements de déconnexion de la MCU.
  2. Réduisez la charge de l'hôte en désactivant temporairement le flux de la caméra, KlipperScreen, les plugins de contrôle à distance ou autres services très gourmands.
  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, le câblage, l'alimentation électrique 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 le problème ne se produit que lors du chauffage, vérifiez simultanément la charge du lit chauffant, de la buse, du ventilateur et de l'alimentation. Ne démontez pas vous-même l'alimentation et ne vérifiez pas le câblage haute tension secteur du lit chauffant.
  6. Si le problème se produit sur une carte d'outils CAN, continuez avec Dépannage des erreurs CAN.

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

Rescheduled timer in the past​

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, provoquant un retard d'exécution des tâches programmé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, par exemple en fermant les interfaces Web inutiles, le flux de la 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 CPU anormale. Configuration de référence : Commandes de débogage courantes.

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

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

Cause de l'erreur : La file d'attente des mouvements du MCU est saturée, l'hôte n'a pas transmis à temps la planification des mouvements et l'état synchronisé au MCU. Cela se produit souvent en cas de performances insuffisantes de l'hôte, d'un grand nombre de petits mouvements en peu de temps, d'une incohérence de version entre l'hôte Klipper et le firmware du MCU, ou d'une logique bloquante ajoutée par le fabricant dans chaque commande de mouvement, comme la synchronisation d'écriture sur disque ou la reprise après coupure de courant.

Points de diagnostic courants :

  • Dans klippy.log, un écart important entre Git version et Loaded MCU 'xxx' ... version indique une différence de version de base.
  • Présence de termes comme dirty, de fichiers klippy/extras tiers, d'une reprise après coupure de courant personnalisée par le fabricant ou d'un Klipper non officiel dans les logs.
  • Un même fichier G-code échoue à un endroit similaire, et le modèle contient de nombreux segments courts, supports denses, Z-hop en spirale ou chemins complexes.
  • L'hôte de faible puissance exécute simultanément une caméra, un écran, un contrôle à distance ou d'autres services gourmands.

Solutions :

  1. Consultez l'intégralité du klippy.log pour vérifier s'il existe des erreurs antérieures comme Timer too close, une déconnexion CAN, bytes_invalid ou des erreurs de température/TMC.
  2. Après avoir mis à jour 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 les cartes d'outils.
  3. Désactivez temporairement le flux de la caméra, KlipperScreen, les plugins de contrôle à distance et autres services gourmands, puis testez à nouveau.
  4. Réduisez la vitesse d'impression, l'accélération, la micro-pas des steppers, ou dans le slicer, diminuez la précision des courbes, la complexité des supports et la densité des segments courts.
  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 désactivez la fonction correspondante. Ne modifiez pas directement le code source de Klipper pour les clients ordinaires.
  6. Si l'erreur ne se produit qu'avec un fichier G-code spécifique, re-tranchez-le et vérifiez si le slicer génère des chemins anormalement denses.

Configuration de référence : Commandes de débogage courantes, Conseils sur l'ajustement des arcs.

Erreur interne de stepcompress / syncemitter / flush_handler​

Messages 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 problème apparaît souvent en conjonction avec un balayage à grande vitesse, des sondes de type scanner / EDDY / Cartographer, input_shaper, des chemins de mouvement complexes ou des modifications tierces de Klipper. Il n'est pas nécessairement dû uniquement au slicer et il ne faut pas se fier uniquement à un nouveau tranchage pour en déterminer la cause racine.

Solutions :

  1. Conservez l'intégralité du klippy.log, en vous concentrant sur le Traceback Python, la commande en cours d'exécution et les lignes Stats juste avant et après l'erreur.
  2. Si l'erreur se produit lors de BED_MESH_CALIBRATE, QUAD_GANTRY_LEVEL ou d'un balayage de scanner, réduisez d'abord la vitesse de balayage, le nombre de points, la densité d'interpolation et les paramètres de scan du plugin.
  3. Désactivez temporairement les scanners tiers, la régulation automatique de vitesse, l'auto-nivellement amélioré, les packs de macros ou les modifications du fabricant, puis testez avec Klipper d'origine.
  4. Après avoir mis à jour Klipper, reflashez tous les firmwares des MCU et assurez-vous que les versions des périphériques correspondent à celle de l'hôte Klipper.
  5. Si le même modèle déclenche l'erreur à plusieurs reprises, re-tranchez-le en réduisant la densité des segments courts. Si l'erreur réapparaît de manière aléatoire après un nouveau tranchage, continuez à enquêter sur 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 et replacez les axes, ne reprenez pas la tâche en cours.

Configuration de référence : Erreurs de mouvement, de fin de course et de nivellement, FAQ sur les sondes EDDY.

Erreur interne sur commande​

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

Causes courantes :

  • Une macro ou une commande G-code déclenche une exception Python interne à Klipper.
  • Une référence de macro erronée ou une erreur de syntaxe 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 d'encodage.
  • Une erreur de stepcompress, syncemitter ou flush_handler interrompt l'exécution de la commande.

Solutions :

  1. Consultez le Traceback Python complet sous l'erreur interne dans klippy.log.
  2. En fonction du Traceback, identifiez quel fichier de configuration ou quelle macro pose problème.
  3. Les causes courantes incluent une erreur de syntaxe 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 mentionne ascii codec can't decode, renommez le fichier G-code pour n'utiliser que des lettres, chiffres, underscores ou tirets.
  5. Si le Traceback contient stepcompress, syncemitter ou flush_handler, continuez à enquêter selon la section Erreur interne de stepcompress / syncemitter / flush_handler.

Configuration de référence : Introduction aux macros, Instructions de modification de configuration.

Impossible d'ouvrir le fichier / SD occupé​

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

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.
  • Problème de permissions de fichier empêchant l'utilisateur Klipper de le lire.
  • Le nom du fichier contient des caractères spéciaux, provoquant des problèmes de traitement du chemin par l'interface ou le système.
  • Une commande d'ouverture, de sélection, de réinitialisation ou d'écriture de la carte SD virtuelle est exécutée alors qu'une impression ou une lecture de fichier est en cours.
  • Le répertoire source de Klipper, le répertoire de configuration ou un autre répertoire non-G-code a été défini par erreur comme [virtual_sdcard] path.

Solutions :

  1. Retéléchargez le fichier G-code depuis l'interface web et assurez-vous que son nom correspond à celui de la commande d'impression.
  2. Vérifiez si [virtual_sdcard] path pointe bien vers le répertoire contenant les fichiers G-code.
  3. Vérifiez les permissions du répertoire : ls -la ~/printer_data/gcodes/.
  4. Renommez le fichier en utilisant uniquement des lettres, chiffres, underscores ou tirets, puis testez à nouveau.
  5. Si le message est SD busy, mettez en pause ou annulez l'impression en cours, et assurez-vous qu'aucune autre macro ne manipule le fichier SD virtuel.
  6. Ne définissez pas ~/klipper, ~/printer_data/config ou un répertoire système comme répertoire de stockage des G-code.

Configuration de référence : Instructions de modification de configuration.

Le CRC du MCU ne correspond pas à la config / Impossible de mettre à jour la config 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 crucial du diagnostic : Can not update MCU 'xxx' config as it is shutdown n'est généralement pas la cause racine initiale, mais une erreur ultérieure qui apparaît lorsque Klipper tente de se reconnecter ou de reconfigurer un MCU déjà en état d'arrêt/erreur. Lors du dépannage, ne regardez pas seulement la dernière ligne du journal, mais remontez pour trouver la première vraie erreur.

Solutions :

  1. Exécutez FIRMWARE_RESTART, si nécessaire, coupez l'alimentation de l'imprimante pendant 10 secondes, puis remettez-la sous tension.
  2. Consultez klippy.log pour trouver la première occurrence de shutdown, Timer too close, Lost communication, Verify heater, TMC ou erreur de température, et corrigez d'abord la cause racine de l'arrêt.
  3. Pour les machines multi-MCU, vérifiez individuellement l'ID USB ou l'UUID CAN de [mcu] et [mcu xxx].
  4. Si vous venez de mettre à jour Klipper, recompilez et flashez tous les firmwares des MCU.
  5. Si vous utilisez [mcu host], vérifiez que le service klipper-mcu a bien démarré, 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 de Klipper et du firmware des MCU proviennent de la même source.

Arrêt du MCU 'xxx' : Demande de commande​

Message d'erreur : MCU 'xxx' shutdown: Command request. Causes fréquentes :

  • La version du firmware de la carte outil CAN n'est pas compatible avec la version de Klipper sur l'ordinateur hôte, ce dernier envoyant des commandes non supportées par le firmware.
  • Après une mise à jour de Klipper ou du système, le firmware de la carte outil n'a pas été recompilé et flashé.
  • Configuration d'une fonctionnalité non prise en charge par le firmware du MCU (par exemple, configuration d'EDDY / ADXL sans avoir activé l'I2C).

Solutions :

  1. Vérifiez dans klippy.log les lignes Loaded MCU 'xxx' ... version et Git version pour confirmer la correspondance des versions.
  2. Recompilez et flashez le firmware du MCU en erreur, en suivant la méthode de flash spécifiée dans la documentation du produit de la carte outil correspondante.
  3. Pour les machines multi-MCU, assurez-vous que tous les firmwares MCU proviennent de la même compilation.
  4. Après le flash, exécutez FIRMWARE_RESTART et vérifiez que l'erreur ne se reproduit plus.

Dépannage de version générique : Erreur de protocole MCU

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 l'arrêt d'urgence a été déclenché manuellement ; si c'est le cas, après avoir écarté les risques, 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 d'automatisation déclenchent accidentellement l'interface d'arrêt d'urgence.

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

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

Solutions :

  1. Réduisez la vitesse d'impression et l'accélération.
  2. Désactivez les services Web, flux de caméra, etc., inutiles sur l'ordinateur hôte.
  3. Réduisez probe_count et mesh_pps dans [bed_mesh].
  4. Si le slicer produit des arcs G2 / G3, référez-vous aux Recommandations pour l'ajustement des arcs pour les ajuster ou les désactiver.
  5. Si les performances de l'ordinateur hôte sont vraiment insuffisantes, envisagez de le remplacer par un modèle plus puissant.

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

Message d'erreur : Perte soudaine de connexion avec Klipper / Moonraker pendant l'impression, interruption brutale du fichier klippy.log sans cause racine claire d'arrêt ; après reconnexion de Mainsail / Fluidd, l'ordinateur hôte ou Klipper a redémarré.

Causes fréquentes :

  • Alimentation insuffisante de l'ordinateur hôte, chute de tension due à la variation de charge de l'USB, de la caméra, de l'écran ou des ventilateurs pendant l'impression.
  • Lecture/écriture anormale du disque système, de la carte TF ou de l'eMMC, interruption soudaine du journal ou corruption de fichier.
  • Surchauffe du CPU de l'ordinateur hôte, entraînant une réduction de fréquence protectrice, un gel ou un redémarrage.
  • Alimentation inverse via USB ou chemin d'alimentation périphérique anormal, affectant mutuellement la carte mère, l'écran ou l'ordinateur hôte.
  • Services tiers, flux de caméra, plugins IA ou trop de connexions Web consommant des ressources.

Méthode de diagnostic :

Opération avec coupure de courant

Avant de vérifier les câbles d'alimentation, USB, écran, ventilateur ou de réorganiser le câblage de l'ordinateur hôte, é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. 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'ordinateur hôte.
  2. Vérifiez les spécifications d'alimentation de l'ordinateur hôte, évitez les 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 ou réinstallez le système si nécessaire.
  4. Vérifiez le refroidissement de l'ordinateur 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 le flux de la caméra, KlipperScreen, les plugins de contrôle à distance et autres services à forte charge avant de tester l'impression.
  6. En cas de suspicion d'alimentation inverse USB, privilégiez le remplacement par un câble USB de qualité ou l'utilisation d'une solution de connexion avec isolation galvanique. Les utilisateurs ordinaires ne doivent pas modifier le câblage eux-mêmes.

Indications sur la pause, la reprise et la sauvegarde d'état​

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

Causes fréquentes :

  • Exécution répétée de PAUSE, ou exécution de RESUME après l'annulation de l'impression.
  • Incohérence de nom dans les macros personnalisées de pause/reprise entre SAVE_GCODE_STATE NAME= et RESTORE_GCODE_STATE NAME=.
  • Conflit ou redéfinition entre les macros de pause/reprise par défaut de Mainsail/Fluidd et des macros tierces.
  • Perte de l'état de pause 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 l'impression n'est pas en pause.
  2. Vérifiez si [pause_resume] est activé et si les macros PAUSE / RESUME / CANCEL_PRINT ne sont pas définies plusieurs fois.
  3. Vérifiez que les noms dans SAVE_GCODE_STATE et RESTORE_GCODE_STATE dans vos macros sont exactement identiques.
  4. Après une erreur Klipper ou un arrêt d'urgence, il n'est pas recommandé de reprendre l'impression ; écartez les risques et recommencez.

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

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 des fichiers klippy.log très courts à chaque redémarrage.

Méthode de diagnostic :

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

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

  2. Si la fin du journal est une trace Python (Traceback), cela indique un plantage dû à l'analyse de la configuration ou à une exception interne.

  3. Ne vous fiez pas uniquement à Klipper restarting too fast pour identifier la cause racine ; c'est souvent le résultat de l'échec répété du démarrage par systemd. Traitez d'abord la première véritable erreur dans klippy.log.

  4. Si la fin du journal montre MCU Protocol error, Unknown command, etc., cela indique une incompatibilité de version du firmware, nécessitant une recompilation et un flash du firmware MCU.

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

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

Exception non gérée pendant l'exécution​

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

Causes fréquentes :

  • Ce n'est pas un défaut matériel indépendant, mais une erreur générique capturée par la boucle principale de Klipper après une exception non gérée. La cause réelle se trouve dans l'erreur spécifique au-dessus du Traceback.
  • Sources déclencheuses courantes : Échec de lecture UART TMC (Unable to read tmc uart 'stepper_x' register DRV_STATUS), interruption de communication CAN, erreur d'exécution de macro template, exception de module d'extension tiers.
  • Incompatibilité entre les anciennes configurations/macros et la nouvelle API après une mise à jour de Klipper.
  • Environnement Python corrompu ou dépendances manquantes sur l'ordinateur hôte.

Solutions :

  1. Ouvrez le fichier klippy.log complet, recherchez le Traceback au-dessus de Unhandled exception during run et trouvez la première véritable erreur (ex : Unable to read tmc uart, CanError, TypeError).
  2. Si l'erreur réelle est un échec de communication TMC UART, consultez Dépannage d'erreur TMC pour vérifier le câblage et la configuration.
  3. S'il s'agit d'une anomalie de communication CAN, consultez Dépannage d'erreur CAN pour vérifier l'état du bus.
  4. Si le 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 survient après une mise à jour de Klipper, consultez Config_Changes.md pour voir 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 qu'une enveloppe, la vraie cause est toujours dans le Traceback.

Planification manquée du prochain événement PWM hard​

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

Causes fréquentes :

  • Similaire à Missed scheduling of next digital out event, l'ordinateur hôte n'a pas pu envoyer l'événement PWM au MCU dans le délai imparti.
  • Charge CPU de l'ordinateur hôte trop élevée (flux de caméra, KlipperScreen, nombreux plugins fonctionnant simultanément).
  • Utilisation d'un module laser ou d'un outil PWM haute fréquence avec un cycle_time trop court rendant l'intervalle de planification extrêmement réduit.
  • Latence élevée du bus CAN, l'événement expire pendant la transmission.

Solutions :

  1. Vérifiez la charge CPU de l'ordinateur hôte, désactivez temporairement la caméra, KlipperScreen et autres services non essentiels, puis testez à nouveau.
  2. Si vous utilisez un laser ou un outil PWM, augmentez cycle_time (par exemple, passez de 0.00002 à 0.0001).
  3. Vérifiez l'état du bus CAN, assurez-vous que tx_error et bytes_retransmit n'augmentent pas de manière continue.
  4. Remplacez le câble USB par un modèle de qualité ou réduisez le débit en bauds du CAN (passez de 1M à 500K) pour tester.
  5. Pour les ordinateurs hôtes à faibles performances (vieux téléphones, cartes de développement bas de gamme), réduisez le nombre de services exécutés simultanément.

Erreur connexe : Planification manquée du prochain événement digital out

Impossible de réinitialiser le temps lorsque le moteur pas à pas est actif​

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, le message 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 l'ordinateur hôte de réinitialiser la référence temporelle du moteur pas à pas alors qu'il est encore en mouvement, ce que le MCU refuse en entrant en protection d'arrêt.
  • La source de déclenchement la plus fréquente est un redémarrage spontané du service Klipper en cours d'impression (côté ordinateur hôte) : dans le journal, on voit 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.
  • Une alimentation insuffisante, une surchauffe ou un épuisement de la mémoire de l'ordinateur hôte entraîne l'arrêt puis le redémarrage du service Klipper par le système.

Solutions :

  1. Ouvrez le fichier complet klippy.log, recherchez Starting Klippy... et confirmez si Klipper a redémarré en cours d'impression, ainsi que l'intervalle de temps depuis la dernière ligne de statistiques d'impression.
  2. Exécutez systemctl status klipper.service et journalctl -efu klipper pour consulter les enregistrements et les causes du redémarrage du service.
  3. Vérifiez les clients et plugins connectés à Moonraker (flux de caméra, plugins tiers, scripts personnalisés) et assurez-vous qu'aucun appareil ne demande un redémarrage du service ou de la machine.
  4. Vérifiez l'alimentation, la dissipation thermique et l'occupation mémoire de l'ordinateur hôte. Les anciens Raspberry Pi ou les cartes de développement peu performantes, surtout lorsqu'ils exécutent simultanément une caméra et KlipperScreen, peuvent être tués par le système en raison d'un manque de mémoire.
  5. Le message Timeout on wait for 'tmcuart_response' apparaissant après le redémarrage est une conséquence de celui-ci, non la cause racine. Ne commencez donc pas par vérifier le câblage TMC.

Erreurs associées : Redémarrage répété de Klipper, Unhandled exception during run

Loading...