1 165
modifications
Modifications
→processing 2 grbl
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|leftcenter]]
Les résistances doivent etre entre 3.3k et 20k
=== C'est là que le fun commence ===
$ stty raw ignbrk 9600 < /dev/ttyUSB0
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 ==
=== Câblage des fins de course ===
D'abord, on n'a rien compris. En fait les câbles reliés aux sorties "normalement ferméfermées" des swithes 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.
=== 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.La carte est capable de contrôler chaque moteur au huitième de pas, au quart de pas, au demi-pas ou demiau 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é é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.pydans ipython