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 que si se puede eliminar la mitad de las variables de la ecuación, cada vez se 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 motor se mueve solo un paso

La razón más común en una nueva instalación para que un motor a pasos haga esto es que se han intercambiado las señales de paso y dirección. Si se presionan las teclas de trote hacia adelante y hacia atrás alternadamente, y el motor se mueve un paso cada vez, y en la misma dirección, ahí está la prueba.

1.2. Los motores no se mueven en absoluto

Muchos controladores tienen un pin de activación o necesitan una bomba de carga para activar su salida.

1.3. Distancia incorrecta

Si se le ordena al eje que se mueva una distancia específica y no se mueve tal distancia, entonces la configuración de escala es incorrecta.

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 errores de 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

  • Holgura mecánica añadida a un eje

Cualquiera de los anteriores puede hacer que los pulsos en tiempo real no puedan mantenerse conforme a la tasa de pasos solicitada. Esto puede suceder si no se ejecutó la prueba de latencia el tiempo suficiente para obtener un buen número para el Asistente Stepconf, o si se configura la Velocidad máxima o la Aceleración máxima demasiado alta.

Si se agregó holgura mecánica, se debe aumentar STEPGEN_MAXACCEL hasta que duplique MAX_ACCELERATION en la sección AXIS del archivo INI para cada eje que se le agregó. LinuxCNC utiliza una "aceleración adicional" en una reversa para tener en cuenta la holgura mecánica. Sin corrección de holgura, 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

Cuando se reciba 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. Se debería correr la prueba de latencia durante un período prolongado de tiempo para ver si hay algún retraso que cause este problema. Si usaste el Asistente Stepconf, ejecútalo de nuevo y prueba el jitter del período base nuevamente, y ajusta Base Period Maximum Jitter en la página Información Básica de la máquina. Es posible que tengas que 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 del hardware está causando demoras o los hilos en tiempo real se configuran demasiado rápido, se obtendrá este error.

Nota
 Este error solo se muestra una vez por sesión. Si se tuviera un BASE_PERIOD demasiado bajo, se obtendrían cientos de miles de mensajes de error por segundo si se mostrara más de uno.

3. Pruebas

3.1. Tiempos de pasos

Si se observa un eje que termina en una ubicación incorrecta durante movimientos múltiples, es probable que no se tengan los tiempos de mantenimiento de dirección o de pasos correctos para los controladores. Cada cambio de dirección puede estar perdiendo un paso o más. Si los motores se saturan, también es posible que se tenga MAX_ACCELERATION o MAX_VELOCITY demasiado alto para ese eje.

El siguiente programa probará la configuración correcta del eje Z. Copia el programa a tu directorio ~/emc2/nc_files y asígnale un nombre como TestZ.ngc o similar. Pon a cero la máquina con Z = 0.000 en la parte superior de la mesa. Carga y ejecuta el programa. Hará 200 movimientos de ida y vuelta de 0.5 a 1". Si tienes un problema de configuración, encontrarás que la posición final no terminará en las 0.500" que la ventana del eje muestra. Para probar otro eje, simplemente reemplaza la Z con la letra del 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 configuraciones de velocidad y aceleración)
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