Qidi X Max 3 - Probleme de shutdown de Klipper

[V3DP]

Bonsoir

Sur mes deux X Max 3 libérées avec Klipper 0.13 dernières version (suivant tuto de @fran6p + écran TJC flashé avec FreeDi, j'ai des soucis récurrents de shutdown durant les impressions plutôt longues.

J'ai l'erreur MCU 'MKS_THR' shutdown: Timer too close

En gros, le MCU est débordé et perd la référence de temps, donc shutdown.

Ca avait commencé avec Klipper 0.12 et j'ai tout mis à jour il y a quelques semaines pour voir si ça n'était pas lié à ca.

J'ai aussi réduit au minimum les macros et surtout les delayed gcodes.

Comme ça le fait sur les deux machines, pour un même fichier, je pense à un souci de paramétrage du slicer. D'autant que les températures des différents éléments sont nickel.

Je me suis aperçu que baisser la vitesse d'impression et surtout celle de l'infill diminuait le risque de shutdown. Pour autant ça ne règle pas le problème.

J'utilise Orca 2.3, avec des paramètres proches de ceux de Qidi Studio. L'infill combination est par contre bridé pour éviter de dépasser une hauteur de couche de plus de 80% du diamètre de buse, et dans certains profils les vitesses ont été baissées pour ce qui est visible.

Hier encore, j'ai du baisser la MVS de 30 à 20 pour du PLA car j'avais un plantage sur une impression en 200 microns et infill à 400 microns, relativement simple (pas de courbes de partout, infill 20%). Les températures étaient assez basses pour les différents MCU car tout est ouvert en grand.

La résolution (dans l'onglet précision) est identique à celle de Qidi Studio : 0.012 mm.

Mais je me demande si le souci n'est pas ailleurs, par exemple les cables USB C qui relient la tête qui fatiguent après quelques milliers d'heures de fonctionnement. Mais il y a certainement d'autres possibilités de problèmes.

Merci par avance pour vos pistes de réflexion.

[souriceaux]

Bonsoir @V3DP,
Comme j'essaye de comprendre (avec mes neurones  ) , j'ai remarqué que le problème avait déjà été soumis ici:
https://klipper.discourse.group/t/mcu-mcu-shutdown/20370/16

Peut être une réponse pour solutionner cette anomalie

 

[fran6p]

La majorité des cas de pertes de connexions entrainant l'arrêt de Klipper sont dus à une liaison défectueuse (câble USB, prise de connexion sur la tête, interférence électriques). Donc pas simple à résoudre…

D'autant plus que dans le câble USB de nos modèles (XM3, XP3) passe du 24 V, il faut juste espérer que les deux lignes de data soient bien isolées des interférences… ce dont je ne suis pas certain . En plus, le moteur de l'extrudeur peut lui aussi induire des perturbations électromagnétiques.

[V3DP]

il y a 24 minutes, fran6p a dit :

La majorité des cas de pertes de connexions entrainant l'arrêt de Klipper sont dus à une liaison défectueuse (câble USB, prise de connexion sur la tête, interférence électriques). Donc pas simple à résoudre…

D'autant que ce n'est ni systématique, ni répétitif sur un même fichier. Ce qui est sur c'est que les deux machines avec le même fichier se comportent à peu près de la même manière.

Pour ce qui est de la connexion de la prise USB C au niveau de la tête, j'avais retiré le strap autour de la tête, qui empêchait le refroidissement du RP2040, mais remplacé par un morceau de caoutchouc coincé entre le haut de la prise et le petit support. Ainsi aucun jeu.

Je vais passer un peu de KF Contact dans un premier temps sur ces connexions.

J'ai vu des choses intéressantes sur le lien de @souriceaux sur Discord, notamment l'analyseur le log klippy, qui a l'air bien plus poussé que klippylyzer.

Je me demande aussi si le problème ne vient pas de timelapse. Je n'avais pas remarqué ces erreurs avant l'installation du plugin, mais comme je n'ai pas tourné beaucoup entre la libération de ma première X Max 3 et l'installation du plugin.... Reste à voir comment le désinstaller proprement car il ne me sert plus.

Je vais checker mon printer.cfg et regarder si je ne peux pas retirer encore quelques macros également.

 

[V3DP]

J'ai un petit peu avancé sur le problème.

Tout d'abord encore un peu de ménage dans les macros. Désinstallation de Timelapse avec tous ses composants.

Suite à mo petit tour sur Discord Klipper, j'ai vérifié les printer.cfg pour les différents steppers : 32 micro pas avec interpolation en X, Y, Z et 16 micro pas avec interpolation pour l'extrudeur. C'était déjà comme cela avant de llibérer mes X Max 3.

J'avais fait des essais lors des premiers problèmes en repassant tout en 16 micro pas, mais ça n'avait strictement rien changé.

La grosse trouvaille du jour c'est l'outil de Sineos pour analyser les logs klippy. Il y a quelques bugs si on navigue dans les pages, mais ça marche plutot  bien. https://sineos.github.io/index2.html

Il y a beaucoup d'informations, mais je n'ai pas tout trouvé encore : SRTT ?? RTO ?? RTTVAR ??

D'après les graphiques, ce n'est pas un problème de charge, ni de bande passante, ni de températures, ni d'utilisation mémoire.

Il y a un souci de stabilité de fréquences sur lee  MKS_THR juste avant le shutdown vers 22h. Quelques tout petits écarts lors de l'impression, mais très faibles.

 

Et un souci de transfert de données entre le mcu et le MKS_THR a ce même moment.

Il y a juste avant une légère augmentation de la charge, mais on est de l'ordre de 5% .....

J'ai analysé une log d'un job qui se passe bien et il n'y a pas du tout ce phénomène, ce qui semble logique.

Maintenant, la question est bien de savoir pourquoi la communication ne se fait pas et si le décalage de fréquence en est la cause ou la conséquence.

Demain je vais relancer le job qui a planté le 11 juin à 22h pour voir si le souci est lié à timelapse, car c'est grosso modo depuis que j'ai ce composant que j'ai les soucis.

[V3DP]

Ce weekend, j'ai vérifié le cable USB C extérieurement et nettoyé les contacts des prises USB au KF Contact sur chacune des machines.

Les deux imprimantes tournent avec du TPU avec une MVS de 13, mais une épaisseur de couche de 300 microns. Donc c'est pépère. J'espère que je ne vais pas avoir de plantage sur ces impressions qui font 17h chacune.

J'ai regardé également de plus près le printer.cfg pour voir ce qui pourrait potentiellement augmenter la charge du mcu MKS_THR, qui est certainement la moins puissante.

J'ai une section de définie, qui pourrait augmenter significativement la charge du mcu.

[gcode_arcs]

resolution: 0.25 # 1.0

Mais si je comprends bien, elle n'est utilisée que si le slicer utilise les commandes G2 / G3. Or mon instance d'Orca est configurée pour ne pas les utiliser.

Quelqu'un peut confirmer que c'est bien ça ?

Modifié (le) il y a 3 heures par V3DP