AlphAndruino

Je confirme que ca venait bien de là. J'ai installé mon Yumi Pad mais j'ai débranché l'écran avant et aucun soucis sur une impression de 18h. Aucun bytes_retransmited dans le log

En même temps, je me demande.... Pour pouvoir reclasser Marlin avec xloader, j'ai été obligé de désactiver la connexion serie de l'écran, c'est une option sur mon firmware écran modifié. Si j'ai été obligé de le faire pour xloadet. Je me demande si il ne fallait pas que je le fasse pour klipper, pour l'utiliser....

Et d'ailleurs il est réinstallé, plein le dos de Klipper

Merci mais pas besoin j'ai un firmware custopm : Molise

Je suis en train de me reconfigurer un Marlin

Bon, bonne, ou mauvaise, nouvelle, mais ce n'est pas non plus un problème de vitesse d'impression. J'ai descendu les viteses à 50mm/s et ça vient de se planter, tout pareil. Je désepsère

Oui, c'est ça, elle attends les 200 voire un tout petit peu plus sur les grandes lignes. Sinon, elle tiens bien les 150, par exemple sur le remplissage

Entre 100 et 200 mm/s

ok, merci de l'info Quand aux vitesses d'impression?

Hum, c'est bien ce que je craignais, je l'ai comparé au log de l'impression d'un benchy qui, lui, fonctionne bien et les graphs ont la même tronche. Mais quand même le bandwidth m'interpelle, il est très grand et vachement variable. Peut-être une autre piste, mais l'alim de l'imprimante et le rapsberry sont sur la même multiprise, celà pourrait-il être une cause d'interférence, sachant que l'imprimant est sur une prise connectée. En fait, mes problèmes de mcu timeout se posent quand je tente d'imprimer des fichier plus gros, genre une boite et son couvercle (2 essai, le premier mcu timeout, le second ok) et là, c'est la tête de Dark Vador que j'imprime taille réelle, ou presque, qui elle fail à chaque tentative. Des benchy ou des cubes de calibration, je n'ai aucun souci mais des plateaux complets ou de grosses pièces, crash. La vitesse d'impression pourrait-elle avoir un impacte sur la communication entre le host et le mcu ou avec la surface d'impression (sous entendu la dimension de ce qu'il y a à imprimer) Si j'imprime moins vite, ça pourrait marcher, en gros, sur une grosse pièce?

Salut Pour infos, j'ai changé de câle usb, pour être sûr d'en avoir un rapide et blindé et je lui ai ajouté un tore de ferrite, question de... J'ai bien cru que c'était bon, mais pas de bol, plantage à 13% de l'impression après presque 5h de print...Bouhhhh. En continuant de creuser, se suis tombé su ce site : https://sineos.github.io/ C'est cool, mais je ne comprend pas trop ce que je vois. Je joint mon le fichier log de mon dernier crash, si un sachant au grand coeur traine dans le coin. Je devrais recevoir mon Yumi pad cette semaine. klippy 2024-12-05.zip

ah, ok, mais du coup, ce n'est pas mon cas, mais merci du tuyau

Non, je n'ai qu'un rapsberry, je verrais ça quand j'aurais reçu mon klipper pas. Mais quel rapport?

Nouveau crash Je désespère. Je joint klippy.log et Moonraker.log, au cas où.... Ainsi qu'une capture d'écran des infos machines juste après le crash. A noter que je dois faire un redémarrage du firmware pour que Klipper se reconnecte Par contre, bonne nouvelle, je devrais recevoir mon Yumi pad dans pas longtemps. Je ne sais pas si ça aidera, mais bon. Klippy.txt Moonraker.txt

Si c'est ça, c'est la merde , je suis loin d'être assez balèze en linux pour débuggeur ce genre de problème. Je viens de relancer mon impression qui a merdée 3 fois de suite en partant d'un klippy.log vierge pour voir si j'ai plus d'info et je suis la charge processeur pour voir si ça ne viendrait pas d'uun ouverload ou vitesse d'impression triop importante, j'ai aussi changé le câble usb, et le port sur le rapsberry, mais je n'ai que des vieux câbles. Enfin, croisons les doigts