les réelles différences entre un controleur 8b et 32b ?

Bonjour à tous,

Pour mon premier post en ce lieux je viens avec une question à laquelle je n'ai pas trouvée de réponse pertinente depuis 2 jours.

J'ai une Monoprice Maker Select v2 depuis 1 an, sa carte Melzi en plus de me heurter à ses limites, me donne des signes de défaillance de plus en plus inquiétants.

J'ai tout d'abord songé à la remplacer par une RAMPS low coast mais en cherchant des renseignements à ce sujet je suis tombé sur le firmware Klipper et les prétendus avantages des contrôleurs 32b

Klipper est bien documenté et j'ai compris l'avantage de déléguer les calculs de cinématiques à un CPU, plus avancé en laissant au MCU la simple gestion électrique et des moteurs.
Mais est-ce qu'il est à un stade suffisamment avancé pour faire autre chose que des expériences ?

Sinon j'ai vu pour quelques dizaines d'euros en plus (bon presque deux fois plus cher qu'un kit RAMPS), la MKS SBASE 1.3 avec AVR 32b

On parle d'une vitesse d'impression possible beaucoup plus élevée dépassant les capacité de l'extrudeuse (où est l’intérêt du coup ?)
et j'ai aussi vu quelques photos où la qualité d'impression est bluffante, presque un peu trop, avec des lignes parfaites comparée à la même machine en 8b.

La question finale est : est-ce que ça vaut vraiment la peine pour une cartésienne low coast, de casser ma tirelire pour une MKS 32b, et si je veux du 32 au prix du 8, est-ce que klipper est vraiment utilisable ?

Merci

Salut,

Pas de réponse à t'apporter, mais ça m'intéresse aussi d'avoir l'avis des gens.
J'envisageais de passer sur du 32b pour ma future machine

Merci d'avance,
Cordialement

---

Ma Prusa i3 (ancienne imprimante, transformé en Itopie depuis)
Mon Itopie
Mon thingiverse
[TUTO] Lcd full graphic avec firmware Marlin
--
Possibilité de vous imprimer des pièces, n'hésitez pas à demander en MP

Bonjour.
Je suis en cours de mise au point d'une Rostock "enlarged" (en attendant ma Zatsit qui ne saurait tarder :>) ). La question de l'électronique s'est donc posée.
Je suis parti sur ce que j'avais en stock, soit arduino mega avec Ramps, et Marlin 1.1.8.
Sur une Delta avec des moteurs 400 pas et drivers DRV8825 réglés à 32 micropas, c'est clairement insuffisant. On est très limité en vitesse, ce qui est quand même dommage pour une delta. Ca a permis de faire les premiers tours de roues, mais pas plus.
Passage à Klipper.
Ca semble fonctionner plutôt bien, même si j'ai encore peu de recul. Un homing G28 peut se faire deux fois plus vite qu'avec Marlin. J'ai imprimé à 5m/min (un peu plus de 80mm/s) sans soucis. C'est pas vraiment un exploit puisqu'une prusa le fait sans problème, mais avec des moteurs 200 pas et 16 micropas "seulement".
Tous les tests qu'on trouve sur Klipper semblent montrer que le contrôle des mouvements est bien meilleur qu'avec arduino+ramps lorsqu'on monte en vitesse. Ca demande un raspberry en plus et octoprint. Je ne connaissais pas, et ça n'est pas insurmontable, loin de là. Pour l'instant, je trouve ça bien, même si c'est assez différent de repetier. Bon, ça va quand même faire plus d'une heure que le raspberry tente de calculer ma géométrie de delta en calibration avancée.... Mais c'est un premier essai, et pas forcément indispensable.
J'ai une MKS 32bits en attente, mais pas encore testée sur une imprimante. Petit soucis : malgré plusieurs essais, impossible de mettre un LCD dessus. Soit je n'ai rien, soit je n'ai pas de rétroéclairage, même en "bidouillant" les modules LCD. Donc, je conseille de prendre un kit MKS + afficheur compatible pour éviter les surprises.
Pour une imprimante cartésienne avec moteurs 200 pas et 16 microstep, je ne suis pas certain qu'une MKS 32b s'impose face à Klipper. Dans cette config, arduino+ramps+Marlin permet déjà d'imprimer à 85mm/s sans problème, à condition que la hotend suive évidemment.
Si on passe en moteurs 400 pas et 32 microstep, je pense que klipper ou MKS 32b deviennent indispensable.
Coté tarif, arduino+ramps+kit raspberry (alim, boitier), ca doit pas être bien loin d'une MKS1.3.
Ensuite, klipper + MKS 32b, ça doit être une boucherie !

Merci pour le partage d’expérience au sujet de klipper.
Pour le temps de calcul ça semble logique, le pi reste un CPU 32b ou 64b précis mais peu véloce.
Je suis pas sûr qu'une MKS change grand chose pour lui, comme le contrôleur n'est plus chargé que d'envoyer les impulsions aux drivers.
Une plus grande vitesse d'horloge oui mais une précision plus haute serait inutile amha.

Salut.
J'apporte ma modeste contribution...
J'avais cherché beaucoup de doc concernant ces affaires d'électronique quand je me suis penché sur les delta.
Clairement, les calculs en vitesse "courante" sont accessibles avec un processeur 8 bits. Mais si l'on cherche à profiter des bienfaits d'une delta (qui par construction est nécessairement plus rapide qu' une cartésienne...) on ne peut plus se limiter à un 8 bits, il faut passer une gamme au dessus. Ça c'est pour les deltas qui nécessitent de gros calculs.
Pour les cartésiennes, là encore pour est affaire de compromis. On peut rester sur du 8 bits si l'on veut faire du très précis et pas très vite. Typiquement des moteurs en 400 pas et des drivers en 1/32 ça passe avec des vitesses de 40mm/s. Ensuite, de deux choses l'une: ou l'on veut juste aller plus vite ou l'on veut tirer le maximum des capacités des imprimantes et en particulier des têtes. Si l'on veut faire vite et précis le 8 bits sera totalement surcharger et il y a fort à parier que la qualité sera pourrie. Si l'on veut faire vite et précis, il y aura nécessairement un volume de calcul important et donc les 8 bits low cost low frequency seront directs hors course.
Aussi, si tu cherches à faire de belle impressions très vite avec une mécanique capable de suivre, il te faut passer par des solutions moins low cost. Effectivement, un raspberry avec une bonne électronique derrière c'est une très bonne approche.
Voilà pour moi.
@+

Ps:si tu regardes les machines type fraiseuse même 3 axes, aucune ne fonctionne avec une arduino+ramps. Juste parce que la précision demandé fait exploser les 8 bits... Du coup, tu peux aussi t'intéresser à ce type d'électronique.

je me suis peu penché sur le cas des fraiseuses mais il me semble que pour ce genre de machines même de petite taille il faut au moins des nema24 pour avoir suffisamment de couple et donc les capacités électriques de la ramps sont dépassées.
Les petites fraiseuses sont souvent propulsées par des arduino mais avec une shield mach3 plutôt que ramps.

au delà de 3 axes la seule option que j'ai vue c'est un PC à port parallèle avec LinuxCNC ou logiciel propriétaire.

Dans l'absolu, avec un peu de bidouille pas très complexe, tu peux facilement mettre un autre driver sur une carte RAMPS. Ce n'est pas réellement le problème. Le vrai ennui, il vient du volume de calcul. Si tu veux de la précision, il va te falloir passer par des moteurs à 400 pas/tour. C'est pas délirant mais ça veut dire que le calcul est deux fois plus précis. Si en 32 bits ça ne pose aucun soucis, en 8 bits ça oblige à faire de la mamaille pour obtenir les bons déplacements. La encore, pas de soucis mais si l'on veut accélérer c'est mission impossible pour les cadences des 8 bits (sauf à tout re développer mais aucun intérêt...).
Pour toi et ton cas un peu particulier, je te proposerais plutôt d'aller voir vers les raspberry avec un shield pour le gpio et être en direct. Autre solution moins tendue, un raspberry qui fait tourner cura et un arduino+RAMPS pour réaliser les déplacements. Cette dernière solution si elle est plutôt élégante demande à vérifier que cura prend bien tout en compte et ne délègue pas les calculs de positions à l'arduino. Si c'était le cas, tu ne gagnerais que les temps d'accès mémoire (ce qui ne doit pas être monstrueux)
Autre piste pour gagner un peu, va voir du côté des applications grbl. C'est un autre Marlin mais qui a été exploité par d'autres machines que les imprimantes 3d. Il y a fort à parier qu'un hardware en 32 bits soit déjà existant. Dans ce cas, il n'y aurait que quelques petites adaptations à faire pour être bien meilleur.
Je n' ai pas fini de tout regarder mais une solution "simple" serait peut être de voir ce qui se fait pour une MPCNC. Il y a une solution arduino+RAMPS mais il y en a une autre "robuste" et c'est déjà tout près.

@+

Non le pi est "puissant" mais il pêche par l'absence de réelles capacités temps réel.
à cause du multitâche on a vite fait de prendre des retards incontrôlables à cause d'une surcharge CPU ou des bus.

Il peut contrôler des stepper mais de là à caler des mouvements à la miliseconde sur des heures, c'est du quasi impossible (y a qu'a voir ses difficultés avec les simples servo).

Mais mon cas n'est pas particulier. je vais remplacer la board melzi sur une machine de série donc j'ai le choix entre une ramps 1.4 et une mks sbase 1.3
J'ai vu des éloges sur les contrôleurs 32b mais sans réelles explications détaillées de leurs avantages.
J'ai aussi vu passer le projet klipper qui promet les mêmes avantages avec des contrôleurs 8b low coast.

pour les CNC de petite taille j'en ai fait une (table traçante) avec un uno et cnc shield (grbl) je vois pas en quoi les calculs seraient plus complexes que pour une imprimante 3D.
Les chemins à suivre sont les même si ce n'est que dans un cas on dépose de la matière et dans l'autre on en enlève.
La différence c'est surtout la dangerosité des fraiseuses en cas de mauvais réglages ou usage (casse de la fraise par exemple a cause d'une mauvaise vitesse de déplacement ou manque de lubrification)

si on veux fraiser de l'acier avec des nema17 par exemple c'est logiquement possible mais ça impose une vitesse lente qui va causer la surchauffe de la fraise et donc un risque d'éclatement

Edited 1 time(s). Last edit at 01/02/2019 08:00AM by L33thium.

En fait, c'est presque vrai tout ça.
Pour le temps réel. C'est un problème oui mais il y a des façons de contourner. La première façon linux: on prend un noyau temps réel et on l'utilise. Du coup, certains thread passent par dessus d'autres et on a de bons résultats même sur plusieurs heures. La seconde solution c'est les façons "pro". Si tu regardes chez Mach4, il prennent un ordi sous Windows et on adjoint une carte type prokey en ethernet. Il y a une prog particulière qui fait que ça passe mais la prog est inaccessible à l'amateur.
Ensuite, pour les calculs et les fraiseuses 3 axes (voir plus). La différence avec une imprimante 3d c'est la précision requise. Elle nécessite de prendre des moteurs avec au moins 400 pas/tour voir avec des servis. Pour avoir des usinages de qualité (surtout en finition) il faut que les vitesses de coupe soient très bien respectée. Pour que ce soit bien à sa place, il faut un volume de calcul important. Ce volume n'est pas du tout possible avec des procs 8 bits. La seule solution serait de générer du G-code qui utilise des fonctions très simple avec des pas extrêmement petits mais ça va à l'encontre des logiciels classiques.
Après moi je donne un avis, pas la loi. Si tu veux essayer un truc et nous dire comment ça se passe: au contraire, ça permettra de donner des infos à tous le monde.

@+

Fraiseuse 3 axes CNC et imprimante 3D cartésienne devrait avoir une électronique assez semblable en théorie. Mais entre la théorie et la pratique....
Les firmwares d'imprimantes sur arduino ont été développés sur mesure, à grand coup d'optimisation rusées pour que "ça marche". Il n'y a pas que les 3 axes à gérer, on a aussi le chauffage du plateau et de la tête, la ventilation de la tête, un deuxième extrudeur, les corrections de géométrie du plateau, l'affichage LCD ... etc. Bref : du "tout en un" mais plein de trucs qui tournent en même temps et qui finissent par dévorer tout le temps machine. N'oublions pas que ces firmwares ne savent pas tracer un cercle autrement qu'en une série de segments, probablement parce que il n'y a plus de temps de calcul disponible.
GRBL, c'est le même esprit appliqué à la CN : tout est fait pour que ce soit rapide et précis. Code aussi light que possible pour l'interpolation 3 axes. Il n'y a pas très longtemps qu'on peut commander une vitesse de broche ou une puissance de laser. Une fonction arrosage. Et ... quasi rien d'autre. Mais ça fait des cercles (et encore, pas dans tout les cas de figure prévus par le Gcode), et on fait du 3000mm/min sans problème.
L'arduino n'a pas été choisi par hasard, et il peut le faire. Comme le dit L33thium, le raspberry n'a pas l'architecture pour faire du "temps réel". C'est un beau processeur 32b multitâches, mais plus adapté au téléphones portables qu'aux machines CN. Lui faire faire les calculs, et transférer les résultats à un proc 8b qui ne s'occupe que de faire bouger les moteurs comme le fait klipper n'est pas une mauvaise idée. Ca fonctionne plutôt bien pour une delta, mais ça ne semble pas égaler les performances d'une carte 32b. Y'a pas de secret, si on veut générer beaucoup d'impulsions moteurs, il faut une fréquence d'horloge conséquente que n'a pas l'arduino.
Linux CNC, c'est l'étage au dessus. Interpréteur Gcode sophistiqué et performant, noyau temps réel, écriture du code superbe avec gestion d'une HAL. Du très beau et performant travail. Pb : on passe par le port parallèle et ses limitations. Sans compter que ce port n'existe quasiment plus. En plus, adapter linux CNC à une imprimante 3D, ça ne doit pas être facile tant le Gcode des slicers est bourré de particularités.

"temps réel" entre guillemets oui puisque qu'on prends souvent ça pour un indice de puissance.
C'est en fait seulement la capacité de savoir précisément en combien de cycles se réalisera une opération, donc de pouvoir planifier un processus au top d'horloge près.
les micro contrôleurs, sans OS sont parfait pour ça.

C'est pour ça qu'avec un Arduino on peut activer un servo de manière fluide et garder une position précise alors qu'avec un raspberry ses mouvements sont secs, saccadés et le maintiens de position tremblant.
Le pi avec des stepper risque fortement de perdre des pas parce que le timing n'est pas assez précis sur le bus GPIO et sans moyens de contrôles de transmission.
l'OS peut faire passer un bit logique de 0 à 1 puis retour à 0 avant que ça ai pu être transmis au bus parce qu'une tache secondaire à tenté d'accéder à la carte SD causant un IO wait par exemple.
C'est en partie à cause du multi tache et aussi à cause de fonctions non nécessaires pour un CPU de ce type.