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) Juin 15 par V3DP

[V3DP]

Suite des problèmes. J'ai une des deux machines qui m'a fait un shutdown après 7 heures d'impression

L'analyse de la log klippy avec l'outil de Sineos montre qu'il n'y a pas de problèmes de températures ni de fréquences, ni de communication entre le mcu et la tête.

Donc c'est certainement un problème du cable USB-C. Hier soir j'avais nettoyé au KF contact les deux prises de ce cable et les prises des cartes.

Je vais changer le cable ce matin, j'en ai un en stock. On verra ce que ça donne.

[V3DP]

Comme prévu, j'ai changé le cable USB C de la machine qui a fait le shutdown la nuit dernière. Opération pas trop compliquée sauf pour remettre la chaine coté chassis. pas très pratique d'accès.

Le cable usb avait été un peu martyrisé au niveau de la tête d'impression et au niveau de l'accroche de la chaine coté arrière.

Le passage de cable au niveau du couvercle arrière de la tête d'impression est un peu juste et vient contraindre le cable.

Et à l'arrière de la chaine, il y avait un colson bien serré pour tenir le cable dans la chaine. Ci joint la photo avec le nouveau colson, que je n'ai pas serré, juste en appui.

J'ai passé un petit coup de fraise sur le couvercle pour augmenter le jeu et ne plus contraindre le cable.

L'autopsie du cable montre qu'il est bien blindé a l'extérieur, mais que les conducteurs ne sont pas blindés entre eux comme les paires des cables ethernet SFP.

En ouvrant le cable coté du colson, on s'aperçoit que le conducteur rouge a été abimé avec une petite cassure.

En dégainant, le cable s'est rompu à cet endroit

J'ai lancé un job de 19h sur cette imprimante, on verra si tout se passe bien. Pour l'instant on est à presque 25% d'imprimé.

J'ai deux cables en commande chez Qidi pour remplacer mon stock et changer celui sur la deuxième machine.

[V3DP]

Bon résultat des courses ce matin, les deux machines ont fait leur shutdown. Pas au même moment dans le fichier.

Celle avec le cable USB C changé a tenu 12h.

Donc revue de tous les paramètres du printer.cfg (micro pas, gcode arcs)

[V3DP]

Ce soir, après 7 heures d'impression la machine avec le cable neuf a encore fait un shutdown. Mais plus sur la tête mais sur le MCU. 

J'avais remis 16 micro pas interpolés partout, baissé le courant de l'extrudeur, remis le gcode arcs à 1.

Les graphiques de la log klippy ne montrent pas vraiment de soucis.

Je vais nettoyer tous les contacts de la carte de la tête d'impression demain matin pour voir.

Pour l'instant la deuxième machine avec son cable usb c d'origine tourne depuis 7h également. On va voir si ça tient ou pas. Pour l'instant le job est à 50%.

[V3DP]

Bon, quelques nouvelles de mon problème de shutdown sur mes deux X Max 3.

J'ai utilisé du KF Contact sur tous les connecteurs de la tête d'impression. Et ça repart !

Je viens de faire un job de 21 h sur chacune des machines avec zéro problème. Les logs ont l'air propres coté communication entre les différentes MCU.

Je fais encore quelques impressions pour valider et ensuite je remets les micro pas sur X, Y à 32. Le bruit à 16 micropas est énervant .... Je ne sais pas si je remonte l'intensité les extrudeurs pour le peu de gain (on passe de 0.714 à 0,72 A).

Sinon j'ai regardé du coté des cables USB C, avec la norme PD, on peut faire passer dans certains cables 5 A, sous 24V ca nous fait 100W. Donc assez pour tout alimenter au niveau tête d'impression sans forcer.

Par contre des cables de cette catégorie avec des prises à 90° de chaque coté, il n'y en a pas des masses. Et je ne sais pas comment il est blindé.

[fran6p]

il y a 2 minutes, V3DP a dit :

J'ai utilisé du KF Contact

Tout électronicien se doit d'en avoir en stock .

il y a 3 minutes, V3DP a dit :

Par contre des cables de cette catégorie avec des prises à 90° de chaque coté, il n'y en a pas des masses.

Pas trouvé non plus. Les seuls que j'aie, dont l'embout est pivotable, ne fournissent que du courant, pas de data (câbles de charge). Idem pour les rares que j'ai trouvés coudés à 90 °, ce sont des câbles de charge.

Les modèles Q1 pro / Plus 4, utilisent des câbles USB, mais sans prise USB-C pour l'arrivée sur la tête.

 

[V3DP]

il y a 15 minutes, fran6p a dit :

Tout électronicien se doit d'en avoir en stock .

C'est le WD40 de l'électronicien . L'alcool isopropylique à 99,99 % marche presque aussi bien, c'est juste la tenue dans le temps.

J'avais trouvé ce cable là qui fait aussi les données https://www.amazon.fr/UGREEN-Degrés-Compatible-Macbook-Samsung/dp/B083PP7PSS?ref_=ast_sto_dp&th=1

il y a 23 minutes, fran6p a dit :

es modèles Q1 pro / Plus 4, utilisent des câbles USB, mais sans prise USB-C pour l'arrivée sur la tête.

J'ai été voir. C'est plus facile pour le remplacer par un cable blindé par paires de qualité qui résiste aux flexions répétées.

[vap38]

Bonjour @V3DP 
sur une des photos de la prise USB qui est coudée à 90° qui est pluggée sur l'extrudeur si je comprends le problème de la connectique ? 
Dans ce cas seule la souplesse du câble  USB compense les déplacements de l'extrudeur pour les axes XY  .
Donc c'est un facteur de pannes consécutif au vieillissement du câble. 
Mécaniquement aucun système de pistes axiales tangentielles en rotation pour la conduction des données (comme sur des robots)
A+
 

Modifié (le) Juin 19 par vap38

[V3DP]

@vap38 Oui comme pour de nombreuses machines, c'est le cable qui encaisse la flexion.

Dans le cas des Qidi séries 3, la prise USB est pluggée sur la carte fille qui est dans la tête d'impression et tous les périphériques de la tête sont connectés sur cette carte avec des connecteurs XH sauf le thermistor qui a une connectique différente mais c'est un standard.

Toutefois la prise usb c coudée coté tête est maintenue par une patte de fixation vissée dans la tête et si on met un petit bout de caoutchouc il n'y a aucun jeu. Donc les contacts sont plutôt bons, hormis si il y a des graisses qui pénètrent.

Dans mon cas et sur les 2 machines, le souci était dans un des connecteurs XH. Je pense celui de l'extrudeur car les ventilateurs n'ont pas de retour, ni la cartouche chauffante. Et un faux contact sur le thermistor te fait une belle erreur qui est bien distincte avec un shutdown pour des raisons de sécurité.

[vap38]

 @V3DP @fran6p Voici les quelques principes de connecteurs axiaux rotatifs sur robots et appareils industriels

[fran6p]

@vap38

L'arrivée du câble sur la tête est bien fixée (en théorie), mais ce câble passe dans la chaine de guidage qui produit toujours les mêmes flexions. 

 

[V3DP]

BAD NEWS.....

J'ai encore eu un shutdown du MCU, plus de la tête. C'est sur la machine qui a un cable usb c neuf, la carte fille nettoyée et le printer.cfg de remis aux valeurs Qidi pour les moteurs. Elle avait bien tourné juste avant pour 21h d'impression.

La seule chose qui a changé c'est le fichier à imprimer.

Voici la log Klippy, mais je n'ai rien trouvé dans l'analyseur de Sineos. Peut-être que quelqu'un plus calé que moi aura des idées. Le shutdown est peu après 0h

klippy.log.zip

Je vais regarder la piste du fichier d'impression généré par Orca slicer 2.3.

J'ai comparé les paramètres de Qidi Studio avec ceux que j'ai mis dans Orca.

Des différences sur les paramètres liés au filament et aux vitesses, mais surtout une grosse différence : Qidi Studio utilise le moteur classique pour les périmètres alors que j'utilise le moteur Arachnee.

Arachnee introduit des variations de débit fréquentes pour adapter la largeur de trait, donc potentiellement charge sur les MCU.

J'ai aussi, vu que le ventilateur de pièce est à 100%, supprimé le forçage pour les overhangs et bridges.

Je vais relancer le job de cette nuit....

[V3DP]

A nouveau shutdown cette nuit, même en ayant modifié le moteur de slicing et ajusté toutes les valeurs qui pourraient augmenter la charge CPU aux valeurs de Qidi Studio

C'est à nouveau le MCU (STM32) et non pas la tête. Il semble bien refroidi d'après les logs.

C'est maintenant devenu très galère car les commandes clients ne sortent pas.

@fran6pJe me posais une question liée à la libération de la Qidi : sous la version officielle Qidi, il n'y a pas de MCU Host, on l'a crée avec la procédure de libération. Ca ne pourrait pas surcharger le STM32 ?

Est-ce que ce MCU Host est bien nécessaire ? Ou plutôt il sert à quoi dans la configuration ?

Modifié (le) samedi à 11:15 par V3DP

[fran6p]

Il y a 1 heure, V3DP a dit :

Ca ne pourrait pas surcharger le STM32 ?

Cela m'étonnerait, mais tu peux le désactiver en arrêtant le service klipper-mcu.service  (sudo systemctl stop klipper-mcu pour l'arrêter et sudo systemctl disable klipper-mcu pour qu'il ne démarre plus automatiquement au lancement du système).

Comme ça fait déjà un certain temps que tu utilises tes XMax3, un remplacement de la pâte (colle) thermique sous le radiateur vert et sur le Rockchip ne pourrait pas faire de mal… et pourquoi pas ajouter un radiateur sur le STM32.

Autre possibilité, une des alimentations (450W) au-dessous de la XM3 commence à flancher, ce qui pourrait créer des perturbations électriques que le Rockchip et/ou le STM n'apprécie pas.

Pour l'utilité du MCU host (en plus de remonter la température du Rockchip dans Fluidd/Mainsail) => https://www.klipper3d.org/fr/RPi_microcontroller.html#pourquoi-utiliser-un-rpi-comme-microcontroleur-secondaire

 

Modifié (le) samedi à 12:48 par fran6p

[V3DP]

il y a 12 minutes, fran6p a dit :

Comme ça fait déjà un certain temps que tu utilises tes XMax3, un remplacement de la pâte (colle) thermique sous le radiateur vert et sur le Rockchip ne pourrait pas faire de mal… et pourquoi pas ajouter un radiateur sur le STM32.

La sonde de température étant dans la puce, il y aurait des montées en température de visibles sur la log. Or c'est bien régulé à 45 °C. J'ai pensé aussi aux ventilateurs, mais j'aurais des traces sur les logs.

il y a 14 minutes, fran6p a dit :

Autre possibilité, une des alimentations (450W) au-dessous de la XM3 commence à flancher, ce qui pourrait créer des perturbations électriques que le Rockchip et/ou le STM n'apprécie pas.

Cest une piste que je vais regarder en dernier recours.

J'avais pensé aussi à mon onduleur qui alimente les 2 machines, mais comme le problème n'arrive pas en même temps alors qu'elles tournent toutes les deux sur le même job, j'ai laissé tombé cette piste là.

Par contre 2 alimentations qui posent problème avec un temps de fonctionnement différent (la deuxième est arrivée en production 5 mois après).

Pour ce qui est du MCU host, merci pour les infos. Je me demande si le problème ne vient pas d'une montée de version de Klipper avec un service qui n'est plus à jour. Je vais regarder les versions entre les deux directories. Au besoin je vais refaire l'opération de flashage de cette MCU complètement.

 

J'ai vérifié les versions du service mcu-host, pas de soucis. J'ai reflashé ce mcu par acquis de consience.

@fran6pUne question bête, si la fréquence d'horloge utilisée pour flasher le STM32 n'est pas la bonne, ça ne va pas créer des problèmes de timing donc de communication ?

 

[fran6p]

il y a 38 minutes, V3DP a dit :

Je me demande si le problème ne vient pas d'une montée de version de Klipper avec un service qui n'est plus à jour.

Préalable : je ne fais pas tourner H24 mes imprimantes.

Quand j'ai libéré ma XM3, les MCUs avaient été flashés avec la version 0.12 de Klipper à l'époque. Depuis via KIAUH ou via Moonraker, ma version de Klipper est en 0.13. Je n'ai pas eu d'erreur au lancement de Klipper (le Mismatch) et les impressions que je fais vont au bout, mais il est rare que j'en fasse qui durent plus de 12 h.

J'ai regardé ton dernier journal via Klippylyser. Il détecte un problème au niveau de la sonde de températures de l'extrudeur :

Thermocouple défaillant, câble du thermocouple, puce du thermocouple de la tête (MAX6675) ?

 

[V3DP]

il y a 23 minutes, fran6p a dit :

J'ai regardé ton dernier journal via Klippylyser. Il détecte un problème au niveau de la sonde de températures de l'extrudeur :

Le shutdown était entre 0h et 1h du matin.

Ce que tu vois à 9h45, c'est plutôt les manipulations opérateurs (chargement / déchargement filament, nettoyage de buse)

En fait, c'est plutôt une erreur d'analyse de Klippylyser qui regarde juste les variations sans avoir la cause.

Si c'est un problème de Thermocouple, tu as une erreur spécifique dans Klipper qui est explicite, mais pas un "timer too close". Pour avoir essayé en débranchant volontairement le thermocouple. 

[fran6p]

il y a 15 minutes, V3DP a dit :

Le shutdown était entre 0h et 1h du matin.

Le journal s'arrête avant 10h  donc Klippylyser n'en fait pas mention… «bizarre, bizarre, comme c'est étrange» ont déclamé en leur temps des acteurs (Michel Simon / Louis Jouvet) dans le film Drôle de drame .

Modifié (le) samedi à 15:07 par fran6p

[V3DP]

il y a 15 minutes, fran6p a dit :

«bizarre, bizarre, comme c'est étrange»

Oui, surtout que si tu utilises Sineos sur la log que j'avais uploadée, tu vois bien le shutdown en question