FraiseuseCNC/restauration : Différence entre versions
m (→références) |
(→processing 2 grbl) |
||
(39 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
= Projet: améliorer la fraiseuse = | = Projet: améliorer la fraiseuse = | ||
− | * monter un shield GRBL pour avoir des drivers + puissants | + | * monter un shield GRBL pour avoir des drivers + puissants modèle GrblShield de SynthEthos |
* coller les radiateur sur les controleurs TI | * coller les radiateur sur les controleurs TI | ||
− | * bien fixer | + | * bien fixer toutes les fins de course |
* mettre à jour GRBL pour essayer d'avoir des fins de course en fonction des emplacements libres sur le shield Uno | * mettre à jour GRBL pour essayer d'avoir des fins de course en fonction des emplacements libres sur le shield Uno | ||
* fignolages mécaniques | * fignolages mécaniques | ||
Ligne 11 : | Ligne 11 : | ||
== références == | == références == | ||
+ | * Notes du chantier boot camp 2010 https://projets.pingbase.net/libro/projects/fablab/wiki/GrBl | ||
* Wiki de référence http://www.synthetos.com/wiki/index.php?title=Projects:grblShield | * Wiki de référence http://www.synthetos.com/wiki/index.php?title=Projects:grblShield | ||
* Code source https://github.com/grbl/grbl | * Code source https://github.com/grbl/grbl | ||
+ | * Jumpers sur les ports MS0 & MS1 pour gérer les micro steps des moteurs pas à pas http://www.flickr.com/photos/rileyporter/8221207276/in/set-72157632010403997/ | ||
== 2013 01 28 == | == 2013 01 28 == | ||
− | + | === flashage de l'Arduino DueMilanove avec la version 0.8c 9600bauds de GRBL === | |
+ | |||
+ | |||
+ | $ cd /dossier/des/sources/grbl | ||
+ | |||
+ | on modifie les sources de Makefile à la ligne 33. On remplace: | ||
+ | |||
+ | PROGRAMMER ?= -c avrisp2 -P USB | ||
+ | |||
+ | par: | ||
+ | |||
+ | PROGRAMMER = -c stk500v1 -P /dev/ttyUSB0 -b57600 | ||
+ | |||
+ | Puis: | ||
+ | |||
+ | $ make; make flash | ||
+ | |||
+ | |||
+ | Pas sûr de ces instructions de http://dank.bengler.no/-/page/show/5471_gettinggrbl?ref=checkpoint qui ont l'air orientées windoze | ||
+ | |||
+ | $ avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -pm328p -cstk500v1 -P/dev/ttyUSB0 -b9600 -D -Ugrbl.hex | ||
+ | |||
+ | === Comment connecter les contacteurs de fin de course === | ||
+ | |||
+ | Un dessin vaut mieux que de longs discours: | ||
+ | |||
+ | [[Fichier:SchFin_2CourseGrblShield.jpeg|640px|thumb|center]] | ||
+ | |||
+ | Les résistances doivent etre entre 3.3k et 20k | ||
+ | |||
+ | Source : http://www.shapeoko.com/forum/viewtopic.php?f=5&t=361&start=10#p3050 | ||
+ | |||
+ | |||
+ | === C'est là que le fun commence === | ||
+ | |||
+ | $ stty raw ignbrk 9600 < /dev/ttyUSB0 | ||
+ | $ ( cat <&3 & cat >&3; kill %%) 3<>/dev/ttyUSB0 | ||
+ | |||
+ | Grbl 0.8c ['$' for help] | ||
+ | $ | ||
+ | $$ (view Grbl settings) | ||
+ | $# (view # parameters) | ||
+ | $G (view parser state) | ||
+ | $N (view startup blocks) | ||
+ | $x=value (save Grbl setting) | ||
+ | $Nx=line (save startup block) | ||
+ | $C (check gcode mode) | ||
+ | $X (kill alarm lock) | ||
+ | $H (run homing cycle) | ||
+ | ~ (cycle start) | ||
+ | ! (feed hold) | ||
+ | ? (current status) | ||
+ | ctrl-x (reset Grbl) | ||
+ | ok | ||
+ | G21 | ||
+ | ok | ||
+ | G91 | ||
+ | ok | ||
+ | G1 X10 F200 | ||
+ | ok | ||
+ | G1 X-10 F400 | ||
+ | ok | ||
+ | $$ | ||
+ | $0=7.273 (x, step/mm) | ||
+ | $1=7.273 (y, step/mm) | ||
+ | $2=400.000 (z, step/mm) | ||
+ | $3=30 (step pulse, usec) | ||
+ | $4=200.000 (default feed, mm/min) | ||
+ | $5=600.000 (default seek, mm/min) | ||
+ | $6=0 (step port invert mask, int:00000000) | ||
+ | $7=25 (step idle delay, msec) | ||
+ | $8=0.008 (acceleration, mm/sec^2) | ||
+ | $9=300.000 (junction deviation, mm) | ||
+ | $10=0.100 (arc, mm/segment) | ||
+ | $11=25 (n-arc correction, int) | ||
+ | $12=3 (n-decimals, int) | ||
+ | $13=0 (report inches, bool) | ||
+ | $14=1 (auto start, bool) | ||
+ | $15=0 (invert step enable, bool) | ||
+ | $16=0 (hard limits, bool) | ||
+ | $17=0 (homing cycle, bool) | ||
+ | $18=0 (homing dir invert mask, int:00000000) | ||
+ | $19=25.000 (homing feed, mm/min) | ||
+ | $20=250.000 (homing seek, mm/min) | ||
+ | $21=100 (homing debounce, msec) | ||
+ | $22=1.000 (homing pull-off, mm) | ||
+ | ok | ||
+ | $0=70 | ||
+ | ok | ||
+ | G1 X10 F400 | ||
+ | ok | ||
+ | |||
+ | == 2013 01 30 == | ||
+ | |||
+ | === Entraînement de la courroie axe Y === | ||
+ | |||
+ | Les axes de renvoi des courroies de l'axe Y (profondeur) restaient fixe. | ||
+ | En fait la partie interne du rotor des roulements frotte contre la surface support des roulements. | ||
+ | Un chambrage dans la surface support permet de limiter le frottement mais il faut quand même éviter de trop serrer les axes. | ||
+ | |||
+ | === Entraînement de la courroie axe X === | ||
+ | |||
+ | C'est pas gagné... | ||
+ | |||
+ | == 2013 01 31 == | ||
+ | |||
+ | === Re-câblage des moteurs pas à pas === | ||
+ | |||
+ | Le câblage des moteurs a été fait pour les trois moteurs qui n'étaient pas branchés sur les bons axes. | ||
+ | Face à la machine : | ||
+ | |||
+ | * axe X : de gauche à droite | ||
+ | * axe Y : du proche au lointain | ||
+ | * axe Z : de bas en haut | ||
+ | |||
+ | === Câblage des fins de course === | ||
+ | |||
+ | D'abord, on n'a rien compris. En fait les câbles reliés aux sorties "normalement fermées" des switches étaient tous connectés entre eux. | ||
+ | |||
+ | Ceci corrigé, nous avons re-etiquetés les cables de fin de course en se référant aux axes et aux sens précisés juste avant. | ||
+ | |||
+ | Finalement, ça ne marche toujours pas... Pour l'instant, les capteurs de fin de course sont déconnectés. | ||
+ | |||
+ | === Calibrage des moteurs === | ||
+ | |||
+ | Résultats pour les réglages d'usine (step/8) | ||
+ | * axe X = 14.7 step/mm (axe inversé) | ||
+ | * axe Y = 14.2 step/mm | ||
+ | * axe Z = 1570 step/mm (axe inversé) | ||
+ | |||
+ | == 2013 02 01 == | ||
+ | |||
+ | === Essais === | ||
+ | |||
+ | Essais de vitesse en fonction de : vitesse max, accélération, microstepping (step/8 ; step/4 ; step/2). | ||
+ | Pour une course de 350 mm pour l'axe X et 230 mm pour l'axe Y. | ||
+ | |||
+ | Résultats, pour éviter les "gros" décalages, il faut limiter les valeurs des paramètres pour : | ||
+ | * accélération < 250 mm/s² | ||
+ | * vitesse max (axe X et Y) < 8000 mm/min | ||
+ | * vitesse max (axe Z) <= 200 mm/min | ||
+ | |||
+ | === microstepping === | ||
+ | |||
+ | À l'aide de bridges sur le GrblShield,on peut sélectionner la précision de chaque moteur au huitième de pas, au quart de pas, au demi-pas ou au pas entier. | ||
+ | Par exemple, au huitième de pas, un pas pour grbl (c'est-à-dire une impulsion) fait tourner le moteur d'un huitième de pas "machine". | ||
+ | Dans chaque cas, il faut corriger le nombre d'impulsion par millimètres (Exemple : 14,2 step/mm au huitième de pas donne 7,1 step/mm au quart de pas). | ||
+ | |||
+ | Les performances en terme de vitesse et d'accélération ne semblent pas être affectées par le choix du microstepping. De même, l'utilisation de pas entier n'a pas permis d'utiliser des vitesses plus élevée pour l'axe Z, qui broute toujours au dessus de 200 mm/min. | ||
+ | |||
+ | === CNC_pycamgrBL === | ||
+ | |||
+ | La CNC a été manipulée avec processing en corrigeant le baudrate (9600). | ||
+ | Le sketch s'appelle désormais : | ||
+ | CNC_pycamgrBL_PAD2_hareng_frit | ||
+ | |||
+ | Il reste à corriger l'orientation des axes X et Z (re-compilation du firmware ?) pour pouvoir balancer du GCode. | ||
+ | |||
+ | |||
+ | |||
+ | == 2013 02 07 == | ||
+ | |||
+ | backup paramètres grbl : | ||
+ | |||
+ | $0=29.400 (x, step/mm) | ||
+ | $1=29.300 (y, step/mm) | ||
+ | $2=196.000 (z, step/mm) | ||
+ | $3=30 (step pulse, usec) | ||
+ | $4=8000.000 (default feed, mm/min) | ||
+ | $5=8000.000 (default seek, mm/min) | ||
+ | $6=0 (step port invert mask, int:00000000) | ||
+ | $7=25 (step idle delay, msec) | ||
+ | $8=10.000 (acceleration, mm/sec^2) | ||
+ | $9=300.000 (junction deviation, mm) | ||
+ | $10=0.100 (arc, mm/segment) | ||
+ | $11=25 (n-arc correction, int) | ||
+ | $12=3 (n-decimals, int) | ||
+ | $13=0 (report inches, bool) | ||
+ | $14=1 (auto start, bool) | ||
+ | $15=0 (invert step enable, bool) | ||
+ | $16=0 (hard limits, bool) | ||
+ | $17=0 (homing cycle, bool) | ||
+ | $18=0 (homing dir invert mask, int:00000000) | ||
+ | $19=25.000 (homing feed, mm/min) | ||
+ | $20=250.000 (homing seek, mm/min) | ||
+ | $21=100 (homing debounce, msec) | ||
+ | $22=1.000 (homing pull-off, mm) | ||
+ | |||
+ | === inversion des commandes X et Z === | ||
+ | |||
+ | === processing 2 grbl === | ||
+ | |||
+ | Pour une raison inconnue, le gcode n'est pas bien communiqué à grbl : les ordres semblent arriver dans un ordre plus ou moins aléatoire... | ||
+ | Nous avons d'abord cherché à recompiler, puis flasher, grbl. | ||
+ | |||
+ | Finalement, c'était processing 2 grbl qui ne marchait pas bien. Avec un petit script python pour lancer le gcode, ça fonctionne... | ||
+ | avec : https://github.com/grbl/grbl/blob/master/script/simple_stream.py | ||
+ | dans ipython |
Version actuelle en date du 7 février 2013 à 20:50
Sommaire
Projet: améliorer la fraiseuse
- monter un shield GRBL pour avoir des drivers + puissants modèle GrblShield de SynthEthos
- coller les radiateur sur les controleurs TI
- bien fixer toutes les fins de course
- mettre à jour GRBL pour essayer d'avoir des fins de course en fonction des emplacements libres sur le shield Uno
- fignolages mécaniques
check chaine logicielle
références
- Notes du chantier boot camp 2010 https://projets.pingbase.net/libro/projects/fablab/wiki/GrBl
- Wiki de référence http://www.synthetos.com/wiki/index.php?title=Projects:grblShield
- Code source https://github.com/grbl/grbl
- Jumpers sur les ports MS0 & MS1 pour gérer les micro steps des moteurs pas à pas http://www.flickr.com/photos/rileyporter/8221207276/in/set-72157632010403997/
2013 01 28
flashage de l'Arduino DueMilanove avec la version 0.8c 9600bauds de GRBL
$ cd /dossier/des/sources/grbl
on modifie les sources de Makefile à la ligne 33. On remplace:
PROGRAMMER ?= -c avrisp2 -P USB
par:
PROGRAMMER = -c stk500v1 -P /dev/ttyUSB0 -b57600
Puis:
$ make; make flash
Pas sûr de ces instructions de http://dank.bengler.no/-/page/show/5471_gettinggrbl?ref=checkpoint qui ont l'air orientées windoze
$ avrdude -C/usr/share/arduino/hardware/tools/avrdude.conf -pm328p -cstk500v1 -P/dev/ttyUSB0 -b9600 -D -Ugrbl.hex
Comment connecter les contacteurs de fin de course
Un dessin vaut mieux que de longs discours:
Les résistances doivent etre entre 3.3k et 20k
Source : http://www.shapeoko.com/forum/viewtopic.php?f=5&t=361&start=10#p3050
C'est là que le fun commence
$ stty raw ignbrk 9600 < /dev/ttyUSB0 $ ( cat <&3 & cat >&3; kill %%) 3<>/dev/ttyUSB0
Grbl 0.8c ['$' for help] $ $$ (view Grbl settings) $# (view # parameters) $G (view parser state) $N (view startup blocks) $x=value (save Grbl setting) $Nx=line (save startup block) $C (check gcode mode) $X (kill alarm lock) $H (run homing cycle) ~ (cycle start) ! (feed hold) ? (current status) ctrl-x (reset Grbl) ok G21 ok G91 ok G1 X10 F200 ok G1 X-10 F400 ok $$ $0=7.273 (x, step/mm) $1=7.273 (y, step/mm) $2=400.000 (z, step/mm) $3=30 (step pulse, usec) $4=200.000 (default feed, mm/min) $5=600.000 (default seek, mm/min) $6=0 (step port invert mask, int:00000000) $7=25 (step idle delay, msec) $8=0.008 (acceleration, mm/sec^2) $9=300.000 (junction deviation, mm) $10=0.100 (arc, mm/segment) $11=25 (n-arc correction, int) $12=3 (n-decimals, int) $13=0 (report inches, bool) $14=1 (auto start, bool) $15=0 (invert step enable, bool) $16=0 (hard limits, bool) $17=0 (homing cycle, bool) $18=0 (homing dir invert mask, int:00000000) $19=25.000 (homing feed, mm/min) $20=250.000 (homing seek, mm/min) $21=100 (homing debounce, msec) $22=1.000 (homing pull-off, mm) ok $0=70 ok G1 X10 F400 ok
2013 01 30
Entraînement de la courroie axe Y
Les axes de renvoi des courroies de l'axe Y (profondeur) restaient fixe. En fait la partie interne du rotor des roulements frotte contre la surface support des roulements. Un chambrage dans la surface support permet de limiter le frottement mais il faut quand même éviter de trop serrer les axes.
Entraînement de la courroie axe X
C'est pas gagné...
2013 01 31
Re-câblage des moteurs pas à pas
Le câblage des moteurs a été fait pour les trois moteurs qui n'étaient pas branchés sur les bons axes. Face à la machine :
- axe X : de gauche à droite
- axe Y : du proche au lointain
- axe Z : de bas en haut
Câblage des fins de course
D'abord, on n'a rien compris. En fait les câbles reliés aux sorties "normalement fermées" des switches étaient tous connectés entre eux.
Ceci corrigé, nous avons re-etiquetés les cables de fin de course en se référant aux axes et aux sens précisés juste avant.
Finalement, ça ne marche toujours pas... Pour l'instant, les capteurs de fin de course sont déconnectés.
Calibrage des moteurs
Résultats pour les réglages d'usine (step/8)
- axe X = 14.7 step/mm (axe inversé)
- axe Y = 14.2 step/mm
- axe Z = 1570 step/mm (axe inversé)
2013 02 01
Essais
Essais de vitesse en fonction de : vitesse max, accélération, microstepping (step/8 ; step/4 ; step/2). Pour une course de 350 mm pour l'axe X et 230 mm pour l'axe Y.
Résultats, pour éviter les "gros" décalages, il faut limiter les valeurs des paramètres pour :
- accélération < 250 mm/s²
- vitesse max (axe X et Y) < 8000 mm/min
- vitesse max (axe Z) <= 200 mm/min
microstepping
À l'aide de bridges sur le GrblShield,on peut sélectionner la précision de chaque moteur au huitième de pas, au quart de pas, au demi-pas ou au pas entier. Par exemple, au huitième de pas, un pas pour grbl (c'est-à-dire une impulsion) fait tourner le moteur d'un huitième de pas "machine". Dans chaque cas, il faut corriger le nombre d'impulsion par millimètres (Exemple : 14,2 step/mm au huitième de pas donne 7,1 step/mm au quart de pas).
Les performances en terme de vitesse et d'accélération ne semblent pas être affectées par le choix du microstepping. De même, l'utilisation de pas entier n'a pas permis d'utiliser des vitesses plus élevée pour l'axe Z, qui broute toujours au dessus de 200 mm/min.
CNC_pycamgrBL
La CNC a été manipulée avec processing en corrigeant le baudrate (9600). Le sketch s'appelle désormais :
CNC_pycamgrBL_PAD2_hareng_frit
Il reste à corriger l'orientation des axes X et Z (re-compilation du firmware ?) pour pouvoir balancer du GCode.
2013 02 07
backup paramètres grbl :
$0=29.400 (x, step/mm) $1=29.300 (y, step/mm) $2=196.000 (z, step/mm) $3=30 (step pulse, usec) $4=8000.000 (default feed, mm/min) $5=8000.000 (default seek, mm/min) $6=0 (step port invert mask, int:00000000) $7=25 (step idle delay, msec) $8=10.000 (acceleration, mm/sec^2) $9=300.000 (junction deviation, mm) $10=0.100 (arc, mm/segment) $11=25 (n-arc correction, int) $12=3 (n-decimals, int) $13=0 (report inches, bool) $14=1 (auto start, bool) $15=0 (invert step enable, bool) $16=0 (hard limits, bool) $17=0 (homing cycle, bool) $18=0 (homing dir invert mask, int:00000000) $19=25.000 (homing feed, mm/min) $20=250.000 (homing seek, mm/min) $21=100 (homing debounce, msec) $22=1.000 (homing pull-off, mm)
inversion des commandes X et Z
processing 2 grbl
Pour une raison inconnue, le gcode n'est pas bien communiqué à grbl : les ordres semblent arriver dans un ordre plus ou moins aléatoire... Nous avons d'abord cherché à recompiler, puis flasher, grbl.
Finalement, c'était processing 2 grbl qui ne marchait pas bien. Avec un petit script python pour lancer le gcode, ça fonctionne... avec : https://github.com/grbl/grbl/blob/master/script/simple_stream.py dans ipython