[Qidi Q2] impossible de générer les graphes Klippain CREATE_VIBRATIONS_PROFILE

[tranbert]

Bonjour,

Est-ce depuis la mise à jour de la semaine dernière ou autre, en tout cas la génération des graphes CREATE_VIBRATIONS_PROFILE chez moi ne se termine pas, j'ai un reboot systématique juste avant la fin. Avant cela, c'était la loterie, mais souvent ça passait... Les autres graphes sont bons.

Les datas sont bien générées. J'ai vu dans le sujet "au long cours" que l'on pouvait générer les graphes, moyennant un peu d'ajout de trucs qui manquent... mais je n'ai pas encore testé.

Avez-vous le même comportement ? Et sinon une idée pour y arriver ?

• reboot juste avant de lancer la macro : testé, pas mieux
• suivre en ssh la génération sans lancer l'interface web : en cours, n'a pas encore planté...
• désactiver les process inutiles https://github.com/bluedrool/Qidi-Q2-tuning-tweaks-and-mods/blob/main/docs/processes.md pas testé encore 

Ha tiens donc... dans /var/log/messages

Oct 16 09:31:13 qidiq2 kernel: [ 4119.100658] EXT4-fs warning (device mmcblk0p6): ext4_dirblock_csum_verify:402: inode #326863: comm f                                                    ind: No space for directory leaf checksum. Please run e2fsck -D.

Je ne sais pas si cela a un rapport, mais j'aime modérément...

 

[V3DP]

Il y a 1 heure, tranbert a dit :

Je ne sais pas si cela a un rapport, mais j'aime modérément...

Un petit souci d'eMMC ?

[tranbert]

il y a 5 minutes, V3DP a dit :

Un petit souci d'eMMC ?

Ben oui, j'imagine, et comme ce n'est pas amovible, je ne suis pas super super rassuré 

mks@qidiq2:~$ sudo  e2fsck -n  /dev/mmcblk0p6
e2fsck 1.46.2 (28-Feb-2021)
Warning!  /dev/mmcblk0p6 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/mmcblk0p6 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 2757 was part of the orphaned inode list.  IGNORED.
Inode 2758 was part of the orphaned inode list.  IGNORED.
Deleted inode 134521 has zero dtime.  Fix? no

Deleted inode 134675 has zero dtime.  Fix? no

Deleted inode 134706 has zero dtime.  Fix? no

Inode 262354 was part of the orphaned inode list.  IGNORED.
Inode 285364 was part of the orphaned inode list.  IGNORED.
Inode 285814 was part of the orphaned inode list.  IGNORED.
Deleted inode 297237 has zero dtime.  Fix? no

Inode 297251 was part of the orphaned inode list.  IGNORED.
Inode 297255 was part of the orphaned inode list.  IGNORED.
Inode 297265 was part of the orphaned inode list.  IGNORED.
Inode 297267 was part of the orphaned inode list.  IGNORED.
Inode 297269 was part of the orphaned inode list.  IGNORED.
Inode 297273 was part of the orphaned inode list.  IGNORED.
Inode 297275 was part of the orphaned inode list.  IGNORED.
Inode 297279 was part of the orphaned inode list.  IGNORED.
Inode 297283 was part of the orphaned inode list.  IGNORED.
Inode 297287 was part of the orphaned inode list.  IGNORED.
Inode 297299 was part of the orphaned inode list.  IGNORED.
Inode 297321 was part of the orphaned inode list.  IGNORED.
Inode 299221 was part of the orphaned inode list.  IGNORED.
Inode 299239 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Directory inode 324801, block #0, offset 0: directory corrupted
Salvage? no

e2fsck: aborted

/dev/mmcblk0p6: ********** WARNING: Filesystem still has errors **********

 

Modifié (le) il y a 22 heures par tranbert

[V3DP]

il y a 3 minutes, tranbert a dit :

Ben oui, j'imagine, et comme ce n'est pas amovible, je ne suis pas super super rassuré 

C'est plus simple à régler avec une eMMC amovible, on peut monter la partition sur un linux localement, faire un backup / restore et tenter une réparation.

@fran6p a peut-être une idée pour faire une image du système (et la remettre au besoin) si fsck ne s'en sort pas et vérole la partition.

[tranbert]

il y a 4 minutes, V3DP a dit :

@fran6p a peut-être une idée pour faire une image du système (et la remettre au besoin) si fsck ne s'en sort pas et vérole la partition.

Oui, je pensais forcer un fliesytem check au reboot, mais elle marche, la bête, je ne veux pas me retrouver avec un presse-papier de luxe (c) (tm) si ça foire.

J'ai fait un mail au support, on ne sait jamais, ils vont peut-être m'envoyer une autre imprimante

edit  : J'ai vu passer quelque part qu'il y avait un client pour proxmox backup qui marchait, ça tombe bien j'ai ça à côté/ Je vais voir...

Il y a 1 heure, tranbert a dit :

désactiver les process inutiles https://github.com/bluedrool/Qidi-Q2-tuning-tweaks-and-mods/blob/main/docs/processes.md pas testé encore 

Ha tiens, c'est passé une fois les modification appliquées. Je vais re re  tester pour éliminer le coup de bol.

Modifié (le) il y a 22 heures par tranbert

[fran6p]

La vérification du système (fsck) se fait toujours sur une partition démontée sauf à vouloir empirer les choses (heureusement l'option -n a été utilisée ).

Je viens de vérifier mon système (pas d'erreurs du système de fichiers) :

mks@linaro-alip:~$ sudo e2fsck -n /dev/mmcblk0p6
[sudo] password for mks:
e2fsck 1.46.2 (28-Feb-2021)
Warning!  /dev/mmcblk0p6 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/mmcblk0p6: clean, 132226/1901280 files, 1940972/7629307 blocks

Bien que le système installé soit une Debian (v11 / Bullseye), le contrôleur est un Rockchip donc un ARM. Le démarrage de ce type de processeur est différent d'un contrôleur / processeur « classique » genre PC. Ce que j'expliquais pour un processeur Allwinner utilisé dans une SonicPad reste valable (voir ici).

En gros, on ne peut modifier comme sur un système Linux « classique » les paramètres de démarrage. Exemple avec un RPi et une Debian où là il est possible de modifier le fichier cmdline.txt (console=serial0,115200 console=tty1 root=PARTUUID=f19e5c12-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=FR) pour avoir une vérification automatique du système de fichiers à chaque démarrage.

Le daemon à absolument arrêter est celui qui gère « l'IA » (algo_app), il accapare au minimum la moitié de la RAM (512 Mo installés, moins de 480 Mo disponibles et encore moins quand "algo_app" tourne en tâche fond => sudo systemctl stop algo_app && sudo systemctl disable algo_app).

Au cas où tu devrais réinstaller le système, Qidi fournit un lien Gdrive avec l'image système (.img), les outils RKDevTool et un document (succinct) pour procéder à la manipulation (nécessite d'accéder à la carte interne (X-9-1) et son port USB-C). Je ne peux fournir le lien, mais une demande étayée au SAV devrait permettre de l'obtenir.

 

 

 

Modifié (le) il y a 16 heures par fran6p

[tranbert]

il y a 25 minutes, fran6p a dit :

Le daemon à absolument arrêté est celui qui gère « l'IA », il accapare au minimum la moitié de la RAM (512 Mo installés, moins de 480 Mo disponibles et encore moins quand "algo_app" tourne en tâche fond => sudo systemctl stop algo_app && sudo systemctl disable algo_app).

Oui merrci, c'est fait et effectivement depuis je peux récupérer les graphes. Vu mes tests de mousse, c'est utile.

 

il y a 25 minutes, fran6p a dit :

Au cas où tu devrais réinstaller le système, Qidi fournit un lien Gdrive avec l'image système (.img), les outils RKDevTool et un document (succinct) pour procéder à la manipulation (nécessite d'accéder à la carte interne (X-9-1) et son port USB-C). Je ne peux fournir le lien, mais une demande étayée au SAV devrait permettre de l'obtenir.

On va espérer y échapper, pour l'instant le principal, c'est qu'elle imprime.

J'ai envoyé un mail détaillé au support justement pour voir ce qu'ils vont en dire.

Révélation

Gardez-la, on vous en envoie une autre 

 

il y a 28 minutes, fran6p a dit :

Je viens de vérifier mon système (pas d'erreurs du système de fichiers) :

C'est une honte.

[fran6p]

La plupart de mes matériels informatiques et quelques imprimantes 3D sont derrière des onduleurs. Hormis quelques matériels (les imprimantes 3D malheureusement), l'arrêt des systèmes se fait proprement (shudown) pas à l'arrache.

Ça vaudrait le coup de l'implémenter sur nos imprimantes (faisable via des scripts car Gcode shell command est déjà installé et utilisé pour la reprise après coupure de courant (plr.cfg) ). C'est ce que j'avais plus ou moins fait sur la XMax3 avec le Klipperscreen installé sur un RPi0-v2 (explications là).

 

 

Modifié (le) il y a 16 heures par fran6p

[tranbert]

il y a 43 minutes, fran6p a dit :

La plupart de mes matériels informatiques et quelques imprimantes 3D sont derrière des onduleurs. Hormis quelques matériels (les imprimantes 3D malheureusement), l'arrêt des systèmes se fait proprement (shudown) pas à l'arrache.

Ici il y a même un powerpack "in line" en plus de l'onduleur qui permet de travailler 3-4 heures si ça se gâte. Moins si on connecte le congélo. Mais malheureusement ça n'évite pas l'arrêt via le bouton on/off de l'imprimante.

il y a 43 minutes, fran6p a dit :

Ça vaudrait le coup de l'implémenter sur nos imprimantes

On peut le faire sous Home assistant sans toucher aux fichiers de l'imprimante ?

Vu qu'il y a déjà une liaison "forte" entre les deux. Je vais creuser tiens.

 

[Savate]

il y a 7 minutes, tranbert a dit :

Mais malheureusement ça n'évite pas l'arrêt via le bouton on/off de l'imprimante.

octoprint a un plugin nut pour gérer les infos d'un onduleur et faire la ou les actions nécessaires.
(bon  il faut installer nut sur le pi, mais ce n'est pas très compliqué)

[fran6p]

Je vois que tu utilises l'intégration Moonraker dans HA .

[tranbert]

il y a 28 minutes, fran6p a dit :

Je vois que tu utilises l'intégration Moonraker dans HA .

Oui, et je pense que ce truc peut aider : 

[fran6p]

Teste d'abord si l'arrêt du système est fonctionnel via Fluidd .

Il me semble que la dernière fois que j'avais testé, ça n'arrêtait pas le système, le reboot lui par contre fonctionnait .

Je suis encore néophyte avec HA. Quelle carte as-tu utilisée pour la section qidi-q2 dans HA ?

Modifié (le) il y a 14 heures par fran6p

[tranbert]

il y a 13 minutes, fran6p a dit :

Teste d'abord si l'arrêt du système est fonctionnel via Fluidd .

Il me semble que la dernière fois que j'avais testé, ça n'arrêtait pas le système, le reboot lui par contre fonctionnait .

A priori ça arête des choses, car à part les leds et la ventilation de base qui restent actives, plus aucun signe de vie de la Q2...

Ssh plus rien. Ping rien non plus. Ecran q2 noir.

Rien dans /var/log/messages par contre, ça c'est moins bien.

edit : Même comportement que via Fluidd cela dit...

edit 2 : même comportement via ssh sudo poweroff

Modifié (le) il y a 14 heures par tranbert

[V3DP]

A voir la fin de la discussion, on ne peut pas simplement appuyer sur le bouton "AZ5" pour arrêter l'imprimante 

J'avoue que je suis gros bourrin avec mes X Max 3, quand la machine est idle, je coupe à l'interrupteur derrière et pour l'instant pas de soucis avec mes eMMC (bon j'en ai plusieurs et j'ai une image prête à flasher et des sauvegardes du printer_data/config).

Il faudrait faire autrement ?

[tranbert]

Réponse du support Qidi cette nuit qui me demande "si j'ai modifié Klipper".

Ce à quoi j'ai très gentiment répondu que non, vu qu'ils l'avaient déjà modifié sans expliquer où/quand/comment, je ne pouvais pas m'amuser à toucher à "leur" klipper...

2ᵉ round à suivre cette nuit...