Marlin vs Repetier (+ Klipper?)

[AlfiQue]

Donc l'idée serait plutôt un shield CNC ou 3Dprint avec seulement 1 micro 32bits ?

Kachidoki tu as un schéma smoothieware ?

Pour l'assemblage, aucun problème pour la pose des composants sur solderpaste par contre la refusion ....

et pour le vert fluo, j'ai pas de solution

[mstrens]

Personnellement, pour une CNC, je penche plus pour un shield supportant 2 modules (blue pill) ayant chacun un STM32 (32 bits à 72 MHz à comparer aux 8 bit 16 MHz des arduino mega).
Un des modules tournerait le soft GRBL et gèrerait uniquement les moteurs, la broche et les éventuels fins de course.
L'autre gèrerait par exemple une carte reprap discount 128/64 (comprenant un écran, une carte SD , un rotary switch) et éventuellement un nunchuk.

Le shield assurerait seulement les connections entre les 2 blue pill ( simplement 2 signaux serial), entre chaque blue pill et ses propres périphériques et éventuellement le relais de commande la broche:
- pour le blue pill avec GRBL, prévoir les connecteurs vers les drivers, les connecteurs pour les fins de course et le relais (et un transistor de commande)
- pour l'autre blue pill, prévoir les 2 connecteurs vers la carte reprap et 1 connecteur I2C pour la nunchuk.
Le shield serait donc très simple à réaliser (peu de composants).

Le coût total de cette solution (sans les drivers TB6600 et l'alim) est de l'ordre de 15 €.
La principale difficulté est de réaliser le software à implémenter sur le blue pill gérant l'écran et la carte SD.
Toutefois, il n'est pas nécessaire de partir de rien car il existe déjà des librairies pour assurer la partie la plus complexe (affichage écran et gestion de fichier sur la carte SD).
Pour GRBL sur STM32, le soft nécessaire est en principe disponible.

[Kachidoki]

Hello,

Et hop !

EDIT: post écrit en même temps que celui de mstrens, donc aucun lien.

C'est une idée comme ça, plutôt que d'avoir une carte avec les drivers intégrés qui seront inutiles car trop petits pour une CNC, autant prévoir deux versions. Une carte micro, avec le minimum vital, alimentations connectiques (USB, SD, écran...), et un shield, au choix pour une printeuse, ou pour une CNC avec les fonctions supplémentaires (nunchuk, relais, stepper driver...)
Ou alors une seule qui fait tout mais avec des drivers prévus pour encaisser des NEMA23, mais bon si un truc crame c'est galère.

Après si c'est un ou plusieurs micros, c'est encore en discussion. Mais je pense qu'il doit être possible de déléguer la génération des Ksteps/sec à un micro dédié pour en avoir un max et précis. Plus je nage dans le code de Repetier, plus je me dit que c'est tout le motion planner qu'il faudrait sortir, et ça revient justement à un équivalent de GRBL, sauf que GRBL est orienté CNC, il y a quelques différences et je ne suis pas sûr qu'on puisse l'adapter sur une imprimante.

Faut que je regarde un peu plus la beaglebone black (et replicape) avec ses deux PRU (un seul d'entre eux est déjà plus puissant qu'une smoothie), j'en ai entendu que du bien sur la qualité des Ksteps/sec générés, j'aimerai bien savoir qu'est-ce qui tourne réellement sur les PRU juste pour l'architecture.

Pour l'assemblage, je parlais bien de faire faire à l'extérieur, je ne sais pas si ce genre de service est accessible aux petits makers.

[Aze]

C'est clair que les bluepills à moins de 2€ pièces c'est difficile à battre quand même pour du 32 bits (x2!)
(Même le ST-LINK pour charger le bootloader coûte moins de 2€, c'est franchement pas la mort)
http://electroniqueamateur.blogspot.fr/ ... -avec.html

Et ça reste de l'arduino au final (et du GRBL), donc c'est déjà populaire tout ça (pour en revenir à ce que disait Kachidoki).

Je suis à des années lumières de votre niveau de compétence dans ce domaine, mais clairement, pour une machine comme la R-CNC, qui se range dans la catégorie "pas chère et qui marche déjà pas mal", je choisirais aussi une carte de la même catégorie (donc pas forcément du 200MHz et pas forcément un écran tactile, surtout s'il y a un nunshuck qui facilite la vie).
Bref, j'aime bien l'idée de Mstrens, de mon point de vue de profane. Et c'est vite testé en mode 'breadboard' en plus. Question bête au passage: l'affichage sur mes imprimantes 3D (Full Graphic et Smart LCD) est plutôt 'lent': avec une bluepill par exemple, ce sera plus rapide où y aura toujours cette latence à l'affichage?

[Tech-raton]

Quand j'ai regardé les boards disponibles, je suis bien sur tombé sur la beagle bone black.
Pour une CNC, c'est probablement le top. En plus, elle permet de maire tourner linuxcnc dessus (enfin, Machinekit, une version adaptée )
En gros, la beagle bone black permet de faire ordinateur + controlleur CNC.
Elle est hyper puissante, (et là, c'est pas le même délire.)
Niveau budget, on commence à décoller, quoi.
Elle coute 60 euros environ sans shield.

On est loin de l'arduino mega cloné avec sa ramps...

Si le tft32 contient un processeur et qu'il ne fait qu'envoyer des codes à la ramps, ce ne serait pas plus facile de faire un shield pour le smt32 avec un branchement pour l'écran TFT32?
ça permettrait de faire tourner GRBL sur le smt32 et on pourrait utiliser l'écran pour gérer les commandes?
on aurait donc 2 processeurs, un pour la génération de steps (le smt32) et un pour l'IHM (le tft32).

ça sonne bien, par contre, je ne sais pas trop comment ils peuvent communiquer ensemble. Dans un lien de mstrens, on pouvait voir un écran pour grbl, donc c'est qqch de faisable.

[mstrens]

la communication entre GRBL et un autre système (PC ou autre micro) est prévue par un port série.
Le protocole est parfaitement documenté sur le site de GRBL.
En gros, GRBL accepte des commandes en GCODE (ex : "G01 X10 Y20 Z1.1 F50") et répond à chaque commande par un "OK".
Ces messages "OK" permettent au PC(ou au micro) de synchroniser l'envoi des commandes avec les possibilités de réception de GRBL, le micro gérant GRBL n'ayant pas un buffer suffisamment grand pour stocker un grand fichier de GCODE; le GCode doit donc être envoyé par ligne de commande au fur et à mesure de leur exécution.

GRBL a plusieurs niveaux de buffers pour pouvoir stocker plusieurs commandes, les décoder et planifier les mouvements de manière à être aussi "souple" que possible sans avoir de perte de pas.

Par ailleurs, GRBL accepte quelques commandes qui sont exécutées immédiatement (sans passer par les buffers).
Par exemple le micro peut demander 2 fois par seconde à GRBL quelle est la position XYZ courante et quel est le statut de GRBL (moteur tourne, moteur au repos, ...). Cela permet de tenir à jour l'écran géré par le micro.

Voila le principe.

[Tech-raton]

Merci !

J'avais à peu près compris, alors, ça me rassure
https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl
Donc on est bien d'accord que "l'envoyeur de Gcode" pourrait être ce qu'on veut tant qu'il est capable de communiquer par le port série.
Et l'écran TFT32 fonctionne de la même manière.
Sauf qu'on aura les mêmes problèmes de connexion USB/TFT32 que pour le CNCshield développé en ce moment... ^^

[RoMaker]

C'est un faux problème le TFT32 sur le shield, c'est juste que c'était le même UART pour l'USB et le TFT, chacun son UART et plus de soucis !

[Kachidoki]

Tout à fait le TFT32 c'est un faux problème mais en aparté, je le trouve très limité. Parler en G-Code c'est bien pour faire tourner la machine, mais c'est tout. Hors là c'est la seule IHM qu'on ait pour configurer la machine autrement qu'en reflashant le firmware, et avoir des retours d'info, notamment la position, ou faire des réglages à la volé, comme la température, le flow ou la vitesse.

Le beaglebone j'en parlais uniquement pour l'architecture à plusieurs micros, c'est clair que c'est un peu comme coller un moteur de ferrari sur une 2cv, il va se tourner les pouces longtemps lol.

De ce qu'il en ressort pour le moment, c'est du STM32 et du GRBL. Le STM32 est très populaire car les demoboard ne coûtent rien et possèdent un debugger intégré (ST-Link) qui peut programmer d'autres STM32. La gamme de micro chez ST est faite pour durer dans le temps, avec un gros accent sur la compatibilité pin à pin. Et les outils de dev ont vachement évolué en bien, tout est gratuit, il y a des configurateurs et des drivers pour les périphériques du micro etc... (Façon je suis déjà un fan, j'ai quelques demoboard perso )

GRBL est en effet très populaire, c'est une solution élégante qui me plait également beaucoup, mais qu'en est-il pour une imprimante 3D ? Est-ce compatible ? Car c'est toujours associé à de la CNC, et j'ai peur qu'on soit en train de partir sur une solution exclusivement CNC.

La méthode blue pills est pas mal en effet, mais je me pose la question de l'intérêt d'un shield + 2 blue pills ? Car dans tous les cas il faut les deux blue pills. Pourquoi pas directement une carte micro avec les deux blue pills intégrés, le debugger, les alim...? Le shield ne servirait que pour ajouter des drivers moteur en gros, et tout ce qui diffère entre une imprimante et une cnc.

Pour l'afficheur LCD, je ne sais pas réellement quel est le point limitant, est-ce l'afficheur lui-même, le bus de communication (4 ou 8bits ? timings à respecter), le micro lui-même ? Les lenteurs que j'ai pu constater sur ma prusa viennent souvent d'une grosse opération interne ou d'un délai avant affichage. Si on veut rester dans les solutions pas chères de tout façon on a pas le choix. Sinon il y a des bons STM32 avec driver de LCD intégré, j'ai déjà fait tourner doom dessus et ça rame moins que sur le premier pc sur lequel j'y jouais

Et enfin (si j'ai pas oublié de points) comme le disais mstrens, le micro qui fait tourner le motion planner, tout est déjà fait, ou presque (3D ?) via GRBL pour STM32. Concernant l'autre micro qui fait tourner le reste, notamment l'écran qui est le point le plus délicat, on a plusieurs solutions. Soit un truc à la TFT32, et dans ce cas rien à faire, c'est du G-Code qui sort. Soit un truc complètement custom, et dans ce cas tout est à faire. Soit faire tourner un firmware existant, et couper au niveau du motion planner. Ou encore un mix, une IHM existante, sur un écran nouveau. En firmware qui tourne sur stm32, je sais pas trop. Juste que smoothieware tourne sur un Cortex-M3, donc c'est portable sur un STM32 (M3 ou M4) sauf si utilisation de périphérique bien spécifique à vérifier.

On est vraiment dans des discussions de barbus là.

[Tech-raton]

ouais, grosse discussion de barbus...

GRBL, c'est uniquement pour la CNC.
Il est trop trop en retard concernant les imprimantes 3d.
Juste en regardant le nombre de Gcodes supportés, on comprend tout de suite le côté archaïque et pas du tout adapté aux imprimantes 3d...

Le Gcode M106 n'existe pas pour GRBL, donc adieu la gestion d'un ventilateur... Je ne parle pas de gestion de palpage, ni de chauffe d'extrudeur, ni de Pid pour la température et encore moins d'un plateau chauffant, de pressure advance, etc etc...

Non, smt32 + grbl c'est uniquement pour la cnc...

Pour une imprimante 3d, smoothieware, c'est pas mal. (reprapfirmware c'est mieux mais je ne suis pas neutre )

Sinon, c'est pas possible de faire tourner marlin sur un smt32?

En cherchant, on trouve des trucs marrants:
https://github.com/St3dPrinter/Marlin4ST
https://github.com/clementleger/Smoothieware-STM32