Marlin vs Repetier (+ Klipper?)

[Aze]

Dans Fusion 360, je coche l'option 'smoothing' qui justement essaye de transformer au maximum les segments en arc de cercles, ça fait déjà une grosse différence. Mais que ce soit Estlcam ou Fusion360 (je ne connais pas les autres softs), on dirait qu'ils travaillent en 'éléments finis', çàd qu'ils ne voient pas les cercles comme ils sont dessinés, mais les transforment systématiquement en petits segments, et qu'ensuite ils font des approximations pour les transformer en arc de cercle de nouveau.
Je suppose que c'est pareil avec tous les autres, vu qu'ils partent d'un .dxf ou d'un .swg .

[mstrens]

GRBL sur AVR 8bit (arduino uno, mini, nano, mega) est supposé gérer les steps jusqu'à 30 Khz .
Le même soft porté sur STM32 est supposé les gérer jusqu'à 180 Khz.
Personnellement j'ai suivi les explications les explications données par cette vidéo

Dans mon cas, cela semble avoir marché du premier coup. Mes tests sont cependant assez limités (vérifier que GRBL répond aux commandes envoyées par le pc, vérifier que le processeur génère bien des signaux steps/dir avec un digital analyser). Je n'ai pas testé avec une CNC car je n'ai pas encore terminé mon montage de R-CNC.

A noter aussi que cette dernière version de GRBL (1.1) est sensée apporter un gain de performance (optimisation accrue du soft).

S'il est vrai que si un processeur peut puissant peut limiter la fréquence max des signaux steps, il se peut aussi que de faibles vitesses de déplacement peuvent aussi résulter des paramètres max feed rate et accélération qui sont appliqués.

[Tech-raton]

Je vais voir ce que ça donne ce STM32F103.
ça m'a l'air pas mal intéressant...

Mais je vois que les signaux de la STM32F103 sont en 3.3 v, il faudrait donc utiliser un Shield CNC pour arduino nano, non?

[Kachidoki]

Les STM32 ont souvent des pins 5V-tolerant. Sauf peut-être les analogiques.

[Tech-raton]

Je ne suis pas sur de comprendre.

Je m'inquiète des pins dir et pull qu'on branche aux drivers.
Le truc un peu chiant c'est que mes drivers fonctionnent à l'envers.
mon driver est branché à la masse partout sauf pour les 2 pins dir et pul. donc si je leur envoie du 3.3v, je doute un peu qu'ils fonctionnent, mais c'est à tester.
(je verrai quand j'aurais reçu ce stm32)

[Kachidoki]

Les entrées des TB6600 sont optocouplées, on peut les câbler soit avec un + commun, soit avec un - commun.
Le plus courant pour piloter des opto (ou des led en général) c'est un + commun, et on pilote à 0. Et en plus on peut mettre du +5V ou du +3.3V.

Après il faut bien sûr configurer le firmware en accord pour piloter les sorties dans le bon sens.

Pour les pins 5V-tolerant, ça veut dire que même si le micro tourne en 3.3V, tu peux lui appliquer 5V sur les entrées sans danger.

[Tech-raton]

mes drivers sont connectés comme ça:




Je comprends bien le coup des 5v-tolérants de la carte, mais avec mon cablage, est-ce que les drivers vont être capables de détecter les dir et pul en 3.3 v?

Je pense que oui, mais j'aimerais bien une confirmation

[Kachidoki]

C'est quoi le -5V ? Un GND je suppose ?
Dans ton cas de figure, le ENA- ne sert à rien puisque ENA+ n'est pas câblé (c'est peut-être de là que venait ton souci à la base ?). Les indications (+5V) laissent penser que les optos sont calculé pour du 5V, même si je pense que ça passe en 3.3V.

Si ça ne passe pas, il reste la possibilité de câbler les (+5V) sur du 5V justement, et les signaux - sur les sorties du STM32, en veillant à être en sortie à collecteur ouvert, et bien sûr d'inverser dans la config du firmware. Et roule ma poule.

[Tech-raton]

Ok, ça marche, je vais donc tester ça. quand j'aurais reçu le SMT32

Fini le Hors Sujet, on parlait de 32bits, non?

Enfin, d'une carte de commande qui ne galère pas, qui a une possibilité de connecter un écran, un lecteur de cartes SD.
Et une possibilité de mettre du Vert Fluo dessus(Pour Romain)

[Kachidoki]

Pour la DUE je suis pas très fan, c'est encore basé sur un Atmel SAM3, encore un truc impossible à sourcer autrement qu'en achetant des cartes arduino.

Niveau soft 32 bits, c'est vrai que smoothieware ressort souvent, avec une communauté active et grandissante, même si les boards officielles sont chères et leur dev n'avance plus. J'ai même lu quelque part que son algo de "motion" est basé sur GRBL, d'ailleurs il a un mode compatible GRBL. Le micro utilisé est sourceable chez les chinois. Je pense que c'est pas déconnant de repartir d'une version dépouillée du schéma d'origine, et de prévoir un shield pour cnc et un autre avec les drivers pour imprimante.
Côté accessibilité grand public, c'est vrai que les outils sont plutôt orientés pour des vrais développeurs soft (et c'est pas plus mal pour un firmware ), mais d'un autre côté la config se fait entièrement en txt sur la SD, sans tripatouiller du code. Seul le développement de nouvelles fonctions (nunchuk) est moins à la portée de tout le monde, mais est-ce un problème ?

AlfiQue, côté CAO et commande de PCB je sais que c'est du gâteau, mais t'as une idée pour faire équiper les cartes (et pour le vert fluo aussi) ? Sinon Romain va devoir se mettre aux CMS fissa !