un petit exécuteur G-code web

  • Auteur de la discussion nraynaud
  • Date de début
N

nraynaud

Apprenti
Salut à tous,

en attendant ma fraiseuse (qui est arrivée ce midi \o/) et pour essayer d'être un peu dans la commande numérique, j'ai commencé un petit simulateur de g-code en ligne : http://nraynaud.github.com/webgcode/
le code fait 230 lignes pour les curieux : https://github.com/nraynaud/webgcode/blob/gh-pages/parser.js
Comme ça fait plus de 10 ans que j'ai pas touché à du g-code, il est possible que j'ai complètement compris de travers certaines bases, c'est l'occasion de me corriger (avant d'avoir un outil tranchant au bout du câble :) ).
J'ai utilisé "The NIST RS274/NGC Interpreter - Version 3" come document de spec c'est tout ce que j'ai trouvé de gratuit en ligne, est-ce que c'est bon ?

il supporte XYZ, G0, G1,G2,G3 (lignes droites et arcs de cercle I,J,R), G20, G21 (unités), G90,G91 (incrémental/absolu).

dites-moi ce que vous en pensez, les bugs les plus visibles, qu'est-ce qui manque le plus dessus, dans quelle direction ça pourrait évoluer, etc.

Nico.
 
Dernière édition par un modérateur:
Y

yent

Ouvrier
Salut,

Super, un collègue codeur dans ce monde de copeaux ! :-D

Un bug : ligne 178-180, il y a des appels à la fonction dist qui n'est définie qu'après.

Sinon ça m'a l'air bien comme idée !
 
N

nraynaud

Apprenti
yent a dit:
Salut,

Super, un collègue codeur dans ce monde de copeaux ! :-D

Un bug : ligne 178-180, il y a des appels à la fonction dist qui n'est définie qu'après.

Sinon ça m'a l'air bien comme idée !

Salut, merci.
Est-ce que tu peux me dire comment tu arrives à déclencher le bug stp ?

parce que javascript a des frankenscopes pour les variables locales (parce qu'en JS tout ressemble à du C mais rien n'est pareil en vrai), et normalement ça marche.
J'ai modifié l'ordre pour que ce soit plus simple à lire, merci.

Nico.
 
Y

yent

Ouvrier
Salut,

Le problème apparaissait lors de la simulation, il semble maintenant réglé.

Le javascript je connais bien, mon domaine c'est l'applicatif web, son concept de scope peut paraitre particulier mais bien maitrisé c'est une arme puissante.

Sinon le résultat est bien sympa.
 
N

nraynaud

Apprenti
est-ce que quelqu'un pourrait regarder les G18-G19 avec le sens de rotation des arcs G2-G3 svp ? je n'arrive pas à savoir si je tourne dans le bon sens ou pas (ce qui me chagrine c'est que le repère de X-Z est indirect alors que X-Y et Y-Z sont directs).


edit:
Unlike functions defined by function expressions or by the Function constructor, a function defined by a function declaration can be used before the function declaration itself
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope c'est à ça que je faisais allusion.
 
Dernière édition par un modérateur:
N

nraynaud

Apprenti
J'ai réussi à faire mon premier fraisage avec ce programme. Je calcule les pas et timings en javascript puis j'envoie la liste des pas et leur timing dans une carte STM32F4 ( http://hackspark.fr/fr/stm32f4-discovery-stm32f4discovery-discovery-kit-for-stm32-f4-series-with-stm32f407-mcu.html ) branchée sur le port parallèle du boitier.

C'est un assemblage un peu bancal de technologies, avec une page web, une extension chrome qui envoie les infos sur l'USB à une carte programmée en C. Pour l'instant la carte ne fait que lire la liste des pas et les exécuter, car c'est bien plus confortable de développer pour PC qu'en embarqué pour faire des trucs complexes comme des calculs d'accélération.
Tout est ici pour les curieux : https://github.com/nraynaud/webgcode
  • interpolator (qui porte mal son nom) : programme embarqué (avec un vendor name USB complètement tombé du camion)
  • webapp : c'est l'extension google chrome, c'est une "packaged app" car c'est obligatoire pour accéder à l'API USB
Le reste c'est la page web et un peu de tests.

Pour le premier programme j'ai simplement gravé un carré de 20cmx20cm dans un bout de contreplaqué à 2mm de profondeur. La géométrie semble bonne. J'ai passé 2 jours à dépanner des problèmes de CEM, je pense que l'action la plus significative a été d'utiliser un câble blindé pour le spindle et de mettre son corps à la terre.

S'il y a des gens intéressés (avoir une carte de 10cmx6 au lieu d'un PC desktop entier dans l'atelier peut intéresser du monde) je peux tenter de rendre le programme plus générique et utilisable par d'autres.

Nico.
 
Dernière édition par un modérateur:
A

adventum

Nouveau
Salut à tous

Ça m’intéresse fichtrement...je viens de terminer une (toute)petite fraiseuse CNC (200x160x100, moteur PAP et vis à billes) et je n'ose pas vraiment me lancer. Je bute sur ce fameux G-Code, je suis comme une poule devant un couteau.
J'ai installé LinuxCNC sur un vieil ordi, les moteurs s'agitent joyeusement, j'ai réussi a lui faire écrire "LINUC CNC en mettant un stylo a la place de fraise, tout va bien pour l'instant...
Je viens d'ajouter des fins de course sur les 3 axes et un bouton stop, mais je galère avec le G-code ...je mettrais quelques photos dès que j'aurais avancé un peu.
L'idée d'une carte me plais bien pour remplacer l'ordi. J'ai vu qu'une programmation spéciale pour Arduino était plus ou moins opérationnelle, mais nécessitait quand même un ordi a proximité !
Si tu progresse dans cette voie je m'en inspirerais peut être si pas trop compliqué !!
 
N

nraynaud

Apprenti
Pour tout t'avouer je bosse dessus tous les jours, mais c'est encore rudimentaire. Tout est dans le repo github, un peu en vrac. Mais c'est un petit peu flippant de vraiment packager et releaser un code qui va piloter un robot avec un outil tranchant tournant.

J'utilise une STM32F4-discovery pour piloter le port parallèle de la box, c'est connecté par USB à mon mac. L'interpolation est faite en javascript dans dans chrome, qui parle par USB à la carte (ça envoie une énorme file de pas sur le cable USB, à 640pas/mm).

J'ai développé une chrome packaged app (pour avoir accès au port USB depuis le browser), un petit protocole USB et un exécuteur dans la carte.
actuellement je m'intéresse à la génération de trajectoires d'outils de façon à supprimer le g-code (qui est une abomination) de la chaine de production.

J'ai pas utilisé d'arduino, car un jour à une conf un gars m'a vendu une STM32F4, du coup j'ai pris des compétences dessus, et c'est quand même largement plus puissant qu'un arduino (mais y'a moins d'aide sur google), donc j'en suis jamais revenu.

Si ça suscite de l'intérêt, je peux tenter de créer un produit un peu packagé, genre un truc connecté en wifi ou bluetooth au PC. Je risque d'avoir besoin d'argent bientôt et je pense que c'est plus marrant de faire ça que de prendre un vrai boulot.
adventum a dit:
Salut à tous

Ça m’intéresse fichtrement...je viens de terminer une (toute)petite fraiseuse CNC (200x160x100, moteur PAP et vis à billes) et je n'ose pas vraiment me lancer. Je bute sur ce fameux G-Code, je suis comme une poule devant un couteau.
J'ai installé LinuxCNC sur un vieil ordi, les moteurs s'agitent joyeusement, j'ai réussi a lui faire écrire "LINUC CNC en mettant un stylo a la place de fraise, tout va bien pour l'instant...
Je viens d'ajouter des fins de course sur les 3 axes et un bouton stop, mais je galère avec le G-code ...je mettrais quelques photos dès que j'aurais avancé un peu.
L'idée d'une carte me plais bien pour remplacer l'ordi. J'ai vu qu'une programmation spéciale pour Arduino était plus ou moins opérationnelle, mais nécessitait quand même un ordi a proximité !
Si tu progresse dans cette voie je m'en inspirerais peut être si pas trop compliqué !!
 
N

nraynaud

Apprenti
Je ne sais pas trop si ça intéresse du monde que j'explique ce que j'ai fait dans mon système.
J'aimerai aussi avoir l'avis des pros, parce que j'ai pas toujours trouvé de publications scientifiques pour avoir le boulot pré-mâché, du coup j'ai un peu inventé.

La vitesse de l'outil
Le Feedrate est donné en mm/min^1, l'accélération maximale est donnée en mm.s^-2 donc gaffe aux unités. Perso, dans mon code, "feedRate" est en mm.min^1, mais "speed" est en mm.s^-1 (j'ai pas encore eu de calcul qui nécessitait des unités internationales).
L'algo de planification de la vitesse le plus intuitif est celui de l'accélération maximale : accélérateur à fond ou frein à fond, comme un jeune dans une 205GTI. J'ai pris la même accélération pour l'augmentation ou la diminution de la vitesse j'espère que c'est pas trop grave. Le planificateur de vitesse ne sait faire que 3 choses : accélérer à fond, garder sa vitesse et freiner à fond. Il existes d'autres algorithmes plus malins, qui limitent les chocs (dérivée de l'accélération trop importante) dans la machine, mais ils sont plus compliqués, et je suis un peu limite en maths.

En ligne droite
Imaginons une ligne droite géante (on parlera des virages plus tard), que l'utilisateur veut parcourir à des vitesses différentes. Prenons la courbe de la vitesse en fonction de la position, ça fait des créneaux de hauteur différente. L'ordinateur a pour tache de suivre cette vitesse, sans jamais dépasser l'accélération maximale et sans jamais aller plus vite que l'utilisateur ne le veut. Les seules marges sont d'aller moins vite et de freiner plus tôt.
Ok, mais notre cher utilisateur il a des désirs que la mécanique ne peut pas suivre (en réalité il le sait mais c'est à l'ordinateur de faire les calculs), il y aura sur certains segments des vitesses qui ne seront jamais atteintes.
Donc en fonction de l'accélération maximale de la machine, l'utilisateur ne lui a peut-être pas laissé assez de longueur d'envol pour atteindre la vitesse voulue sur le segment. Pareil au freinage, il a demandé une vitesse trop grande sur un segment et on arrivera pas à freiner pour rentrer dans le segment suivant assez lentement.
l'approche que j'ai prise est assez simple: je passe une fois sur la courbe en accélérant et une fois sur la courbe à l'envers en freinant. Dans la phase d'accélération, si j'ai le temps d'accélérer jusqu'à la vitesse de l'utilisateur, je note qu'à la fin du segment je serai à la bonne vitesse, sinon, je note la vitesse maximale que j'ai pu atteindre. Au segment suivant, je pars de la vitesse max atteinte au précédent et je tente d'accélérer jusqu'à la nouvelle vitesse. Si le segment avait une vitesse inférieure, je laisse sa vitesse, on s'occupera du freinage plus tard. j'avance comme ça jusqu'au bout à tenter d'accélérer.
Ensuite, je pars de la droite, et j'applique le même algorithme en freinant. A la fin la vitesse est toujours 0, au dernier segment je regarde si j'arrive à freiner de la vitesse max au 0, si oui je garde la vitesse max, sinon je regarde quelle aurait été la vitesse max qui m'aurait permis de freiner à temps et je la garde comme nouvelle vitesse max. De l'avant-dernier au dernier, si l'avant dernier et plus rapide que le dernier, je tente de freiner à l'avant dernier pour rentrer dans le dernier à sa vitesse max, si ça passe, c'est bon, sinon je calcule quelle était la vitesse max d'où j'aurai du partir. etc.
voici le résultat (toujours en fonction de la distance parcourue), j'ai généré aléatoirement des vitesses et des longueurs de segments:
MJsjt7H.png

en rouge ce que l'utilisateur a rentré, en vert les vitesses max réellement atteintes, et en bleu la vitesse qu'on va faire en tenant compte des accélérations.

Par curiosité, voici la position de l'outil par rapport au temps:
FSf0MjG.png

C'est nettement moins intéressant, vu que l'outil est resté très longtemps dans un segment lent (ça vient de ma génération aléatoire du graphe-au dessus).

En arc de cercle
Comme nos profs nous l'expliquaient, aller en ligne droite à vitesse constante n'implique aucune accélération, mais pour pour changer le vecteur vitesse (en norme ou en direction), il faut de l'accélération. Un arc de cercle, même à feedrate constant, ça tourne le vecteur vitesse, ça utilise de l'accélération.
Avec l'arc de cercle, on a de la chance, c'est un virage à norme d'accélération constante (si la norme de la vitesse est constante), avec une b-spline ou un bézier, c'est une frankeinaccélération qu'il faut calculer.
Donc pour calculer la vitesse dans un arc de cercle il y a une première chose à vérifier : que parcourir l'arc de cercle à la vitesse demandée est possible, qu'on est pas en train de dépasser l'accélération max admissible simplement en tournant. Mécaniquement ça voudrait dire qu'on est en train de dépasser la force centrifuge acceptable (la masse en X et en Y du chariot n'est pas la même donc on y va à la louche avec un max pour tout le monde, y compris Z, avec ou sans force de coupe).
220px-Cinematique_mouvement_circulaire_uniforme.png


Ok, maintenant plus dur: si on veut accélérer dans un arc ? Une partie de l'accélération disponible est "prise" par la forme du mouvement, il ne reste pour faire varier la norme de la vitesse qu'une partie de l'accélération. Et si on est à la vitesse maximale possible pour la machine, on a plus d'accélération disponible pour freiner sans sortir de la trajectoire, donc il faut limiter la vitesse. C'est là que mes compétences en math ont atteint leur max : http://math.stackexchange.com/questions/351699/time-equation-of-acceleration-along-an-arc . La solution qui n'utilise pas toute l'accélération disponible mais est plus simple niveau maths consiste à planifier une accélération angulaire contante qui fasse atteindre la vitesse demandée sans jamais que sa projection ne dépasse l'accélération max de la machine. Normalement, si on utilisait bien toute l'accélération linéaire "disponible" l'accélération angulaire devrait varier, car seule l'accélération linéaire instantanée nous intéresse. J'ai fait cette partie de manière assez scolaire avec des équations, donc je n'ai pas trop d'explication intuitive à donner.
Suite à la simplification, on voit les oreilles de batman sur la courbe d'accélération :
gnSgABU.png

(code live : http://nraynaud.github.io/webgcode/?code=G2%20X1%20Y0%20I0.5%20J0%20F300 )

Donc maintenant on est capable de planifier la vitesse pour des segments et des arcs, on peut calculer les directions de mouvement en entrée et en sortie des arcs, regarder si le mouvement en sortie d'un arc et co-linéaire avec le mouvement d'entrée du segment qui suit, si c'est le cas, on peut faire une chaine. On fait une chaine de mouvements colinéaires aussi longue que possible, et on planifie leur vitesse globalement et en calcul formel, sans avoir encore utilisé le pas de la machine. Reste la géométrie qu'on verra une autre fois.

J'espère que ça vous intéresse, si vous relevez des erreurs, dites-le svp, j'utilise ce code pour ma faiseuse :p
Si vous voyez des améliorations, go. Pas sûr que j'implémente toutes les suggestions car j'ai pas mal de taf sur le reste de la chaine CNC.
 
Dernière édition par un modérateur:
G

Guigui32

Nouveau
Bonjour,
C'est très intéressant tout cela ! je ne peux que te conseiller d'aller jeter un oeil aux documentations de siemens (c'est les seules que je connaisse) pour en savoir plus.
Les mots clefs sont : compression (COMPCAD) , G642, loockahead (FFWON) , contrôle de l'acceleration (jerk) etc...

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDUQFjAA&url=http%3A%2F%2Fwww.automation.siemens.com%2Fdoconweb%2Fpdf%2FUMC_SINUMERIK_072010_fr%2FPG.pdf%3Fp%3D1&ei=rfS-UYujIYrDhAfQ84GgBw&usg=AFQjCNG-qkgp74Fw8GX1_oZJWBeJS0gcvQ&bvm=bv.47883778,d.ZGU

Des thèses aussi :
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDMQFjAC&url=http%3A%2F%2Ftel.archives-ouvertes.fr%2Fdocs%2F00%2F76%2F49%2F75%2FPDF%2FMAC_DP_2011.pdf&ei=y_W-UbXuKoOR7Abp2YHYAQ&usg=AFQjCNE43OXZpgvyyiy7l_NAGtaN--_fpA&bvm=bv.47883778,d.ZG4

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CDEQFjAC&url=http%3A%2F%2Fperso.crans.org%2Fpessoles%2FThese%2FManuscritPessoles.pdf&ei=Nfe-UfqKLa-d7gbX1YCICw&usg=AFQjCNGGWDccpVbGJIeojmOfwgR7MkTagA&bvm=bv.47883778,d.ZG4

ou encore
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CC0QFjAB&url=http%3A%2F%2Ftel.archives-ouvertes.fr%2Fdocs%2F00%2F67%2F34%2F00%2FPDF%2F2011CLF22146Pateloup.pdf&ei=Nfe-UfqKLa-d7gbX1YCICw&usg=AFQjCNEmaUeUFQB5YzmquNM0oGNY7L3C0Q&bvm=bv.47883778,d.ZG4

Par contre je n'arrive pas à visualier les trajets sur ton appli web... Mais je connais rien en Java !

Bonne continuation
Guillaume
 
Dernière édition par un modérateur:
N

nraynaud

Apprenti
merci, je vais étudier tout ça.
c'est du javascript, par contre il se pourrait que la 3D ne fonctionne qu'avec chrome, quel navigateur utilises-tu et est-ce que tu as un message d'erreur ?
est-ce que tu peux me faire une copie d'écran stp ?
 
G

Guigui32

Nouveau
Salut,
Je suis sous Firefox est c'est écran noir, sans erreur...

Je verrai avec Chrome dès que je l'aurai installé !

A très bientôt !
Guillaume
 
N

nraynaud

Apprenti
je suis désolé, quelle version utilises-tu ?
est-ce que tu as un message d'erreur ?

ici ça semble marcher
9NQCYWW.png
 
J

JLuc69

Compagnon
nraynaud a dit:
Salut à tous,

en attendant ma fraiseuse (qui est arrivée ce midi \o/) et pour essayer d'être un peu dans la commande numérique, j'ai commencé un petit simulateur de g-code en ligne : http://nraynaud.github.com/webgcode/
le code fait 230 lignes pour les curieux : https://github.com/nraynaud/webgcode/bl ... /parser.js
Comme ça fait plus de 10 ans que j'ai pas touché à du g-code, il est possible que j'ai complètement compris de travers certaines bases, c'est l'occasion de me corriger (avant d'avoir un outil tranchant au bout du câble :) ).
J'ai utilisé "The NIST RS274/NGC Interpreter - Version 3" come document de spec c'est tout ce que j'ai trouvé de gratuit en ligne, est-ce que c'est bon ?

il supporte XYZ, G0, G1,G2,G3 (lignes droites et arcs de cercle I,J,R), G20, G21 (unités), G90,G91 (incrémental/absolu).

dites-moi ce que vous en pensez, les bugs les plus visibles, qu'est-ce qui manque le plus dessus, dans quelle direction ça pourrait évoluer, etc.

Nico.
Moi je verrais bien des lignes de code bancales :
G0 Y10 Z-5
G1 Z-10
G1 Y20
G02 X10 Y30 R10
G1 X30
G2 X40 Y20 R10
G1 Y10
G2 X30 Y0 R10
G1 X10
G2 X0 Y10 Z-15 R10 (yeah spiral !)
G3 X-10 Y20 R-10 (yeah, long arc !)
G3 X0 Y10 I10 (center)
G91 G1 X10 Z10
G3 Y10 R5 Z3 (circle in incremental)
Y10 R5 Z3 (again, testing modal state)
G20 G0 X1 (one inch to the right)
G3 X-1 R1 (radius in inches)
G3 X1 Z0.3 I0.5 J0.5 (I,J in inches)
G21 (back to mm)
G80 X10 (do nothing)
G90
G0 X30 Y30 Z30
G18 (X-Z plane)
G3 Z40 I0 J5
G19 (Y-Z plane)
G3 Z50 I0 J5
G17 (back to X-Y plane)
Lorsque tu programmes un cercle sur les plans G18/G19, le centre du cercle doit être défini par IK/JK (respectivement).
Le I est la position du centre sur l'axe X
Le J """""""""""""""""""""""""""""""""""""" Y
Le K """""""""""""""""""""""""""""""""""""" Z
Sur le plan G18 (XZ) j'aurais représenté dans l'autre sens :
En sélectionnant un plan, considère que le troisième axe remplace le "Z", le G3 c'est rotation en sens trigonométrique (anti-horaire)
Pour le reste ça semble correct mais j'y met quelque reserves : c'est pas évident de bien voir tes trajectoires avec une vue isoparamétrique
Mon simulateur ne tiens pas compte du G20/G21 :???: Sinon, au niveau du G18 il pense comme moi 8-) à condition de mettre K à la place de J
Beau travail sinon. Tu peux lui rajouter des options de vues (dessus, dessous, droite, arrière, et isoparamétrique) ?
Félicitation
 
Dernière édition par un modérateur:
N

nraynaud

Apprenti
Merci pour la vérification, je vais aller lires des docs et essayer de corriger les arcs de cercle.

J'ai un peu de mal, parce que certains changement de plans de la doc donnaient des repères indirects, du coup je ne savais pas qu'est-ce qui était "logique".
 
N

nraynaud

Apprenti
Je te confirme que j'avais mal lu la doc concernant les changements de plan, c'est corrigé, merci beaucoup.
 
Z

zorgloub

Nouveau
Bonjour,

Ce pratique petit exécutable en ligne fonctionne t-il encore ?
Je viens de faire un essai et rien ne se passe lorsque j'active la touche "Simulate".
L'image du code qui est présent à l'ouverture de la page reste figée et mon code ne se simule pas.

Merci.

Z.
-----------------------------------
 

Sujets similaires

M
Réponses
4
Affichages
4 806
modjo756
M
B
Réponses
9
Affichages
2 657
ben_mtl
B
Haut