pascal_lb

@LeSprinter je déplace dans la bonne section

Voilà c'est ça, avec un peu de force, pas trop serré et pas trop lâche il faut trouver un juste milieu, ce n'est pas facile de donner une indication précise...

RAPPEL La carte mère «tout-en-un» s'occupe à la fois du fonctionnement de Klipper (klippy) via le système d'exploitation et de la gestion matérielle (voir ce sujet pour plus d'explications si besoin) via les firmwares installés sur chaque MCU. Les deux unités ci-dessous communiquent via une liaison série directement câblée. une unité de calcul (SBC) une unité de contrôle (MCU) Jusqu'à maintenant, on s'est occupé de la partie «unité de calculs» installée sur le système d'exploitation, il reste la partie MCU à mettre en place. FIRMWARE KLIPPER FIRMWARE, GÉNÉRALITÉS Pour chacun des contrôleurs (MCU): principal secondaire (la tête «MKS-THR») Linux les étapes à suivre sont quasi identiques: se placer dans le répertoire Klipper du dossier personnel de l'utilisateur «mks»: cd ~/klipper ou cd /home/mks/klipper ou si on est déjà dans le dossier perso cd klipper ou cd ./klipper configurer le firmware: make menuconfig dans la fenêtre de configuration, sélectionner les paramètres adéquats (dépend de chaque MCU) sauvegarder cette configuration préparer la compilation: make clean compiler: make (le microcontrôleur RK3328 possédant plusieurs cœurs, utiliser une compilation parallèle à l'aide de make -j4) à l'issue de la compilation, récupérer le firmware dans le dossier out (~/klipper/out/). Le nom du fichier compilé dépend des directives de compilation ( klipper.bin / klipper.uf2 / klipper.elf ) flasher ce firmware sur le MCU ( la méthode dépend du MCU à flasher ) Connaissant le principe, on va pouvoir entrer dans les détails. PRÉREQUIS Quelques outils sont nécessaires: clés Allen Fer à souder maxi 30w Etain avec âme décapante Cable USB / carte μSD, clé USB ou adaptateur USB/μSD logiciels: pour l'accès distant (SSH) pour le transfert de fichiers entre matériels en réseau PRÉPARATION MATÉRIELLE Imprimante éteinte accéder au dessous de l'imprimante pour retirer les vis du capot renfermant l'électronique retirer ce capot Mettre sous tension l'Imprimante accéder à l'aide d'un client SSH à l'imprimante via son adresse IP se connecter en utilisateur mks (mot de passe par défaut si inchangé: makerbase) se déplacer dans le dossier klipper cd klipper vérifier que l'on est dans le dossier correct pwd MCU PRINCIPAL Configurer le firmware Klipper Connecté en ssh, lancer la suite de commandes: cd ~/klipper make clean make menuconfig Le menu de configuration du firmware apparait, choisir les options : cocher «Enable extra low-level» STMicroelectronic STM32 comme famille de contrôleur Processor model (STM32F401) (le STM32F402 de la carte en est un ) Bootloader offset (32 Kio bootloader) Communication interface (USB (on PA11/PA12) Au final, la configuration complète doit être comme ci-dessous : une fois ces options sélectionnées, presser Q pour sortir de ce menu, valider par Y pour sauvegarder la configuration Compiler compiler le firmware (utiliser une compilation parallèle à l'aide de plusieurs cœurs du contrôleur RK3328 => paramètre -j4) make -j4 attendre que le processus se termine Le firmware compilé se trouve dans le dossier ~/klipper/out et porte le nom klipper.bin Flasher le firmware Le processus de flashage utilise une carte μSD (formatée FAT32 d'une capacité de moins de 32 Go) introduite dans le lecteur de carte μSD situé sur la carte mère Important Pour que le flashage réussisse, le fichier klipper.bin doit porter un nom précis : mks_skipr_mini.bin Important Reste à récupérer ce fichier, le renommer puis le copier à la racine de la carte μSD Récupérer (télécharger) le firmware Plusieurs méthodes permettent de le faire : le copier dans le répertoire de configuration de Klipper (~/printer_data/config) c'est la méthode que j'ai utilisé cp ~/klipper/out/klipper.bin ~/printer_data/config/mks_skipr_mini.bin Le récupérer ensuite en utilisant Fluidd (clic droit sur le fichier, télécharger) le mettre à disposition sur le réseau local via Python qui possède un serveur web python3 -m http.server -d "/home/mks/klipper/out" 8888 Une fois le serveur lancé sur le port utilisé dans la commande précédente (8888): - via un navigateur, accéder à l'adresse http://adresse-ip-imprimante:8888 - récupérer le fichier klipper.bin - le renommer en mks_skipr_mini.bin - le copier sur la carte μSD - CTRL + C pour interrompre et quitter le serveur Web Si Samba a été ajouté au système, on peut accéder au répertoire personnel de l'utilisateur «mks» à partir de l'explorateur de fichiers Si l'automontage de périphériques de stockage a été installé sur le système, utiliser une clé USB adaptateur SD après l'avoir insérée : cp ~/klipper/out/klipper.bin ~/printer_data/gcodes/USB/mks_skipr_mini.bin Procéder au flashage une fois le fichier mks_skipr_mini.bin recopié à la racine de la carte μSD: introduire celle-ci dans le lecteur de carte allumer l'imprimante (si elle était allumée, l'éteindre et patienter au moins 30 secondes, le temps que le supercondensateur se décharge, allumer alors) Patienter (très peu de temps), le temps que le processus de flashage se termine Ce tuto n'est pas encore terminé, la suite va arriver bientôt

Le système d'exploitation est fin prêt à accueillir les applications composant l'écosystème Klipper. La base étant Klipper lui-même, Moonraker pour communiquer avec Klipper, une (ou les deux) interface Web (Fluidd / Mainsail) communiquant avec Moonraker pour afficher les informations et piloter l'imprimante. Pour réaliser ces installations, le moyen le plus simple à ce jour est d'utiliser la suite de scripts shell fournie par KIAUH KIAUH (Klipper Installation And Update Helper) Grâce à celui-ci, il est possible d'installer, de mettre à jour, de supprimer des éléments de la suite, juste en choisissant les bonnes options. On commence par récupérer le dépôt Github de cet outil puis on exécutera son script shell. 1. installer le paquet "git" (au cas où il serait absent (ce qui ne devrait pas être le cas avec l'installation de la distribution Armbian Bookworm) sudo apt update && sudo apt install -y git 2. cloner le dépôt KIAUH cd && git clone https://github.com/dw-0/kiauh.git L'installation en détail 3. Exécuter le script ~/kiauh/kiauh.sh La première fenêtre donne accès au menu principal Rien n'est encore installé. Choisir l'option 1) [Install] pour accéder au menu des installations Installer dans l'ordre : Klipper Moonraker Mainsail Fluidd KLIPPER Après sélection de l'option (1), choisir la version de Python (v3 recommandée et de toute façon il n'y a pas de Python v2 installé avec la distribution Armbian Bookworm) Nombre d'instances de Klipper (plusieurs imprimantes) L'installation se déroule Le retour au menu principal nous confirme l'installation, le nombre d'instance, la version de Python et le dépôt installé MOONRAKER Choix du menu d'installation des composants, puis choix (2) pour l'installation de Moonraker. L'installation détecte seule combien d'instances Klipper ont été installées (ici, une seule) puis préparer son environnement Retour au menu principal, cette fois Moonraker est signalé comme installé INTERFACES d'ACCÈS WEB Interfaces Web permettant l'accès à partir d'un navigateur Internet à Klipper via les APIs de Moonraker choix (3) pour Mainsail et (4) pour Fluidd. On peut n'en installer qu'une des deux, l'installation de la première, par défaut, communiquera avec le port HTTP standard (80). Pour la seconde, il faudra fournir un autre numéro de port. MAINSAIL Lors de cette première installation, répondre Yes (Oui) à la demande d'installation des macros «client» (PAUSE, RESUME, …) Mainsail installé FLUIDD Mainsail (si installé en premier) utilise le port standard HTTP (80), il est nécessaire d'en indiquer un différent pour l'accès à Fluidd (Qidi Tech utilise le port 10088). Normalement, Mainsail ayant déjà été installé, les macros (client.cfg) indispensables ont elles-aussi été ajoutées, inutile de les réinstaller pour Fluidd (répondre Non à la demande d'installation). Ces deux interfaces Web utilisent désormais les mêmes macros (PAUSE, RESUME. …). A l'issue de ces installations: ----------------------------------------------------------------------- Installations facultatives mais bien pratiques ----------------------------------------------------------------------- CROWSNEST Crowsnest est responsable de la configuration et du contrôle des webcams (même en l'absence de caméra, autant l'installer de suite). Crowsnest installé NOTE IMPORTANTE Un redémarrage du système sera nécessaire pour prendre pleinement en compte cette installation de Crowsnest GCODE SHELL COMMAND Permet d'étendre les fonctionnalités des macros G-code en utilisant des scripts shell. Choix (4) du menu principal puis dans le nouveau menu choix (8) A la fin de ces installations, l'écosystème Klipper est prêt. Mon eMMC de 8Go est occupée à plus de 60%, il reste encore plus de 2.5Go disponibles (avec le système originel, on disposait de moins de 1Go). NOTE IMPORTANTE Le menu principal affiche ce qui a été installé, le choix (2) permet de vérifier les versions des composants que l'on pourra mettre à jour si besoin Les premières tentatives d'accès que ce soit avec Fluidd ou Mainsail affichent des messages d'erreurs Mainsail Fluidd Le fichier de configuration, printer.cfg installé par Klipper est minimaliste, vous devez le remplacer par le fichier printer.cfg que vous avez sauvegarder avant toute cette installation avec Fluidd ou Mainsail, vous devez également ajouter ces 2 fichiers : MKS_THR.cfg et include MCU_ID.cfg Après enregistrement et redémarrage les erreurs sont plus précises, vous avez : Là il vous indique tout simplement qu'avec la dernière version de Klipper v0.12 les firmware ne sont pas à jour --------------------------------------------------------------- Mainsail (et Fluidd) possède une bonne documentation. Ce lien (Mainsail) explique la raison de ce message d'erreur «MCU protocol error»: De temps en temps, des changements sont réalisés dans la communication Klipper entre l'hôte et le MCU. Cela nécessite de mettre à jour tous vos MCU pour corriger l'erreur de communication. --------------------------------------------------------------- Le firmware Klipper n'est à jour sur aucun des MCUs utilisés. Le dépôt Klipper a installé une version 0.12.x alors que les firmwares Klipper flashés sur les MCUs sont en version 0.10.x (version utilisée par Two Trees). Il reste à installer le firmware Klipper sur les MCU (Micro Controler Unit) de l'imprimante : carte contrôleur (STM32F402) la carte MKS-THR de la tête (RP2040) le Linux MCU (nommé fréquemment «rpi»)

Bonjour @s_ghislain bienvenue chez les imprimeurs fous

J'ai vu ça aussi, effectivement de quelle année ? Si fin août je n'ai rien reçu je verrai pour annuler la commande On est des mauvaises langues je viens de recevoir un mail comme quoi l'écran a été envoyé

@jpm02 je déplace dans la bonne section

@Alucard_pla je déplace dans la bonne section

pas grave on va lui dire

Tu as vu ça ou ? C'est une bonne nouvelle, je l'ai pré commandé depuis 2 mois et demi Après faut voir quand ils vont les envoyer, pas reçu de message pour l'instant

Accéder aux dossiers de l'utilisateur MKS via l'explorateur de fichiers de Windows Même si on peut accéder via l'interface Web (Fluidd / Mainsail) à certains dossiers de Klipper avec un navigateur, l'explorateur de fichiers permet en plus (si l'utilisateur mks a bien été ajouté ) l'accès total au répertoire personnel de «mks» Pour réaliser «cette magie», rien de bien sorcier: 1. Installer quelques paquets : sudo apt install && sudo apt install samba winbind 2. Éditer le fichier /etc/samba/smb.conf: sudo nano /etc/samba/smb.conf 3. Ajouter à la fin de ce fichier : [Print_Files] comment = GCode_files path = /home/mks/printer_data/gcodes browseable = Yes writeable = Yes only guest = no create mask = 0770 directory mask = 0770 public = yes read only = no force user = mks force group = mks [Klipper_Configs] comment = Klipper configurations path = /home/mks/printer_data/config browseable = Yes writeable = Yes only guest = no create mask = 0770 directory mask = 0770 public = yes read only = no force user = mks force group = mks [Timelapses] comment = Timelapses path = /home/mks/timelapse browseable = Yes writeable = Yes only guest = no create mask = 0770 directory mask = 0770 public = yes read only = no force user = mks force group = mks 4. Enregistrer le fichier modifié 5. Ajouter l'utilisateur mks pour lui permettre l'accès à son «home» depuis Windows sudo smbpasswd -a mks 6. Redémarrer le daemon système : sudo systemctl restart smbd Savourer : Accès au partage \\adr.ess.e.ip Accès au dossier «Home» Agrandir la partition système J'ai d'abord installé le nouveau système sur l'ancienne eMMC de 8 Go. Régulièrement j'ai fait des images du contenu à l'aide de mon utilitaire favori imageUSB. Au départ, la place occupée représentait à peu près moins de la moitié de la capacité totale. mks@mkspi:~$ df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 379M 0 379M 0% /dev tmpfs 92M 2,4M 89M 3% /run /dev/mmcblk1p2 6,7G 3,6G 3,1G 55% / tmpfs 456M 0 456M 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 456M 16K 456M 1% /tmp /dev/mmcblk1p1 256M 88M 169M 35% /boot /dev/zram1 47M 960K 43M 3% /var/log tmpfs 92M 0 92M 0% /run/user/1000 Au fil des installations liées à l'écosystème Klipper (Klipper, Moonraker, Fluidd, Mainsail, Crowsnest, Mobileraker, PrettyGCode, OctoEverywhere, Spoolman, …) je me retrouvais comme avec l'image du système de Qidi avec moins de 1 Go disponible (système utilisé à plus de 90%) mks@mkspi:~$ df -H Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 398M 0 398M 0% /dev tmpfs 96M 4,3M 92M 5% /run /dev/mmcblk1p2 7,2G 6,4G 722M 90% / tmpfs 478M 0 478M 0% /dev/shm tmpfs 5,3M 0 5,3M 0% /run/lock tmpfs 478M 8,2k 478M 1% /tmp /dev/mmcblk1p1 269M 92M 177M 35% /boot /dev/zram1 50M 3,8M 42M 9% /var/log tmpfs 96M 0 96M 0% /run/user/1000 J'ai donc ré-imagé un système sur une eMMC de 16 Go à partir d'une image enregistrée de 8 Go. Pour prendre en compte la capacité de cette nouvelle mémoire, il faut procéder à un agrandissement de la partition (nul besoin de pompe comme pour d'autres agrandissements ). sudo systemctl enable armbian-resize-filesystem && sudo reboot Après redémarrage, la partition a été agrandie mks@mkspi:~$ df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 379M 0 379M 0% /dev tmpfs 92M 4,2M 87M 5% /run /dev/mmcblk1p2 14G 6,1G 7,6G 45% / tmpfs 456M 0 456M 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 456M 4,0K 456M 1% /tmp /dev/mmcblk1p1 256M 88M 169M 35% /boot /dev/zram1 47M 2,7M 41M 7% /var/log tmpfs 92M 0 92M 0% /run/user/1000

Sur l'imprimante réinsérer l'eMMC sur la carte contrôleur de l'imprimante brancher le câble d'alimentation et le câble Ethernet (rappel: le Wifi n'est pour le moment plus fonctionnelle) allumer l'imprimante (le système démarre, une adresse IP est attribuée (Box internet, routeur) l'écran ne fonctionne plus et reste sur le logo Two Trees récupérer l'adresse IP par le moyen qui convient (Box internet, routeur, logiciel type AngryIP démarrer le logiciel SSH (Putty, SSH natif, Mobaxterm, …) et accéder à l'imprimante via son adresse IP le premier accès se fait en tant qu'utilisateur "root", mot de passe "1234". Cette première connexion lance le setup initial du systéme Armbian changement du mot de passe "root", choix de la zone horaire, choix du shell entre autre ensuite il est demandé de créer un nouvel utilisateur ( par exemple: "mks", mot de passe "makerbase" ), confirmer par ENTRÉE. Ce nouvel utilisateur possède des droits équivalents à «root» (sudo) chez moi, la zone horaire (timezone) ayant été détectée (Europe/Paris), l'installateur propose de générer les locales. Plusieurs choix étant possible, je sélectionne le 4 (fr_FR.UTF-8) à l'aide du logiciel SSH, ouvrir une nouvelle session en tant que le nouvel utilisateur créé ( "mks" ) mettre à jour le système : sudo apt update sudo apt upgrade ou en une seule ligne sudo apt update && sudo apt upgrade Confirmer la mise à jour (manuellement) ou ajouter le paramètre "-y" à la suite de "upgrade" sudo apt upgrade -y Aperçu des étapes ci-dessus Le système de base est installé sur l'eMMC, il occupe moins de 2Go de la capacité totale de 8Go (eMMC originelle ) mks@mkspi:~$ df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur udev 379M 0 379M 0% /dev tmpfs 92M 2,0M 90M 3% /run /dev/mmcblk1p2 6,7G 1,9G 4,8G 29% / tmpfs 456M 0 456M 0% /dev/shm tmpfs 5,0M 0 5,0M 0% /run/lock tmpfs 456M 0 456M 0% /tmp /dev/mmcblk1p1 256M 88M 169M 35% /boot /dev/zram1 47M 740K 43M 2% /var/log tmpfs 92M 0 92M 0% /run/user/1000 «Améliorer» l'OS Tel quel le système d'exploitation est pleinement fonctionnel Certaines fonctionnalités de l'ancien OS de Makerbase ne sont plus disponibles, par exemple: plus d'automontage d'une clé USB le nom des interfaces réseau adopte celui «imposé» par systemd (je préfére l'ancien (ethX, wlanX) l'utilisateur mks ne peut accéder aux GPIO, le groupe gpio n'existe pas, on ne peut accéder aux GPIO que via sudo pas de synchronisation régulière du système de fichiers (/bin/sync) quelques paquets doivent encore être installés (python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev python3-serial) … On peut se passer de toutes mais ce serait dommage de s'en priver, certaines sont purement cosmétiques d'autres apportent plus de fonctionnalités. Bloquer certaines mises à jour du système d'exploitation Le OS prévus pour les Single Board Computer (SBC), Ordinateurs monocartes dont le plus connu est le RaspberryPi gèrent moyennement bien les montées de version du noyau (kernel), c'est particulièrement le cas des distributions Armbian. Des outils existent permettant d'empêcher la mise à jour de paquets (linux-dtb-*, linux-image-*, linux-headers-*, armbian-firmware*, …). Normalement, ces paquets après installation de l'image système sont bloqués. A chaque connexion ssh, c'est normalement indiqué On peut utiliser l'outil «armbian-config» pour geler / dégeler ces mises à jour : sudo armbian-config La première option de l'écran permet d'accéder aux paramètres «sensibles» du système: En choisissant cette option, le fond d'écran change de couleur pour rappeler le caractère «dangereux» de certains choix. On peut geler / dégeler les mises à jour à «éviter» : On peut évidemment aussi faire cette manipulation en ligne de commande. La liste des paquets gelés peut être récupérée lors d'un «apt upgrade» ou après un «apt update» suivi d'un «apt list --upgrable»: Connaissant le nom des paquets, la commande à utiliser est «apt-mark hold nom-du-paquet» (unhold pour dégeler): sudo apt-mark hold base-files linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-headers-current-rockchip64 armbian-config armbian-firmware armbian-plymouth-theme armbian-zsh Synchronisation du système de fichiers Ces systèmes monocartes apprécient moyennement l'extinction brutale (coupure d'alimentation) avec le risque de corruption du support mémoire (les eMMC sont un peu plus tolérantes que les cartes SD). On peut demander au système d'écrire régulièrement via une tâche «cron. Soit on édite manuellement cette tâche : crontab -e en ajoutant pour une synchronisation toutes les cinq minutes : */5 * * * * /bin/sync Soit en une seule ligne de commandes : (crontab -l 2>/dev/null; echo "*/5 * * * * /bin/sync") | crontab - Modifier la manière de gérer les noms d'interfaces réseaux Les systèmes récents utilisent «systemd» qui donnent des noms «aléatoires» aux interfaces réseaux, je préfère l'ancien système de nom (ethX, wlanX avec X={0,1,2, …} On peut en ajoutant une ligne dans le fichier /boot/armbianEnv.txt revenir à cet ancien nommage : echo "extraargs=net.ifnames=0" | sudo tee -a "/boot/armbianEnv.txt" > /dev/null On peut évidemment ajouter cette ligne (extraargs=net.ifnames=0) manuellement en éditant le fichier : sudo nano /boot/armbianEnv.txt Pour être pris en compte, il faudra redémarrer le système. Sans cette modification, l'interface Ethernet (eth0) serait nommée end1 Quelques paquets à ajouter sudo apt update sudo apt install python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev python3-serial Automontage des clés USB Le système d'exploitation originel montait automatiquement les supports de masse (clés USB) dans le dossier de stockage des Gcodes dans un dossier sda1 créé au montage puis supprimé au démontage (retrait du support). C'est une fonctionnalité bien pratique qui n'est pas implémentée sur la nouvelle image du système. On pet ajouter cette fonctionnalité manuellement: créer des règles UDEV indiquant au système quoi faire quand un périphérique de masse est inséré créer le dossier servant de point de montage attribuer ce point de montage à l'utilisateur mks recharger les règles UDEV tester C'est l'objet du script shell suivant (contenu à recopier dans un fichier nommé comme vous voulez ( automontage.sh, par exemple), droits d'exécution (chmod +x …)) : #!/bin/bash # Remove old rule if it exists sudo rm -f /etc/udev/rules.d/99-usb_automount.rules # Define the path for the udev rule file udev_rule_path="/etc/udev/rules.d/99-usb_automount.rules" # Define the mount point mount_point="/home/mks/printer_data/gcodes/USB" # Obtain UID and GID for the mks user uid=$(id -u mks) gid=$(id -g mks) # Udev rule to add udev_rule_add="ACTION==\"add\", SUBSYSTEMS==\"usb\", SUBSYSTEM==\"block\", KERNEL==\"sd*1\", ENV{ID_FS_USAGE}==\"filesystem\", RUN{program}+=\"/usr/bin/systemd-mount --no-block --automount=yes --collect --options uid=$uid,gid=$gid,sync,nofail \$devnode $mount_point\"" # Udev rule to remove udev_rule_remove="ACTION==\"remove\", SUBSYSTEMS==\"usb\", SUBSYSTEM==\"block\", KERNEL==\"sd*1\", RUN+=\"/bin/sh -c '/bin/umount $mount_point'\"" # Write the rules to the udev rule file { echo "$udev_rule_add" echo "$udev_rule_remove" } | sudo tee "$udev_rule_path" # Create the mount point directory if it doesn't exist if [ ! -d "$mount_point" ]; then #sudo mkdir -p "$mount_point" mkdir -p "$mount_point" fi # Change the ownership of the mount point to user 'mks' sudo chown mks:mks "$mount_point" # Reload udev rules sudo udevadm control --reload-rules && sudo udevadm trigger echo "Udev rule for USB automount with sync option is configured." Lors de l'introduction d'un clé, désormais, le système la gérera automatiquement 1) Pas de clé insérée: 2) Clé insérée (le périphérique SDA est détecté mais pas encore monté) 3) La lecture du contenu de la clé monte le dossier là où il faut : 4) Après retrait de la clé, le périphérique est bien démonté, le point de montage lui n'a pas disparu mais est vide (il pourrait parfaitement contenir des fichiers qui n'apparaitraient pas en cas de montage d'une clé ) :

bonjour @Jackhadi bienvenue chez les imprimeurs fous

Houai en faite tu mélanges toutes les touches quoi

Bonjour @Grymreaper bienvenue chez les imprimeurs fous