FraiseuseCNC/restauration

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)

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