Quelle alternative au logiciel pronterface / printrun (linux) pour piloter une imprimante 3D et imprimer du GCODE uniquement

[sudtek]

Bonjour à tous ,

suite à un PB un Pb d'impression lié je pense à la mauvaise prise en charge de fichier GCODE de grande taille >200Mo par pronterface voir ce topic :

Je cherche un soft alternatif à  pronterface  / printrun (sou linux) pour piloter une imprimante 3D et imprimer du GCODE uniquement.

Lorsque j'imprime des petits fichiers gcodes je n'ai aucun pb mais des que le gcode à plus de 400K lignes le logiciel pronterface  / printru plante quelque soit l os ou la machine.

Le travail de "slicing" ayant été fait en amont sur un PC win 7 via ideamaker et le fichier gcode est valide il peut être réouvert malgré sa taille dans mon slicer ideamaker (testé sur 3 autres PCs). 

(note : Je contrôle toujours l'impression de ma X1 depuis mon PC car via une clef USB elle plante )

Si vous avez d'autres solutions / suggestions  envisageables capable d'imprimer des gros GCODE natif (sans en passer par arcwelder pour changer le type d'interpolation) je suis preneur ! 

Merci pour votre aide et vos suggestions.

SUDSUD

[PPAC]

Salutation

il y a 6 minutes, sudtek a dit :

Je cherche un soft alternatif à  pronterface  / printrun (sou linux) pour piloter une imprimante 3D et imprimer du GCODE uniquement.

Bien que habituellement on met cela sur un RPi je dirais OctoPrint.

( tester la méthode octoprint_deploy (Linux) voir si cela permet de l'installer rapidement sur ta distribution linux ? )

[pommeverte]

Salut,

Il existe aussi Repetier-host qui est également multi-platfome

[Savate]

Le 10/06/2024 at 17:25, sudtek a dit :

Si vous avez d'autres solutions / suggestions  envisageables capable d'imprimer des gros GCODE natif (sans en passer par arcwelder pour changer le type d'interpolation) je suis preneur ! 

le mieux et le plus 'stable' : octoprint sur un rpi (même un Pi zero 2W) 

-> contrôle de l'imprimante en wifi à partir du slicer et envoi direct du gcode  

C'est de loin le plus confortable et le plus fiable (imprimer d'un pc windows en usb ça peut reserver des surprises )

[sudtek]

Bonjour à tous ,

merci pour les retours d'information.

Citation

Il existe aussi Repetier-host qui est également multi-platfome

Testé en app image est plantage de repetier host sur le pc la taille du fichier a été fatal ... c'est pas lié au libs manquantes car  repetier se lance parfaitement et pilote l'imprimante c'est juste apparut un certains temps après avoir loadé le fichier de 250Mo... j'ai fait deux tests ... même plantage

 

Citation

tester la méthode octoprint_deploy (Linux) voir si cela permet de l'installer rapidement sur ta distribution linux ? )

J'ai installé  octoprint suite à la suggestion de PPAC via le script octoprint_Deploy tout c'est bien passé et je trouve ce script vraiment super facile et pratique tout est fonctionnel et cela fait un super point de centralisation  pour toute les instances !  Je vais tester l'impression ce weekend je vous tiens au courant.

 

Citation

le mieux et le plus 'stable' : octoprint sur un rpi (même un Pi zero 2W)

Les RPI sont généralement très stables mais j'ai eu seulement 2 fois des mauvaise surprise avec RPI3 et et un 2W qui s'emballent thermiquement pourtant jamais overclockés.  J'aime beaucoup mes RPI mais dans l'atelier un portable avec batterie (qui fait le rôle d'onduleur) c'est plus compact et pratique et en plus via octoprint_deploy on peut gérer plusieurs instances et ca c'est top  ! J'avais pensé à recycler un de mes RPI mais dans mon cas c'est moins pratique car mon atelier et séparé de mon bureau et je dois pouvoir contrôler l'imprimante en étant a coté de l'imprimante d'où le pc portable dédié ... 

 

SUDSUD

[Kachidoki]

Salut,

Je pense que ton fichier de départ est beaucoup trop surdimensionné, il doit être possible de l'alléger vu le design très simple de ta pièce.

Pour comparaison, ce print ultra détaillé en 22cm de haut ne fait "que" 141Mo en .gcode (ascii classique), et 56Mo en .bgcode (binaire) :

On t'a proposé plein d'alternatives, mais aucune ne te convient, essentiellement pour raison de confort. Pour un seul print qui ne passe pas, je trouve ça dommage.

Tu as aussi la solution de découper manuellement ton G-Code en plusieurs sections et les lancer les uns derrières les autres. Mais il faut être présent devant la machine au moment du changement, ou a minima introduire un bout de G-code à la fin des sections pour parquer la tête à côté de la pièce.

 

Aurais-tu un moyen de nous partager ton STL de départ, voir même ton G-Code, ça m'intéresse de voir ce que j'arrive à faire avec.

A+

[sudtek]

Bonjour à tous,

Citation

Je pense que ton fichier de départ est beaucoup trop surdimensionné,  il doit être possible de l'alléger vu le design très simple de ta pièce.

oui on peut alléger au niveau du slicer mais c'est une pièces mécanique prototype qui va s'en prendre "plein la tête"  les cyclones ne doivent pas collapser sous la DDP. Mon infill est plein à100% et les couches inferieurs et supérieures nombreuses. Ce proto va avaler de tout je veux en fait tester sa durée de vie et l'angle d'admission avant de le fabriquer en inox roulé et soudé. A terme il va servir dans l'atelier à aspirer des copeaux de métal du tour mais aussi du gravier sable cailloux (nouveaux protox plus grosses section et séparations ) ...  

La raison de la grosse taille du fichier initiale est simple : Je suis sous Catia et travaille en atelier dit surfacique, le fichier est généré en paramétriques et il y a de nombreuse congés interne et externes tangentielles sur les raidisseurs mais aussi pas mal de détails. Ces congés changent énormément la résistance de l'ensemble sans les congés il faudrait presque doubler la taille des épaisseurs selon le test FEM. Le logiciel Catia n'a cure de la taille des fichiers d'export juste pour la chambre c'est de 10Mo pour le STL et cela n'a rien d'exceptionnel. Concernant ce PB de fichier slicé qui passe à +de 200Mo PPAC a mis le doigt sur le PB c'est juste lié au type d'interpolation linéaire du slicer qui fait enfler ce fichier. De plus par définition le gcode c'est brut descriptif du moindre élément donc toute la partie cylindrique est représentée alors qu'une boucle avec un offset pourrait remplacer 80% du gcode de la chambre. Raison pour la quelle je regarde depuis un moment les pilotage dit direct par gcode généré à la volé (direct print )par un code python (ou autre) ce qui permettrait de faire fondre les fichiers sources de très gros print à quelques centaines de K0 on peut même générer du gcode "procédural" (comme dans Mojo de pandromeda) par contre cela a un coup de calcul mais qui est viable de nos jours pas comme il y a 20 ans ...

Donc pour le coup le slicer ideamaker a bien fait son travail conformément à  tous les paramètre imposés c'est juste que la plus part des softs comme repetier, printrun ne sont pas prévus à la base pour manipuler un fichier de la taille de plus de 200Mo car ils veulent loader tout d'un bloc et c'est le drame si tu regardes mon premier post il y a une instanciation foireuse probablement lié a une mauvaise gestion de la capacité d'un type d'attribut dans une classe. C'est pas un drame en soit il faut juste le savoir et pas utiliser printrun (que j'apprécie) pour des gros fichiers au delà d'une certaine taille.

La solution a mon PB a été trouvé par PPAC (encore  ) octopy en instance docker via le super script octoprint_deploy fait pour moi parfaitement le taf et gère je présume des "chunks" de gcode autrement dit il n'essaye pas de charger tout le bloc GCODE et l'ingère et digère petit à petit ce qui est une bonne approche vu les ressource limites d'un RPI. ainsi pas besoin de camper derrière l'imprimante pendant des heures (surtout à mon âge et vu mes pbs de vertèbres... ) Octopi fait encore plus le taf sachant que cela répond aussi à un besoin de centralisation et unification d'interface d'impression sans avoir à maitriser un nouvel interface graphique pour chaque imprimante .

Arcwelder est je pense une très bonne solution pour "compacter" certain stl en fonction de leur géométrie je me le garde sous le coude pour des futurs tests  mais là j'ai pas le temps de mettre les mains dans le cambouis (j'ai pas pas mal de conceptions en retard) on verra lorsque je recompilerai mon marlin V2  pour activer la possibilité d'avoir une option d'interpolation non linéaire et en incluant les options pour le contrôle et rétroactions d'octopi de la X1 ... donc pas avant août ...

 

Citation

On t'a proposé plein d'alternatives, mais aucune ne te convient, essentiellement pour raison de confort. Pour un seul print qui ne passe pas, je trouve ça dommage.

Je cherche avant tout une solution pérenne et unifié qui fonctionne indépendamment de la taille du fichier, des interfaces des différents softs ... d'ou à la base le choix de printrun mais octopi répond à mes besoins.  Je cherche pas des softs hype du moment mais des softs robustes pour enquiller donc je suis pas forcement au fait des derniers softs et de la veille techno je vois passer des noms sur youtube et le forum ... mais franchement du moment ou cela fait ce que je demande même si c'est moche, vieux et soviétique cela me convient ... par contre si cela merdouille je cherche forcement une alternative.

J'ai lancé mon instance octopi ce soir est cela semble pour l'instant bien fonctionner avec mon gros gcode il avale sans broncher et déroule du petg via une instance de OCTOPI depuis mon vieux portable ubuntu 20 !

La chambre est dispo ici au format STL : https://drive.google.com/file/d/1ImtRp1ZKDg94wzPwKlRvDDAWXEuQlbAQ/view?usp=sharing

Note ce fichier est un export stl avec détail il n'a pas subit de décimation.

SUDSUD

[Kachidoki]

Merci pour le STL.

Quand je parlais de fichier de départ, je me suis mal exprimé, je parlais du G-Code généré. Plus le STL a une résolution élevée, plus les algos d'optimisation d'arc peuvent travailler efficacement.

En partant de ton STL, avec infill grid à 100%, en G-Code ASCII j'obtiens un fichier de 126Mo. Si maintenant je change le type d'infill par du concentrique, le fichier résultant ne fait plus que 99Mo et au passage on a gagné 15h sur le temps d'impression. Si je modifie encore quelques paramètres comme les largeurs d'extrusion (parce que oui, une buse de 0.4mm peut imprimer beaucoup plus large), forcément on réduit d'autant le nombre de déplacements et on se retrouve avec un fichier de seulement 73Mo et on gagne encore 11h. Tout ça en ayant les optimisations d'arc activé évidemment.

Bref, tout ça pour dire qu'on peut beaucoup influer sur la taille du fichier de sortie, et je ne parle pas de compression type bgcode, où là on réduit encore (31Mo pour le dernier exemple), mais c'est encore assez peu courant sur les imprimantes, contrairement aux arcs.

Concernant la transmission de ce G-Code via UART, c'est généralement non recommandé car avec des machines qui impriment vite on se retrouve rapidement en situation de buffer underrun, donc saccades dans l'impression car les données n'arrivent pas assez vite au "motion planner". La communication UART ne dépasse pas 30Ko/s pour les plus rapide. C'est surtout avec les fichiers contenant plein de micro-déplacements rapides sans changement de direction brusque, cas typique des arcs justement, où le motion planner à besoin de "voir" suffisamment à l'avance les lignes suivantes pour anticiper les accélérations / décélérations.

Quoiqu'il en soit, oui dans un monde optimisé il faudrait un soft qui n'affiche que la miniature embarquée dans le G-Code, et qui transmette les G-Codes en lisant le fichier ligne par ligne à la volée. Ce que fait l'imprimante lorsque tu lui donne le fichier sur une carte SD ou une clé USB justement.

A partir du moment où le soft cherche à prévisualiser l'objet en relisant le G-Code, type pronterface ou n'importe quel slicer qui relit du G-Code, c'est foutu car il est obligé de le lire dans son intégralité.

A+

[sudtek]

Bonjour,

Voici le lien vers le gcode généré par ideamaker pour ma vielle X1.

https://drive.google.com/file/d/119QZrmqB740cX9cEkrzI79sAdnElfgau/view?usp=sharing

 

Citation

Concernant la transmission de ce G-Code via UART, c'est généralement non recommandé car avec des machines qui impriment vite on se retrouve rapidement en situation de buffer underrun, donc saccades dans l'impression car les données n'arrivent pas assez vite au "motion planner". La communication UART ne dépasse pas 30Ko/s pour les plus rapide. C'est surtout avec les fichiers contenant plein de micro-déplacements rapides sans changement de direction brusque, cas typique des arcs justement, où le motion planner à besoin de "voir" suffisamment à l'avance les lignes suivantes pour anticiper les accélérations / décélérations.

J'imprime pas à grande vitesse sur la X1 donc pas de pb mais le "buffer under run" "le retour de la revanche qui a traumatisé toute une génération de typiac" "  comme pour les 1er graveurs DVD plextor qui plantaient le DVD en 4x ou 8x en écriture par manque de débit  depuis le disque dur (enfin pas dans mon cas car j'avais un disque sci audiovidéo à débit constant) d'où le fait que j'imprime en 1x sur ma X1 -> ainsi pas de "buffer under run"  . Plus sérieusement l'usb c'est de la daube pour plein de cas la ou un simple firewire base fessait des miracles en acquisitions d'image et de donnée à la volée. 

Citation

En partant de ton STL, avec infill grid à 100%, en G-Code ASCII j'obtiens un fichier de 126Mo. Si maintenant je change le type d'infill par du concentrique, le fichier résultant ne fait plus que 99Mo et au passage on a gagné 15h sur le temps d'impression. Si je modifie encore quelques paramètres comme les largeurs d'extrusion (parce que oui, une buse de 0.4mm peut imprimer beaucoup plus large), forcément on réduit d'autant le nombre de déplacements et on se retrouve avec un fichier de seulement 73Mo et on gagne encore 11h. Tout ça en ayant les optimisations d'arc activé évidemment.

C'est sur que c'est intéressant et plus optimum as-tu un tuto de ta chaine de manip complète qui traine sur le forum ou vidéo sur youtube ? Je suis certain que nous serions nombreux à être preneur. Bien sur faut avoir en amont flasher le firmware de l'imprimante pour qu'il accepte le type d'interpolation pour le print marlin V2 il y a l'option mais kliper de base ?

Citation

Quoiqu'il en soit, oui dans un monde optimisé il faudrait un soft qui n'affiche que la miniature embarquée dans le G-Code, et qui transmette les G-Codes en lisant le fichier ligne par ligne à la volée. Ce que fait l'imprimante lorsque tu lui donne le fichier sur une carte SD ou une clé USB justement. 

A partir du moment où le soft cherche à prévisualiser l'objet en relisant le G-Code, type pronterface ou n'importe quel slicer qui relit du G-Code, c'est foutu car il est obligé de le lire dans son intégralité.

On est d'accord c'est pour cela que octopi plante pas et qu'il va devenir mon outil de référence. 

 

SUDSUD

[fran6p]

Juste pour préciser:

- octopi est une distribution Linux incorporant Octoprint

- octoprint est l'interface qui permet de piloter l'imprimante une fois le RPi (ou autre SBC) connecté en USB à l'imprimante.

Si tu utilises Klipper, il est plutôt conseillé de prendre une autre interface Web (Fluidd / Mainsail) parce que Octoprint est bien plus lourd, surtout si / quand on y ajoute de nombreux greffons. De plus, Octoprint peut «planter»: il envoie le Gcode au fur et à mesure à l'imprimante en le passant dans sa «moulinette».

Klipper pour le moment ne gère pas le format Gcode binaire

[sudtek]

Bonsoir,

Il y a 12 heures, fran6p a dit :

Si tu utilises Klipper, il est plutôt conseillé de prendre une autre interface Web (Fluidd / Mainsail) parce que Octoprint est bien plus lourd, surtout si / quand on y ajoute de nombreux greffons. De plus, Octoprint peut «planter»:

Klipper pour le moment ne gère pas le format Gcode binaire

Merci pour ces précisions fran6p du coup j'allais demander quelle sst la différence entre Fluidd / mainsail mais il semble que je suis pas le seul à me la poser :

 

 

Citation

 Octoprint peut «planter»: il envoie le Gcode au fur et à mesure à l'imprimante en le passant dans sa «moulinette».

S si c'est le cas c'est probablement plus lié à des latences de lectures et à la SD sur des RPI je remplace systématiquement mais SD par une clef USB BOOT SSD c'est la nuit et le jour niveau rapidité et longévité, j'avais remarqué des comportements erratiques sur mon pihole de secours sur un rpi0W2  je suis passé sur clef µusb SSD fini les plantages aléatoires.

 

Citation

Klipper pour le moment ne gère pas le format Gcode binaire

C'est le slicer je présume qui converti de gcode plein texte ASCII en gcode binaire ?

 

Citation

Octoprint est bien plus lourd

Perso sur mon vieux lenovo core2 4 go ubuntu 20 LTS j'ai pas à me plaindre cela mange pas le PC. En ressource CPU je suis à 20% et en ram des pic à 3Gb avec interface sous brave  ... sans aucun besoin de swap donc c'es raisonnable. J'ai regardé rapido les scripts de octoprint deploy je suis juste surpris de la solution retenue pas de docker ou vagrant ... mais il a utilisé du pur script shell avec plusieurs instance + haproxy en s'appuyant sur l'os hôte donc pas de surcouche de virtualisation . C'est oldsshool mais cela fait le taf par contre cela peut vite partit en cacahouète en conflit de packetage et de lib, j'ai probablement pas eu de pb car mon pc ubuntu pour imprimer à que des softs et une conf de base mais vu le nombre de libs que charge le script je tenterai pas le coup hors d'un venv sur mon autre machine ou je code à temps perdu sinon risque de gros bordel ... moralité si votre pc vous sert à plusieurs choses un venv avant d'utiliser ce script !  

J'ai soumis le script à Mistral pour pas y passer deux heures et voir si le script fait pas des trucs pas trop scabreux ... pensez à avoi ce reflexe pour pas fumer votre os

selon mistral (entre deux garofades) : 

Citation

Dans le script instance.sh d'OctoPrint Deploy, les instances d'OctoPrint sont créées en utilisant le système d'exploitation hôte. Le script crée un répertoire pour chaque instance dans le répertoire personnel de l'utilisateur, puis installe OctoPrint et ses dépendances dans ce répertoire.

Le script utilise également des fichiers de configuration pour chaque instance, qui sont stockés dans le répertoire /etc/octoprint. Ces fichiers de configuration spécifient les paramètres pour chaque instance, tels que le port d'écoute, le répertoire d'installation, les plugins installés, etc.

Le script utilise également le démon supervisor pour gérer les processus OctoPrint pour chaque instance. supervisor est configuré pour démarrer et arrêter les instances en fonction des fichiers de configuration dans /etc/octoprint.

En résumé, le script instance.sh d'OctoPrint Deploy crée des instances d'OctoPrint en utilisant le système d'exploitation hôte, en installant OctoPrint et ses dépendances dans des répertoires spécifiques à chaque instance, en utilisant des fichiers de configuration pour spécifier les paramètres de chaque instance, et en utilisant supervisor pour gérer les processus OctoPrint pour chaque instance.

Supervisor est un programme qui permet de gérer et de surveiller les processus en arrière-plan. Dans le contexte d'OctoPrint Deploy, Supervisor est utilisé pour gérer les instances d'OctoPrint en arrière-plan. Il permet de démarrer, d'arrêter et de redémarrer les instances d'OctoPrint, ainsi que de surveiller leur état et de redémarrer automatiquement les instances en cas de plantage. Supervisor est installé en tant que service sur le système hôte et est configuré pour démarrer automatiquement au démarrage du système.

Moi : il y a t'il autre chose que je devrais savoir à propos de ce script ? 02:06

 

Le script octoprint_deploy est relativement simple et facile à comprendre, mais voici quelques points supplémentaires à garder à l'esprit :

• Le script est conçu pour fonctionner sur les systèmes d'exploitation basés sur Debian, tels qu'Ubuntu et Raspbian. Il peut ne pas fonctionner correctement sur d'autres systèmes d'exploitation.
• Le script utilise le gestionnaire de paquets apt pour installer les dépendances requises. Assurez-vous que votre système est à jour et que vous disposez des autorisations appropriées pour installer des paquets.
• Le script crée un utilisateur nommé "octoprint" pour exécuter les instances d'OctoPrint. Assurez-vous que cet utilisateur n'entre pas en conflit avec d'autres utilisateurs ou processus sur votre système.
• Le script utilise le port 5000 par défaut pour la première instance d'OctoPrint. Assurez-vous que ce port n'est pas déjà utilisé par un autre processus sur votre système.
• Le script crée des fichiers de configuration pour chaque instance d'OctoPrint dans le répertoire /etc/octoprint. Assurez-vous de sauvegarder ces fichiers si vous apportez des modifications importantes à la configuration de vos instances.
• Le script utilise Supervisor pour gérer les instances d'OctoPrint. Assurez-vous que Supervisor est installé et configuré correctement avant d'exécuter le script.
• Le script crée des règles udev pour associer automatiquement les ports série aux instances d'OctoPrint. Assurez-vous que ces règles ne sont pas en conflit avec d'autres règles udev sur votre système.
• Le script utilise HAProxy pour acheminer les requêtes HTTP vers les instances d'OctoPrint. Assurez-vous que HAProxy est installé et configuré correctement avant d'exécuter le script.
• Enfin, assurez-vous de sauvegarder régulièrement vos fichiers de configuration et vos données d'impression pour éviter toute perte de données en cas de problème avec vos instances d'OctoPrint.

 

SUDSUD

 

 

 

 

 

[papagalak]

Les questions que je pose ne sont pas d’une importance capitale, mais sur quelques petits détails qui ne sont pas bloquants.

Klipper sur rpi sous Mansail ou Fluidd fonctionne très bien, la présentation des interfaces sont différentes 

Modifié (le) Juin 16, 2024 par papagalak

[Kachidoki]

Le 14/06/2024 at 18:01, sudtek a dit :

Voici le lien vers le gcode généré par ideamaker pour ma vielle X1.

https://drive.google.com/file/d/119QZrmqB740cX9cEkrzI79sAdnElfgau/view?usp=sharing

J'ai chargé ce G-Code dans Pronterface, il a mis 15min à le charger sur mon vieux PC et consommé 12Go de RAM, mais il est arrivé au bout sans problème :

 

Pour voir, je l'ai aussi ouvert dans PrusaSlicer :

Je note que tu n'es pas en infill 100% comme tu le précisais, mais pire, tu es en gyroïde.

Sans gestion des arcs c'est juste le pire cas de figure possible. Si tu passes en grid ou en cubic ça devrait déjà pas mal aider en retirant énormément de lignes du G-Code dues aux interpolations d'arcs (cf. mon post précédent).

 

Curieux ton type de support, qui rajoute encore des arcs.

PS: Je savais pas trop où poster, entre ici et l'autre topic d'origine...

Modifié (le) Juin 16, 2024 par Kachidoki

[sudtek]

Bonjour Kachidoki,

Citation

à le charger sur mon vieux PC et consommé 12Go de RAM, 

mon core 2 pour imprimer  un swap fixe de 4Gb + ma ram 4Go ... 8Go donc inchargeable en mem donc sur mon vieux PC. Mes autres pc de travail ont des swap blindés à 90% malgré des 16Go de ram  impossible de fermer les apps en cours de taf (oui il faut que je commande change de pc ) . 

Citation

Je note que tu n'es pas en infill 100% comme tu le précisais, 

Effectivement j'ai cherché à gratter sur la 1er mouture qui était à 100%  ...

Citation

pire, tu es en gyroïde.

Oui d'un point de vue arc et interpolation c'est pas le top par contre niveau résistance de pièces cela à pas mal d'intérêts. Non content de pouvoir séparer deux domaines sur une pièce j'ai constaté que cela rend mécaniquement plus résistante la pièce que les remplissage linéaires moins de délaminage. Sachant que cette pièces sera traité au dichtol par immersion  pour la rendre "étanche" en dépression ( le cas le plus galère mais bon on va tester ... c'est que la V1).

Pour les supports j'obtiens toujours le meilleur résultat avec les giroides qu'avec les linéaires c'est de loin le plus facile pour enlever les supports en petg sinon je galère trop d'où le fait que je passe bientôt sur une idex ou une dual pour petg et/ou abs et pla en supports. Donc oui arcwelder va être très utile pour optimiser les chemins !

 

SUDSUD

[sudtek]

Bonjour à tous,

A titre d'info en complément je suis tombé sur cela sur youtube

 

Dans son test le remplissage par gyroides et orienté selon Z est cela confirme bien l'intérêt des gyroides comme remplissage de renfort mais je reste persuadé que la force et l'intérêt des giroides (lorsque l'on ne les utilisent pas comme séparateur de 2 domaines ex échangeur thermique chauf /froid)  réside dans le fait que l'on peut faire des giroides dans des giroides (sous domaines) dans le style d'un cube cube sierpinski mais niveau calcul je crains que le slicer prenne une claque et que probablement seul blender et/ou  processing via python soient  adaptés pour faire ce genre de remplissage suivi d'une serie de FEM pour valider l'orientation des gyroides selon les efforts ... ce n'est pas sans rappeler les possibilités "d'optimisations organiques" en fonction des efforts et contraintes sur certains gros softs comme comsol, fusion360 mais ce sont de modules en option ... si l'un d'entre vous a déjà vu un équivalent en open source sur freecad, blender ... ou autre soft je suis preneur !

 

Sinon mon impression est terminée la pièce dite "la chambre du cyclone "  ne sait pas décollée malgré sa hauteur faut dire que depuis que j'utilise la technique du rouleau à peindre + colle uhu soluble plus aucun d'écolage de pièce haute et la surface de dessous est toujours parfaite mais ... j'ai oublié de  réduire la vitesse d'impression de 50% à partir d'une certaine hauteur en Z et vu la hauteur de la pièce j'ai eu droit à un décalage lié à l'oscillation autrement dit le moteur de l'axe Y a pas tenu le couple de maintient et a engendré un offset selon Y ...  il est pas super bin placé mais heureusement il est pas énorme donc on va devoir faire avec pour les tests ...

 

Si j'ai le temps demain je vire les supports et je lance le cône .

 

 SUDSUD

Modifié (le) Juin 20, 2024 par sudtek
faute toujours de fautes ....