Perte de connexion mcu

[Bayou Tèche]

Bonjour,

Je rencontre un problème d'impression que je n'arrive pas à surmonter.

1°) Hier soir vers 21:00 j'ai lancé l'impression d'une pièce qui devait durer environ 13 h. L'impression s'est arrêtée vers 3:00, je m'en suis rendu compte vers 6:00 ce matin.

Une notification indiquait: "Lost communication with MCU 'mcu'"

2°) Début après midi (13:14), je lance un nouveau fichier moins gros. Même problème moins de trois heures après (15:53).

Mes câbles USB sont bons, l'alim du Pi est correcte, les connexions pour autant que je puisse en juger sont franches. Je ne trouve nulle part de réelle solution, bien qu'il semble que ce souci arrive à pas mal de monde...

Mon rapport Klippy pèse 18,1 Mo pour 45850 lignes, il ne passera certainement pas ici. Que pourrais-je expurger pour qu'il reste parlant?

Je tranche avec Cura, les impressions étaient en PETG et PLA à des vitesses et températures très raisonnables.

Comprends pas ce qu'il se passe. Micro coupures réseau?

Est-ce que quelqu'un pourrait me donner un chtit coup de main, SVP?

Merci

 

 

 

 

[pascal_lb]

  Le 28/01/2024 at 17:14, Bayou Tèche a dit :

Est-ce que quelqu'un pourrait me donner un chtit coup de main, SVP?

Dérouler  

Pour lancer tes impressions tu passes par Fluid ou Mainsail ou par une clé USB ?

[Bayou Tèche]

J'uploade sur Mainsail depuis Cura, et je lance l'impression depuis l'écran tactile, ou bien l'ordinateur.

[pascal_lb]

  Le 28/01/2024 at 17:47, Bayou Tèche a dit :

J'uploade sur Mainsail depuis Cura, et je lance l'impression depuis l'écran tactile, ou bien l'ordinateur.

Dérouler  

C'est quelle version de Pi ? As tu un radiateur sur le proc de ton Pi ? Tu es sûr de ton câble USB ?

[Bayou Tèche]

C'est un Pi3B+, qui n'a pas de dissipateur mais qui est à l'air libre.

J'ai utilisé deux câbles USB, dont un tout neuf, assez court (env. 50 cm). Pas facile d'être sûr de la qualité de transmission des infos.... Surtout que la perte de communication a lieu au bout d'un certain temps.

[pascal_lb]

  Le 28/01/2024 at 18:27, Bayou Tèche a dit :

Surtout que la perte de communication a lieu au bout d'un certain temps.

Dérouler  

Le câble USB est souvent la cause, as tu essayé de flasher à nouveau ta carte

As tu fait les mises à jour de ton Pi ? De Klipper etc ...

Je lance des idées, ce n'est peut-être pas les bonnes mais on ne sait jamais

[Bayou Tèche]

J'ai fait une mise à jour complète de l'écosystème Klipper hier soir. Par contre non, je n'ai pas flashé la carte. Je testerai demain .

 

[Nunki0]

Bonjour,

J'ai aussi eu pas mal ce souci avec ma vieille Anet. Ce qui a finalement réglé le problème a été de passer sur un câble livré avec un kit Arduino très court (~15cm), qui je suppose devait avoir une meilleure isolation.

J'ai aussi lu que couvrir le pad +5v du cable ou du port de l'imprimante permet d'avoir une connexion plus fiable (personnellement j'ai utilisé du scotch a peinture et ça fonctionne très bien).

[Bayou Tèche]

Flash carte fait tôt ce matin, connexion perdue de nouveau

Je suis en train de regarder la multitude de câbles USB, qui sont tous bien évidemment de grande qualité..... Pas facile de faire un choix pertinent. Avez vous un modèle/marque en tête?

Je me demande s'il serait possible de s'en passer et de faire la connexion à partir du GPIO du Pi sachant que je m'achemine vers l'intégration de toute l'électronique dans un unique boîtier.

J'ai vu cette page, ça doit pouvoir se faire? Au prix d'une autre carte mère?

[Nunki0]

Salut,

  Le 29/01/2024 at 09:53, Bayou Tèche a dit :

J'ai vu cette page, ça doit pouvoir se faire? Au prix d'une autre carte mère?

Dérouler  

Il est indiqué que c'est une version obsolète du tuto, il y en a une autre Ici.

Cependant, je ne pense pas qu'il y ait à changer la carte mère. Il me semble que parmi les pins de communication avec l'écran il y a les pins Rx/Tx, mais je n'arrive pas à retrouver où j'ai vu cela...

[Bayou Tèche]

  Le 29/01/2024 at 10:45, Nunki0 a dit :

Il me semble que parmi les pins de communication avec l'écran il y a les pins Rx/Tx, mais je n'arrive pas à retrouver où j'ai vu cela...

Dérouler  

Pareil!!!! Vu tant de pages que tout se mélange!!! Merci pour le nouveau lien, je regarde.

 

[Edit]: je me demande si les connexions ne sont pas sur ce port: Image du bas dans le post #9

J'ai diagramme de la carte 4.2.7 que @fran6p m'avait communiqué; je regarderai dans la journée.

En fait non, c'est l'endroit où brancher le LCD. (Je n'ai pas de visuel sur la carte en service, juste une vieille qui est HS)

Modifié (le) Janvier 29, 2024 par Bayou Tèche
Complément

[pommeverte]

Salut,

  Le 29/01/2024 at 11:03, Bayou Tèche a dit :

En fait non, c'est l'endroit où brancher le LCD

Dérouler  

dans ce cas, tu n'as pas la possibilité de compiler un nouveau firmware de carte-mère en choisissant les broches PB10/PB11 pour la communication, au lieu de PA09 et PA10?

Modifié (le) Janvier 29, 2024 par pommeverte

[Bayou Tèche]

Bonjour @pommeverte,

Le port cité ci-dessus ne me sert plus puisque je suis sous Klipper, avec Klipperscreen et un écran tactile HDMI. Donc peut être exploitable????

Peut être en bricolant le printer.cfg? Je ne sais pas du tout si on peut ré-assigner les broches d'un port .

A creuser!

[pommeverte]

  Le 29/01/2024 at 12:42, Bayou Tèche a dit :

Peut être en bricolant le printer.cfg?

Dérouler  

non, comme je l'ai indiqué, c'est lorsque tu crées le firmware de la carte-mère que tu indiques quel port série/ USART sera utilisé.

Après vérification, il est bien possible de choisir les broches PB10/PB11: à la ligne communication interface, tu choisis USART3 ( PB11/PB10). Une fois  fait, il ne te reste plus qu'à flasher le nouveau firmware

Modifié (le) Janvier 29, 2024 par pommeverte

[Bayou Tèche]

Yes! Compris .

C'est l'étape:

make menuconfig

J'ai du mal, mais ça va finir par rentrer

[Bayou Tèche]

@pascal_lb   la piste du câble semblait juste (je croise les doigts)

J'ai fouillé dans mes cartons de pièces et trouvé un câble court, neuf (sur lequel est monté bloc ferrite - utilité dans ce cas??) qui rentre plus serré dans la prise de la carte mère.

J'ai collé un chatterton sur le +5V.

Résultat: pour le moment 3 impressions arrivées à terme.

Mais je n'abandonne pas le projet de me passer du câble USB. Quand j'aurai du temps à y consacrer pour le faire bien, je testerai la méthode indiquée par @pommeverte.

Merci donc pour l'idée

[pascal_lb]

  Le 30/01/2024 at 11:23, Bayou Tèche a dit :

pour le moment 3 impressions arrivées à terme

Dérouler  

Je croise aussi les doigts

C'est pour ça que j'ai abandonné toutes connections USB... 

[Bayou Tèche]

Bon, c'est pas ça.

J'ai lancé une première impression qui a échoué au bout d'un moment. Comme j'avais augmenté la vitesse petit à petit jusqu'à 115%, je me suis dit que ça venait de là.

Je relance l'impression, échec à la toute fin (4h30 d'impression). Il me manquait 5 couches essentielles à la fonctionnalité de la pièce.

Au début de ce second essai, j'ai essayé de bouger les fiches USB dans leurs prises à la main sans causer de perte de connexion.

Saoûlant, ça commence à faire beaucoup de gaspillage....

[Savate]

  Le 30/01/2024 at 16:46, Bayou Tèche a dit :

Je relance l'impression, échec à la toute fin (4h30 d'impression). Il me manquait 5 couches essentielles à la fonctionnalité de la pièce.

Dérouler  

tu peux mettre ton klipper.log en fichier attaché ?

[Bayou Tèche]

Voici Klippy.log. Je n'arrive pas l'ouvrir chez moi, il y a une erreur! je ne sais pas si tu vas pouvoir l'exploiter?

logs-20240130-181525.zipFetching info...

[Savate]

  Le 30/01/2024 at 17:23, Bayou Tèche a dit :

oici Klippy.log. Je n'arrive pas l'ouvrir chez moi, il y a une erreur! je ne sais pas si tu vas pouvoir l'exploiter?

Dérouler  

15 mo notepad a du mal (notepad++ s'en sort mieux  )

il faudrait supprimer le klipper.log pour réduire un peu sa taille

Sinon les logs montrent qu'il y a des erreurs de temps en temps dans les communication avec la CM

jusqu'au moment ou il n'arrive plus à rien : bytes_write ne bouge plus et il plante

Stats 20004.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2427474 bytes_read=967002 bytes_retransmit=123 bytes_invalid=0 send_seq=64837 receive_seq=64837 retransmit_seq=12875 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363298 sysload=0.39 cputime=911.618 memavail=431296 print_time=5728.912 buffer_time=2.532 print_stall=0 extruder: target=235 temp=235.2 pwm=0.299

Stats 20005.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2428029 bytes_read=967101 bytes_retransmit=867 bytes_invalid=0 send_seq=64847 receive_seq=64844 retransmit_seq=64847 srtt=0.003 rttvar=0.000 rto=0.400 ready_bytes=39 upcoming_bytes=33 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363363 sysload=0.39 cputime=911.645 memavail=430488 print_time=5729.579 buffer_time=2.198 print_stall=0 extruder: target=235 temp=235.1 pwm=0.299

Stats 20006.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2428029 bytes_read=967101 bytes_retransmit=1053 bytes_invalid=0 send_seq=64847 receive_seq=64844 retransmit_seq=64847 srtt=0.003 rttvar=0.000 rto=0.800 ready_bytes=39 upcoming_bytes=630 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363426 sysload=0.43 cputime=911.668 memavail=429296 print_time=5730.566 buffer_time=2.185 print_stall=0 extruder: target=235 temp=235.1 pwm=0.299

Stats 20007.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2428029 bytes_read=967101 bytes_retransmit=1239 bytes_invalid=0 send_seq=64847 receive_seq=64844 retransmit_seq=64847 srtt=0.003 rttvar=0.000 rto=1.600 ready_bytes=39 upcoming_bytes=2218 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363604 sysload=0.43 cputime=911.693 memavail=428812 print_time=5732.114 buffer_time=2.731 print_stall=0 extruder: target=235 temp=235.1 pwm=0.299

Stats 20008.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2428029 bytes_read=967101 bytes_retransmit=1425 bytes_invalid=0 send_seq=64847 receive_seq=64844 retransmit_seq=64847 srtt=0.003 rttvar=0.000 rto=3.200 ready_bytes=39 upcoming_bytes=2793 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363670 sysload=0.43 cputime=911.717 memavail=427592 print_time=5733.037 buffer_time=2.653 print_stall=0 extruder: target=235 temp=235.1 pwm=0.299

Stats 20009.4: gcodein=0  mcu: mcu_awake=0.010 mcu_task_avg=0.000046 mcu_task_stddev=0.000081 bytes_write=2428029 bytes_read=967101 bytes_retransmit=1425 bytes_invalid=0 send_seq=64847 receive_seq=64844 retransmit_seq=64847 srtt=0.003 rttvar=0.000 rto=3.200 ready_bytes=39 upcoming_bytes=3442 freq=72001083 heater_bed: target=70 temp=70.0 pwm=0.096 sd_pos=363734 sysload=0.43 cputime=911.754 memavail=427340 print_time=5734.042 buffer_time=2.658 print_stall=0 extruder: target=235 temp=235.1 pwm=0.299

Timeout with MCU 'mcu' (eventtime=20010.415973)
Transition to shutdown state: Lost communication with MCU 'mcu'

Question : 

Est-ce que ça plante avec n'importe quel fichier ou un fichier spécifique (je n'ai pas eu le courage de regarder dans les logs  )

Est-ce que ça plante depuis une modifications ? une maj ?

 

 

[Bayou Tèche]

J'ai eu des plantages sur au moins trois fichiers différents.

La première erreur flagrante (que je n'ai pas associée au phénomène) est arrivée il y a qques jours:

J'avais une pièce de dimension moyenne genre 50x110x30, qui devait être  solide et dont l'aspect était peu important. J'ai décidé de l'imprimer en PETG avec une buse de 1 mm et des couches de 0.5 mm pour que ça aille vite.

Je m'y suis repris à trois fois, et chaque fois plantage. J'ai fait des recherches et il semblerait que je demandais plus d'extrusion que Klipper n'en autorise: une histoire de limite de 0.640 mm^² (vu dans les notifications). Il fallait que j'avance, me suis dit que je verrais ce souci de limite plus tard, donc je suis repassé en buse de 0.4, j'ai re-tranché et lancé l'impression samedi soir .

J'ai obtenu une pièce quasi complète, exploitable bien que non terminée à 100%.

Ensuite plantages aléatoires, et rédaction de ma demande d'aide.

  Le 30/01/2024 at 18:01, Savate a dit :

il faudrait supprimer le klipper.log pour réduire un peu sa taille

Dérouler  

Pour que Klipper en redémarre un nouveau, tu veux dire?

 

 

 

[Bayou Tèche]

Bonjour,

 

Bon, la connexion carte mère

PB10 = Rx

PB11 = Tx

 est faite sur GPIO

14 = Tx

15 = Rx

J'ai re-flashé a carte mère avec un nouveau firmware.bin créé avec comme paramètre:

USART3 ( PB11/PB10)

Mais la communication Pi / Imprimante ne fonctionne pas:

pi@raspberrypi:~ $ ls /dev/serial/by-id/*
ls: cannot access '/dev/serial/by-id/*': No such file or directory
pi@raspberrypi:~ $ ls /dev/serial/by-path/*
ls: cannot access '/dev/serial/by-path/*': No such file or directory
pi@raspberrypi:~ $ 

 

[pommeverte]

Salut,

Est-ce que tu as activé le port série et désactivé le bluetooth (spécifique au RPi3) comme indiqué sur cette page?
D'après cette page et celle-ci , il faudrait déclarer dans le fichier printer.cfg: /dev/ttyS0

[Bayou Tèche]

J'ai désactivé le bluetooth, mais suivant d'autres infos trouvées sur Reddit. Je vais suivre tes procédés avec attention, ils sont plus précis que ce que j'avais.

Je reviens quand c'est fait