Quel logiciel utiliser

[web34]

Bonjour,

Quel logiciel gratuit et performant utilisez vous pour votre imprimante.
Je viens de ressortir celle que j'avais entièrement réalisé en alu en 2014 (Mendelmax 2.0), mais je n'ai plus le pc que j’utilisais me semble t-il avec slicer ou un truc comme ça et repetier.
Existe t il autre chose ?
Merci

 

[J-Max]

Bonsoir,

Il y a trois types de logiciels : les firmwares qui sont des gestionnaires et interpréteurs de langage machine qui résident sur la carte mère de la machine,
et les trancheurs qui transforment un modèle 3D en langage machine (gCode). Les trancheurs permettent parfois de télécommander aussi l'imprimante.
Les logiciels "Host" permettent avant tout de télécommander l'imprimante et intègrent parfois également des moteurs de tranchage

Firmwares :
Marlin (le plus courant)
Repetiter Firmware,
Smoothieware (avancé), sait gérer toutes les CNC jusqu'à 5 axes, imprimante, laser, fraiseuse, plasma...

Host !
Repetier Host, intègre les moteurs de tranchage Cura et Slic3r.
Pronterface, un host avancé avec mode console, intègre le moteur slic3r.

Trancheurs :
slic3r, le plus complet des trancheurs gratuits, mais plus difficile à appréhender en raison de la richesse des réglages.
Cura, le plus simple des trancheurs ou comment parvenir à ses fins sans se prendre la tête. Revers de la médaille, on est désemparé quand un modèle réclamerait d'aller plus en détail.
Kisslicer, version d'évaluation gratuite ou payante, il offre une gestion des parcours assez optimisé. Reste peu utilisé, donc peu documenté.


Simplify3D est un trancheur/host payant, mais excellent. Très largement au dessus des autres, il justifie son achat.

++JM

 

[Marc PELTIER]

On peut ajouter ReprapFirmware à la liste des firmwares : c'est celui qu'utilise le contrôleur haut de gamme DuetWifi (très bon, très cher).

Par ailleurs, je signale une nouvelle approche très prometteuse : Klipper, qui déplace la plupart des tâches gourmandes en calcul sur un ordinateur avec un OS Linux, le plus souvent un Raspberry Pi 2 ou 3.

Ce qui reste à traiter au niveau du contrôleur de la machine s'en trouve réduit à pas grand chose, à savoir générer des impulsions de pas au moment précis qui a été défini préalablement par l'ordinateur, et communiqué au contrôleur sous forme de liste d'événements, compactée. En quelque sorte, du temps réel différé...

Il en résulte que, par exemple, une vieille carte RAMPS sur un Arduino 8 bits retrouve une nouvelle jeunesse, et peut générer des signaux Step au timing parfait à 110 kHz, même sur une machine non cartésienne. Par ailleurs, cette architecture logicielle permet de déployer toute la puissance de calcul de l'ordinateur sans devoir faire aucun des compromis qui s'imposent aux petits contrôleurs, même 32 bits, des machines actuelles (mémoire, timing, liaisons série, etc...). Outre la vitesse théoriquement accessible, la qualité d'impression est immédiatement améliorée, du fait de la précision des mouvements.

En gros, tout utilisateur d'un vieux contrôleur un peu limité peut accéder aux performances d'un carte Duet ou Smoothieboard, en ajoutant simplement un Raspberry Pi 2 ou 3 au système. Comme le même Raspi peut aussi supporter le logiciel de host Octoprint, on se retrouve avec une imprimante 3D gérable par WiFi, avec caméra, etc... Grand confort !

Web34, qui remet en route une machine d'il y a quatre ans, et qui a donc sans doute tout oublié , devrait s'en inspirer : tant qu'à réapprendre quelque chose, Klipper, ça vaut vraiment le coup, et ça ne coûtera que les 35€ du Raspberry Pi qu'il lui faudra rajouter à son système actuel !

 

[tyros]

Il y a aussi Mattercontrol qui est gratuit, et plutôt bien fait sans être compliqué:
https://www.matterhackers.com/store/l/mattercontrol/sk/MKZGTDW6

 

[J-Max]

Bonjour,

Je n'ai cité que les principaux. Si on veut une liste exhaustive de firmware, il faudrait aussi évoquer le Robin de MKS.

tant qu'à réapprendre quelque chose, Klipper, ça vaut vraiment le coup, et ça ne coûtera que les 35€ du Raspberry Pi qu'il lui faudra rajouter à son système actuel !

Je suis partagé sur la question, puisqu'on trouve la MKS Sbase (Smoothieware 32 bits) au même prix... Donc pourquoi une surcouche ?
Est-ce que le Pi sera vraiment performant avec Klipper + Octoprint ? Rien n'est moins sûr. Le Multitâche sur Rpi c'est pas vraiment fiable.
Par ailleurs, tant qu'on ne lui demande pas l'interpollation à haute vitesse d'une Delta, une carte 8 bits (Ramps ou équivalent) imprime très bien...
La qualité d'impression "améliorée" franchement il faut voir, car il y a des millions d'exemples d'impressions 8 bits tout à fait parfaites.
Je parle en connaissance de cause car j'ai toujours une partie de mes machines sous cartes 8 bits.

++JM

 

[Marc PELTIER]

Bonjour J-Max,

Je pense que l'approche Klipper est féconde, pour plusieurs raisons :

1 - L'essentiel étant traité sur un ordinateur, les ressources informatiques, et donc les fonctionnalités, pourront augmenter indéfiniment, tout en gardant sur les machines des contrôleurs simples et pas chers.

2 - Le logiciel étant écrit principalement en Python, le firmware va cesser d'être une affaire de spécialiste. On pourra y mettre son grain de sel, et je suis sûr que de nouvelles choses seront inventées. On y récoltera au passage un peu de désordre dans les versions, sûrement, mais pas plus que pour Marlin...

3 - Klipper est très bien adapté à une architecture électronique décentralisée, avec un tout petit contrôleur pour chaque organe de la machine, comme le plateau chauffant, chaque Hot-End /extrudeur, et chaque moteur/endstop, le tout communiquant sans fil pour recevoir la liste d'événements à exécuter, et se synchroniser. Il n'y aurait plus de "carte pour imprimante 3D" qui fait tout, et impose sa personnalité et ses performances à la machine, mais des organes mécaniques ou thermiques "intelligents" et interchangeables. C'est d'ors et déjà possible, et ça ouvre des tas de possibilités...

4 - Ceux qui ont essayé affirment que l'amélioration de qualité est immédiate et flagrante. Klipper ne fait aucune approximation par segments linéaires lors du calcul des pas, et, comme sur ReprapFirmware, n'utilise pas l’algorithme de Bresenham. Les moteurs avanceront d'un micropas juste au moment exact où, selon la physique et en tenant compte des inerties, ils sont censé avancer pour suivre une trajectoire donnée, et peu importe la quantité de calculs nécessaires. Aucun petit contrôleur ne peut faire ça, surtout pour une Delta ou une autre cinématique compliquée. Même si les Firmwares actuels, à force d'évolutions, d'astuces et d'adaptations, donnent de bons résultats, c'est vrai, il y a néanmoins d'innombrables compromis inévitables, les trajectoires ne sont qu'approchées, et il y a des artefacts.

5 - Klipper prend en compte, sans compromis ni approximation, la viscosité et la non-linéarité de l'extrusion (Pressure Advance), comme les dernières versions de ReprapFirmware. D'autres le prétendent aussi, avec plus ou moins de succès, mais par une forme ou une autre d'astuce ou d'approximation.

6 - Enfin, en ce qui concerne le Raspi, il n'est utilisé que parce qu'il est commode, disponible à pas cher, et qu'il y en a souvent déjà un d'installé, à cause d'Octoprint. On pourrait aussi bien utiliser un ordinateur de bureau, un smartphone (?), ou une station de calcul. Une des implémentations les plus brillantes de Klipper utilise un BeagleBone, avec les PRUs en guise de contrôleur : là, ça dépote à 500 kHz sur tous les axes !

Mais de toute façon, le Raspi 3 est bien assez puissant : quatre coeurs avec unités de calcul en virgule flottante, plein de mémoire, que demande le peuple ? La cohabitation avec Octoprint ne pose aucun problème, à condition d'utiliser un Raspi 2 ou 3. Le Raspi Zéro n'est pas assez puissant. Il faut bien comprendre que les calculs de Klipper sont complètement désynchronisés des mouvement de la machine, et ont lieu bien avant ceux-ci. Les aléas de timing de l'OS n'ont donc aucune incidence : c'est bien là l'astuce !

Klipper n'en est qu'à ses débuts, mais déjà, à mon avis, peu de choses l'empêchent d'égaler ce qui se fait de mieux aujourd'hui, selon moi, à savoir ReprapFirmware sur une carte DuetWiFi en 24V. (€€€€€ !)

Il nous faudrait une carte genre RAMPS/DUE , mais fiable, et en 24V, équipée de drivers de moteur genre Pololu, mais avec courant réglable par logiciel.

https://hackaday.com/2017/12/26/fast-3d-printing-with-raspberry-pi-but-not-how-you-think/

P.S. Je viens de lire sur le forum de Klipper qu'une carte clone de Smoothieboard a été adaptée pour fonctionner comme simple exécuteur en aval de Klipper, en oubliant Smoothieware. Par rapport à une RAMPS/arduino, on y gagne en fréquence de pas maximale (300 kHz au moins). Ces cartes ne sont pas très chères, et acceptent 24V.

 

[flogpr]

intéressant , surtout qu'actuellement un raspi se touche à 25euro , sa permet de donné un coup de jeune à son imprimante sans tout jeter .

bon j'y connait rien , mais quand on branche sur son pc avec les autres firmware sa ne fait pas la même chose ?

 

[speedjf37]

Klipper n'en est qu'à ses débuts

Bonjour,

Merci à Marc PELTIER qui m'a fait découvrir Klipper.

Pour l'instant Klipper à l'air assez expérimental (c'est eux qui le dise) et lié à Octoprint.

J'ai parcouru un peut le sujet , je pense qu'il faut attendre si on ne veut pas mettre les mains dans le "camboui"

JF

 

[J-Max]

Bonjour,

Rien ne presse, en effet ! Loin de moi l'idée de dénigrer Klipper.
C'est juste qu'il s'agit de surcouche, ce qui sonne comme une alerte sur mes oreilles.
J'ai testé Octoprint, mais je ne gère pas mes machines avec car je n'en voit pas l'utilité.
Par habitude et par philosophie, j'aime les choses les plus simples et il se trouve qu'elles sont aussi les plus fiables.

Carte "standard" 15€ + Rpi 35€ = 50€ et l'on doit rajouter par dessus le câblage et les drivers.
Carte MKS Sbase <40€, processeur ARM 32 bits, 24V, pas besoin d'octoprint ni de Rpi.
La machine est accessible ou pilotable par le réseau. Le courant des drivers est lui aussi réglable par le firmware.
Drivers type StepStick DRV8825 en 32 micropas ou possibilité de sortir pour attaquer n'importe quel autre driver.

Il y a aussi la MKS Robin, mais dont je ne parlerai pas car non testée à ce jour.

Je suis peu sensible à la mode ou à la nouveauté si elle ne comble pas un problème ou un besoin.
Avec une bonne interpolation gcode par Simplify3D, les impressions sont lisses, nettes, sans artefacts, et autant que la buse peut le permettre : justes.
C'est même assez impressionnant avec une buse de 100µ.
Si les composants de la machine sont de qualité, il reste bien peu de place à une nette amélioration.
Je ne testerai donc pas Klipper car l'amélioration serait sans doute minime et pourquoi remplacer une solution déjà hautement satisfaisante ?

++JM

 

[flogpr]

comme dit plus haut , l’intérêt est surtout pour les personne upgradant leur imprimante , ont trouve pas forcement de mks sbase sur une imprimante pas chère donc ont à déja une carte en 8 bit de base, par exemple moi j'ai pas mal de driver d'avance au cas ou , sa m’embête de mettre à la poubelle quelque chose qui fonctionne bien alors que la si klipper passe le stade du proto , j'ai juste un Rpi à acheté(25e à l'heure actuel , peut etre un nouveau en vue ? ) , et je pense qu'on est pas mal dans ce cas .

 

[J-Max]

Re,

Imprimes-tu mal avec ton imprimante ?
Est-ce dû à la carte ?

++JM

 

[flogpr]

non c'est plus dans une optique d'amélioration pour le plaisir de bricolé

 

[J-Max]

Bonsoir,

C'est ce qui confirme mon sentiment.
Beaucoup de gens se lancent dans les "améliorations", souvent pour plus cher que le prix de la machine au final.
Fréquemment, c'est même le réflexe premier avant même de calibrer la machine comme il se doit.
Autre cas de figure, changer une carte ou des moteurs quand les défauts d'impression viennent avant tout de la structure ou des guidages...
Dans les deux cas, les mises à niveau sont tout bonnement inutiles.
Régulièrement je croise des propriétaires dépités qui m'amènent leur machine en me demandant ce qu'il y a à changer et combien ça va coûter.
La plupart du temps, après quelques réglages, ils repartent le sourire au lèvres avec une machine exploitable en l'état.

Effectivement, si c'est pour le plaisir de tripoter de l'électromécanique, c'est un hobby comme un autre. Mais il n'y a aucune réelle nécessité à cela.

++JM

 

[Marc PELTIER]

J-Max, tes arguments sont parfaitement justes, et pleins de bon sens.

C'est vrai, quoi, pourquoi se casser la tête à développer la métallurgie, alors que les haches en obsidienne polie fonctionnent si bien ?

Blague à part, c'est vrai qu'il n'y a pas d'urgente nécessité à développer autre chose que les firmwares actuels : le plus souvent, ce n'est pas par là que les choses pêchent le plus.

Néanmoins, je soutiens Klipper, et j'en suis un prosélyte, parce que c'est un changement stratégique : évolution illimitée des firmwares, et surtout, architecture électronique décentralisée.

Pour tout ce que je concevrai désormais, dans le domaine FDM, j'aurai Klipper en tête : c'est l'avenir, à mon avis.

 

[J-Max]

Bonsoir,

Tu présuppose que je suis conservateur, ce qui est un raccourci pour le moins risqué.
Je te confirme qu'on peut être dubitatif quant à l'utilité d'Octoprint et de Klipper, sans pour autant être rétrograde.
Ce qui me laisse songeur dans les deux cas, c'est la question de couches supplémentaires. J'y vois une fausse bonne idée.
Très franchement, s'il s'agit de gérer l'interpolation par un ordinateur maître, cela n'a rien de novateur, bien au contraire.
Nombre de CNC et centres d'usinage utilisent un ordinateur dédié et ce depuis des lustres. Je ne vois pas la solution d'avenir là dedans.
Clairement, pour interpréter du gCode, pas besoin d'un processeur qui pulse à je ne sais combien de gigahertz.

Je pense, exactement à l'inverse, que les micro-contrôleurs modernes et les cartes intégrées ont tout leur sens sur une machine.
Les machines autonomes et connectées me semblent une solution sage et durable.
Cela a tous les marqueurs d'une solution moderne et intelligente : économie de matière et d'énergie, gain de volume, etc.
Même si l'on est capable d'imprimer très correctement avec, les cartes 8 bits, ça date de 2005, heureusement que les choses ont évolué depuis !
Aujourd'hui tu as des cartes open source connectées avec des processeurs ARM 32 bits à plus de 100mhz, pour 30 euros.
Un écran tactile basse consommation pour guère plus cher. Déjà l'intérêt d'un ordinateur dédié, même Rpi, est discutable.
Aujourd'hui, qu'apporte Octoprint qui n'existe pas déjà de manière autonome ?
Même la puissance du processeur n'est pas forcément un facteur. Une carte 32 bits n'a aucune latence et même de la réserve.
Aujourd'hui, comme beaucoup de possesseurs d'imprimantes en font l'expérience : les impressions sont de très haute qualité.
Il ne faudra pas des années avant d'avoir des interpréteurs de gCode et des firmwares encore meilleurs,
lesquels tourneront sur des cartes encore mieux connectées, le tout pour un prix de plus en plus démocratique.
Mon sentiment est que l'avenir est plutôt à cet endroit. D'ailleurs, aucune de mes 7 machines CNC n'a un ordinateur dédié.
J'ai même récemment mis à jour ma grosse CNC avec une carte d'imprimante 3D sous Smoothieware.
J'envoie directement mes fichiers par le réseau et je lance tout à partir de mon PC de production.
Bilan : aucune perte de qualité, gain de fonctionnalité et de place. En ce qui me concerne, la messe est dite.

J'irai même plus loin. Je pense que les ordinateurs personnels de plus en plus puissants n'existent que pour le business.
On sait largement exporter les fonctions de calcul sur station distantes. La logithèque Cloud croit de plus en plus.
On pourrait déjà ne posséder que de petits terminaux avec juste des fonctions d'interface et de visualisation graphique.
Je pense qu'on y viendra et peut-être plus vite qu'on le pense : ce sera juste une migration de l'économie du marché individuel vers l'économie de fonctionnalité.

++JM

 

[vres]

En ce qui me concerne, la messe est dite.

Amen

Nombre de CNC et centres d'usinage utilisent un ordinateur dédié et ce depuis des lustres. Je ne vois pas la solution d'avenir là dedans.
Clairement, pour interpréter du gCode, pas besoin d'un processeur qui pulse à je ne sais combien de gigahertz.

La différence entre un PC et un Micro-contrôleur ...c'est la puissance de calcul. Les ARM 32bits ont dépassés les 100MhZ depuis longtemps, ma précédente carte employait déjà un DSP 32bits avec FPU à 80MHz, un TMS320C31 de 1993.
Sur mon interpolation, sur chaque cycle, la vitesse est contrôlée par rapport a un vitesse de fin de vecteur ça ressemble à ça :

Vous devez être connecté pour voir ce contenu.

Un algorithme détectent les micro-vecteur issu de vectorisation de courbe pour les transformer en mini courbe de bézier, et ceci sur tout les axes. L'interpolation se fait sur ces mini-courbes de bézier ça ressembe à ça :
pour le calcul

Vous devez être connecté pour voir ce contenu.

pour l'interpolation :

Vous devez être connecté pour voir ce contenu.

et bien d'autre chose ... As tu idée de combien de threads on peut faire tourner simultanément sur un PC ? (tiens je sais pas)

Le PC fait ça très bien, ma première version tournait sur un 386 avec co-processeur, pourquoi confier ça a un micro-contrôleur ?
En revanche l'asservissement des servomoteurs je le fait dans le micro-controleur car je travaille sous windows et on ne peut pas descendre en dessous de 1ms en temps réel et aussi pour des raisons de sécurité.
W10 pour ARM va peut-être changer les choses avec peut-être un version de W10 embedded avec ou sans RTAI, pouvant tourner sur des petites cartes équipée de Qualcomm Snapdragon.

Après tu n'as pas non plus vraiment tord, les moteurs travaillent souvent en basse résolution et tournent souvent en dessous des vitesses start/stop. Ce n'est pas trop ça qui va empêcher les stries et les angles arrondis.

 

[Marc PELTIER]

J-Max, tu as peut être raison. Mais tu vois une surcouche de complication gratuite et peu utile, là où je vois au contraire, à terme, une simplification drastique : la fusion logique, et donc prochaine, de Klipper et de l'un des slicers actuels écrit en Python, pour supprimer carrément le G-Code, qui deviendra une étape de complication inutile, entre le fichier décrivant le volume, et la liste d'évènements d'impression.

Le G-Code a bientôt 60 ans, c'est un des standards les plus anciens de l'informatique. Il fonctionne "très bien", et les arguments que tu as déjà développés peuvent resservir : pourquoi changer ?

Il y a bien des raisons, qui ne relèvent pas de la mode. Le G-Code fait des positions dans un repère cartésien le concept central, alors que la plupart des machines modernes, et bien au delà des imprimantes 3D, ont besoin d'utiliser la trajectoire comme concept de base, avec les NURBS comme mathématiques sous-jacentes. C'est conceptuellement plus simple, plus élégant, plus efficace, et plus près des réalités physiques. Le G-Code ne permet qu'une représentation beaucoup trop sommaire et trop idéale du mouvement, et ne s'adapte aux nouveaux besoins qu'à coup de greffes et boursouflures. Il est par exemple quasiment impossible de coder un mouvement visqueux, qui est pourtant l'essence même de l'impression FDM, alors qu'avec les NURBS, c'est trivial. Se passer du G-Code, et tout remettre à plat sur des représentations mathématiques mieux adaptées, serait, à mon avis, une simplification salutaire.

Je pense que Klipper, ou d'autres logiciels dans la même architecture, va peut-être induire deux simplifications majeures : la suppression des cartes pour imprimante 3D, et la suppression du GCode.

C'est ma vision, mais j'admets tout à fait que je peux me tromper. En tout cas, je ne suis pas prêt à dire des messes pour Klipper !

 

[J-Max]

Bonsoir,

Marc, ce que tu décris est très bien et si cela évolue dans cette direction à l'avenir, je serai probablement parmi les enthousiastes.
Car là il s'agit en effet de créer une carte de gestion qui intègre son propre interpréteur.
Mais ce n'est pas ce qui était débattu ici initialement, c'est à dire 1 carte 8 bits + un Rpi avec Octoprint + Klipper.
Ce que tu décris est plutôt dans ce que j'évoquais : "Il ne faudra pas des années avant d'avoir des interpréteurs de gCode et des firmwares encore meilleurs"
Tu remplaces le terme "gCode" par celui qui te convient, et on y est. On est pas loin de penser la même chose finalement.

@CNCSERV je ne vois pas trop où tu veux en venir avec tout ça...
Je te parle de ce que je connais : une carte que j'utilise qui pédale à 120Mhz, ce sont ses specs, je n'y peux pas grand chose.
Oui, il y en a des plus hautement cadencés, d'accord.
Oui, aussi, un PC a une puissance de calcul supérieure. Bien évidemment.
Je ne communique que mon expérience, et il se trouve que je n'ai pas noté de baisse de qualité en passant d'un PC à une carte ARM.
Même précision dans les cotes, dans les courbes, dans les angles. Même sur la précision d'un trait laser qui est plutôt fin...
Donc pour moi, à l'usage c'est kif kif, voire même plus simple, (plus fiable que windows, j'avais basculé sur Linux CNC) ça consomme moins et ça prend moins de place.
Du coup je l'ai adopté et je me demande pourquoi je me suis encombré d'un PC pour ça toutes ces années...
En toute honnêteté, je précise toutefois que je n'utilise jamais de palpeur et que je ne prends que très rarement les origines pièces.

++JM