Qidi X-Max3, libérée, délivrée ou comment passer tout l'écosystème Klipper en versions «full vanilla»

[V3DP]

Ca y est, elle imprime à nouveau ma reine des neiges...

Quelques soucis de macros à traiter (M141 avec une erreur de frappe, macros pour le SFS V2 qui ne prenaient que l'encoder) et un fila a renommer en filament dans le printer.cfg dans la section du client mainsail/fluidd du fait du passage à FreeDi pour l'écran, un souci sur une macro Qidi.

Le dernier point qui reste est sur Fluidd, les macros ne sont pas disponibles dans l'interface. Mais ce n'est pas bloquant, juste du confort.

 

 

[hcl28]

Salut,
@V3DP donc tu as installé un klipper à jour suivant le tuto de @fran6p, mais pour ce qui est de l'écran tu es parti sur le fichier de FreeDi, j'hésite à faire la même chose ou à partir sur la dernière version du projet FreeDi.

Tu as mis combien de temps pour faire les manipulations ?

Merci

[V3DP]

@hcl28 Oui j'ai mis à jour la machine au niveau Klipper avec le tuto de @fran6p et derrière j'ai utilisé le fichier de FreeDi, mais celui qui part d'une machine déjà sous Klipper mis à jour.

FreeDi a géré le point de la clé USB et du dongle Wifi, donc pas à refaire.

J'ai eu pas mal de soucis avec Katapult, je n'en connais pas encore la cause, mais je vais réessayer.

Le plus long est d'avoir le fichier printer.cfg et les macros qui vont bien. C'est là dessus que je passe du temps, notamment pour avoir les bons plugins (KAMP, TMC Autotune, Dynamic Macros, Shaketune, Klipper Maintenance) . Et je viens de découvrir que les macros load_filament et unload_filament posent problème avec l'interface. C'est les dernières car tout testé à maintenant.

Je dirais qu'avec un bon printer.cfg et les macros, en une petite demi journée c'est fait.

[V3DP]

@fran6p @pascal_lb Comme je suis un peu perfectionniste, je voulais voir où était le problème du flashage avec Katapult.

J'ai donc refait complètement la construction du système Armbian, Klipper et le flashage des MCU.

Donc Armbian bookworm v25, KIAUH v6 et Klipper en 0.12.0.439

Suivi de la procédure de @fran6p

J'ai par contre repris mon répertoire de config qui fonctionnait (printer.cfg + macros + scripts). Donc la définition du mcu MKS_THR est déjà faite.

Le flashage du STM32 et du Host se passent sans soucis.

Le flashage de Katapult ne se fait pas :

• Mise en mode Boot du RP2040 se fait, on le voit bien en stockage de masse et en périphérique USB comme en mode Boot
• le montage manuel du disque ne pose pas de soucis et Armbian indique de faire un systemctl daemon-reload
• la copie du .uf2 se fait, mais ne déclenche rien
• le sync ne déclenche rien et le RP2040 reste en mode boot sans se démonter.

Si par contre on flashe directement le MCU avec le code compilé, tout se passe bien comme prévu.

Début mars, j'essaierai sur ma deuxième X Max 3 qui est encore d'origine pour voir ce que donne Katapult. Je vais partir de l'image disque que je viens de créer, donc juste les flashages des MCU + FreeDi pour l'écran.

Ce que j'ai gagné en passant en open :

• Vignettes des gcodes
• le BTT SFS V2 a l'air de fonctionner à 100% du temps pour la macro de poursuite en cas de fin de filament
• l'adaptative mesh qui semblait être lié au paramétrage d'Orca, mais la commande PROBE_COUNT est maintenant reconnue
• des utilitaires en plus (va falloir que je regarde de près Shake Tune)

Merci pour le tutoriel qui est une très bonne base de travail et l'aide ce weekend !

[pascal_lb]

il y a 27 minutes, V3DP a dit :

Le flashage de Katapult ne se fait pas

Là je ne peux pas t'aider car je n'ai jamais utilisé Katapult, il n'y a que mon maître bidouille @fran6p qui peut t'aider sur ce coup là

Modifié (le) Février 18 par pascal_lb

[fran6p]

@V3DP

Katapult peut parfois être problématique à installer.

Quand tu dis ;

Citation

• la copie du .uf2 se fait, mais ne déclenche rien
• le sync ne déclenche rien et le RP2040 reste en mode boot sans se démonter.

Après le sync, avais-tu tenté comme ultime manipulation de presser le bouton RESET sur la carte ? Cette manipulation, normalement, «redémarre» la carte.

Une fois relancée, un lsusb ou plutôt un ls -l /dev/serial/by-id affiche-t-il un périphérique dont le nom contient «katapult» (usb-katapult_rp2040_xx…) ?

Si oui, alors katapult est bien installé en tant que chargeur de démarrage (bootloader). Il faut ensuite construire le firmware klipper en précisant qu'il doit s'installer avec un décalage d'adresse ( 16 Ko ), puis le flasher via le script Python de Katapult (flashtool.py).

Tu peux aussi, comme tu as dû le faire, installer directement le firmware Klipper. L'inconvénient est juste qu'au cas où une mise à jour des firmwares Klipper doive être faite, il faudra démonter le capot arrière de la tête pour pouvoir presser le bouton BOOTSEL. Katapult ajoute simplement un peu de praticité… à condition qu'il veuille bien s'installer.

Juste une dernière remarque, mais tu l'avais déjà indiqué précédemment, la puce sur la carte est bien un RP2040 ?

Le meilleur guide sur Katapult est celui d'Esoteric

Un autre moyen de flasher le firmware Katapult est celui de ce lien (une fois la carte passée en mode BOOT). Comme ça fait déjà de nombreux mois que ma XM3 a été modifiée, si je devais le refaire, c'est plutôt cette méthode que j'emploierais.

 

Modifié (le) Février 18 par fran6p

[V3DP]

il y a 27 minutes, fran6p a dit :

Une fois relancée, un lsusb ou plutôt un ls -l /dev/serial/by-id affiche-t-il un périphérique dont le nom contient «katapult» (usb-katapult_rp2040_xx…) ?

Non j'ai fait reboot complet de la machine.

il y a 27 minutes, fran6p a dit :

Tu peux aussi, comme tu as dû le faire, installer directement le firmware Klipper. L'inconvénient est juste qu'au cas où une mise à jour des firmwares Klipper doive être faite, il faudra démonter le capot arrière de la tête pour pouvoir presser le bouton BOOTSEL. Katapult ajoute simplement un peu de praticité… à condition qu'il veuille bien s'installer.

C'est bien pour cela que j'aimerais bien faire marcher Katapult.

il y a 27 minutes, fran6p a dit :

katapult est bien installé en tant que chargeur de démarrage (bootloader). Il faut ensuite construire le firmware klipper en précisant qu'il doit s'installer avec un décalage d'adresse ( 16 Ko ),

Donc si je ressors mes souvenirs sur le microprocesseur, Katapult est un bootloader, donc doit s'installer sur les 16 premiers Ko de la mémoire, et le fw Klipper sur les Ko restants (pour faire simple, on oublie les pages mémoires)

Dans ce cas, pourquoi préciser dans la compilation de Katapult qu'il y a un bootloader et faire faire un décalage de 16 Ko ? La carte ne peut pas booter vu qu'il n' y a plus de séquence de boot utilisable après le flash de Katapult ...

Cette config pour la compilation est donnée également par leadustin.

Ca m'est venu au déjeuner. J'irai voir le guide d'Esoteric ce soir.

Modifié (le) Février 18 par V3DP

[fran6p]

il y a 11 minutes, V3DP a dit :

Dans ce cas, pourquoi préciser dans la compilation de Katapult qu'il y a un bootloader et faire faire un décalage de 16 Ko ? La carte ne peut pas booter vu qu'il n' y a plus de séquence de boot utilisable après le flash de Katapult ...

C'est le principe d'ex CANBOOT (Katapult): c'est un chargeur de démarrage. Seul, il ne démarre que sur lui-même, ce qui ne sert pas à grand-chose. Un firmware doit lui être adjoint (le décalage d'adresse) pour booter sur ce firmware.

En tout cas, c'est ainsi que je comprends Katapult.

 

[V3DP]

@fran6p Nous sommes d'accord sur le role de Katapult.

Dans ce cas, je verrais plutôt la préparation du FW de Katapult sans décalage et celle du FW de Klipper avec un décalage, de manière que Katapult démarre et lance le FW Klipper.

Actuellement les 2 ont un décalage d'adresse d'après les différents githubs sur l'upgrade des Qidi.

J'ai trouvé une différence entre les fw Katapult utilisés entre le GitHub de @fran6p et celui de leadustin.

fran6p : 

sudo cp /home/mks/katapult/out/katapult.uf2 /mnt

leadustin :

 

sudo cp out/katapult.withclear.uf2 /mnt

les deux fichiers sont bien générés lors de la compilation.

 

 

[fran6p]

il y a 15 minutes, V3DP a dit :

Dans ce cas, je verrais plutôt la préparation du FW de Katapult sans décalage et celle du FW de Klipper avec un décalage, de manière que Katapult démarre et lance le FW Klipper.

C'est exactement ce que font les directives de compilation  

Les choix de compilation pour Katapult sont bien :

Citation

choisir les options

• Raspberry Pi RP2040
• build Katapult deployment application (16 KiB booloader)
• communication interface (USB)

La deuxième ligne ne dit pas de compiler avec un décalage de 16 Ko, mais de construire l'application de déploiement (pour le firmware Klipper) dans les 16 premiers Ko pour servir de bootloader. C'est le firmware Klipper qui lui doit être construit après ce décalage de 16 Ko. Firmware Klipper qui sera lancé par le chargeur de démarrage de Katapult.

 

[V3DP]

@fran6p Après plusieurs tentatives j'ai finalement réussi à installer Katapult.

La méthode https://canbus.esoterical.online/toolhead_flashing.html#rp2040-based-boards n'a pas foncitonné, j'avais une erreur sur une librairie manquante.

La méthode qui a marchée est celle de ton GitHub, mais après deux tentatives de compilation / copie (le RP2040 restait en mode Boot).

Finalement Katapult s'est installé et après quelques secondes, le RP2040 s'est affiché en Open Moko ....

Le flashage de Klipper a été un jeu d'enfant derrière.

Modifié (le) Février 18 par V3DP

[fran6p]

 

  

 

[V3DP]

Retour d'expérience après un petit 3 semaines d'utilisation de ma X Max 3 libérée et l'écran tactile FreeDi.

Tout marche plutôt bien : l'écran fonctionne sans soucis, le capteur BTT SFS V2 ne pose plus de soucis de poursuite x mm après la fin de filament et pas de soucis sur les différents affichages depuis Orca.

J'ai du reprendre le idle timeout à 24h car j'avais une mise en idle lors d'une pause suite à une fin de filament de nuit.

Reste quelques soucis mineurs / améliorations :

- le script clean-backup.sh ne trouve pas les fichiers de backup à déplacer et fait une erreur non bloquante

- la macro load filament modifie la température de la buse lors d'un changement de filament en cours d'impression

- la macro unload filament ne met pas en chauffe la buse

- la macro pause n'arrête pas la chauffe de la buse

- la macro resume ne remet pas en chauffe la buse à la température d'impression.

Dès que ces derniers points sont réglés, je libère la deuxième X Max 3

[V3DP]

Le script clean-backup.sh qui fait partie du package zippy fonctionne ! J'ai mis les dernières versions, corrigé les chemins d'accès et donné les permissions qui vont bien....

J'ai installé time-lapse sur moonraker sans aucune dificulté et fait les mises à jour, sauf celle de Klipper qui a pas beaucoup bougé. Je me demande si monter de version Klipper de x.x.x.y ne va pas nécessiter de flasher à nouveau tout les composants....

Dès que j'ai un peu de temps, je m'attaque aux macros load/junload et pause/resume.

Modifié (le) Mars 14 par V3DP

[fran6p]

Il y a 17 heures, V3DP a dit :

Je me demande si monter de version Klipper de x.x.x.y ne va pas nécessiter de flasher à nouveau tout les composants....

La plupart du temps, non. Je n'ai eu à reflasher aucun «mcu» depuis la libération de ma XM3 (version Klipper actuelle : v0.12.0-177-gaf149b47).

Mais ça pourrait arriver, auquel cas, tu aurais un «beau» message dans Fluidd ou Mainsail.

 

[V3DP]

Ca y est ! Tout marche comme je veux maintenant !

Les dernières macros qui ne marchaient pas bien sont revues :

• load et unload gèrent la mise en chauffe et l'arrêt ou la remise à la température initiale
• pause et resume gèrent l'arrêt et la remise en chauffe de la hotend

Je revois le script d'install de HID Flasher pour éviter d'ouvrir le compartiment de la carte pour flasher et j'essaye sur ma première X Max 3 qui n'est pas encore libérée.

Si ça marche, tout pourra être mis à jour (avec la tête sous Katapult) depuis l'ordinateur.

[V3DP]

Je viens de libérer ma deuxième X Max 3. Pas sans mal et pas tout à fait comme prévu.

J'avais prévu de passer par un clone de l'eMMC de la première, de flasher les MCU, de flasher l'écran avec la procédure FreeDi et de mettre à jour le printer.cfg (adresses des MCU, paramètres de PiD).

Au boot après mise en place de l'eMMC, l'écran a été flashé avec le FW FreeDi et la machine est restée plantée sans accès SSH ou web. A voir il y a un souci avec l'écran dans ce cas et certains services (ceux de FreeDi ?) ne démarrent pas et bloquent le boot. L'écran boote et reste en attente de connexion à Klipper.

Donc reconstruction de l'image suivant le tutoriel de @fran6p et reprise des fichiers de configuration de la première machine après avoir mis à jour le printer.cfg avec les paramètres de la deuxième machine.

Pour FreeDi, pas de soucis, il a reflashé l'écran malgré la première tentative.

Pour le flashage de la carte mère, j'ai essayé HID Flash, sans plus de succès que sur la première machine. Donc passage par la case microSD.

Pour le flashage de la tête, à nouveau des soucis avec Katapult, impossible de flasher la carte avec le bootloader, malgré de nombreux essais (avec arrêt de Klipper, sans, passage en BootSel avec un boot - reset, ....). Donc flashage en direct de la tête sans bootloader et plus de soucis.

Un reboot pour la reconnection de l'écran (qui veut bien se faire une fois toutes les MCU à jour), puis les calibrations du Z offset, Input shaping et mesh bed leveling.

Elle est à nouveau prête à imprimer !

Le  flashage de Katapult est toujours aussi aléatoire. Faut-il effacer la mémoire du RP2040 avant de flasher le bootloader ?