V3DP Posté(e) Juillet 12 Auteur Posté(e) Juillet 12 Quelques progrès dans ce problème qui devient pénalisant avec mes X Max 3. Donc hier matin désactivation du MCU Host Linux qui n'est pas dans la configuration d'origine Qidi (ni dans FreeDi). Pas de pertes de paramètres ou de fonctionnalités. Remplacement de l'alimentation principale de ma deuxième X Max 3 par une de 600 W, comme pour la première X Max 3. Pour le reste les MCU sont flashées de manière normale avec l'écran FreeDi 1.42, le ventilateur de refroidissement de la carte est d'origine tout comme le cable USB C. Et c'est parti pour des jobs de production sur les deux machines, mais cette fois ci sans la clim -> 25°C dans la salle d'impression. La deuxième X Max 3 a tourné 24h au total sans problèmes de shutdown (MCU Timer Too Close) dont 19h d'impression et une pause car le capteur de filament avait détecté un problème de débit. Dans tous les cas, c'est bien mieux que quelques jours auparavant où le même job plantait vers 9h d'impression. La première X Max 3 a imprimé 4h45 avant un shutdown (MCU Timer Too Close) au bout de 6h alors qu'elle était en pause pour un problème de débit de filament. Même scénario que la veille. Sur les logs, rien d'anormal à nouveau. Sur celle ci le MCU est flashé avec une vitesse de communication série à 500 000 bauds et l'écran flashé avec FreeDi 2.0, ventilateur de 80 mm pour refroidir la carte mère, cable USB -C changé. En rentrant de weekend, je vais reflasher la première avec une vitesse de communication de 115 000 bauds (standard Qidi) et relancer le même job.
V3DP Posté(e) Juillet 15 Auteur Posté(e) Juillet 15 Le 12/07/2025 at 17:29, V3DP a dit : En rentrant de weekend, je vais reflasher la première avec une vitesse de communication de 115 000 bauds (standard Qidi) et relancer le même job. Oups de 250 000 bauds (standard Klipper et Qidi). Je viens de reflasher la carte mère et c'est reparti pour un tour avec le même job. 1
fran6p Posté(e) Juillet 16 Posté(e) Juillet 16 (modifié) @V3DP J'espère que ton impression se déroule correctement. Comme pas mal de matériel a déjà été changé / remplacé, je pense à un truc qui n'a peut-être aucun rapport avec ces «mcu shutdown, timer too close», mais je le pose tout de même là. Pour les axes X et Y, quelle valeur utilises-tu pour les microsteps ? 16 est la valeur par défaut et généralement ça produit de bonnes impressions . Plus on utilise une valeur supérieure (32, 64, 128) plus le microcontrôleur est sollicité, il me semble . Sinon M. Freedi a émis une mise en garde pour les XM3 sous Freedi 2.0 : https://github.com/Phil1988/FreeDi/issues/290 Modifié (le) Juillet 16 par fran6p
V3DP Posté(e) Juillet 16 Auteur Posté(e) Juillet 16 (modifié) Il y a 3 heures, fran6p a dit : J'espère que ton impression se déroule correctement. @fran6p Oui elle est allée jusqu'au bout, soit 4h45. Avec une température extérieure de 25°C, la chambre à 55°C, le plateau à 80°C et la buse à 260°C. Il y a 3 heures, fran6p a dit : Pour les axes X et Y, quelle valeur utilises-tu pour les microsteps ? 16 est la valeur par défaut et généralement ça produit de bonnes impressions . Plus on utilise une valeur supérieure (32, 64, 128) plus le microcontrôleur est sollicité, il me semble . Je tourne avec 32 micro steps, interpolés. C'était déjà comme ça avant les problèmes. J'avais essayé à 16 micros steps lors des problèmes mais cela n'avait pas modifié le comportement. Vu les derniers shutdown qui ont eu lieu alors que la machine était idle mais juste la chauffe, je ne pense pas que le souci soit une bande passante ou une charge trop élevée. La piste d'un problème de stabilité de la tension me semble la plus probable. Mais normalement avec 600 W, même avec le derating il reste 480 W de dispo, soit bien assez pour les cartes, le plateau chauffant, la hotend, les LED et les ventilateurs du filtre à charbon. Mais j'ai un doute sur la machine qui a fait les derniers shutdown car la mise en chauffe de la chambre a déclenché la ventilation de l'alimentation de 600 W. Comme elle avait déjà le ventilateur d'origine du filtre à charbon monté à l'envers ..... en sortie d'usine.... Modifié (le) Juillet 16 par V3DP
fran6p Posté(e) Juillet 16 Posté(e) Juillet 16 Les versions suivantes de la Serie 3 (Q1 pro, Plus4, Q2?) utilisent un chauffage alimenté par la tension secteur (230V) via un SSR, ce qui permet de se passer d'une alimentation ne servant que pour la chauffe du caisson en 24V avec la XM3 . Si en plus le lit chauffant était, lui aussi, sous tension secteur, l'alimentation électrique pourrait n'être qu'une simple 150-24 sans ventilateur . Bon ça ferait tout de même de gros changements (sans omettre une excellente mise à la terre de ces éléments). 1
V3DP Posté(e) Aout 27 Auteur Posté(e) Aout 27 Je ressort mon problème après une longue pause de l'activité pour cause de déménagement + congés. J'ai redémarré mes deux X Max 3 et après 24h de fonctionnement dans une salle à moins de 25°C, les shutdown ont recommencé. Galère totale pour la reprise. Comme les logs ne montrent pas de souci de communication, que les alimentations ne sont pas en cause (des 600 W neuves) et que toutes les versions sont à jour, les MCU reflashées à 500 000 bauds et FreeDi 2.0, je penche pour un souci de carte mémoire. Au passage l'écran flashé FreeDi 2.0 avec une vitesse de communication à 250000 bauds ne fonctionne pas bien du tout. Donc à ne pas faire. Je me suis lancé dans le remplacement des emmc et là galère pour les cloner avec mon Mac. La copie avec l'Utilitaire de Disque de macOS comme un CD / DVD Master (copie théoriquement bit à bit) ne se fait pas bien. Derrière Etcher copie bien, mais une mauvaise image. Bref la machine ne boote plus, même si l'écran démarre, mais ne se synchronise pas avec Klipper. J'ai mis une journée à comprendre le problème .... Clonage réussi avec ImageUSB sur une machine virtuelle Windows et c'est reparti avec une emmc 32Go. Impression en cours. A suivre.....
fran6p Posté(e) Aout 27 Posté(e) Aout 27 Il y a 5 heures, V3DP a dit : les shutdown ont recommencé. Peut-être que ces problèmes sont dus à l'image du système utilisé par Freedi2 . Mi-juillet le sieur Freedi a émis un avertissement : https://github.com/Phil1988/FreeDi/issues/290 De nombreux soucis sont remontés sur le Discord. Certains apparemment rencontreraient moins de soucis avec l'image «FreeDi_v2.00_test_Armbian_24.11.1_current_6.6.62» au lieu de «FreeDi_v2.00_test_Armbian_25.08.0_edge_6.16.0»… edge correspondant généralement à une distribution genre Bugfix chez Marlin . L'OS installé sur ma XM3 est daté, mais fonctionnel. C'est celui de Redrathnure… quand j'aurai le temps et le courage, il faudrait que je mette à jour (en flashant une nouvelle eMMC) avec une version récente (là je teste la Qidi Q2, ça me prend tout mon temps). 1
V3DP Posté(e) Aout 27 Auteur Posté(e) Aout 27 (modifié) Il y a 4 heures, fran6p a dit : De nombreux soucis sont remontés sur le Discord. Certains apparemment rencontreraient moins de soucis avec l'image «FreeDi_v2.00_test_Armbian_24.11.1_current_6.6.62» au lieu de «FreeDi_v2.00_test_Armbian_25.08.0_edge_6.16.0»… edge correspondant généralement à une distribution genre Bugfix chez Marlin . Je n'utilise FreeDi que pour l'écran. L'OS est celui de Redrathnure, j'ai suivi ta documentation @fran6p. Les problèmes de shutdown étaient déjà existants avec FreeDi 1.42. FreeDi 2.0 a certainement introduit d'autres soucis comme la mauvaise synchronisation de l'écran si on est à 250 000 bauds au niveau de la MCU prinicpale. Le clonage de l'emmc a apporté semble t il un mieux mais à voir avec quelques impressions longues. Pour l'instant 6h30 sans problèmes alors qu'hier soir c'était 4h max pour le même job. Il y a 4 heures, fran6p a dit : Peut-être que ces problèmes sont dus à l'image du système utilisé par Freedi2 . Voire peut-être même par FreeDi 1.42. Pour l'instant je n'ai pas d'éléments pour le confirmer. Le doute vient du fait que lors d'un shutdown pour un MCU timer too close, les analyses Sineos ne mesurent que les communications entre les différentes MCU, pas l'écran. Et qu'il n'y a aucune anomalie sur les logs. De même, j'ai remarqué qu'éteindre puis redémarrer l'imprimante entre deux jobs diminuait fortement le risque de shutdown. Comme on reset tout ... D'un point de vue temporel, les problèmes ont commencé en fin Avril 2025, sachant que je suis passé directement de FreeDi 1.40 à 1.42 après le 8 Avril (release de la 1.42 le 11 mars). Si j'ai toujours mes soucis fin de semaine, je pense que je vais retirer les services FreeDi (Autoflasher.service et FreeDi.service) et déconnecter l'écran pour voir ce que ça donne avec juste Klipper 0.13 et son écosystème. Klipperscreen + client VNC sur un vieil iPad à priori. Modifié (le) Aout 27 par V3DP
fran6p Posté(e) jeudi à 12:57 Posté(e) jeudi à 12:57 Il y a 17 heures, V3DP a dit : Klipperscreen + client VNC Ça marche aussi (n'ayant pas de matériels Stevejobesque, je le suppose ). J'avais testé plusieurs solutions (Klipperscreen avec RPi0v2 additionnel et écran BTT HDMI (ce que j'utilise actuellement), Klipperscreen sur XM3 + VNC, CYD (Cheap Yellow display), ancien smartphone avec Fluidd, …)… tous fonctionnels 1
V3DP Posté(e) samedi à 13:41 Auteur Posté(e) samedi à 13:41 Le 28/08/2025 at 14:57, fran6p a dit : Ça marche aussi (n'ayant pas de matériels Stevejobesque, je le suppose ). J'ai encore eu un shutdown cette nuit, après 3 heures d'impression. Donc j'ai retiré FreeDi (désactive ses services, l'entrée dans Moonraker.conf et débranché l'écran). L'installation de KlipperScreen a pris un peu de temps, j'avais oublié le fichier de configuration et de mettre le script de démarrage de KlipperScreen exécutable ... Maintenant ça marche avec un client VNC sur un viel iPad Air de 2013 (Remote Ripple qui tourne meme avec une version ancienne d'iOS). Je vais pouvoir m'attaquer à la machine qui est en production et qui a planté cette nuit après lui avoir fait toutes les mises à jour et flashage des MCU en dernière version de Klipper comme l'autre. A voir si ça règle le problème de shutdown. 1
fran6p Posté(e) samedi à 13:57 Posté(e) samedi à 13:57 J'espère pour toi qu'effectivement cela résoudra ces pu…ns de problème de shutdown. Parce qu'après toutes ces tentatives de solutions, je suis à court d'idées. 1 1
V3DP Posté(e) dimanche à 09:05 Auteur Posté(e) dimanche à 09:05 Après mise à jour des versions de la machine en production, flashage des MCU (MCU principale à 500 000 bauds), retrait de FreeDi et installation de KlipperScreen + serveur VNC sur la machine en production hier après midi. Premier job de 2h sans problèmes (sur la base d'un job validé précédemment) Deuxième job de 8h40, le meme que le précédent mais plus de pièces, sans soucis non plus. Reste à voir dans la durée sur des jobs plus importants. Espérons que ça soit ça et que ce souci majeur soit derrière moi. 1
fran6p Posté(e) dimanche à 12:19 Posté(e) dimanche à 12:19 On croise les doigts et on serre les fe…es. Un petit cierge ne serait pas de trop, on ne sait jamais, accompagné d'une prière à saint Murphy . Tu nous tiendras au courant. 2
Messages recommandés
Créer un compte ou se connecter pour commenter
Vous devez être membre afin de pouvoir déposer un commentaire
Créer un compte
Créez un compte sur notre communauté. C’est facile !
Créer un nouveau compteSe connecter
Vous avez déjà un compte ? Connectez-vous ici.
Connectez-vous maintenant