Impression 3D : gestion de plusieurs profils d’impression

Je connais des gens qui ont des imprimantes 3D qui ne sont guère plus que des appareils. Ils l’achètent, ils impriment avec et ils ne changent pas grand-chose. Cela ne me décrit pas et, je suppose, cela ne vous décrit pas non plus. Cela pose cependant un problème en ce qui concerne les trancheuses. Vous devez continuer à changer de profils et à les modifier. Il peut être difficile de garder les choses au clair. Par exemple, si vous avez des profils pour différentes buses, vous devez faire un choix : conserver un profil et modifier les pièces qui changent, ou conserver plusieurs profils et toute modification commune doit être propagée aux autres profils.

J’ai longtemps voulu créer un système qui me permette d’avoir des profils de base, puis d’utiliser simplement des profils spécifiques qui modifient quelques éléments dans la ligne de base. Il s’avère que je n’avais pas besoin de le faire. Prusa Slicer et son fork, SuperSlicer, en ont déjà la capacité. Les deux, bien sûr, sont basés sur Slic3r, mais les langages de script sont différents et ce que je fais nécessite un script G-code. Le problème est que cette capacité n’est pas très bien documentée et que l’interface graphique ne la prend pas vraiment en charge directement, ce qui nécessite un peu de contournement. Je vais vous montrer comment j’ai configuré les choses et où sont les limites. Si vous voulez vous y essayer, je vous suggère fortement de sauvegarder votre répertoire de configuration ou de passer à un nouveau.

En parlant de cela, les deux programmes prennent un --datadir argument de ligne de commande qui vous permet de placer les fichiers de configuration où vous le souhaitez. Si vous êtes comme moi et que vous utilisez le slicer à partir de différents ordinateurs, c’est un excellent moyen de placer les fichiers dans un lecteur partagé ou d’utiliser quelque chose comme Syncthing pour conserver quelques copies synchronisées sur le réseau.

Regroupez-le

Les préréglages ou les profils sont généralement stockés dans .ini fichiers qui ont un format très simple. Le nom de chaque préréglage est entre crochets, avec un identifiant du type de préréglage dont il s’agit. Par exemple, vous pourriez avoir :

[print:myprinter]
layer_height = 0.3

Ce n’est pas génial, cependant, car un préréglage vit dans un fichier. Vous pouvez, bien sûr, garder une trace d’une myriade de ini fichiers et les générer à la volée. C’était ma première pensée. Cependant, les trancheuses vous permettent d’exporter et d’importer des ensembles de configuration qui remplissent un tas de profils à la fois.

À première vue, cela peut ne pas sembler très grave, car vous pouvez simplement compresser un tas de ini fichiers dans une archive. Mais il y a deux choses qui jouent en notre faveur. Tout d’abord, vous pouvez masquer certaines entrées dans un bundle. Deuxièmement, vous pouvez faire en sorte qu’une entrée hérite des éléments d’un autre préréglage dans le même lot.

Cela signifie que vous pouvez exporter votre configuration sous forme d’ensemble, puis tout réorganiser afin d’avoir tous vos paramètres communs au même endroit, puis hériter de la plupart de ces paramètres à partir d’éléments spécifiques. Par exemple, vous pourriez avoir un type de filament PLA de base. Ensuite, un type PLA pour « Marque X » qui ne remplace que quelques articles. Enfin, vous auriez un « Red Brand X PLA » spécifique qui n’a qu’à définir la couleur et – si vous avez plusieurs extrudeuses – peut-être le facteur de pigment qui contrôle la quantité de filament purgé entre les couleurs.

Par exemple:

[filament:PLA Brand X Red]
inherits = *PLA_Brand_X*]
filament_colour = #FF0000
filament_wipe_advanced_pigment = 0.7

Entrées masquées

Remarquez les astérisques autour de l’identifiant PLA_Brand_X ? Cela indique au slicer de ne pas montrer cette entrée à l’utilisateur. En fait, lors de l’importation, le slicer ne les utilise que pour remplir le fichier ini d’un élément spécifique. Cela vous permet de ne pas avoir un tas d’entrées sans signification juste pour conserver vos valeurs par défaut.

L’inconvénient, cependant, est qu’une fois que vous avez importé, il n’y a plus de connexion commune entre le préréglage et la « classe de base ». Si vous faites un changement, cela ne changera que le préréglage actuel. Vous pouvez contourner cela, cependant, de plusieurs façons.

Ainsi, lorsque j’ai mentionné l’exportation de votre configuration existante sous forme d’ensemble, vous créez de nouvelles entrées pour des éléments tels que « print:*default* » pour héberger toutes les choses courantes. Notez que vous ne voulez pas d’espace après les deux-points, mais ne me demandez pas pourquoi je le sais.

Scénarios communs

Il y a un autre problème. L’une des raisons pour lesquelles cela m’intéresse est que j’ai un système qui me permet d’échanger rapidement des hotends. Parfois, j’utilise un hotend de commutation, et parfois j’utilise un hotend plus conventionnel comme un Dragon. Le problème est que les extrémités chaudes ont des facteurs d’extrusion, des étalonnages de thermistance et des tailles de buse différents. Certains d’entre eux sont faciles à gérer avec les bundles de configuration. Ce qui est moins facile, cependant, c’est d’avoir un seul script de démarrage et d’arrêt unifié ou d’envoyer un code personnalisé pour définir l’étalonnage de la thermistance, par exemple.

Une tête de mixage, par exemple, nécessite un démarrage beaucoup plus complexe qu’un E3DV6 normal. Cependant, les deux ont besoin d’ajustements de lit et d’échauffements de température. J’ai actuellement six versions d’extrudeuses et je ne souhaite pas apporter de modifications parallèles à six scripts différents.

La réponse est d’utiliser des scripts. Malheureusement, le langage de script fourni par le slicer est assez limité, vous ne pouvez donc pas définir de variables à utiliser ultérieurement, par exemple. Mais vous pouvez lire des « espaces réservés » (variables système) pour apprendre des choses comme la hauteur de la première couche ou la température souhaitée. Vous avez probablement déjà vu cela utilisé dans le gcode de démarrage pour vous éviter d’avoir différents scripts de démarrage pour différents matériaux ou tailles de buses.

Cependant, vous pouvez également apprendre le nom du préréglage d’imprimante et le rechercher pour une expression régulière. J’en ai profité en nommant chaque profil comme je veux mais en ayant !1! ou !2! ou un autre numéro apparaît dans le nom. De cette façon, je peux facilement écrire du code qui modifie les paramètres en fonction du profil qui l’utilise. Par exemple:

{if printer_preset=~/.*~!3!.*/ }
M305 P0 B4981
M301 E0 P22.7 I2.4 D53.8
{endif}

Évidemment, il existe des morceaux de code similaires pour chaque ID hotend. Les noms des imprimantes ressemblent à : NF-!3! ou E3D-!0!. Vous pouvez préférer différents personnages et schémas. Vous pouvez, bien sûr, simplement rechercher le nom exact si vous préférez et ignorer l’encodage numérique. Cependant, ce schéma me permet d’avoir plusieurs profils pour le même hotend et de toujours choisir les paramètres communs quel que soit le nom exact. Autrement dit, NF-!3! et NF-HF!3! les deux obtiennent le même code de début et de fin.

Un problème avec les scripts aussi, c’est qu’ils sont tous sur une seule ligne avec n encodé pour afficher les retours à la ligne. La façon dont je travaille autour de cela est que je garde un fichier sous contrôle de version avec chaque script de démarrage. Quand j’ai besoin de faire un changement, je le mets dans n’importe quel préréglage que j’ai et je le sauvegarde sous un nom temporaire ou parfois je le sauvegarde simplement puisque je suis sur le point de l’écrire de toute façon (dont vous entendrez parler , dessous). Puis j’ouvre le correspondant .ini fichier et copiez la ligne à mettre dans le bundle. Il existe de nombreuses autres façons de le faire.

En tant que fonctionnalité supplémentaire, chaque script commence par un numéro de version et une date afin que je puisse facilement voir que mes modifications ont été apportées et je peux facilement revenir en arrière en utilisant git sans trop confondre.

La déconnexion de l’interface graphique

Le dernier problème est celui de l’interface graphique. Comme je l’ai mentionné précédemment, l’importation du bundle détruit la relation entre les préréglages. J’ai trouvé quelques règles simples qui aident à gérer la folie. Je gère les versions du bundle et les fichiers associés avec gitmais ce n’est pas la panacée puisque les fichiers individuels changent.

1. Ne modifiez jamais les profils importés et enregistrez-les. Vous pouvez, bien sûr, mais cela vous embrouillera.
2. Si vous modifiez un profil importé, enregistrez-le avec un nouveau nom similaire (j’ajoute -exp pour expérimental au nom).
3. Lorsque vous décidez de modifier l’un des préréglages standard ou d’en ajouter un de manière permanente, utilisez le trancheur pour vous montrer les différences entre le préréglage et celui qui, selon vous, constituera une bonne classe de base.
4. Modifiez le groupe pour refléter les modifications que vous souhaitez conserver. Certaines modifications ne valent pas la peine d’être conservées et n’oubliez pas de définir la clé « inherits » sur la classe de base.
5. Réimportez le bundle. Supprimez tous les préréglages supplémentaires que vous avez créés à l’étape 2.

Si vous faites des erreurs, l’importation vous avertira. Un problème courant est que l’interface graphique aime capitaliser des choses comme les noms des modèles de remplissage. Cependant, dans le fichier, tout est en minuscules.

Une fois l’importation effectuée, tout devrait bien se passer. Une chose à surveiller est que le [physical_printer] tag a tous les préréglages que vous souhaitez définir, vous n’avez donc pas besoin de modifier l’imprimante physique pour la réassocier à de nouveaux profils.

Si vous voulez vraiment changer d’outil, consultez [Joshua’s] Jubilé. Si vous n’utilisez pas de slicer compatible, vous pouvez en savoir plus sur PrusaSlicer et Super Slicer.