‼️Klipper Troubleshooting
Guía de resolución de problemas más comunes con Klipper y algunos de sus componentes
Última actualización
Guía de resolución de problemas más comunes con Klipper y algunos de sus componentes
Última actualización
REPORTAR PROBLEMAS EN NUESTROS GRUPOS DE TELEGRAM:
Dado que Klipper es un sistema con una arquitectura compleja y gran flexibilidad lo que dificulta enormemente en ocasiones poder ofrecer soluciones a los mismos es más que aconsejable el aportar información como logs de los componentes básicos, información de configuración de sistema, etc...
Dado que para algunos usuarios en ocasiones parece una tarea muy complicada os aconsejamos utilizar el servicio creado por el compañero Andrey Kozhevnikov que permite obtener y analizar los logs mediante un servicio cloud.
Desde estos scripts podremos obtener los logs de Klipper, Moonraker, dmesg y ficheros de sistema de configuración, Crownest o la extensión de Telegram actualmente.
Para poder utilizarlo, es muy sencillo, nos conectaremos a nuestro host Klipper por SSH y lanzaremos el siguiente comando dependiendo de nuestra instalación:
Instalación estándar, datos de Klipper en la directorio printer_data:
curl -L https://coderus.openrepos.net/klipper_logs/getlogs | bash -s
Instalación no estándar o en multi-instancia, donde tenemos una carpeta para cada instancia/impresora o directorio personalizada... en nuestro caso usamos printer_2_data como directorio de ejemplo de una instancia:
curl -L https://coderus.openrepos.net/klipper_logs/getlogs | bash -s -- printer_2_data
Una vez lanzado el script recuperará todos los datos necesarios, nos va a solicitar la contraseña de nuestro usuario, y los subirá al servicio web:
Por favor limpiar los logs de Klipper, Moonraker u otros servicios antes de generar estos logs para facilitar la tarea de quien quiera/pueda ayudaros... facilitareis la vida a quien quiera invertir/perder el tiempo ayudando. El proceso lo tenéis explicado en esta misma guía para Klipper y Moonraker donde se explica como acceder a los logs.
Aunque estos logs no deberían mostrar información confidencial o crítica os aconsejamos compartirlo de forma privada con quién os ayude.
Es vuestra propia responsabilidad el uso de esta herramienta, nosotros no nos hacemos responsable de cualquier uso de esta información por terceros.
Si todo ha ido correcto al final de la ejecución nos va a proporcionar un link a nuestro análisis de logs que podemos compartir en el grupo o con quien nos esté ayudando, obviamente os invitamos a que seáis vosotros mismos quienes reviséis primero los logs en búsqueda de fallos obvios o sencillos.
A continucación os facilitamos algunas soluciones a los problemas más comunes:
En ocasiones los servicios de Klipper pueden no arrancar correctamente por diferentes causas.
Para obtener más información en estos casos podemos utilizar el comando systemctl status klipper que nos va a reportar datos sobre el estado:
También tenemos el comando journalctl -u klipper que nos va a dar más detalles sobre posibles errores o cambios de estado del servicio:
También en el caso de necesitar compartir esta información con terceros podemos volcar todos esos datos en un archivo de log, en el siguiente ejemplo lo ponemos en una ubicación (ajustarla para vuestra instalación de no ser estándarizada) que sea sencilla de descargar desde vuestro interfaz web de gestión de Klipper:
Aunque hemos utilizado el servicio Klipper como ejemplo podemos hacer lo mismo con otros críticos como moonraker, klipperscreen, etc...
En los siguientes puntos veremos diferentes formas de corregir errores con Klipper, normalmente el 60% de los problemas suelen solucionarse con los problemas y posibles soluciones comentadas a continuación. El 39.8% siguiente suelen ser problemas relacionados con la configuración y el último raro 0.2% pueden ser bugs o el propio funcionamiento de Klipper.
En el caso que no puedas conectar con tu MCU, y veas los errores mencionados en el título de esta sección en el log de Klipper (klippy.log).
Posibles razones:
Problemas hardware entre tu electrónica/MCU y tu host, el cable USB de baja calidad o largo, el cableado si usamos otros tipos de conexión como USART, CAN, SPI o I2C
Utilizar parámetros incorrectos durante el make config para crear tu firmware para tu MCU
El firmware no se aplicó correctamente a tu electrónica/MCU
La electrónica/MCU está dañada ya sea completamente o su comunicación serial
Posibles soluciones:
Revisar si nuestra electrónica se registra correctamente en nuestro host Linux, para ello utilizaremos el comando dmesg
Desconectaremos, físicamente el cable, nuestra electrónica/MCU de nuestro host
Volveremos a conectarla
Lanzaremos el comando sudo dmesg -e (si has de pasarle el resultado a alguien para revisión utiliza sudo dmesg > ~/printer_data/logs/dmesg.txt ajusta el path/directorio a tu instalación para que te deje ese log accesible para descarga desde el interfaz web de Klipper que uses para facilitarte el proceso)
Una electrónica/MCU correctamente conectada muestra algo como esto en Manufacturer:
Otras cosas a tener encuenta:
Revisar y verificar que los parámetros utilizados durante la creación del firmware mediante make menuconfig eran los correctos para nuestra electrónica/MCU y la conexión elegida con nuestro host
Repeteir el proceso de aplicar el firmware para asegurarse que se hizo correctamente.
Revisar mediante el comando ls /dev/serial/by-id/* por el serial id de nuestra MCU y asegurarnos que dentro de la sección[mcu] de nuestro printer.cfg o includes que usemos la misma cadena que la obtenida del comando ls
Normalmente son provocados por problemas de comunicación entre el host Klipper y la MCU:
En caso que usemos comunicación USB entre host y MCU es importante que el cable sea de buena calidad y que los conectores están fijos y seguros
Si usamos una RPI, u otro tipo similar de SBC como host, como host de Klipper es importante usar una fuente de alimentación y un cable USB de alimentación de calidad. Si la fuente de alimentación tiene fluctuaciones puede llegar a afectar a la comunicación USB/USART entre MCU y host Klipper. Los avisos de "under voltage" no son buenos.
De igual forma que disponer de una fuente dimensionada y estable en nuestro host es muy importante mantener este a una temperatura de trabajo adecuada es igual de importante.
Problemas de alimentación y temperaturas en hosts SBC (Single Board Computer):
Usar hosts SBC, Raspberry Pi y similares, es una de las mejores opciones con Klipper... ya sea por su compatibilidad con las diferentes distribuciones, modulos, tamaño compacto para integrar en nuestra impresora o consumo de electricidad contenido.
Por otro lado usando estos SBC hay que tener dos aspectos bajo control:
una alimentación dimensionada y estable para evitar el temido aviso de "undervoltage"
una correcta ventilación de nuestro SBC para evitar temperaturas que afecten al rendimiento/estabilidad de nuestro host
Pero en que puede afectar lo anterior?
Reducción de la frecuencia de la MCU, afectando al rendimiento
Problemas de estabilidad de Klipper y sus módulos/componentes
Desconexiones de dispositivos USB/USART
Reinicios de nuestro host
Comunicaciones WiFi inestables
Podemos detectar estos errores desde la propia interfaz de Klipper con un aviso de undervoltage por ejemplo, añadiendo el control de temperatura del host en nuestra configuración o desde línea de comandos SSH con el comando vcgencmd get_throttled donde devolverá 0x0 si todo está correcto.
Algunas sugerencias para evitar estos problemas:
Utilizar una fuente de alimentación de calidad que entregue 3A y 5.1v (en el caso de Pi, consultar necesidades del fabricante para otros SBC) de forma estable y constante. Os hacemos incapié en estable y constante, mucha gente usa sistemas de alimentación que aunque indiquen que entregan lo necesario en la realidad no lo son.
Utilizar un cable USB de calidad, algunos cables de baja calidad tienen una resistencia alta lo que afecta a la alimentación que llegue a nuestro SBC.
No conectes de forma directa dispositivos USB que tengan un alto consumo de alimentación, utiliza un hub USB que disponga de su propia alimentación independiente.
Asegurarnos que las conexiones en general de nuestra MCU con el resto de componentes estan correctas y firmes para evitar fallos en conexión.
Es muy importante que si nuestra electrónica MCU no cuenta con un jumper de alimentación entre USB y la fuente de la impresora tapemos la alimentación USB del cable para evitar retroalimentación
Revisa que la versión de firmware Klipper en tu electrónica coincida con la de tu Host, en determinadas circunstancias no usar las mismas versiones puede ocasionar perdidas de conexión.
Podemos encontrar muchos ejemplos de estos en el propio repositorio de Klipper.
En otras ocasiones podemos tener una MCU soportada por Klipper pero no disponer de un printer.cfg de ejemplo. En estos casos podemos usar el gran trabajo de Marlin en sus ficheros pins.
Podremos usar el pins.h para localizar donde se encuentra nuestro fichero pins y sus alias para realizar la traducción a nuestro printer.cfg.
En ocasiones Klipper puede pararse indicando un error ADC (Analog to Digital Converter) cuando intenta leer o convertir las lecturas de los termistores (sonda de temperatura) definidos en nuestra configuración. Klipper en estos casos, y por seguridad, se parará:
revisa que las definiciones y pines de control en tu configuración de Klipper para los termistores es correcta
revisa que el cableado, conexiones y estado del sensor sean correctos
reemplaza los sensores por unos nuevos sensores
En ocasiones, normalmente durante la impresión o movimientos de la máquina, podemos encontrarnos con errores TMC reportados por Klipper:
asegúrate que tu electrónica esté alimentada con la fuente de tu impresora, los drivers TMC no se inicializan si no están alimentados correctamente
revisa que los drivers estén correctamente instalados en su zócalo y los jumpers necesarios correctamente colocados
en caso de otro tipo de errores revisa la guía oficial de Klipper sobre drivers TMC
Configuración Klipper:
Los siguientes errores suelen tener relación con problemas en la configuración de Klipper, printer.cfg o cualquier include que se cargue desde el.
Os recordamos que Klipper monta la configuración de forma secuencial... esto es que va leyendo línea por línea el printer.cfg y los includes de forma que si una sección se encuentra dos veces en la configuración la última en procesarse es la que prevalece sobre cualquier anterior.
Esto es especialmente importante y útil cuando tenemos un printer.cfg desestructurado o una configuración modular en base a includes.
Para evaluar cual es la configuración efectiva de Klipper en estos casos lo mejor es revisar el log de Klipper donde nos mostrará la configuración efectiva que usará.
Estos errores suelen indicar un problema en el parseo del fichero de configuración, normalmente por poner incorrectamente valores u opciones.
En el propio error o en el log suele dar bastante información. Por otro lado podemos revisar la documentación de Klipper donde encontramos las referencias a todas sus funciones de configuración para poder verificar que incluimos correctamente estas y sus opciones.
Por otro lado en ocasiones podemos encontrarnos con opciones que ya no están en uso, podremos buscar en la documentación de Klipper sobre estos cambios en configuración y como adaptarlos a versiones actuales. Algunos ejemplos:
A partir de las versiones de Klipper del 13/03/2024 la sección max_accel_to_decel ha sido reemplazada por minimum_cruise_ratio.
Esto significa que si actualizamos nuestra versión de Klipper y en nuestro cfg utilizamos max_accel_to_decel deberemos cambiarlo al nuevo minimum_cruise_ratio:
Aquí podremos ver como adaptar nuestra configuración:
Importante recalcar que, aunque ambas propiedades actúan sobre el mismo concepto en referencia a las gestiones de aceleración/desaceleración max_accel_to_decel se expresaba en mm/s, normalmente 1/2 de max_accel... mientras que con minimum_cruise_ratio es un valor entre 0 y 1 a modo de porcentaje sobre el la distancia de traslado para hacer unas deceleraciones menos bruscas que produzcan vibraciones, con lo que si usamos un valor de 0.5 (valor que por defecto en caso de no definirlo utilizará) y tenemos un movimiento de 10mm realizaría en 5mm esa aceleración/deceleración.
Por último y relacionado con esto mismo podremos encontrar que determinadas configuraciones solamente están disponibles cuando se instalan extras/plugins a Klipper que añaden nuevas funcionalidades, en estos casos deberemos asegurarnos que están correctamente instaladas en nuestro sistema y como han de ajustarse sus configuraciones.
El log de Klipper es muy util para identificar problemas con el sistema. Para poder acceder a el podemos hacerlo de dos formas:
La forma mas sencilla es desde la UI, en el caso de Mainsail usaremos el apartado MACHINE y dentro de esta en la seccion Log Files podremos descargar logs de Klipper y Moonraker
En el caso que nuestros logs sean muy grandes o con mucha información antigua podemos realizar una limpieza del mismo desde la propia interfaz:
Para reiniciar el servicio Klipper podemos hacerlo de diferentes formas:
Para que Mainsail funcione correctamente nuestro printer.cfg, o alguno de nuestros includes, ha de añadirse ciertas secciones al mismo.
Normalmente la propia UI o logs informan del problema pero en ocasiones el síntoma es que no tenemos acceso a los gcode para imprimir.
Secciones básicas necesarias:
Normalmente suele ser mejor opción añadir el include al mainsail.cfg que nos deja la instalación de Mainsail en nuestro printer.cfg:
En el caso que no tengáis por cualquier cosa ese mainsail.cfg podéis crearlo a partir de:
https://github.com/mainsail-crew/mainsail-config/blob/master/client.cfg
En el caso de que nos indiquen que siguen faltando opciones, las añadiremos a mano a nuestro printer.cfg:
En ocasiones, en especial si hemos sido creativo instalando Klipper, nos podemos encontrar que intentamos subir un gcode ya sea desde el laminador directamente o desde el interfaz web... o simplemente al intentar imprimirlo y no nos deja dando errores en el log del tipo "Unable to open file".
En ocasiones estos errores están relacionados con lo siguiente:
El path configurado en la sección [virtual_sdcard] no existe o no es accesible. En una instalación de Klipper normalizada deberíamos tener algo así:
Comprobaremos que el path anterior existe en nuestra instalación de Klipper, si no podemos crearlo o poner el correcto normalizado en el caso que esté mal el path
Otro problema que puede ocurrir es que el path exista pero el usuario que usamos para Klipper no tenga acceso, lo solucionaremos de la siguiente forma desde SSH:
chown pi ~/printer_data/gcodes
chmod 777 ~/printer_data/gcodes
Donde la primera linea la usariamos para hacer el usuario pi como propietario de ese path, si usas otro para lanzar tu Klipper sustituye pi por tu usuario, y la segunda linea permite a cualquier usuario o grupo poder leer/escribir/ejecutar en ese path.
Crowsnest es un demonio para la gestión de webcams en distribuciones basadas en Raspberry Pi como MainsailOS o RatOS aunque puede llegar a funcionar en otras distribuciones.
Si tu sistema de gestión de webcam, usando obviamente Crowsnest, ha dejado de funcionar después de una actualización, es posible que esté relacionado con los cambios entre v3 a v4 que ha sido un gran cambio en este componente.
Os aconsejamos leeros este procedimiento para solventar correctamente el upgrade.
El log de Moonraker es muy util para identificar problemas con el sistema. Para poder acceder a el podemos hacerlo de dos formas:
La forma mas sencilla es desde la UI, en el caso de Mainsail usaremos el apartado MACHINE y dentro de esta en la seccion Log Files podremos descargar logs de Klipper y Moonraker
En el caso que nuestros logs sean muy grandes o con mucha información antigua podemos realizar una limpieza del mismo desde la propia interfaz:
Para reiniciar el servicio Moonraker podemos hacerlo de diferentes formas:
Disponeis de una completa guía de troubleshooting aquí.
Dado que es un tema recurrente en nuestro grupo Klipper de Telegram vamos a exponer algunos de los puntos por lo que a día de hoy, Agosto 2023, no se da mucho soporte en el grupo a este dispositivo.
Un poco de historia... La Creality Sonic Pad es un dispositivo de Creality que monta una MCU llamada Creality T800 sobre una distribución de Linux un tanto especial llamada Tina, que a su vez es un fork de Allwinner de una OpenWRT.
Ya tenemos un primer problema con el uso de una MCU no muy popular junto con una distribución de Linux un tanto especial... pero aquí es donde viene lo peor de todo... la Creality Sonic Pad y la distribución de firmware que usa implementa versiones muy antiguas, a día de hoy más de 9 meses, de Klipper/Moonraker/Mainsail y la UI Fluidd.
Además y en referencia a la UI Fluidd es un fork creado por Creality.
Por otro lado los componentes de Klipper antes mencionados son compartidos como paquetes pre-montados y que, en su propio repositorio de Creality, no ofrecen instrucciones de como montarlos además de no incluir algunos de ellos.
Con todo esto lo que queremos decir:
Hardware muy específico
Distribución especial y limitada
Componentes Klipper que requieren de Creality para ser actualizados
Algunos de estos componentes no se dispone, a día de hoy, de la suficiente información como para poder actualizarlos y dependemos de "la buena fe" de Creality
Mucha gente asegura que no es un problema y que se puede, como cualquier dispositivo de estas características, usar otros sistemas... si y no!!! si, seguro que si Creality abre el acceso a cierta información se va a poder hacer... y no, a día de hoy poder hacerlo es un verdadero quebradero de cabeza y de hecho no abundan firmwares alternativos funcionales para este dispositivo.
Pero aquí el segundo gran problema de esta máquina a día de hoy... al no tener unos componentes Klipper actualizados, de hecho muy desactualizados, nos lleva a que muchas mejoras... soporte a electronicas... bugs solucionados... funciones nuevas... NO estén disponibles y por lo tanto no poder usarse en algunos casos como el uso de ciertas macros, configuraciones o incluso máquinas que ya han tenido Klipper en versiones actuales.
La solución como siempre seria reemplazar la actual distribución por una más genérica como una Debian o similar dado que aparentemente el kernel usado en la Sonic Pad parece relativamente compatible. Además de que basandose en AllWinner se dispone de cierta información que ya os adelantamos que no es fácil de seguir y mantener, aquí.
Además hay que tener en cuenta que la maquinaria de márketing de Creality, y en especial de las hordas de Youtubers patrocinados, han vendido la Creality Sonic Pad como un producto de "ten Klipper en 5m" y, pese el trabajo de Creality en hacer lo más simple el proceso (en especial en sus máquinas obviamente) y que es de agradecer, por desgracia Klipper es algo más que dedicarle 5m de ahí muchas de sus ventajas que son que al tener que conocer el sistema mínimamente te lleva a poder ajustarlo, mejorarlo y adaptarlo a tu uso acabando al final con un conjunto que aporta más calidad y funciones. Sumando, de nuevo, que los componentes Klipper en la Sonic Pad son "añejos" si seguimos documentaciones o procesos actuales de Klipper pueden no ser compatibles.
También seamos sinceros, el usuario medio de una Sonic Pad le hablas de kernels, particiones rootfs, compilaciones y demás... les va a sonar, nunca mejor dicho, a chino.
Por todo esto cuando se habla sobre este tipo de dispositivos no los aconsejamos, a día de hoy, y si aconsejamos otros más genéricos como Raspberry, OrangePi, etc... en especial, y por ofrecer un producto similar, la gama Pad de Bigtreetech que SI que usan componentes Klipper de las fuentes originales y quizás lo más importante para nosotros... que Bigtreetech es un colaborador de Klipper!!!
Esperemos que ahora entendáis mejor el por qué, de nuevo a día de hoy, para nosotros la Sonic Pad no es en todos los casos la mejor alternativa para el uso de Klipper... cuando tenemos otras soluciones que usan mejor Klipper, más baratas y que en algunos casos apoyan el crecimiento de Klipper.
Custom Firmware Sonic Pad:
Aclarado todo lo anterior y en el caso que dispongas de una Sonic Pad y quieras tener una experiencia de uso con Klipper "libre" te aconsejamos, bajo tu propia responsabilidad, revisar la siguiente guía para poder aplicar un firmware alternativo que nos dará un acceso a Klipper oficial con todas sus ventajas.
Moonraker
Encuentra soluciones a los problemas más comunes de esta API para Klipper.
