[Duda] Problema CNC Shield + Arduino ALARM: Homing fail

[Diego]

 Hola,

 Estoy en proceso de construir una Cyclone PCB Factory y estoy ahí ahí. Tengo la estructura acabada y funcionando pero me estoy dando de cabezazos con el software.

 He leído un montón de hilos del foro pero no termino de aclararme. Por eso he decidido poner un poco lo que me pasa a ver si hay alguien que me pueda echar una mano.

 La electrónica que tengo es un arduino con un CNC shield. Le he cargado el Grbl 0.9j , antes ya había tenido la precaución de borrar la EEPROM. Los valores que tiene actualmente son :

 $0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=0 (dir port invert mask:00000000)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.010 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=1 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=50.000 (homing feed, mm/min)
$25=500.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=2560.000 (x, step/mm)
$101=2560.000 (y, step/mm)
$102=4800.000 (z, step/mm)
$110=300.000 (x max rate, mm/min)
$111=300.000 (y max rate, mm/min)
$112=150.000 (z max rate, mm/min)
$120=16.000 (x accel, mm/sec^2)
$121=16.000 (y accel, mm/sec^2)
$122=16.000 (z accel, mm/sec^2)
$130=168.000 (x max travel, mm)
$131=101.000 (y max travel, mm)
$132=50.000 (z max travel, mm)

Desde el pc estoy usando un Linux Mint con el programa Universal Gcode Sender (version 1.0.9 / Nov 11,2015). Una vez que conecto el Arduino aparece :

Grbl 0.9j ['$' for help]
['$H'|'$X' to unlock]
>>>

Con lo que la placa está bien reconocida. Le mando el comando $X y me deja mover los tres ejes. Aquí tengo una duda ya que el eje Z me lo deja mover en una sola dirección. He probado a cambiar el driver del motor y sigue comportandose igual así que debe ser algún tema de software.

Una vez hecho esto lo que hago es un $H. Un home para que vaya a la posición de referencia. Y obtengo esto por el puerto serie :

Grbl 0.9j ['$' for help]
['$H'|'$X' to unlock]
>>> $H
ALARM: Homing fail
ok

Grbl 0.9j ['$' for help]
['$H'|'$X' to unlock]

La máquina empieza a moverse en los ejes X , llega al final de carrera y para. A continuación hace lo mismo con el Y y para. Pero tras parar devuelve la Alarma y parece que el Grbl se reinicie.

Desconozco si puede ser problema de los fines de carrera. He comprado unos por ebay que llevan la placa incorporada con tres cables y un led. Los he conectado a normalmente abiertos ambos y parecen responder.

 A ver si me podéis ayudar que llevo días dándole vueltas.

 Un saludo

[Jose Vega]

Hola Diego, prueba a ver si tiene que ver con algo de esto:

https://groups.google.com/d/msg/cyclone-pcb-factory-es/G2QIhd9xSN8/PEIM0Wd_BQAJ

Saludos

[Diego]

Hola,

Este hilo ya lo vi en su momento y no conseguí dar con el problema. Los endstop creo que están bien configurados, pero de todas maneras lo volveré a revisar.

Muchas gracias

[Diego]

Una pregunta en concreto. ¿Que software usáis en el pc para el homing y demás?

Gracias

[Juan Lopez]

Hola Diego.
Tienes desactivado el homing por hardware ($21=0 (hard limits, bool)), activalo con el comando $21=1.
Un saludo.
Juan Lopez

[Diego]

 Hola,

 Muchas gracias por las respuestas. El homing por hardware viene desactivado en el firmware que se ha publicado en el github de cyclone. ¿Realmente es necesario activarlo?

 He detectado otro error que parece bastante importante. Los fines de carrera provocan que la placa se reinicie. Son los típicos de las páginas chinas que tienen un led de encendido para cuando están pulsados. Además incluyen una pequeña resistencia y un condensador. (http://www.ebay.com/itm/3pcs-Mechanical-Endstop-Limit-Switch-With-Cable-for-CNC-3D-Printer-RAMPS-1-4-NEW-/251262380165?hash=item3a8067a885:g:SPoAAOSw5cNYT-KZ)
 Lo que he hecho finalmente ha sido desoldar todos los componentes adicionales y conectar solamente el cable negro y verde. Con esto parece que puedo seguir con mis pruebas.

 Saludos

[Diego]

 Hola,

 Sigo haciendo pruebas y la cosa va mejorando. He conseguido hacer el homing pulsando los endstop con las manos. Así que la parte eléctrica funciona correctamente. He detectado un posible error en el software que voy a explicar para ver si hay alguien que puede echarme una mano. He detectado que en el segundo eje me está pasando una cosa extraña a la hora de pulsar el fin de carrera. Voy a explicar el proceso :

 - En primer lugar se produce el homing del eje X. Para ello el motor se mueve y va acercando el carro al fin de carrera. Una vez que pulsa se aleja del carro y se vuelve a acercar mucho más despacio. Con esto pasa al eje y.

 - Una vez que ha acabado el eje x comienza el eje y. El motor se mueve al fin de carrera se acerca y pulsa el fin de carrera. Una vez pulsado, el carro sigue acercándose al final de carrera :S. Debería alejarse en lugar de acercarse.

 He probado a hacer el homing con las manos y funciona pero el segundo eje hace mal el proceso de acercamiento. He probado a cambiar el orden del eje x e y y siempre es el segundo eje el que da problemas. La versión de firmware que estoy utilizando es Grbl 0.9j con los valores por defecto descargados del repositorio https://github.com/carlosgs/grblForCyclone

A ver si alguien me pudiera guiar.

 Gracias ^_^

[Juan Lopez]

Hola Diego.
Intentalo aumentando el homing pull-off ,haber si así se soluciona (por ejemplo ponlo en 2 mm)

$27=1.000 (homing pull-off, mm)

Un saludo.

[Diego]

 Hola

 Lo he cambiado y no funciona :( . Si que se nota el comportamiento del comando, pero el segundo eje no vuelve hacia atrás una vez que se ha producido el contacto con el fin de carrera. En lugar de eso va hacia el fin de carrera.
 ¿Alguna idea?

 Un saludo y gracias de nuevo ^_^

[Diego]

 Hola,

 El problema está en la electrónica. He cambiado el arduino y todo ha empezado a funcionar correctamente.

 Gracias a todos. Un saludo