Après avoir solidifié les fondations Linux de notre Elegoo Neptune 4 Max, il est temps de se pencher sur le moteur même de Klipper : ses fichiers de configuration. Contrairement aux firmwares traditionnels "compilés" comme Marlin, Klipper interprète ses instructions à la volée au démarrage. C’est ici que la magie opère. Là où les constructeurs vous abandonnent face à un fichier unique, illisible et long de plusieurs milliers de lignes — et là où les configurations open-source brutes ne vous livrent qu'un squelette vide — nous faisons le choix de la rigueur. En exploitant pleinement la puissance de l'architecture modulaire via la fonction [include], nous séparons enfin le matériel de l'intelligence logicielle. Dans ce guide [À Savoir], nous décortiquons les mécanismes invisibles de ces inclusions et le principe fondamental de la cascade.
Ce que vous allez comprendre : Cet article ne détaille pas encore l'arborescence finale de notre projet. Son but est de vous donner la gymnastique mentale nécessaire pour comprendre comment Klipper lit vos fichiers, et pourquoi un simple changement d'ordre peut transfigurer (ou bloquer) le comportement de votre imprimante 3D.
1. La Modularité : Le super-pouvoir de la commande [include]
Imaginez le fichier de configuration principal de Klipper (printer.cfg) comme le chef d'orchestre de votre machine. S'il devait contenir les lignes de code de chaque moteur, de chaque macro, du pinout de la carte mère et des capteurs, il deviendrait un labyrinthe inextricable.
Pour résoudre ce problème, Klipper utilise la directive [include ...]. C'est une commande chirurgicale qui dit textuellement au système : "Va lire ce fichier spécifique, injecte tout son contenu ici, puis continue ta lecture."
Grâce aux inclusions, on peut isoler les fonctions. Les macros de calibration vont dans un dossier, la cinématique dans un autre, et la configuration de l'extrudeur reste indépendante. C'est propre, lisible et infiniment plus simple à maintenir ou à partager.
Vous ajoutez temporairement un accéléromètre (ADXL345) pour mesurer vos résonances ? Il suffit d'ajouter une ligne [include adxl.cfg]. Vos mesures sont finies ? Mettez un dièse (#) devant pour la commenter, et l'extension est désactivée sans polluer votre fichier sain.
2. Le Principe de Cascade : "Le dernier qui parle a raison"
C’est ici que réside toute la subtilité — et parfois les pièges — de Klipper. Klipper lit les fichiers de haut en bas, de manière strictement séquentielle. Lorsqu'une section ou une variable est définie plusieurs fois, **Klipper n'affiche pas d'erreur : il écrase la valeur précédente par la nouvelle**.
Analogie concrète : La feuille de consignes
Imaginez que vous donniez une feuille de route à un technicien :
• En haut de la page, il est écrit : "Régler la vitesse d'impression à 150 mm/s".
• Au milieu de la page, vous ajoutez une note : "Finalement, régler la vitesse d'impression à 250 mm/s".
Le technicien va appliquer la dernière consigne lue. C'est exactement ce que fait Klipper. C'est ce qu'on appelle la lecture en cascade.
Cette logique s'applique de la même manière aux fichiers inclus. Si votre printer.cfg appelle un fichier externe qui redéfinit une configuration déjà écrite plus haut, c'est le fichier externe qui prendra le dessus.
3. Pourquoi l'ordre des [include] est une question de vie ou de mort (pour vos prints)
Puisque le dernier bloc lu l'emporte, l'ordre dans lequel vous écrivez vos lignes [include] dans le fichier principal devient absolument crucial. Un mauvais ordonnancement peut annuler vos optimisations sans que vous ne vous en rendiez compte.
Cas d'école : Le piège de la Macro écrasée
Imaginons que vous ayez créé une macro de démarrage ultra-personnalisée nommée [gcode_macro PRINT_START] pour gérer parfaitement votre extrusion sur la Max. Regardez ces deux scénarios :
[include stock_openneptune.cfg] # Contient aussi un PRINT_START générique d'origine
Résultat : Klipper lit vos macros perso, puis lit le fichier d'origine. Le PRINT_START générique étant lu en dernier, il **écrase complètement le vôtre**. Votre personnalisation est ignorée.
[include mes_macros_perso.cfg] # Arrive en dernier et prend le dessus !
Résultat : Klipper pose la base d'origine, puis applique vos fichiers modifiés par-dessus. Votre configuration personnalisée a le "dernier mot" et s'exécute parfaitement.
C'est précisément grâce à cette mécanique que l'on peut surcharger proprement les paramètres constructeurs d'usine ou d'OpenNept4une sans jamais modifier leurs fichiers sources. On charge la brique d'origine, puis on injecte nos briques d'optimisation en dessous.
Vous maîtrisez maintenant la théorie de la cascade et de l'écrasement de données. Dans le prochain article, nous allons mettre ce concept en pratique : nous allons lever le voile sur l'arborescence complète et épurée de notre projet. Restez connectés !