Gérer des moteurs PAS à PAS revient à compter et décompter en permanence en fonction des consignes de mouvement envoyées à l’électronique de pilotage TB6600. Si à chaque pas effectué la distance franchie est connue, on en déduit la longueur du déplacement effectué. C’est exactement de cette façon que fonctionnent les podomètres « anciens » qui n’étaient pas géo-localisés par les ondes téléphoniques. Le promeneur sachant d’où il est parti, (Donc ce n’est pas Dudule !) en « portant sur la carte » la trace de son déplacement, sait alors exactement où il se trouve. C’est exactement de cette façon que fonctionnent généralement les programmes « en boucle ouverte ». Le fondement de la mise en œuvre des moteurs PAS à PAS réside dans la simplification considérable qu’apporte le fonctionnement en aveugle sur le matériel et sur le logiciel, cette technologie évitant la présence de capteurs complexes pour mesurer les déplacements effectués. On se contente de compter et décompter les pas, et d’ajouter ou retrancher les distances élémentaires aux valeurs des coordonnées. Cette technologie est toutefois basée sur l’hypothèse que toute consigne pour faire un pas soit réellement effectuée, le moteur ne doit jamais se trouver un surcouple. Si un ou plusieurs pas ne sont pas réalisés pour une quelconque raison, les coordonnées théoriques seront faussées. La technologie mise en service sur la machine devra donc satisfaire cette exigence incontournable.
Retour aux Origines.
Jeu de mots facile, je l’avoue, mais je n’ai pas résisté à ce petit plaisir. Redevenons sérieux. Sur cette petite machine nous allons avoir à considérer trois sortes d’origines. Il me semble tout à fait légitime que vous puissiez vous demander pourquoi, et ce d’autant plus que l’Origine Machine ne concerne pas l’utilisateur, elle n’est pertinente que pour le technicien, c’est à dire le concepteur ou le réalisateur de ce projet ludique. Quelle que soit l’origine qui sera prise en compte, nous allons retourner à l’école et fleureter un tout chtipeu avec les coordonnées Cartésiennes.
– HOUOUOULàlàlala, mais c’est téra durdurissime les coornodétruc !
– Mais non Dudule, c’est exactement ce que tu fais quand tu joue à la bataille navale, sauf qu’au lieu d’utiliser des lettres pour indiquer la situation de la cible on utilise des valeurs de position dans deux directions à angle droit que l’on nomme arbitrairement X et Y.
– X25, Y32, BOUM … c’est ça ?
– Oui, sauf que BOUM est remplacé par pchhhh et le carton se met à fumer.
– Et les moteurs PAS à PAS font cloc cloc cloc.
– Exactement Dudule, t’as tout pigé.
Sur cet exemple, l’image générée par LaserGRBL sera comprise entre 20mm et 95mm sur X’X et 107mm à 163mm sur Y’Y. Comme le programme commence par dégager le plateau et capturer l’Origine Machine située à l’arrière, pour gagner du temps en déplacement sur l’origine de l’image il est avantageux de décaler cette dernière à gauche et vers le fond du plateau.
Manifestement le logiciel LaserGRBL et la pyrograveuse représentée sur la Fig.39 se partagent un arbre généalogique commun. Cette similarité est induite par la géométrie cartésienne pour laquelle une surface plane est représentée traditionnellement par deux axes X et Y tracés à angle droit et dont l’origine se trouve à gauche et vers le bas du graphe. Cette vision de l’espace a été généralisée, et se retrouve sur les machines outils depuis les origines de la mécanisation. On se contente d’ajouter la troisième dimension par un axe vertical Z’Z. Par osmose, toute image va adhérer à cette représentation « tacite » et présentera une Origine Image située en bas et à gauche. Il sera bien entendu totalement libre de la positionner en n’importe quel emplacement sur le plateau de la machine, à condition que l’intégralité des PIXELs de cette image soit contenue dans la surface opérationnelle du LASER. Cette surface sera implicitement représentée virtuellement par un système de coordonnées Cartésiennes XOY centré sur l’Origine plateau. C’est dans ce système de coordonnées que seront indiquées, par le fichier gco, au logiciel de gestion de la machine, les positions des points P à « noircir » par le LASER de puissance.
Capturer l’Origine Machine.
Rechercher la performance la meilleure sera toujours une constante dans un projet quel qu’il soit. Sur une machine à commande numérique, le volume couvert par l’outil constitue une caractéristique de base, et l’on recherchera les dimensions les plus grandes possibles en fonction des éléments mécaniques approvisionnés. Dans notre cas, ce sera en fonction des glissières à billes qui matérialisent les guidages en translation rectiligne. Toutefois, en fonctionnement normal il importe de « surveiller » en permanence la position des ensembles mobiles pour que, quelles que soient les coordonnées imposées par une ligne de code gco, la mécanique n’aille jamais en butée physique. Franchement, c’est arrivé plusieurs fois sur le prototype. Le moteur vibre au lieu de tourner, rien de plus. Mais c’est une question de rigueur technique. La cécité totale pour un automatisme est inconcevable, il y a bien à un moment où à un autre, où il doit prendre en compte son environnement pour savoir où il se trouve. Ensuite ce ne sera plus qu’une question de comptage et de décomptage. Cette fonction est précisément assurée par la capture de l’Origine Machine, c’est à dire de déplacer le LASER jusqu’à ce qu’il pointe la position la plus à l’arrière et située à gauche, juste avant que les ensembles mobiles ne viennent buter physiquement sur les organes fixes des guidages rectilignes.
Principe de fonctionnement des deux capteurs de capture d’Origine.
Tester l’environnement, c’est forcément munir la machine de senseurs, qui toutefois sont infiniment plus rudimentaires que s’il fallait mesurer une position avec précision. Un simple contact électrique constitué d’un micro-switch et l’affaire est classée. C’est du reste l’une des techniques les plus courantes rencontrée sur les imprimantes 3D par exemple. Cette technologie présente toutefois l’inconvénient de rester relativement vulnérable mécaniquement, tout particulièrement si un moteur vient forcer sur le micro-switch car un incident logiciel ou matériel a fait « perdre le nord » au programme d’exploitation, sans compter les nombreuses « doudounes » lors du développement.
Bussi, personnellement je suis infiniment plus séduit par des capteurs optiques qui ne risquent absolument rien. Le principe d’une barrière optique décortiqué sur la Fig.40 est enfantin. Un LASER de très faible puissance 1 (Globalement une LED collimatée.) génère un Rayon lumineux de faible dispersion. Quand ce dernier illumine une cellule photorésistante 2 cette dernière présente une résistance électrique très faible. Si un obstacle 3 vient s’interposer et coupe le faisceau lumineux, la cellule 2 ne recevant plus d’énergie voit sa résistance interne devenir très grande. Pour minimiser l’influence de la lumière locale parasite, un tube fin 4 englobe 2 qui alors se trouve presque dans le noir « en plein jour ». Le Masque constitue une sorte de bouchon percé d’un petit trou qui obture le tube 4 et ne laisse passer que le Rayon lumineux. (Je dois vous avouer que cette complication n’est absolument pas indispensable, on pourrait parfaitement s’en passer … et j’adore bricoler des petites mécaniques !) L’obstacle 3 est constitué d’une pièce plate, fine et longue fixée sur le chariot dont on désire trouver la position de départ. Par analogie, elle devient Couteau dans la littérature spécialisée.
Convertir la lumière en information pour le programme.
L’opération est élémentaire dans la mesure où le microcontrôleur dispose de plusieurs entrées analogiques de type CAN. Le schéma de la Fig.1 en page 2 du MANUEL.pdf montre que ce sont respectivement A6 et A7 qui sont dévolues à cette mission. Les cellules photorésistantes R forment un diviseur de tension avec une résistance de 10kΩ qui va au +5Vcc. Lorsque le chariot est loin de l’origine machine, la cellule présente presque un court-circuit avec GND et la tension présente sur le CAN est très faible. Lorsque le Couteau intercepte le Rayon lumineux, étant dans une quasi obscurité, la résistance devient grande et l’entrée analogique « voit » alors une tension élevée. Les deux valeurs très différentes qui seront retournées par le CAN seront alors faciles à différencier. Notez au passage que les deux petits LASER 1 ne sont pas directement alimentés par le +5Vcc. C’est la sortie binaire A3 qui s’en charge. On n’illumine les cellules 2 qu’au moment de capturer une origine. Outre l’économie d’énergie qui résulte de cette approche, le logiciel peut automatiquement vérifier si les capteurs sont opérationnels, et prévenir l’opérateur si ce n’est pas le cas.
Réalisation des deux capteurs pour la capture de l’Origine Machine.
Facilitant le travail pour l’électronicien improvisé, la Fig.21 en page 13 du MANUEL.pdf montre qu’un petit module LASER du commerce destiné à Arduino équipe la machine. Nous n’avons que les deux petits circuits imprimés de la Fig.20 et de la Fig.21 à assembler. À ce stade de notre projet nous n’avons pas encore besoin du circuit de câblage intermédiaire de la Fig.19, ceci dit, tant qu’à faire chauffer « le frère à souder », pourquoi pas l’équiper également. ATTENTION, comme c’est les cas pour tous les circuits proposés dans MANUEL.pdf les dessins sont réalisés à une forte échelle d’agrandissement. Avant d’assembler quoi que ce soit, il me semble URGENT d’imprimer la fiche Câblage des capteurs d’Origine Machine ou tout au moins de la consulter avec attention. En particulier observer avec concentration les Image1.JPG à Image5.JPG qui sont préservées dans le dossier <Les circuits électroniques> du répertoire <Galerie d’images>. Enfin, lorsque tous les éléments sont disponibles, on les assemble sur une plaque provisoire comme le présente Image5.JPG et l’on branche les diverses broches des connecteurs HE14 à GND, à +Vcc, à A3, à A6 et à A7. (Vous remarquez au passage la souplesse d’utilisation de l’ATmega328 dont l’entrée analogique A3 peut également fonctionner en sortie binaire.) Le matériel étant disponible et en principe fonctionnel, il reste à le valider. Dans ce but on téléverse P16_Test_des_Origines.ino sur la carte Arduino NANO et à l’aide d’un quelconque morceau de carton un peu épais masquez ou dégagez manuellement la barrière lumineuse. L’afficheur OLED indiquera la valeur issue du CAN et l’état que le logiciel déduit de cette dernière. Notez au passage que pour chaque test on effectue 250 itérations dont on fait la moyenne pour émuler un antiparasite. Dans le programme définitif on se contentera de 20 mesures pour optimiser la rapidité de déplacement des moteurs tout en conservant une très bonne immunité aux perturbations éventuelles. Bien qu’en tête de programme deux lignes sont prévues pour optimiser la valeur des seuils de décision, inutile à ce stade de s’en préoccuper. Les valeurs que l’on mesure ne correspondent pas à celles qui seront présentes sur la machine, car le +Vcc ne fait que 4,4V au lieu de 5V nominal, La carte Arduino NANO n’étant alimentée que par sa mini prise USB. Pour information, dans le programme d’exploitation on disposera de cette fonction de maintenance en faisant appel à l’option U sur capteurs ORG du menu SYSTEME. Il sera aisé en temps utile d’optimiser le logiciel lors de la validation du matériel assemblé.
La suite est ici.
