:ini:ini :hal:hal :ngc:ngc
Muchas veces lo que se obtiene no es lo que espera; pero todo es cuestión de experiencia. Aprender de la experiencia aumenta la comprensión del todo. La mejor manera de diagnosticar problemas es dividir y conquistar. Con esto quiero decir si puede eliminar la mitad de las variables de la ecuación, cada vez encontrará el problema más rápido. En el mundo real esto no siempre es el caso, pero generalmente es una buena manera de comenzar.
1. Problemas comunes
1.1. El Stepper se mueve solo un paso
La razón más común en una nueva instalación para que un motor paso a paso haga esto es que se han intercambiado las señales de paso y dirección. Si presiona el jog hacia adelante y hacia atrás, alternativamente, y el motor se mueve un paso cada vez, y en la misma dirección, ahí está la prueba.
1.2. Los steppers no se mueven en absoluto
Muchos drivers tienen un pin de activación o necesitan una bomba de carga para activar su salida.
1.3. Distancia no correcta
Si le ordena al eje que se mueva una distancia específica y se mueve a otra distancia, entonces su ajuste de escala es incorrecto.
2. Mensajes de error
2.1. Error de seguimiento
El concepto de error de seguimiento es extraño cuando se habla de motores de pasos. Como son sistemas de lazo abierto, no hay retroalimentacion de posición para hacerle saber si realmente está fuera de rango. LinuxCNC calcula si puede mantener el cumplimiento del movimiento solicitado y, si no, entonces da un error de seguimiento. Los erroresde seguimiento generalmente son el resultado de uno de los siguientes problemas en sistemas paso a paso.
- FERROR demasiado pequeño - MIN_FERROR demasiado pequeño - MAX_VELOCITY demasiado rápida - MAX_ACCELERATION demasiado rápida - BASE_PERIOD demasiado largo - Backlash agregado a un eje
Cualquiera de los anteriores puede hacer que los pulsos en tiempo real no pueda mantenerse conforme a la tasa de pasos solicitada. Esto puede suceder si no ejecutó la prueba de latencia el tiempo suficiente para obtener un buen número para el Asistente Stepconf, o si configura la Velocidad Máxima o la Aceleración Máxima demasiado alta.
Si agregó backlash, debe aumentar STEPGEN_MAXACCEL hasta que duplique MAX_ACCELERATION en la sección AXIS del archivo INI para cada eje al que se agregó. LinuxCNC utiliza una "aceleración adicional" en una inversión para tener en cuenta el backlash. Sin corrección de backlash, la aceleración del generador de pasos será solo un pequeño porcentaje mayor que la aceleración planificada del movimiento.
2.2. Error RTAPI
Usted puede recibir este error:
RTAPI: ERROR: retraso inesperado en tiempo real en la tarea n
Rtapi genera este error basándose en una indicación de RTAI de que se violó el tiempo limite. Suele ser una indicación de que BASE_PERIOD en la sección [EMCMOT] del archivo ini está configurado demasiado bajo. Debería correr la prueba de latencia durante un período prolongado de tiempo para ver si tiene algun retraso que causarían este problema. Si utilizó el Asistente Stepconf, ejecútelo de nuevo y pruebe el jitter del período base nuevamente, y ajuste Base Period Maximum Jitter en la página Información Básica de la máquina. Usted debe dejar la prueba en funcionamiento durante un período prolongado de tiempo para encontrar si algún hardware causa problemas intermitentes.
LinuxCNC rastrea el número de ciclos de CPU entre invocaciones de hilos en tiempo real. Si algún elemento de su hardware está causando demoras o sus hilos en tiempo real se configuran demasiado rápido, obtendrá este error.
NOTA: Este error solo se muestra una vez por sesión. Si tuviera su BASE_PERIOD demasiado bajo, podría obtener cientos de miles de mensajes de error por segundo si se mostrara más de uno.
3. Pruebas
3.1. Temporización de pasos
Si tiene un eje que termina en una ubicación incorrecta durante movimientos múltiples, es probable que no tenga los tiempos de mantenimiento de dirección o de timing de pasos correctos para sus drivers. En cada cambio de dirección puede estar perdiendo un paso o más. Si los motores se saturan, es también es posible que tenga el conjunto MAX_ACCELERATION o MAX_VELOCITY demasiado alto para ese eje.
El siguiente programa probará la configuración correcta del eje Z. Copie el programa en su directorio ~/emc2/nc_files y asígnele un nombre como TestZ.ngc o similar. Ponga a cero su máquina con Z = 0.000 en la parte superior de la mesa. Cargue y ejecute el programa. Hará 200 movimientos de ida y vuelta de 0.5 a 1". Si tiene un problema de configuración, encontrará que la posición final no terminará en las 0.500" que la pantalla muestra. Para probar otro eje, simplemente reemplace la Z con la letra de eje a probar en las líneas G0.
(programa de prueba para ver si el eje Z pierde posición)
(msg, prueba 1 de configuración del eje Z)
G20 #1000=100 (bucle 100 veces)
(este bucle tiene retrasos después de los movimientos)
(prueba ajustes de velocidad y aceleracion)
o100 while [#1000]
G0 Z1.000
G4 P0.250
G0 Z0.500
G4 P0.250
#1000 = [#1000 - 1]
o100 endwhile
(msg, prueba 2 de la configuración del eje Z, S para continuar)
M1 (para aquí)
#1000=100 (bucle 100 veces)
(el siguiente ciclo no tiene demoras después de los movimientos)
(prueba los tiempos de retención de dirección del controlador y también la aceleración máxima)
o101 while [#1000]
G0 Z1.000
G0 Z0.500
#1000 = [#1000 - 1]
o101 endwhile
(msg, Listo ... Z debe estar exactamente .5" sobre la mesa)
M2