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 ===
=== 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 ==
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
=== 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 ou , au demi-pasou 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).
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) $CNC_pycamgrBL_PAD2_hareng_frit21=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