Un peu perdu avec klipper

[jerem59120]

d'accord merci

voici le fichier klippy (2).txt

[Savate]

  Le 10/03/2024 at 13:50, jerem59120 a dit :

voici le fichier klippy (2).txt

Dérouler  

il faut le récupérer juste après l'erreur, là il est tout vide (enfin pas vide, mais sans erreurs)

[jerem59120]

ah désolé, le voici après erreur klippy (3).txt

[Savate]

  Le 10/03/2024 at 16:57, jerem59120 a dit :

ah désolé, le voici après erreur klippy (3).txt

Dérouler  

il est mieux ... mais il n'a loggué aucune erreur ..

il fait le pressure advance et hop il s'arrête

il fait quand même beaucoup d'erreur de transmissions de données : câbles à vérifier 

Stats 12379.1: gcodein=0  mcu: mcu_awake=0.009 mcu_task_avg=0.000012 mcu_task_stddev=0.000010 bytes_write=12509832 bytes_read=3967644 bytes_retransmit=1220 bytes_invalid=0 send_seq=246482 receive_seq=246482 retransmit_seq=244331 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168005629 heater_bed: target=60 temp=60.0 pwm=0.175 sd_pos=729565 Raspberry_Pi: temp=47.8 Motherboard: temp=39.2 sysload=0.40 cputime=468.532 memavail=616388 print_time=12381.646 buffer_time=2.478 print_stall=0 extruder: target=230 temp=230.4 pwm=0.413

[jerem59120]

D'accord merci, je vais changer de câble. pour le fichier de log, les erreurs se trouverons en début ou en fin de fichier ? je voudrais mieux comprendre sont fonctionnement

[Savate]

  Le 11/03/2024 at 06:27, jerem59120 a dit :

D'accord merci, je vais changer de câble. pour le fichier de log, les erreurs se trouverons en début ou en fin de fichier ? je voudrais mieux comprendre sont fonctionnement

Dérouler  

les logs les plus récents sont en bas ... donc les erreurs sont plutôt en fin de fichier.

[jerem59120]

  Le 11/03/2024 at 06:16, Savate a dit :

il est mieux ... mais il n'a loggué aucune erreur ..

il fait le pressure advance et hop il s'arrête

il fait quand même beaucoup d'erreur de transmissions de données : câbles à vérifier 

Stats 12379.1: gcodein=0  mcu: mcu_awake=0.009 mcu_task_avg=0.000012 mcu_task_stddev=0.000010 bytes_write=12509832 bytes_read=3967644 bytes_retransmit=1220 bytes_invalid=0 send_seq=246482 receive_seq=246482 retransmit_seq=244331 srtt=0.001 rttvar=0.000 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168005629 heater_bed: target=60 temp=60.0 pwm=0.175 sd_pos=729565 Raspberry_Pi: temp=47.8 Motherboard: temp=39.2 sysload=0.40 cputime=468.532 memavail=616388 print_time=12381.646 buffer_time=2.478 print_stall=0 extruder: target=230 temp=230.4 pwm=0.413

Dérouler  

Merci beaucoup j'ai changé de câble USB et je n'ai plus de problème pour l'instant, je continue les tests

[jerem59120]

Bonjour,

Hier j'ai intégré le raspberry & l'écran dans la SR, le tout alimenté par l'alim Meanwell RS25-5, le problème est revenu et s'est présenté sur mes deux derniers prints.

J'ai utilisé le câble USB qui a résolu mon problème et quand je regarde les fichiers de log je vois le même problème vous confirmez ?

Voici les deux fichiers récupérés après chaque plantage.

Merci

klippy(3).txtFetching info... klippy(2).txtFetching info...

Modifié (le) Mars 15, 2024 par jerem59120

[Savate]

  Le 15/03/2024 at 05:36, jerem59120 a dit :

Hier j'ai intégré le raspberry & l'écran dans la SR, le tout alimenté par l'alim Meanwell RS25-5

Dérouler  

Si le  câble usb passe près du 230v ou des moteurs, tu peux essayer de l'éloigner un peu

ça n'a rien à voir, mais  Il faudrait que tu regardes qui envoie la commande M10086 - qui n'existe pas (slicer ?)

Modifié (le) Mars 15, 2024 par Savate

[jerem59120]

Merci bien pour ta réponse.

Dans mon montage l'alim Meanwell que j'ai ajouté est à coté de l'alim de l'imprimante donc dans le pied. Le câble USB ne passe pas à coté du 230V, mais j’avais enroulé ce câble qui est trop long. Ce matin je l'ai remplacé par un câble de 20 cm. J'ai lancé une petite impression qui s'est bien passé, mais dans les fichiers de logs de cette impression il n'y a que 60 bytes retransmit ! Il y a donc toujours un problème ? Cela peut-il jouer sur la qualité de l'impression étant donné qu'il manque pleins d'infos (si j'ai bien compris )?

Pour la commande "M10086" de ce que je viens de voir c'est un plugin MKS que j'ai installé pour ma D12 que j'ai dû laissé activer pour la SR je testerai dès que je rentre, mais merci je n'y avais pas prêté attention

[Savate]

  Le 15/03/2024 at 08:35, jerem59120 a dit :

Cela peut-il jouer sur la qualité de l'impression étant donné qu'il manque pleins d'infos (si j'ai bien compris )?

Dérouler  

non pas de perte d'infos (quand il n'arrive pas à renvoyer il s'arrête ...)

à vérifier aussi : les soudures et la bonne tenue des prises (surtout côté carte mère, sur le pi c'est plus costaud)

[jerem59120]

d'accord, donc si j'ai que 60 bytes retransmit ce n'est pas un problème ? désolé question peut être bête mais j'aime bien comprendre...

[Savate]

  Le 15/03/2024 at 09:18, jerem59120 a dit :

d'accord, donc si j'ai que 60 bytes retransmit ce n'est pas un problème ? désolé question peut être bête mais j'aime bien comprendre...

Dérouler  

Ce n'est pas un problème si ça se limite à des pertes 'occasionnelles', en fait ça veut juste dire qu'il y a eu une erreur de transmission et que klipper a du renvoyer le paquet.

Les erreurs de transmission peuvent être dues a des tas de raisons :

* CM surchargée (ce n'est pas le cas)

* PI surchargé (ce n'est pas le cas non plus)

* câble défectueux ou non blindé,

* parasites temporaires (moteur, 230v)

* faux contact au niveau d'une prise

* et probablement tout un tas d'autres  

[jerem59120]

d'accord merci, donc pour toi ce fichier est bon niveau transmission de données ?

klippy 1503.txtFetching info...

[Savate]

  Le 15/03/2024 at 12:47, jerem59120 a dit :

'accord merci, donc pour toi ce fichier est bon niveau transmission de données ?

Dérouler  

Dans l'idéal, le retransmit devrait être à 0.

Comme la charge cpu de la carte mère et la t° sont ok, je ne vois plus qu'un problème d'interférences ou de connecteur. 

[jerem59120]

D'accord merci je vais contrôler et tester tout ça

Après un nouveau test et un nouveau plantage j'ai ceci et je ne comprends pas ces points;

 

Stats 27.4: gcodein=0  mcu: mcu_awake=0.005 mcu_task_avg=0.000008 mcu_task_stddev=0.000009 bytes_write=2388 bytes_read=6171 bytes_retransmit=9 bytes_invalid=0 send_seq=203 receive_seq=203 retransmit_seq=2 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168006293 heater_bed: target=0 temp=24.1 pwm=0.000  Raspberry_Pi: temp=42.4 Motherboard: temp=32.1 sysload=2.00 cputime=2.579 memavail=629276 print_time=0.000 buffer_time=0.000 print_stall=0 extruder: target=0 temp=23.2 pwm=0.000
webhooks client 548380031584: New connection
webhooks client 548380031584: Client info {'program': 'Moonraker', 'version': 'v0.8.0-268-ga23187b'}
Stats 28.4: gcodein=0  mcu: mcu_awake=0.005 mcu_task_avg=0.000008 mcu_task_stddev=0.000009 bytes_write=2394 bytes_read=6348 bytes_retransmit=9 bytes_invalid=0 send_seq=204 receive_seq=204 retransmit_seq=2 srtt=0.001 rttvar=0.001 rto=0.025 ready_bytes=0 upcoming_bytes=0 freq=168005569 heater_bed: target=0 temp=24.2 pwm=0.000  Raspberry_Pi: temp=42.9 Motherboard: temp=32.3 sysload=2.00 cputime=2.597 memavail=629772 print_time=0.000 buffer_time=0.000 print_stall=0 extruder: target=0 temp=23.3 pwm=0.000
webhooks: registering remote method 'shutdown_machine' for connection id: 548380031584
webhooks: registering remote method 'reboot_machine' for connection id: 548380031584
webhooks: registering remote method 'pause_job_queue' for connection id: 548380031584
webhooks: registering remote method 'start_job_queue' for connection id: 548380031584

[jerem59120]

J'ai calibré l'alimentation meanwell du rasp à 5,5V comme sur la vidéo dans liens utiles sur le site de guillouz.

Est-ce vraiment la bonne tension ? La j'ai des arrêts à chaque impression et en plus d'avoir tout intégré dans la sr je suis passé d'un bloc alim pour rasp à cette alimentation meanwell

[Savate]

  Le 15/03/2024 at 12:58, jerem59120 a dit :

webhooks: registering remote method 'shutdown_machine' for connection id: 548380031584
webhooks: registering remote method 'reboot_machine' for connection id: 548380031584
webhooks: registering remote method 'pause_job_queue' for connection id: 548380031584
webhooks: registering remote method 'start_job_queue' for connection id: 548380031584

Dérouler  

Rien d'anormal, c'est la procédure de démarrage normale

  Le 15/03/2024 at 20:12, jerem59120 a dit :

J'ai calibré l'alimentation meanwell du rasp à 5,5V

Dérouler  

ça fait beaucoup 5.5v (je met 5.1v puisque c'est la tension officielle du pi 4)

[jerem59120]

D'accord merci, j'ai refait un test avec l'alimentation pi que j'utilisais avant et j'ai le même problème.... hier j'ai eu un message d'erreur comme sur la photo mais ce matin pareil tout était figé même l'écran...

J'en ai marre à force que ça bug je suis obligé d'éteindre à l'arrache et rallumer et maintenant j'ai cette erreur au démarrage....

Je suppose que je dois tout réinstaller ?

[jerem59120]

Bon je ne comprends pas depuis ce matin j'ai du réinstaller 4x pour resoudre le problème initiale mais là plus moyen de faire fonctionner klipperscreen !

Comme je suis allé au bout de la procédure j'ai le logo FLsun mais le rasp me demande mon login et mon mot de passe et Klipper screen ne démarre pas j'ai pourtant relu à chaque fois pour être sur de rien oublier mais ça ne veut pas...

J'ai ce message pendant l'install;

mv: cannot move '/home/pi/KlipperScreen-Flsun-Super-Racer' to '/home/pi/KlipperScreen/KlipperScreen-Flsun-Super-Racer': Directory not empty

le problème vient de là ?

 

 

Modifié (le) Mars 16, 2024 par jerem59120

[Savate]

  Le 16/03/2024 at 13:55, jerem59120 a dit :

le problème vient de là ?

Dérouler  

la j'avoue, je n'utilise pas klipperscreen donc je ne sais pas du tout (sauf que c'est une erreur 'courante' avec klipperscreen)

une invocation de @fran6p fera peut être avancer le schmilblik

[fran6p]

Non, désolé, aucune idée hormis une carte SD défaillante car la commande de déplacement devrait pouvoir s'exécuter sans plus de droits (l'utilisateur étant «pi»)

Pour les erreurs liées à Klipperscreen, le mieux est de consulter ou le Github ou la documentation ou encore le Github de @Guilouz

[jerem59120]

la commande de déplacement ?

Pour l'instant depuis l'interface web ça fonctionne, je peux lancer une impression, je n'arrive "juste" plus a avoir klipper screen sur l'écran 7"

[fran6p]

  Le 16/03/2024 at 13:55, jerem59120 a dit :

mv: cannot move '/home/pi/KlipperScreen-Flsun-Super-Racer' to '/home/pi/KlipperScreen/KlipperScreen-Flsun-Super-Racer': Directory not empty

Dérouler  

C'est ce message : le «mv»

[toonsandco]

Tu as tenté de faire le move en tant que sudo ?