... et une fraiseuse en bois.
J'avais envie de faire un truc dans ce genre:
Et si on codait un soft de commande CNC ? comme çà juste pour le fun ?
Ca me trottait dans la tête depuis longtemps de créer mon propre soft de commande CNC. J'ai jadis programmé en assembleur sur les microprocesseurs Z80, 6502 et 68000, l'assembleur PIC m'attire et rien de tel qu'une
immersion totale pour apprendre un nouveau langage. Le chip choisi sera un PIC 18F4525.
Evidemment je n'ai pas la prétention de faire concurrence à LinuxCNC ou Mach3, mais déjà pondre un petit truc fonctionnel, un projet passionnant qui devrait m'amuser pendant un bon moment et c'est tout ce que je recherche en fin de compte :D
En premier lieu il faut construire un banc-test pour tester les routines, et comme j'aime bien faire de la programmation confortablement bien au chaud il faut qu'il tienne sur le bureau sans trop encombrer.
Je vais donc commencer par construire une micro-CNC minimaliste. Pour faire simple elle s'appelera aussi 4L1C3, comme le soft.
Cahier des charges du banc-test:
Low-cost.
Motorisation en NEMA17.
Fonctionnement en 1/16 de pas.
Doit pouvoir fonctionner sous 12vcc.
Drivers low-cost chinois à base de TB6600.
Petit prix oblige le matériau sera du médium.
Noix usinées dans du POMC pour limiter le backlash.
Pour les tests la broche sera remplacée par un stylo.
Encombrement format A4 pour ne pas gêner sur le bureau.
L'électronique sera incluse dans le châssis toujours par souci d'encombrement.
Vis-mères en tige filetée M6/100. 1mm par tour, pas idéal pour simplifier les calculs
Choix d'un seul guidage MGN12 par axe, pas besoin d'une grande rigidité pour écrire sur une feuille.
Pas d'écran pour simplifier dans un premier temps, tout devra fonctionner par poussoirs et visu à leds.
Et bien sur, toujours le début en 3D pour savoir ou on va, comme d'habitude je commence par définir les trois axes et j'adapte ensuite un bâti pour les supporter.
Axe X
Axe Y
Axe Z
Ensemble des 3 axes. Les guidages sont en MGN12, j'ai fais le radinasse: un seul par axe, la machine n'ayant qu'à déplacer un stylo pas besoin de plus. Pour optimiser la compacité les moteurs X et Y sont montés à l'intérieur du bâti, la transmission par courroies et poulies GT2 rapport 1/1 résoud le problème d'alignement moteurs/axes. Seul le moteur Z est monté sur coupleur souple.
Le cahier des charges imposant de ne pas occuper une surface plus grande qu'une feuille A4 sur le bureau j'ai fais le choix de positionner l'électronique sous la machine. Ce sont de petits drivers chinois équipés de TB6600 que j'ai déjà montés sur CH4RL0TT3. et qui fonctionnent très bien.
Châssis en médium 10 et 13mm. C'est bizarre mais elle me rappelle quelqu'un, un mec caractériel toujours en noir et un casque, qui parle avec la gorge et qui n'arrête pas de souffler. Ca me reviendra.
Elle a l'air un peu féroce comme çà mais il ne faut pas s'y fier, ce sera une brave fille.
La grosse T1T1N3. mise à contribution pour la découpe des différents panneaux.
Toujours low-cost les vis d'entraînement sont en M6x100, le pas de 1 sera bien pratique lors de la programmation des déplacements d'axes, les tiges sont montées sur de petits roulements à billes 13x5x4. J'ai remplacé les écrous M6 initialement prévus par des noix usinées dans des chutes de POMC pour limiter le backslash.
Réalité conforme au virtuel.
Les moteurs X et Y sont montés à l'intérieur du châssis pour un gain de place.
Encombrement A4 sur le bureau.
Bon, maintenant on peut passer à ce qui nous intéresse.
L'âme d'4L1C3. Schéma et implantation du PCB PIC18F4525.
NOTA: J'ai depuis refondu le schéma et l'implantation par rapport à la carte finie première version ci-dessous car les barettes étant très serrées il était peu pratique d'avoir accès aux pins avec le chevelu une fois tout câblé.
Tiens, un PIC18F4525duino...
j'ai doublé les barettes pour pouvoir connecter un analyseur logique en // sur les signaux. Le PCB comporte deux régulateurs de tension, un petit pour l'alim du PIC et un 1A pour distribuer
le +5vcc aux périphériques.
La platine POM (Prises Origines Machine).
Au démarrage de la machine les axes peuvent être positionné n'importe ou dans le domaine usinable, cette opération permet de
ramener chaque axe en début de course. Les origines sont mises à zéro, la machine connaissant ses limites maxi (constantes définies dans le programme), elle connait par conséquent son volume usinable et il n'y aura pas de
risque que les chariots aillent taper dans le châssis en bout de course. C'est la première opération qu'on fait au démarrage de la machine.
La platine POP (Prises Origines Pièce).
La pièce à usiner peut-être bridée par l'opérateur n'importe-ou dans le volume usinable, il faut donc indiquer à la machine sa position exacte en venant tangenter sur
les trois axes et ainsi faire les origines pièce.
La platine JOG, déplacements manuel des axes.
(pour aller faire les POP par exemple ou pourquoi, pas faire de l'usinage manuel).
Les platines installées sur le châssis.
Mise en place des capteurs d'origines machine.
Système par relais ILS fixé sur le châssis et commandé par un aimant solidaire du chariot, masse commutée envoyée au PIC.
Capteur origine X.
Vue de l'ILS fixé sur le châssis.
Capteur origine X.
Vue de l'aimant fixé sur le chariot.
Capteur origine Y, l'aimant est fixé sur la table mobile.
Capteur origine Z.
Câblage de l'électronique de commande.
........( Heureux évènement )........
C'est officiel, j'ai la grande joie de vous annoncer la naissance de la petite 4L1C3, 3.2kg et des boutons bleus. Le papa est très fier.
bon c'est pas tout çà, je lui ai mis un PIC 18F4525 en guise de cerveau mais maintenant il s'agit de le lui remplir...
Après moults tests et grognements j'ai fini par trouver les bons paramètres de courant et fréquences de pulses. Les trois axes sont fonctionnels, fluides et pseudo-silencieux.
Et même assez rapides pour des vis au pas de M6, je m'attendais à pire.
Pour déterminer les fréquences de fonctionnement idéales j'ai fais les premiers essais avec un générateur de signaux TTL, directement appliqué aux entrées STEP des drivers. A priori les fréquences de pulses valides sont comprises dans une fourchette allant de 1 à 20Khz
suivant le réglage de micro-pas.
- en 1/2pas 2,4Khz
- en 1/4pas 4,6Khz
- en 1/8epas 9Khz
- en 1/16pas 18Khz
Pour une utilisation plus confortable je me suis aperçu que je manquerai de poussoirs, j'ai donc rajouté une plaque avec deux boutons de fonctions qui, associés aux autres ajoutera des
fonctionnalités supplémentaires (retour aux POP, avances rapides, etc.). Ces deux poussoirs sont câblés sur les deux pins libres Re0 et Re1.
Je suis en ce moment en plein déménagement et toutes mes machines sont démontées, j'ai donc du graver la plaque à
la Mac Gyver, au cutter sur un bord de table. Pas très joli mais fonctionnel, je referai çà mieux quand je serai de nouveau installé. On va dire que c'est du provisoire définitif.
Algorithme de fonctionnement d'4L1C3, tout simple, on fait d'abord les prises d'origines machine (POM) et pièce (POP, on lance le programme (RUN). A partir de là le gcode est transmi au PIC qui le découpe en trains de données X, Y et Z.
On active l'uart, on reçoit un train de données, on bloque l'uart le temps de déplacer les axes selon les données reçues et on recommence cette séquence jusqu'à la fin du programme gcode.:
........( Labels et assignation des pins )........
L'assignation des pins, reste pour l'instant 5 pins de libres pour d'éventuelles futures modifs ou améliorations. Les trois capteurs d'origine machine sont assignés à RB0, RB1 et RB3 au cas ou je devrais les placer sous interruptions
Quelques légendes:
capteur_pomX = capteur Prise Origine Machine sur l'axe X
capteur_pomY = capteur Prise Origine Machine sur l'axe Y
capteur_pomZ = capteur Prise Origine Machine sur l'axe Z
btn_run = poussoir démarrage usinage
btn_pom = poussoir prise origine machine
btn_popX = poussoir Prise Origine Pièce
btn_jogXmoins = poussoir déplacement X en négatif
btn_popX = poussoir prise d'origine pièce sur l'axe X
led_popX = Led visu prise origine pièce sur l'axe X
led_pomX = led visu prise origine machine sur l'axe X
drv_dirX = info direction sur le driver X
drv_stepX = info de pas sur le driver X
........( Format gcode )........
Un exemple du gcode simplifié que j'utiliserai pour le développement, généré par Cambam. Au début pas de trucs compliqués, codes G et autres, je garde juste le M30 pour signifier la fin du programme. Au départ je vais faire simple, juste des déplacements X, Y et Z, je verrai quand tout fonctionnera pour apporter des améliorations si besoin.
Voilà ce qu'on va faire, tout ce qui suit n'en est que le développement:
Recevoir par l'UART des trains de données contenant les valeurs de déplacement et déplacer les trois axes entre chaque train. Ceci jusqu'à la fin du gcode. C'est tout, pas plus.
Maintenant il s'agit de développer.
Il va me falloir programmer un interprèteur gcode mais d'abord il faut réfléchir au format des données, j'ai envie de tout stocker en 64bits, pas que j'ai besoin d'autant pour cette petite machine mais ce programme pourrait peut-être servir de base pour d'autres futurs projets, autant voir grand tout de suite. Ca ne m'empêchera pas d'effectuer les calculs dans un autre format approprié à mes petites courses, histoire de gagner du temps de calcul bien qu'en assembleur et les microcontrôleurs actuels çà ne pose pas de réel problème.
Qu'est-ce qu'on a à faire ?
Cambam (le soft dont je me sers pour générer mes gcodes) donne des valeurs en mm, le PIC fonctionne en pulses pour faire fonctionner les moteurs, il va donc falloir transformer ces mm en nombre de pulses, dépendant du choix
de micro-pas.
L'UART envoie des données ASCII, il faudra donc les convertir en valeurs décimales
Cambam génère au début du gcode un ordre Z isolé et redondant. A l'heure actuelle je n'ai toujours pas réussi à modifier le post-processeur pour l'annuler donc je le ferai sauter manuellement.
........( Transmission gcode PC vers PIC )........
Tout cela est déjà suffisamment compliqué alors pour les débuts et les premières mises au point j'ai simplifié les performances, la machine ne tracera que des droites horizontales, verticales et à 45°,
suffisant dans un premier temps pour faire de la gravure de PCB à l'anglaise, des améliorations pourront toujours être implémentées une fois le projet viable.
Un choix important à faire au départ: l'importation du gcode.
Deux options, soit par transmission PC/CNC par liaison série en temps réel comme sur la plupart des CNC, soit le fonctionnement en autarcie de la machine sur SDcard genre imprimante3D. Ayant eu quelques soucis de fiabilité
avec les cartes SD lors du projet G4ST0N. j'ai opté cette fois pour la liaison série. En plus c'est une technique que je n'ai pas encore expérimentée, çà va me permettre de découvrir. Le développement du projet se faisant en
partie sur un vieux PC portable non équipé de prise série DB9 la transmission se fera par USB/FTDI. Coté PC j'utiliserai le terminal TERATERM.
Le code ASM qui gère la liaison RS232 servira de tronc au programme, toutes les autres routines seront implémentées en tant que sous-procédures appelées par le tronc.
........( Réception des lignes gcode sur le PIC )........
Un fichier gcode peut prendre énormément de place en mem suivant la complexité de la pièce à usiner, souvent trop volumineux pour un PIC. Pour remédier à ce problème je vais envoyer le fichier par morceaux, il
restera stocké sur le PC qui enverra des trains d'octets au PIC. Celui-ci n'aura qu'à recevoir le nombre d'octets composant une ligne Z,X et Y du fichier gcode, il ordonnera au PC de cesser la transmission le temps de
bouger les trois axes suivant les valeurs reçues, une fois ce travail terminé il ordonnera au PC d'envoyer la ligne suivante, etc. etc. Le challenge est d'arriver à retirer les infos de déplacement dans une ligne gcode
codée de cette manière:
"'Z' ascii, valeur Z sur 32bits, 'espace' ascii, 'X' ascii, valeur X sur 32 bits, 'espace' ascii, 'Y' ascii, valeur Y sur 32 bits".
Au départ pour gagner une pin j'ai voulu faire les interruptions du flux de façon logicielle (XON/XOFF), ça ne fonctionnait pas et çà me faisait parfois disparaitre mon port COM4. En visu avec l'analyseur logique il
s'avérait que les ordres partaient bien vers le PC mais n'interrompaient pas la liaison UART, je met çà sur le compte de mon W7 qui est vieux et commence à être corrompu. Plutôt que tout réinstaller je suis passé en
interruption de flux hardware avec CTS, et là tout fonctionne correctement. Un petit bémol quand même, il passe encore deux octets après envoi du CTS, il a fallu gérer çà dans le gcode en rajoutant deux octets non
significatifs en fin de chaque ligne.
Pour résumer la réception coté PIC se fait sous interruption, lorsque RCIF passe à 1 on récupère l'octet reçu et on le stocke sur le PIC dans la variable prévue à cet effet,
un train d'impulsions comporte les données X,Y et Z. Plus besoin d'émission coté PIC, le contrôle du flux se faisant en hard par la pin CTS du module FTDI.
La première chose à faire, séparer les infos ligne par ligne. Pour m'y retrouver j'ai créé un fichier gcode test avec des valeurs reconnaissables qui se suivent stockées sur 32bits.
Les macros qui assurent la séparation des lignes en activant ou bloquant l'uart.
Le résultat vu par l'analyseur logique, on voit bien les trames isolées par les impulsions CTS. C'est dans ces espaces qu'oeuvreront les sous-programmes de gestion des trois axes de la machine.
Loupe sur une trame.
Elles font toutes 30 octets de long mais le CTS laissant passer 2 octets après son envoi (visible sur l'écran de l'analyseur), j'ai du initialiser le compteur de réception à 28.
A l'issue de chaque train XYZ les valeurs reçues sont stockées dans leurs variables respectives, il n'y aura plus qu'à venir les récupérer pour calculer le déplacement de chaque axe.
Nota: on peut voir sur la capture de l'analyseur des trains 64bits, alors que le gcode est en 32bits, normal ils ne sont pas actualisés, je suis en pleine phase de recherches et bricolages
et je ne fais pas une nouvelle capture d'écran à chaque modif.
........( Conversion ASCII -> numérique )........
Les valeurs reçues par la liaison UART sont sous format ASCII.
Chiffre 0 = valeur ascii 0x30 (48 décimal)
Chiffre 1 = valeur ascii 0x31 (49 décimal)
etc.
etc.
Chiffre 9 = valeur ascii 0x39 (57 décimal)
Il suffit de retrancher 0x30 aux valeurs contenues dans les variables pour obtenir leur valeur numérique. (Nota: pour plus de clarté je ne traite ici que l'axe X)
Variables brutes de réception avant conversion.
Après conversion.
Mais tout cela ne suffit pas et c'est un peu plus compliqué qu'il n'y parait. Une telle conversion aussi simple ne fonctionne que sur les premiers chiffres (0 à 9), ensuite à partir de 10 on est codé sur deux octets,
cad 10= 0x01 0x00 (0x31 0x30 en ascii), chaque chiffre étant codé sur 8 bits. Si on prend comme exemple la valeur maximale ASCII sur 32bits qui est 9999, çà donne 0x39 0x39 0x39 0X39. Pour avoir la valeur hexa il faut
faire:
9*0xa*0xa*0xa (4ème rang: 0x2328) + 9*0xa*0xa (3ème rang: 0x0384) + 9*0xa (2ème rang: 0x5a) + 9*0x0 (1er rang: 9) = 0x270f.
Vérification d'9999'= 0x270f, valeur hexa codée sur deux octets et maintenant utilisable
dans le programme.
Voici la routine qui éxécute la conversion par table pré-calculée.
Petite aparté... j'avais suggéré au départ que le stockage des données se ferait en 64bits et ceux qui ont suivi ont du remarquer que j'ai tout fait jusque-là en 32bits, , le plus grand nombre ASCII pouvant être stocké
sur 32bits (4 octets) est 9999, ce qui donne après conversion 9999 décimal, évidemment, donc 9999mm ce qui est amplement suffisant pour une CNC. Si on examine la mémoire ce nombre est stocké sous
la forme 0x39 0x39 0x39 0x39 (0x39 étant la valeur hexadécimale du chiffre 9 ascii).
Pour avoir une valeur plus grande que 9999 il faut augmenter le format.
........( Génération des impulsions pour la commande des moteurs )........
On pose comme base que la machine fonctionnera en 1/4pas, donc 800pas par tour. Le pas des vis-mères fait 1mm (M6x100, choisi en conséquence), unité ronde bien pratique dont on n'aura pas à tenir compte dans les calculs. Pour obtenir le nombre de pulses par axe en 1/4pas il faut donc multiplier chaque valeur par 800.
Bien que la famille des PIC18F possède des instructions de multiplication, il est lourd en assembleur de multiplier un grand nombre occupant plusieurs octets par un autre nombre supérieur à 255. Je vais tourner la difficulté
en
faisant en quelque sorte une multiplication hardware, c'est à dire décomposer le nombre stocké sur les 8 octets d'une coordonnée et multiplier chaque terme par une routine qui produira 800 impulsions et un multiple de
10 suivant son poids.
Tricheur va !
Exemple: la valeur 537 est stockée dans les trois premiers octets de coordX. Il faudrait faire une routine pour multiplier 537x800, stocker sur plusieurs octets le résultat qui sera certainement abomifreux, il faudra ensuite coder une routine pour en tirer le nombre de pulses adéquat. Lourd à programmer. Il existe certainement des algorithmes pour faire ce genre de chose mais n'étant pas du métier je n'en connais aucun. Je trouve plus élégant de programmer: nb2=5, nb1=3, nb0=7 , puis (nb2x10x10x4x200)+(nb1x10x4x200)+(nb0x4x200) pour arriver au même résultat (429600). Niveau programmation il suffit de faire des boucles imbriquées, çà donne une boucle effectuant 200 pulses inclue dans une boucle de 4 itérations et suivant le poids contenue elle-même dans une ou plusieurs boucles de 10 itérations. Aucun résultat à stocker, juste des créneaux en sortie, exactement ce qu'on veut.
La routine produisant 800 pulses sur l'axe X.
L'analyseur logique confirme le résultat:
La routine semi-complète, j'ai traité seulement les 4 bits de poids faible (ce qui m'autorise des courses maxi de 9000mm).
J'ai évidemment fait les tests sur plusieurs valeurs. Pour vérification j'ai forcé dans les variables coordX la valeur de la course maxi de la table d'4L1C3 qui fait 150mm, on obtient bien 120000 pulses (150x800), la translation complète devrait se faire en environ 26 secondes et on a bien les 4,6Khz définis aux essais.
Test: séries de 120000 pulses séparées par des tempos de 0,5 secondes.
Les trois axes en fonction (virtuellement pour l'instant car les drivers ne sont pas encore branchés, il reste à gérer les directions). On distingue bien les séquences de pulses XYZ successifs entre les trains de données UART, tous des multiples de 800 selon le gcode incrémental spécial créé pour les tests: le premier fait 800 pulses (X00000001) et le dernier 120000 pulses (Z00000015).
Autre petite aparté: certains pourraient se dire "Oui mais comment fait-on quand on ne possède pas de supers appareils de mesure de la mort qui tue pour voir ce qui est invisible ?". Simple, il existe actuellement des analyseurs logiques 16 canaux à relier sur un port USB vendus pour quelques euros chez les chinois.
A ce niveau on a tout ce qu'il faut pour éxécuter un programme gcode:
- on a converti les données ascii en valeur hexa
- on a calculé et généré des impulsions à envoyer aux drivers pour commander les moteurs pas à pas
- on a calculé la vraie valeur à parcourir d'après le point à atteindre et le chemin déjà parcouru par l'axe.
Mais çà ne suffit pas pour avoir une machine opérationnelle, il faut faire auparavant quelques opérations d'initialisation.
........( Initialisations de la machine )........
Au démarrage de la machine la réception UART est coupée et on effectue une lecture des poussoirs en attendant une décision de l'opérateur (il manque ici la lecture du poussoir Run qui sera implémenté plus tard).
........( Les POM )........
Mais se servir de la machine à ce stade comporte des risques et inconvénients, les axes peuvent être positionnés n'importe-ou au démarrage de la machine, rien n'est carré et on pourrait très bien aller
taper les chariots dans le bâti et détruire la machine. Pour cela les machines cnc sont équipées de deux fonctions: les POM (Prises Origines Machines) et POP (Prises Origines Pièces). Ces origines se font sur chaque axe.
Il faut effectuer en premier lieu les POM. Sur ordre de l'opérateur la machine déplace ses chariots pour venir les positionner au point zéro de chaque axe. Ces points zéro sont matérialisés par des capteurs (ici des ILS), une
fois ce point zéro atteint sur chaque axe la machine connait son volume usinable, ses distances de translation maximum étant déterminées par des constantes inclues dans le programme et réglées précisemment par des essais
préalables. A partir de là la machine connait ses limites min et max en translation et ne peut plus aller taper dans le bâti.
Une variable nommée 'translat' à pour tâche de tenir le compte des mm parcouru par les axes dans les deux sens.
........( Les JOG )........
Il faut pouvoir déplacer les axes manuellement, pour par exemple effectuer les Prises d'origine des pièces, soit pour usiner à la main, on n'a pas toujours envie de passer du temps à créer un gcode pour effectuer
une tâche simple tel un surfaçage. Des poussoirs sont prévus pour cette fonction, deux par axes pour pouvoir se déplacer dans les deux sens.
Donc pouvoir déplacer les axes tout en tenant compte des limites de la machine, toujours pour rester dans le cadre de son domaine usinable.
........( Les POP )........
Connaître son domaine usinable c'est bien mais l'opérateur peut décider de brider la pièce à usiner n'importe-ou sur la surface de la table, il faut aussi connaître la hauteur de la pièce pour effectuer les prises de passe. Donc déterminer les positions X, Y et Z de l'emplacement de la pièce. C'est un acte d'opérateur en venant tangenter sur la pièce en exécutant des Jog et validant les positions.
........( gestion des pentes )........
Pour l'instant la machine ne sait tracer que des lignes verticales et horizontales. Si on lui demande de tracer une pente de X20,Y30 à X80,Y50 elle va commencer par se déplacer de x20 à X80 horizontalement et
seulement ensuite elle de déplacera verticalement de Y30 à Y50, elle dessinera un angle. Evidemment ce n'est pas ce qu'on veut mais au départ ne sachant pas ou j'allais j'ai choisi de faire simple, il s'agit maintenant de
lui apprendre à tracer des pentes.
On connait la position XY de départ et la position XY d'arrivée, L'idée qui vient de suite est d'utiliser l'équation de droite y=ax+b avec a=deltaY/deltaX et b=y-(ax). L'ennui c'est que suivant la pente on peut
se retrouver avec un b négatif. D'un autre coté on se fiche de b car le déplacement à l'ordonnée est déjà fait, le chariot se trouvant déjà positionné. Donc on dit que b=0 et on se retrouve avec un calcul de tangente y=tan().x
tan()=deltaY/deltaX pour calculer la pente, ensuite il ne reste plus qu'à incrémenter X et on calculer Y pour chaque valeur de X --> Y(X) --> Y=X.tan(), on incrémente les pas moteurs pour chaque position.
Seulement voilà, pour simplifier on a décidé de rester en entiers dés le début du projet et on se retrouve maintenant avec des nombres à virgule pas pratiques, on va donc transformer tout çà en entier en multipliant par un
grand nombre. Ca tombe bien il faut 800 pas pour une révolution de moteur et parcourir 1mm (pour rappel on a choisi sciemment une vis au pas de 1). On va donc multiplier la valeur de tangente par 800, tan()=(deltaY/deltaX).800,
on obtient un grand nombre et du coup les chiffres derrière la virgule ne sont plus significatifs. Pour garder l'équilibre on commandera 1/800e de révolution à chaque appel de la routine, c'est à dire 1mm/800=0,00125 (1,25micron)
parcouru par un pas moteur.
Je récapitule: on connait la position XY de départ, la position XY d'arrivée, on calcule deltaX: Xnew-Xold et deltaY: Ynew-Yold, ce qui nous permet de calculer la tangente. Si Xold (idem pour Yold) est supérieur à Xnew en cas
de retour en arrière, il résultera un nombre négatif, donc on inverse les données et on fait dans ce cas Xold-Xnew (ce qui nous donne le bon deltaX positif), on prend soin d'inverser le sens de déplacement du chariot et on
retombe sur nos pattes.
On multiplie cette tangente par 800 pour obtenir un grand nombre. Ensuite on incrémente X en recalculant Y à chaque pas. On déplace les chariots X et Y et on trace la pente.
Ca roule.
La routine ci-dessous détecte si elle doit tracer une verticale, horizontale ou une pente:
Je ne m'intéresserais pas jusqu'ici à la gestion des cercles et des arcs, le postpro de Cambam intègre une fonction pour les transformer en un ensemble de segments ce qui me simplifie bien le travail.
ELLE BOUGE !!!! elle était là, pauvre petite chose inerte sur la table, j'ai dirigé les lasers métafulgurants asymétriques sur elle, abaissé un levier contre le mur, des éclairs partout, odeur d'ozone, pompé le
courant dans tout le quartier, black-out total mais je m'en tape.
et... et... et PAF! elle s'est mise à dessiner.
Tout d'abord je voudrai remercier un ami pour tous ses conseils sur la marche à suivre. Dr Frank Stein si tu me lis... je sais enfin ce que tu as éprouvé.
4L1C3 en langage digital çà s'écrit comme çà:
La gestion des arcs et cercles à été un peu plus pointue à mener parce que j'ai du résoudre pas mal de petits bugs autant mécaniques que logiciels, mais voilà, c'est chose faite.
Quand 4L1C3 fait de l'art abstrait...
Le programme est à présent fonctionnel, on passe maintenant à la phase d'optimisation. Jusqu'à présent on fonctionnait en entiers, le gcode arrivait sur 4 chiffres codés en 32bits et n'affichait que des mm entiers,
impossible de travailler avec précision avec de telles données mais c'était plus pratique pour la mise au point du programme. J'ai modifié le postpro de Cambam pour qu'il me livre à présent du gcode codé sur 4 chiffres avec
deux décimales après la virgule. On est précis maintenant au 1/100e de mm, largement suffisant pour graver des circuits imprimés.
J'ai aussi passé les drivers en 1/16e de pas pour augmenter la précision des déplacements et avoir ainsi une plus grande marge de programmation.
Cela remet en cause tous les calculs, ainsi que les dimensionnements des variables. Pour la phase de tests et vérifications je me suis aidé d'une feuille de calcul créée sur le tableur d'Open-Office, elle m'évite de longs
et laborieux calculs manuels avec toutes les sources d'erreurs que çà implique. Je rentre mes données gcode dans la feuille, je les écris parallèlement en dur dans le gcode que je donne en pâture à 4L1C3 et les résultats doivent coincider.
Cette feuille de calcul est décrite ci-dessous. Les données à saisir manuellement sont dans les cases blanches, les résultats dans les cases rouges. La partie tout à gauche m'a servi pour définir les datas précalculés pour
la conversion ASCII/décimal. Les trois autres blocs simulent tous les calculs du programme en partant de la valeur de la donnée gcode jusqu'à la valeur de la tangente utilisée pour le calcul des pentes. L'exemple ci-dessous
simule les données gcode X1234.56, Y7890.12 et Z3456.78 (en décimal). Les anciennes coordonnées nécessaires pour le calcul des delta X, Y et Z sont rentrées en hexadécimal à la main (on part du principe qu'elles ont déjà été
calculées et traitées au tour d'avant), dans cet exemple 0x12122 pour le X et 0x73839 pour le Y. Les deltas résultant sont deltaX=0x0C11E et deltaY=0x04D1DB. Comme on l'a vu plus haut le deltaY est ensuite multiplié par 800 ce qui nous donne 0xF0FCC60
pour arriver à la valeur de tangente: 0x13F7.
Il n'y a plus qu'à envoyer le gcode au PIC, placer des points d'arrets dans le programme et scruter les registres après chaque opération pour vérifier les calculs.
La machine est trop petite pour y installer un tableau de bord de BOEING, néanmoins on peut accèder à toutes les fonctions de base par des associations de boutons.
bouton POM générale: Prise d'Origines Machine sur les trois axes.
bouton FN2+bouton Jog Z plus: Pom Z seule.
bouton FN2+bouton jog X moins: Pom X seule.
bouton FN2+bouton jog Y moins: Pom Y seule.
boutons JOG: déplacements manuels dans les deux sens sur les trois axe.
boutons POP: Prises d'Origines Pièce sur les trois axes.
bouton RUN: lance l'usinage.
bouton FN2+bouton popX: descend Z pas à pas 1/100e mm
bouton FN1+bouton popX: monte Z pas à pas 1/100e mm
bouton FN2+bouton popY: descend Z pas à pas 5/100e mm
bouton FN1+bouton popY: monte Z pas à pas 5/100e mm
bouton FN2+bouton popZ: descend Z pas à pas 1/10e mm
bouton FN1+bouton popZ: monte Z pas à pas 1/10e mm
bouton FN1+bouton jog Z moins: envoie 4L1C3 en code morse.
bouton FN2+bouton jog Z moins: envoie F6FCO en code morse.
bouton FN2+ bouton run: envoie La rirette en code morse.
bouton FNZ+bouton jog Z plus: joue la musique "La rirette"
bouton RUN en fin de programme: réinitialisation.
Nota: en fin de gcode le Z remonte en POM et toutes les leds clignottent au rythme de 1Hz pour signaler la fin du programme.
Le programme est à présent abouti et fonctionnel, il peut y avoir de petites différences entre le code définitif et les exemples cités plus haut, les modifications ayant été nombreuses depuis mais l'idée générale est
respectée.
Dés que j'aurai terminé mon nouvel atelier je m'emploierai à construire une cnc graveuse de PCB digne de ce nom pour remplacer le prototype actuel en médium et elle servira à dévellopper la version V.2 du soft 4L1C3.
Code définitif et complet d'4L1C3:
La vidéo d'4L1C3 dans ses oeuvres:
Sarah Connors en saute de joie.