Civade.com

La mécanique

L'objectif n'est pas de documenter cette machine pour refabrication, car à mon avis la cinématique CoreXY sur une découpe laser représente plus de contraintes que d'avantages. Néanmoins les résultats obtenus ne sont pas si mal, aussi cela pourra en inspirer certains..

Genèse

Il y a 3 ans, je suis tombé sur une publication de Morris Vanegas du MIT ( http://fab.cba.mit.edu/classes/865.15/people/morris.vanegas/demo/inspiration.html ) qui m'a particulièrement inspirée. Il s'agissait en effet, grâce à un astucieux trajet de courroies, d'implémenter une machine dotée d'une nouvelle cinématique : CoreXY.

Dans cette cinématique, nous ne sommes plus sur un repère cartésien ou un moteur commande l'axe X et l'autre l'axe Y, mais oû les déplacements sont régis par les règles suivantes (avec A et B qui sont 2 moteurs) :

• Delta X = 1/2 (Delta A + Delta B)
• Delta Y = 1/2 (Delta A - Delta B)

Il y aurait plusieurs intérêts à ce type de configuration :

• Les moteurs étant sur le châssis et non sur les parties mobiles, moins de matériel à bouger lors des déplacements
• le 1/2 dans l'équation ci dessus, suppose des vitesses individuelles de moteurs 2X moins élevées, et donc des vitesses de déplacement max plus importantes.

Vous pourrez trouver plus d'info sur la cinématique sur http://corexy.com/theory.html et la publication originale de la table sur Thingiverse : https://www.thingiverse.com/thing:22005 Pour voir ce que l'on peut faire d'autre avec cette cinématique, vous pouvez aussi jeter un oeuil sur la très intéressante table de traçage de patron : http://web.mit.edu/imoyer/www/portfolio/botofthecloth/index.html également publiée sur Thingiverse https://www.thingiverse.com/thing:6640/remixes.

Prototype

J'ai donc réalisé un prototype reprenant les dessins originaux et en y apportant quelques modifications pour que cela soit réalisable avec le matériel dont je disposais et découpable avec une laser de Fablab (<150W). Il a été découpé dans un matériau intéressant : le Valchromat. C'est très proche du médium, mais possède de bien meilleures caractéristiques mécaniques que l'original. La rançon est que c'est un peu compliqué à découper sur une laser, et il faut au moins 120W pour couper du 6mm... mais bon. J'ai fait cela sur la laser du Fablab de Montpellier.

En voici les : plans Sketchup et quelques visuels. Les courroies et poulies ne sont pas représentées, mais sont du standard des imprimantes 3D Prusa I3. Les moteurs sont des Nema17 de 1.2 A.

J'ai du apporter des modifications manuellement qui ne sont pas sur les plans. Avec des axes de 3mm, cela bougeait beaucoup à cause des efforts sur les courroies. Il a été nécessaire de monterle diamètre des axes support de poulies à 4 voir 5 mm à certains endroits, et bien sur changer les poulies en fonction. Après renforcement et une bonne tension des courroies (il faut vraiment les tendre....), la précision était bien meilleure. Par contre, le couple résistant lors des déplacement a pas pal augmenté....

Au chapitre des modifs, le chariot a notamment été modifié pour permettre le montage d'un laser bleu de 3W et de son alimentation 12V, et son réglage en hauteur pour la focalisation. Il vient de chez Banggood et est pilotable en puissance en PWM (Pulse Width Modulation).

J'ai également découpé un capot, car travailler sur un laser de cette puissance est extrêmement dangereux. Il faut donc TOUJOURS travailler avec le capot fermé.... Voici les plans du capot en DXF et en format Sketchup. Il est dessiné pour être découpé dans du medium / contreplaqué de 3mm. L'assemblage se fait par collage des tenons / mortaises. Cela ressemble à ceci :

L'électronique de pilotage

Le cerveau

J'ai essayé pas mal de trucs différents sur cette machine, non pas parce que cela marchait mal, mais parce que cela faisait une plateforme d'expérimentation mécanique pratique et petite. Marlin sur Arduino Mega.. TinyG2 sur Arduino Due, (sur lequel au passage, j'ai du implémenter la cinématique CoreXY), GRBL sur Arduino Uno. Mais finalement, j'ai été très séduit par un portage de GRBL sur une petite carte ARM 32bits à base de STM32F103C8T6 nommée "BluePill". Pour la programmer, il faut un petit dongle USB nommé "StlinkV2". On trouve l'ensemble à moins de 3 euros sur Aliexpress.

Fonctionnant à 72 Mhz (sois près de 5X la vitesse d'une Arduino Uno), cette carte dispose d'un port USB (qui ne permet pas la programmation de la carte, mais sert de liaison série USB), de 64K de flash, 20k de ram, et de suffisamment d'entrées sorties pour piloter une CNC 3 axes (voir 6 axes nous le verrons plus loin..), les fins de course, un détecteur de longueur d'outil, un laser ou une broche commandée en PWM ou par relais et même l'arrosage et le brouillard.

Cela autorise des fréquences de pas entre 120 et 150Khz, ce qui est pas mal du tout.

La vue détaillée montre en plus du processeur au centre, le connecteur mini USB à gauche et à l'autre extrémité les IO pour raccorder l'interface de programmation qui fait aussi debugger. Deux leds sont intégrées : l'une matérialise que la carte est alimentée, l'autre est branchée sur le port PC13. Nous verrons qu'elle sera utilisée pour matérialiser le status de la carte sous GRBL. Il y a aussi un bouton de reset qui peut s'avérer pratique et un régulateur 3.3V intégré qui permet d'alimenter la carte en 5V.

Autre chose intéressante, comme vous pouvez le voir sur le brochage ci dessus (cliquer pour zoomer), une bonne moitié des entées sorties bien qu'en 3.3V sont tolérantes au 5V. Ceci nous évitera l'emploi de translateur de niveau pour lire des entrées en 5V.

Les muscles

En ce qui concerne les drivers, j'aurais pu utiliser des classiques Pollolu, mais pourquoi pas essayer des Toshiba TB6600: https://www.banggood.com/fr/TB6600-Upgraded-Stepper-Motor-Driver-Controller-for-4A-940V-TTL-32-Micro-Step-2-or-4-Phase-of-4257-Stepper-Motor-3D-Printer-CNC-Part-p-1453122.html. Pilotant des moteurs jusqu'à 3A en 40V max, ils fonctionnent jusqu'à une résolution du 1/32 de pas. Sur un moteur de 200 pas par tours, cela fait donc une belle résolution de 6400 pas pour un tour de moteur. Pas mal!

Le bon cerveau avec les bons muscles

Mais au fait, pourquoi parler des kilo hertz et de pas par tour sur une cnc, et quelles répercussions sur les mouvements de notre machine?

Lors de la conception d'une machine nous cherchons à obtenir des déplacements, à une vitesse la plus élevée possible et avec la meilleure précison/résolution possible. La précision dépend dépend bien sur de la mécanique elle même, mais la résolution dépend de la façon dont nous allons assurer les mouvements sur cette machine.

Étant supposé que le moteur a une vitesse max donnée, si l'on démultiplie la transmission moteur, on augmente la résolution (et le couple) mais en contre partie on diminue la vitesse max.

Sur les à moteur pas à pas, le nombre de pas par tour est généralement de 200 (et beaucoup plus rarement 400 sur certains types de moteurs).

Notre résolution va donc être sérieusement plombée si l'on pilote en plein pas, puisque l'on a même pas un pas par degré d'angle.. Heureusement, les fabricants de solutions de pilotage de moteurs pas à pas commercialisent des solutions permettant de générer des pas intermédiaires (ou micro pas) par électronique.

Très classiques en 1/8e et 1/16e de pas, les circuits les plus récents permettent de faire des subdivisions au 1/32e de pas. Super, nous venons de trouver un moyen d'augmenter notre résolution, mais en contrepartie, notre électronique de commande va devoir envoyer 32X plus d’informations à notre moteur pour une même vitesse de rotation.

Supposons que nous disposions d'une petite machine pilotée par des vis de 8mm au pas de 1.25mm (axe Z d'une imprimante 3D prusa i3). Un tour de vis parcours 1.25 mm. OK, mais quelle est la résolution et les limites de cette solution?

• En pilotant en 1/8e de pas, nous avons donc 200 pas par tour du moteur x 8 micropas = 1600 pas par tour. 1600 / 1.25mm = 1422 pas pour 1mm de déplacement. (résolution < au 1/1000 de mm).
• C'est très largement supérieur aux caractéristiques mécaniques (précision et répétabilité) de notre machine : Ce n'est clairement pas la ou nous perdrons de la qualité.
• La vitesse max à 25Khz (maximum atteignable par GRBL sur arduino Uno) sera donc de 25000/1422=17.5 mm /s.
• C'est cohérent en terme de vitesse pour un pilotage, puisque la mécanique de la machine et les moteurs ne permettront pas d'atteindre ces limites,...
• Nous pourrions même passer en 16e de pas sans pour autant que cela soit pénalisant (c'est d'ailleurs ce qui est fait sur une imprimante 3D). Cela ne limiterait que la vitesse de l'axe Z à un peut moins de 9mm / s ce qui est très acceptable pour cet axe, qui ne bouge que peu.

Prenons un autre exemple, pour montrer que cela ne fonctionne pas toujours. Sur une CNC de grande dimension (> 1m) les mouvements sont assurés par une vis à bille de diamètre 25mm / pas de 5mm.

• En pilotant au 8e de pas, nous avons donc 1 tour moteur = 1600 pas, soit 1600/5 = 320 pas par mm.
• La résolution est donc de 1/320e de mm soit 3 centièmes. C'est pas fantastique.
• a 25Khz, la vitesse max théorique sera de 78mm /s soit 4680 mm par minute. La traversée de notre machine de 1m prendra donc 12 secondes à vitesse max. C'est acceptable.
• Si nous cherchons à augmenter cette résolution, nous passons au 1/32e de pas.
• En pilotant au 32e de pas, nous avons donc 1 tour moteur = 6400 pas, soit 1600/5 = 1280 pas par mm.
• La résolution passe à 1/1280e de mm soit 0.00078. C'est très largement suffisant pour ne plus être visible.
• a 25Khz la vitesse max théorique sera donc de 25000/1280 = 19.53mm/min. La traversée de notre machine de 1m prendra donc 51 secondes. Là ça commence à être franchement lent.... et plus acceptable.
• En changeant de solution de pilotage pour passer sur GRBL/Stm32, la vitesse max passe à mini 120 Khz. La vitesse max théorique passera de 12000/1280 =93.75 mm /minutes. Cette fois ci nous ferons le mètre en 10.66 secondes. C'est nettement plus raisonnable.....

Dans ce 2e cas, les 25Khz de fréquence de pas de GRGL sur Arduino Uno ne suffisent clairement pas à moins de sacrifier la résolution et qu'il peut être souhaitable d'augmenter la fréquence, même pour des machines d'usage maker.

On voit bien aussi que le couple résolution / vitesse est toujours un compromis à trouver... Attention, ces calculs théoriques ne tiennent pas compte des caractéristique moteur, qui justement imposent une vitesse de rotation max, d'un couple résistant qui varie avec le carré de la vitesse, et du couple moteur qui plafonne puis dégringole avec la vitesse (au moins sur les pas à pas). Cela fera certainement hurler un mécanicien (que je ne suis pas) mais a uniquement pour objectif de démontrer l'intérêt de la montée en fréquence sur une solution de pilotage pas à pas.

Petite pirouette finale : si on veut vraiment monter en vitesse, et qu'on est bloqué par les caractéristiques techniques de moteurs pas à pas, on peut utiliser des servos moteurs CC ou AC qui sont capables de monter à plusieurs centaines voir de tours minute sans problème, et d'être pilotés en STEP/Dir comme un moteur pas à pas. le cout n'est pas le même mais dans certains cas, c'est la seule solution viable. Plus découvrir ces solutions voir par exemple https://www.banggood.com/fr/search/closed-loop-driver.html

Au final, l'ensemble STM32 + drivers TB6600 va donc nous permettre de piloter une large gamme de machines, avec des moteurs pas à pas 4A/40V max, et le tout à 120Khz. 3 drivers à 9 euros, un stm32 à 3 euros : 30 euros pour une solution de pilotage de ce niveau c'est juste imbattable.

Software:

USBCNC/GRBL STM32

Côté logiciel, c'est un peu compliqué à suivre...

En effet, le premier portage sur STM32 "BluePill" a été réalisé il y a près de 3 ans (auteur?) et mis à disposition sur https://github.com/usbcnc/grbl . J'ai pas mal travaillé avec à l'époque et ajouté du support pour la compilation sur OSX et par Makefile. Malheureusement mes contributions n'ont pas été intégrées par l'auteur.

Plus récemment, j'ai repris le projet afin de pouvoir le compiler sous Visual Studio Code + PlatformIO. Objectivement ca fonctionne plutôt bien. Mes premiers essais récents ont étés faits sur cette branche. J'ai cloné le projet sur mon compte Gitlab avec les modifications faites pourle compiler avec Visual Studio Code + Plaformio. A voir sur https://github.com/ewidance/grbl-usbcnc-stm32

Toutefois, sur https://github.com/usbcnc/grbl , le bug report commence à se remplir sérieusement.. et l'auteur ne bouge plus depuis plus de 2 ans. Même les correctifs de bugs soumis ne sont pas intégrés. Du coup, ce sont près de 200 forks (https://github.com/usbcnc/grbl/network/members) qui ont étés réalisés.. sans pour autant que le projet d'origine en bénéficie. C'est dommage, car ce n'est clairement pas l'esprit du logiciel libre.

RoboMechs 6-AXIS-USBCNC-GRBL

Parmi tous les forks d'usbcnc, identifier les projets qui ont beaucoup vraiement bougés et on ajouté pas mal de fonctionnalités n'est pas simple. L'un des plus évolués est celui de Robomechs : https://github.com/robomechs/6-AXIS-USBCNC-GRBL

L'auteur (Yaroslav Vlasov) a fait un travail remarquable en permettant de passer GRBL jusqu'à 6 axes et en corrigeant de nombreux bugs à la version d'USBCNC (en fait tous ceux qui ont étés listés sur le bug report d'usbcnc). Pour le compiler, il faut la chaine de développement d'Atollic: TrueStudio for STM32. Elle est gratuite et peut être téléchargée à partir de https://atollic.com/truestudio/.

L'auteur semble notamment avoir fait un travail important sur l'affectation des fonctions GRBL aux broches du microcontrôleur. En effet, il semblerait que l'on ne puisse pas utiliser n'importe quelle combinaison de broches pour n'importe quel usage. Certaines n'ont pas les mêmes caractéristiques en sortie (courant réduit) et d'autres ne peuvent pas réellement être utilisées entrée dans toutes les conditions sous peine de perturber le microcontrôleur durant les phase de boot. Enfin les broches step et dir de pilotage des moteurs doivent impérativement être sur le même port, sous peine de perte de performance. C'est d'ailleurs pour cette raison qu'en version 6 axes, les 2 derniers axes (B & C) ne peuvent pas fonctionner à la fréquence max. Mais c'est un compromis acceptable dans la plupart des cas.

A l'origine, le mapping des broches sur la version d'USBCNC était comme suit (activée par #ifdef CPU_MAP_STM32F103 dans cpu_map.h):

Vous pouvez cliquer dessus pour agrandir. Vous constatez qu'il reste un certain nombre de broches disponibles. Il est prévu la gestion de :

• Step/Dir pour 3 moteurs
• Enable global pour les 3 moteurs
• 3 sorties pour piloter le moteur en tout ou rien, le moteur en PWM et un enable global
• 2 sorties pour piloter l'arrosage (coolant) et le brouillard ( mist)
• 3 entrées fin de course pour recherche d'origine
• Une entrée pour la détection de longeur d'outil
• 4 entrées pour le contrôle (reset, start, feedhold, etc..)

Pour passer en 6 axes, Yaroslav Vlasov a revu complètement le brochage. En voici le résultat :

Cette fois ci nous trouvons :

• Step/Dir pour jusqu'à 6 moteurs
• Enable global pour les 6 moteurs
• 3 sorties pour piloter le moteur en tout ou rien (enable) la direction(nouveau!!!) et un PWM
• 2 sorties pour piloter l'arrosage (coolant) et le brouillard ( mist)
• 6 entrées fin de course pour recherche d'origine
• Une entrée pour la détection de longeur d'outil
• 4 entrées pour le contrôle (reset, start, feedhold, etc..)

Par contre, il y a de sérieuses limitations lors de l'utilisation du 6e axe. En effet, les broches utilisées sont celles qui servent habituellement à la programmation par le STlink. Lire les notes de l'auteur sur le sujet... Mais en utilisation amateur rare sont ceux qui dépasseront 4 axes. De plus même avec ce brochage, on peut par configuration activer le 4e, le 4e et 5e, ou le 4e et 5e et 6e. C'est donc assez souple.

A noter que la version de Yaroslav Vlasov peut fonctionner avec les 2 brochages alternatifs, et donc est rétrocompatible avec les montages qui ont étés fait en utilisant l'ancien brochage 3 axes. Pour l'ancien, il faut définir "CPU_MAP_STM32F103". Pour le nouveau il faut définir "ABC_AXIS_EXAMPLE".

N'ayant pas franchement envie d'installer la chaine de développement d'Atollic, étant déjà pratiquement intégralement sous Visual Studio Code + Platformio, j'ai fait une adaptation pour permettre la compilation dans cet environnement. Je l'ai gittée sur https://github.com/ewidance/6-AXIS-USBCNC-GRBL . N'hésitez pas à utiliser le lien et le compilateur d'origine pour fabriquer la version de Yaroslav Vlasov. Cela vous permettra de bénéficier des mises à jour futures. La mienne n'est là que pour garder une mémoire de l'adaptation faite pour utiliser VSCode.... et pas à recevoir toutes les MAJ.

L'installation de Visual Studio Code et Plaformio ne pose pas de problème particulier. Installer d'abord VSCode à partir de https://code.visualstudio.com/ . Une fois installé et mis à jour, dans la barre de gauche, module "Extensions", chercher "Platformio IDE" et installez le. Vous pouvez aussi installer "GitLens" pour avoir une meilleure gestion des repository Git, mais cela l'a rien d'obligatoire.

Ensuite, le projet peut être simplement chargé à partir de l’icône de gauche donnant accès à la page d'accueil de Platformio dans VSCode, et "Open Project".

Platformio détecte le compilateur et les bibliothèques requises et les télécharge. Il est alors prêt à l'emploi pour cette plateforme.

La compilation ou l'upload sur la cible ne pose par de problème particulier. Toujours lorsque l'on a cliqué à gauche sur Platformio (1), apparait une liste de taches:

• "Build" (2) va seulement compiler,
• "Upload" (3) va compiler et envoyer à la cible, au travers de l'interface de programmation STLink V2.

Le raccordement de l'interface de programmation à la bluepill est lui aussi un leu d'enfant. Utiliser les câbles livrés avec pour raccorder les fils de même nom ensemble (VCC> VCC, GND > GND, etc..). Avant de mettre sous tension, vérifier à nouveau que vous n'avez pas permuté les fils d'alimentation ce qui serait destructif.

IL faudra également installer les drivers ST : https://www.st.com/en/development-tools/stsw-link009.html

La programmation via STLink est rapide (qq secondes). Le programme ne remplit d'ailleurs pas toute la ram / flash du STM32, il y a encore de quoi faire pour de futures évolutions :

Memory Usage -> http://bit.ly/pio-memory-usage
DATA:    [===       ]  26.9% (used 5500 bytes from 20480 bytes)
PROGRAM: [======    ]  60.1% (used 39404 bytes from 65536 bytes)

Adaptation à votre machine

Tout comme sur GRBL sur Arduino, le gros de la configuration se fait dans 2 fichiers :

• inc/config.h ou l'on fait le choix du brochage (CPU_MAP_STM32F103 ou ABC_AXIS_EXAMPLE voir leur définition dans inc/cpu_map.h)
• inc/config.h ou l'on fait le choix de la machine et de ses réglages par défaut (définis dans defaults.h). Il est ainsi aisé d'ajouter sa propre machine comme je l'ai fait sur les 2 repos (DEFAULT_COREXYLASER).

Concernant les réglages par défaut, il faut comprendre qu'ils ne sont lus par qu'à partir de l'E2prom. Si cette dernière contient des réglages valides, ils primeront sur ceux qui auraient étés programmés, et ce même en cas de mise à jour du logiciel. Rien de surprenant donc à ce que les nouveaux réglages par défaut ne soient pas appliqués dès lors que les réglages en E2prom sont valides. heureusement, GRBL dispose d'une commande spécifique permettant de réinitialier l'E2prom avec les réglages par défaut : $RST.

• `$RST=$` restores the `$$` grbl settings back to firmware defaults, which are set when compiled.
• `$RST=#` restores the `$#` parameters in EEPROM. At times it’s useful to clear these and start over, rather than manually writing each entry.
• `$RST=*` wipe all of the data in EEPROM that Grbl uses and restores

them to defaults. This includes `$$` settings, `$#` parameters, `$N` startup lines, and `$i` build info string.

Un peu de câblage

Le raccordement est simplifié puisque nous n'avons que 2 axes moteurs, un laser et 2 fins de course pour initialiser la position home. En voici le schéma (cliquer pour agrandir) :

Les essais

Pour les essais, j'ai utilisé différents logiciels (libres et moins libres). Commençons par les logiciels libres :

• https://lasergrbl.com/en/download/
• https://github.com/LaserWeb/LaserWeb4/wiki
• Et plusieurs autres encore, mais c'est hors scope de cet article...

J'ai aussi évalué le logiciel commercial Lightburn. Pas mal du tout, parfaitement compatible avec les différentes versions de logiciels et même les contrôleurs vectoriels chinois Ruida que l'on trouve fréquemment dans les Fablabs. A 40 euros (80 pour la version vectorielle), c'est plutôt pas mal placé : https://lightburnsoftware.com/

La machine marche pas mal et permet de graver en profondeur sur du contreplaqué bouleau avec une jolie précision. Un petit exemple :

Ici, gravé à 100% de puissance laser et 45mm / secondes (2700 mm /min).

C'est probablement frustrant de ne pas voir plus d'exemples, mais j'ai déjà écrit beaucoup de choses dans cet article et entre le logiciel, le matériel, les logiciels de pilotage, ça fait énormément de choses à documenter.. J'ai essayé de rester concentré plutôt sur les aspect conception et test machine, en espérant que cela ne génère pas trop de frustration pour toi, lecteur :). Je te rassure néanmoins, la machine marche bien !

Quelques photos du proto terminé (capot de protection enlevé)

(cliquer pour agrandir)