jerem59120 Posté(e) Mars 10, 2024 Auteur Posté(e) Mars 10, 2024 d'accord merci voici le fichier klippy (2).txt
Savate Posté(e) Mars 10, 2024 Posté(e) Mars 10, 2024 il y a une heure, jerem59120 a dit : voici le fichier klippy (2).txt il faut le récupérer juste après l'erreur, là il est tout vide (enfin pas vide, mais sans erreurs)
jerem59120 Posté(e) Mars 10, 2024 Auteur Posté(e) Mars 10, 2024 ah désolé, le voici après erreur klippy (3).txt
Solution Savate Posté(e) Mars 11, 2024 Solution Posté(e) Mars 11, 2024 Il y a 13 heures, jerem59120 a dit : ah désolé, le voici après erreur klippy (3).txt 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 1
jerem59120 Posté(e) Mars 11, 2024 Auteur Posté(e) Mars 11, 2024 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 Posté(e) Mars 11, 2024 Posté(e) Mars 11, 2024 Il y a 1 heure, 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 les logs les plus récents sont en bas ... donc les erreurs sont plutôt en fin de fichier.
jerem59120 Posté(e) Mars 11, 2024 Auteur Posté(e) Mars 11, 2024 Il y a 13 heures, 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 Merci beaucoup j'ai changé de câble USB et je n'ai plus de problème pour l'instant, je continue les tests 1
jerem59120 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 (modifié) 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).txt klippy(2).txt Modifié (le) Mars 15, 2024 par jerem59120
Savate Posté(e) Mars 15, 2024 Posté(e) Mars 15, 2024 (modifié) il y a 36 minutes, jerem59120 a dit : Hier j'ai intégré le raspberry & l'écran dans la SR, le tout alimenté par l'alim Meanwell RS25-5 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 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 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 Posté(e) Mars 15, 2024 Posté(e) Mars 15, 2024 il y a 30 minutes, 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 )? 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 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 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 Posté(e) Mars 15, 2024 Posté(e) Mars 15, 2024 il y a 35 minutes, 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... 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 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 d'accord merci, donc pour toi ce fichier est bon niveau transmission de données ? klippy 1503.txt
Savate Posté(e) Mars 15, 2024 Posté(e) Mars 15, 2024 il y a 7 minutes, jerem59120 a dit : 'accord merci, donc pour toi ce fichier est bon niveau transmission de données ? 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. 1
jerem59120 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 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 Posté(e) Mars 15, 2024 Auteur Posté(e) Mars 15, 2024 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 Posté(e) Mars 16, 2024 Posté(e) Mars 16, 2024 Il y a 15 heures, 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 Rien d'anormal, c'est la procédure de démarrage normale Il y a 8 heures, jerem59120 a dit : J'ai calibré l'alimentation meanwell du rasp à 5,5V ça fait beaucoup 5.5v (je met 5.1v puisque c'est la tension officielle du pi 4)
jerem59120 Posté(e) Mars 16, 2024 Auteur Posté(e) Mars 16, 2024 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 Posté(e) Mars 16, 2024 Auteur Posté(e) Mars 16, 2024 (modifié) 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 Posté(e) Mars 16, 2024 Posté(e) Mars 16, 2024 il y a 8 minutes, jerem59120 a dit : le problème vient de là ? 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 Posté(e) Mars 16, 2024 Posté(e) Mars 16, 2024 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 1
jerem59120 Posté(e) Mars 16, 2024 Auteur Posté(e) Mars 16, 2024 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 Posté(e) Mars 16, 2024 Posté(e) Mars 16, 2024 il y a 26 minutes, jerem59120 a dit : mv: cannot move '/home/pi/KlipperScreen-Flsun-Super-Racer' to '/home/pi/KlipperScreen/KlipperScreen-Flsun-Super-Racer': Directory not empty C'est ce message : le «mv»
toonsandco Posté(e) Mars 16, 2024 Posté(e) Mars 16, 2024 Tu as tenté de faire le move en tant que sudo ?
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