Mise à jour entrainant une charge à 100% de la emmc. Qidi x-plus 3

[Noob3D]

Bonjour,

Ce poste est à titre informatif. Je donnerai suite aux réponses du SAV Qidi dans ce post.

J'ai réalisé la mise à jour de ma Qidi X-Plus 3 hier soir, passant de la version 4.2.12 à la version 4.2.13. Cette mise à jour a entraîné une charge à 100 % de l'eMMC, ce qui a pour effet de rendre l'imprimante non fonctionnelle. Il est impossible de récupérer les températures de la buse ou du lit... Aucune idée de ce qui a pu créer ce bug, il me restait 1,5 Go sur l'eMMC avant l'installation de la mise à jour.

La solution est de flasher la carte mère Qidi avec un OS vierge, mais il est impossible de le trouver l'os et la marche à suivre.

Donc, c'est parti pour un ticket de support chez Qidi pour éviter des bidouilles qui ferons sauter la garantir.

 

Théo

Modifié (le) Mai 19 par Noob3D

[pjtlivjy]

@Noob3D effectivement c'est un sacré problème , je vais suivre avec attention la réponse sachant que sur ma x-max3 j'ai mis leur EMCC de 32 Go, fait la mise à jour et pas eu de problème. 

[Noob3D]

Imprimante réparée par mes soins. J'attends quand même une réponse du support.

La solution fut l'installation de l'image 4.2.13 récupérée sur leur site (ou Reddit, je ne m'en souviens plus) et non GitHub. Après cela, l'imprimante est de nouveau fonctionnelle. J'ai aussi remarqué que le fichier klippy.log pesait 1,9 Go. J'ai réalisé un sudo rm -rf ./klippy.log puis un touch klippy.log. Bim, de pas de place à beaucoup de place.

Par sécurité (je n'aime utiliser des fichiers provenant de reddit), je vais refaire une update vers 4.2.13 récupérées sur le site de Qidi.

Donc, imprimante fonctionnelle et opérationnelle. Je vais tester avec une impression.

Modifié (le) Mai 19 par Noob3D

[pjtlivjy]

bonne nouvelle @Noob3D, leur réponse va être intéressante effectivement parce qu'une telle manip n'est pas à la portée de l'utilisateur lambda 

[Noob3D]

Oui clairement, et c'est par hasard que j'ai trouvé que le fichier de log avait une taille gargantuesque. Compte tenu que le fichier n'est pas dans /tmp, il n'est pas supprimé à chaque restart. Je pense que c'est une vraie faille dans l'architecture klipper. Il fait déjà 2 mo ...

Modifié (le) Mai 19 par Noob3D

[Noob3D]

Réponse du support ce matin.

Ils m'ont transmis un document qui montre comment supprimer le dossier contenant le gcode par ligne de commande. Ils m'ont aussi demandé des références de la machine. J'ai coupé court en indiquant que j'avais résolu le problème. Je les ai informés du problème de fichier klippy.log trop volumineux.

[pjtlivjy]

salut @Noob3D en espérant que ta remonté d'information leur soit profitable.

pourrais tu partager ce document ?

[Noob3D]

Bien-sur, le voici.

 

recovery the gcode folder.pdf

[pjtlivjy]

super, hop dans les archives en espérant que ça ne serve jamais 

[fran6p]

Peut-être aller regarder du côté de la rotation des journaux, non ? (logrotate toussa) (pas de configuration implémentée pour Klipper, Moonraker, Fluidd, Mainsail, …)

Si Crowsnest est installé, on peut s'aider du fichier /etc/logrotate.d/crowsnest pour faire tourner les serviettes journaux de klipper et moonraker par exemple :

mks@mkspi:~$ cat /etc/logrotate.d/crowsnest
# crowsnest logrotate file
#### crowsnest - A webcam Service for multiple Cams and Stream Services.
####
#### Written by Stephan Wendel aka KwadFan <me@stephanwe.de>
#### Copyright 2021 - 2022
#### https://github.com/mainsail-crew/crowsnest
####
#### This File is distributed under GPLv3
####

/home/mks/printer_data/logs/crowsnest.log {
compress
rotate 3
missingok
notifempty
copy
daily
dateext
dateformat .%Y-%m-%d
maxsize 4M
}
mks@mkspi:~$

Il suffirait de créer les fichiers klipper / moonraker puis copier de /home/mks/… jusqu'à } en remplaçant pour chaque fichier créé (klipper|moonraker) le fichier journal du chemin d'accès :

/home/mks/printer_data/logs/klippy.log  (moonraker.log)

Révélation

mks@mkspi:~/printer_data/logs$ cat /etc/logrotate.d/klipper
# klipper logrotate file
/home/mks/printer_data/logs/klippy.log {
compress
rotate 3
missingok
notifempty
copy
daily
dateext
dateformat .%Y-%m-%d
maxsize 4M
}
mks@mkspi:~/printer_data/logs$ cat /etc/logrotate.d/moonraker
# Moonraker logrotate file
/home/mks/printer_data/logs/moonraker.log {
compress
rotate 3
missingok
notifempty
copy
daily
dateext
dateformat .%Y-%m-%d
maxsize 4M
}

 

Ainsi les journaux ne pourraient plus grossir indéfiniment.

Ou encore en utilisant GCode shell command et en écrivant un script shell pour «nettoyer» les archives des journaux.

L'OS est un Linux donc on peut quasiment tout faire avec

Pour l'écriture de ces éventuels fichiers, à faire en tant que «maitre tout puissant des lieux (root)» donc sudo nano …

PS:

Mes chemins d'accès (~/printer_data/logs) correspondent à ma configuration actuelle (Armbian Bookworm + écosystème Klipper «officiel»), Pour la version Qidi, les chemins d'accès sont plutôt ( ~/klipper_logs)avec  ~ <=> /home/mks

Il y a 22 heures, pjtlivjy a dit :

hop dans les archives

Si tu en veux encore plus: https://drive.google.com/drive/folders/1oOBPgxhqPG-WALbQCwg4BVuN9feDIop3

La plupart des documents / vidéos du SAV pour la X-Max 3 (plus de 5 Go)

Modifié (le) Mai 21 par fran6p