Pilotage CNC avec GRBL
Une note de développement autour de mon dernier projet de machine à commande numérique. Des précisions sur l'excellent micro-programme GRBL pour Arduino. Quelques détails à propos d'une interface en Objective-C de ma conception.
CNC "semi-pro" : Mach 3/4
Les solutions "sérieuses" de pilotage de machine à commande numérique sont pour la plupart disponibles sous Windows seulement. Je pense particuièrement aux célèbres Mach 3 et 4 d'Artsoft.
Il s'agit là de logiciels très complets et très satisfaisants qui permettent un pilotage avancé des moteurs (accélérations, interpolations diverses, fine tuning, etc) via le port parallèle. Ils proposent également tout un environnement pour la CNC : une implémentation complète du G-Code, un interpréteur de fichiers EPS ou JPEG, un outil de jogging, divers offsets et compensations de diamètres d'outils et plus encore). Des plug-ins spécialisés sont également disponibles.
Cependant, je souhaitais depuis longtemps obtenir des fonctionnalités comparables sous Mac OS. Outre l'avantage de se passer d'une seconde machine, cela me permettrait d'écrire mon propre logiciel en Cocoa / Objective-C.
CNC avec les librairies pour Arduino
Les librairies de contrôle de moteurs pas-à-pas proposées sur Arduino fonctionnent bien mais ne sont pas suffisantes pour piloter une CNC. La librairie "stepper" par exemple, n'offre pas de solution facile pour les accélérations/décélérations et plus grave : aucune interpolation n'est présente.
Il y a bien la librairie "accelStepper" qui met à disposition des accélérations convaincantes, mais là encore, pas d'algorithme d'interpolation utilisable.
GRBL !!!
Mes recherches m'ont finalement conduit à l'excellent GRBL qui fait référence en la matière. Grands bravo et merci aux auteurs ! Ce micro-programme n'est pas un traditionnel sketch pour Arduino mais bien une application embarquée, optimisée pour le micro-contrôleur. Son installation, bien documentée, est très facile, même si ce n'est pas la manière habituelle de procéder avec les Arduinos.
Avec GRBL, nous avons :
- Un contrôle des moteurs avec interpolation 3 axes et gestion des accélérations !
- Un interpréteur de G-Code quasi complet
- Une interface série à 115200 bauds pour pousser des commandes et du G-Code
- une prise en charge des fin de courses et autres commandes hardware.
La documentation en ligne est très bien faite et couvre clairement la plupart des questions liées à l'installation et l'utilisation. J'ai installé ce micro-programme sur un Arduino Nano, sans rencontrer le moindre problème.
Stream du G-Code vers GRBL (série)
GRBL ne donne pas d'interface autre que le port série. Des logiciels de tierce partie existent pour cela et sont présentés dans la documentation. Cette doc donne aussi divers conseils pour ceux qui souhaitent développer leur propre logiciel.
Une difficulté réside dans le fait que GRBL possède un buffer d'entrée série limité à 127 caractères. Il est de la responsabilité du développeur d'exploiter au mieux ce buffer, c'est à dire :
- Ne pas envoyer de données au delà de ces 127 caractères
- Envoyer toutefois les données le plus rapidement possible car GRBL optimise le pilotage des moteurs en fonction du chemin à venir.
Par exemple, si on a une succession de très courts segments, GRBL va profiter d'en connaître à l'avance les coordonnées pour assurer un mouvement fluide. C'est la fonction de "look ahead".
Si on se contente d'envoyer les segments un par un, il y aura un mouvement saccadé, ce qui pose des problèmes assez embêtants (ne serait-ce que mécaniquement à cause de l'inertie de la machine).
Pour chaque ligne de G-Code envoyée, GRBL envoie un accusé-réception. Il suffit donc de maintenir un compte exact du nombre de caractères envoyés, et de retrancher ces nombres à chaque confirmation reçue. Le stream de G-Code est donc régulé selon ce décompte de manière à remplir le buffer au maximum sans le dépasser.
J'ai développé une implémentation de cette méthode dans mon application Cocoa "Glyphs.app" avec succès. GRBL et cette méthode de stream constitue le coeur du système.
Glyphs.app
j'ai enrichi ce coeur avec diverses fonctionnalité de plus haut niveau :
- Outil typographique complet avec conversion vers G-Code
- Import et conversion de dessin vectoriel au format SVG grâce à : cette classe.
- Import d'image bitmap pour rasterisation ou autre conversions.
- Fonction temps réel de homing, feed hold, zero machine et offline mode
- terminal d'envoi d'instructions ou de G-Code.
- console de monitoring
- simple jogging
-
Séquence de G-Code optionnelle exécutée tous les x mm parcourus (voir après).
Séquence de G-Code optionnelle
L'objectif pratique qui m'a conduit à développer cette fonction est de pouvoir utiliser un pinceau comme outil de dessin et d'exécuter une routine de "trempage dans le pot de peinture" de temps en temps.
Le bloc de G-Code est arbitraire et on peut imaginer une séquence plus complexe par exemple :
- lever d'outil
- déplacement rapide jusqu'au pot de peinture ou d'encre
- trempage
- essuyage de la goutte de trop sur le bord du flacon
- retour à la position de travail à vitesse réduite
- reprise du tracé
Avec un peu de développement additionnel il est tout-à-fait envisageable d'avoir plusieurs couleurs différentes et une routine de rinçage du pinceau. L'information de couleur du tracé est en clair dans le fichier SVG et pourrait, je suppose, facilement être récupérée.
Dans le décompte de la longueur parcourue, on ne compte que les tracés et pas des déplacements de positionnement.
À propos du format SVG
Ce format de dessin vectoriel encode des tracés, polygones et autres formes primitives (cercles, rectangles...). La classe de conversion "tracé vers NSBezierPath" que j'utilise ne peut interpréter que les tracés (balise "path").
Avant de sauvegarder un travail sous Illustrator au format SVG, il faudra convertir toutes les formes primitives en véritable tracé (type "path"). Jusqu'ici, la solution la plus directe que j'ai trouvé est de sélectionner tout (ou seulement ces primitives) et de créer un "tracé transparent" (Objet > Tracé transparent > Créer).
Quelques détails sur la machine (v1)
J'ai construit par le passé une machine assez grande et plutôt satisfaisante (4 axes, courroies crantées, démultiplication, guidage sur roulements...). Elle était équipée d'un driver de moteurs 4 axes "otocoup" au demi-pas et je la pilotais avec Mach 3 sur un PC. Tout ceci est fort encombrant et j'avais envie de quelque chose de plus léger.
J'ai décidé d'en construire une autre, aussi simple et cheap que possible, sans trop sacrifier la précision et avec beaucoup de récup'. Ceci m'a conduit aux choix suivants :
- entraînement par câbles (en fait : de la corde "Dyneema" fine, souple, très résistante et presque exempte d'allongement sous contrainte) enroulée sur tige filetée motorisée en direct.
- guidage par glissières de tiroir
- fabrication en bois
- système de plateau X/Y : l'outil est fixe, c'est le medium qui se déplace.
- long bras porte-outil pour l'axe Z (une sorte de potence).
L'entraînement par câble enroulé sur tige fileté est une solution très facile à mettre en oeuvre, bon marché et plutôt satisfaisant. Il y a une erreur de parallaxe inévitable mais en pratique, cela n'influe que très peu sur la précision et je ne cherche pas le 1/100 de mm :-).
En revanche, les glissières de tiroir sont assurément les pièces faibles de l'ensemble. Le guidage est plutôt doux mais pas assez rigide. L'essentiel des défauts de positionnement provient de cela. Cela reste une approche valable selon moi pour un bricolage.
Sachant que je possédais déjà les 3 moteurs, le driver de moteurs, un Arduino et quelques petites pièces, cette table de m'a coûté que du temps pour un résultat certes imparfait mais tout-à-fait exploitable (pour du dessin). Je trouve que ceci mérite d'être souligné...
Quelques détails sur la machine (v2)
La zone de travail de la v1 étant par trop limitée à cause du parti-pris "système de plateau X/Y" , je me suis décidé à en construire une autre plus grande sur le principe classique de chariot X/Y (le medium est fixe, c'est l'outil que se déplace).
Les glissières de tiroir ne pouvaient pas convenir non plus à cause de leur course max d'une part et évidemment à cause de leur principal défaut : la trop faible rigidité. Mais il restait hors de question de dépenser trop d'argent en pièces mécaniques spécialisées.
J'ai trouvé en magasin de bricolage des barres d'aluminium de section trapézoïdales. En les plaçant petit côté contre petit côté, on obtient d'honnêtes glissières en V pouvant recevoir des roulements à bille.
J'ai en revanche conservé le principe de l'entraînement par cordelette Dyneema. La tête porte-outil reste similaire dans son concept à celle utilisée précédemment.
La zone de travail est désormais de 45x70 cm et la précision (c.à.d. des trajectoires exactes et reproductibles) est là !
Voici une page très éclairantes sur les difficultés inhérentes aux moteurs pas-à-pas dans la réalité (voir le chapitre sur la réponse fréquentielle).
Un lien vers quelques images de cette v2 et de ses résultats prises par Marc Wathieu lors d'une sympathique intervention à l'un de ses cours (ERG, Bruxelles, 2017).
