Micropython.fr

Firmware CNC en Micropython ?

A l'heure où j'écris, cela n'existe pas, et probablement qu'il faut commencer "petit" pour arriver à quelque chose au final.

L'existant

A peu près rien... Le simple fait que çà n'existe pas indique que l'intérêt est probablement limité...

Sources d'inspiration éventuelles

Pertinence d'un tel portage ?

Des firmwares CNC opensources déjà mâtures et utilisables en production existent. Et on peut notamment citer :

  • GRBL : pour carte Arduino basé ATMega 328 - CNC 3 +1 axes
  • Ramps : pour carte Arduino Mega - I3D 3 + 2 axes
  • Smoothieware : pour cartes ARM Cortex 32 bits - CNC, Laser, I3D : 5 axes ou 3+2 axes.

L'objectif de remplacement en situation de production de ces firmwares serait sans intérêt car :

  • ils sont très bien validés, opérationnels, etc.
  • ils sont peu coûteux côté matériel, etc.
  • ils atteignent un niveau de performance en raison du caractère "bas niveau" du langage C qui sera peu ou pas égalable en Python.

Du coup, quel intérêt d'envisager la création d'un firmware CNC en Micropython ?

Cela pourrait être intéressant / utile de plusieurs points de vue :

  • permettrait d'avoir une solution de contrôle en GCode au moins pour des petits projets, déjà 1 axe, puis ensuite plusieurs axes.

  • pour l'exercice intellectuel de ce type de codage, intéressant de plusieurs point de vue.

  • pour la possibilité de construire une solution modulaire qui permettrait de créer des "blocs fonctionnels" combinables entre eux.

  • fournirait une base didactique beaucoup plus souple que les firmwares C qui sont de véritables "toiles d'araignées" si on veut les modifier. A part Smoothieware qui a un côté modulaire extrêmement intéressant.

Explorations préliminaires à faire

La clé d'un firmware est le contrôle parfait de délai entre 2 impulsions tout en réalisant les calculs associés. Il faut donc évaluer en amont si on arrive à obtenir une fréquence suffisamment élevée entre 2 pulses tout en ayant la possibilité de réaliser un temps de calcul associé.

  • test 1 : fréquence max entre 2 pulse simple haut/bas par codage
  • test 2 : fréquence obtenue avec delay 1 µs entre haut / bas
  • test 3 : fréquence max obtenue avec une boucle 100 ou 1000 entre haut/bas

Les étapes de l'implémentation d'un décodeur de GCode

  • Décodage de la chaîne de GCode = extraction des coordonnées à partir du GCode
  • Réalisation du mouvement simple associé sur un seul axe

  • Réalisation du mouvement synchrone associé sur 2 axes, voire 3 axes

  • Gestion de l'accélération sur 1 axe : note 1 : le nombre de pas à réaliser est fonction de la distance et uniquement de la distance. note 2 : l'acceleration vient simplement modifier l'écart entre les pas, debut et fin

  • Gestion de l'accélération sur 2 axes en mode synchrone

  • Gestion des enstops : à priori simple par interruption

  • Gestion de la planification instructions successives reçues

En clair, c'est tout de même un gros travail, et il faut probablement y aller de façon progressive.

Et aussi ?

Une question fondamentale est probablement le "pourquoi" d'absolument vouloir faire au micropython ce qui est déjà très bien fait par le firmware. Et finalement, dans la mesure où Micropython est capable de communiquer facilement via une UART, on peut aussi considérer la possibilité de contrôler Arduino via la connexion UART directement à partir de la carte micropython. De cette façon, on peut envisager une automatisation par le micropython tout en laissant la fonction de firmware au code C.

C'est en quelque sorte une architecture "slave-master" entre le firmware C et le code Micropython.

On peut par exemple imaginer :

  • que le micropython reçoivent un GCode
  • extrait / traite l'info utile de ce GCOde à des fins d'automatisation élaborée tout en relayant ce GCode vers le firmware pour exécution
  • à réception de la validation par le firware, prendrai en compte cette validation et renverrai le résultat vers le poste de contrôle.

On peut aussi imaginer un flux GCode spécifique pour le code micropython, disons de "haut niveau" pouvant correspondre à une séquence complète de plusieurs GCodes simples qui seraient exécutés par le firmware, vérifiés par micorpython et l'exécution complète pouvant être validée par le Micropython auprès du poste de haut niveau demandeur.

Une telle architecture d'enchaînement de logiques différentes n'est pas en soi propre à micropython, mais elle serait pertinente avec micro-python, une carte Arduino + GRBL pouvant ici être considérée comme une simple "exécutante" (effecteur) d'une logique plus complexe. .