Youtube
Telegram
Discord
Colabora

‼️Klipper Troubleshooting

Guía de resolución de problemas más comunes con Klipper y algunos de sus componentes

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:

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.

A continucación os facilitamos algunas soluciones a los problemas más comunes:

Mayo 2023 - Incidente Debian Bullseye (MainsailOS, por ejemplo, se basa en el) con actualización udev que rompe la creación de links simbólicos en /dev/serial/by-id.

  • Como verificar si nos afecta:

    • obviamente si despues de actualizar nuestro host perdemos la conexión con la máquina

    • si al hacer un ls /dev/serial/by-id da error o no muestra nuestra mcu

    • si hacemos un apt show udev (desde SSH en nuestro host) y tenemos la versión 247.3-7+deb11u2

    • si verificamos nuestras reglas udev, /lib/udev/rules.d/60-serial.rules, y vemos que es como el siguiente caso https://www.diffchecker.com/0PizKhy1/( izquierda es el incorrecto y derecha el correcto)

  • Como solucionarlo... tenemos diferentes opciones:

    • ejecutando el siguiente comando para actualizar la version udev... recordad reiniciar una vez aplicado

      cd ~;wget http://ftp.us.debian.org/debian/pool/main/s/systemd/libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb http://ftp.us.debian.org/debian/pool/main/s/systemd/udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb;APT_LISTCHANGES_FRONTEND=none sudo apt install --fix-broken ./libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb ./udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb; rm libudev1_252.5-2~bpo11+1_`dpkg --print-architecture`.deb udev_252.5-2~bpo11+1_`dpkg --print-architecture`.deb

    • Actualizando la regla udev tal como vimos en https://www.diffchecker.com/0PizKhy1/

    • usando como conexión a nuestra mcu by-path, ls /dev/serial/by-path/* para encontrar tu mcu, temporalmente hasta que el problema se solvente en próxima actualización del sistema,lo ideal es usar by-id

    • creando un link simbolico del punto de montaje by-path a by-id, NO ACONSEJABLE dado que no es aconsejable el uso de by-path

Revisión de errores de servicios

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:

systemctl status klipper > ~/printer_data/logs/klipper_status.txt
journalctl -u klipper > ~/printer_data/logs/klipper_journal.txt

Aunque hemos utilizado el servicio Klipper como ejemplo podemos hacer lo mismo con otros críticos como moonraker, klipperscreen, etc...

Klipper

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.

Errores MCU: Serial connection closed/Timeout on connect/Wait for identify_response

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:

[127913.638806] usb 5-1: new full-speed USB device number 25 using ohci-platform
[127913.873733] usb 5-1: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[127913.873755] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[127913.873761] usb 5-1: Product: lpc1769
[127913.873765] usb 5-1: Manufacturer: Klipper
[127913.873769] usb 5-1: SerialNumber: 0C70001625813AAF86E06B5CC32000F5
[127913.877920] cdc_acm 5-1:1.0: ttyACM0: USB ACM device

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

Pérdidas comunicación/reinicios con MCU/Host

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.

MCU definiciones de pines

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.

Error ADC

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

Errores TMC

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á.

Errores "option xxx is not valid in section xxx" o fallos al procesar vuestro/s fichero/s de configuración

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:

Ejemplo configuración antigua con max_accel_to_decel
[printer]
max_velocity: 200
max_accel: 1500
max_accel_to_decel: 750
max_z_velocity: 15
max_z_accel: 30
square_corner_velocity: 5

Aquí podremos ver como adaptar nuestra configuración:

Ejemplo de configuración actualizada a minimum_cruise_ratio
[printer]
max_velocity: 200
max_accel: 1500
minimum_cruise_ratio: 0.5
max_z_velocity: 15
max_z_accel: 30
square_corner_velocity: 5

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.

Acceder al log de Klipper

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:

Reinicio del servicio Klipper

Para reiniciar el servicio Klipper podemos hacerlo de diferentes formas:

Mainsail

Requerimientos en configuración

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:

[include mainsail.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:

printer.cfg
[pause]

[resume]

[cancel_print]

[pause_resume]

[display_status]

[virtual_sdcard]
path: ~/printer_data/gcodes

Errores acceso gcodes

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í:

[virtual_sdcard]
path: ~/printer_data/gcodes

  • 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

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.

Upgrade v3 a v4

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.

Moonraker

Os aconsejamos leeros este procedimiento para solventar correctamente el upgrade.

Incidentes:

Octobre 2022 - Moonraker... cambios estructura directorios

Recientemente, Moonraker hizo un cambio importante en la estructura de carpetas que afectan a carpetas de configuraciones.

Un indicativo que tenemos este problema es que después de actualizar nuestra instalación de Moonraker esta no se comunica con Klipper, nos saltan varios errores o no tenemos acceso/permiso desde la UI a nuestros ficheros de configuración o alguna de las funciones relacionadas.

/home/pi/printer_data
├── backup
│   └── 20220822T202419Z
│       ├── config
│       │   └── moonraker.conf
│       └── service
│           └── moonraker.service
├── certs
│   ├── moonraker.cert (optional)
│   └── moonraker.key (optional)
├── config
│   ├── moonraker.conf
│   └── printer.cfg
├── database
│   ├── data.mdb
│   └── lock.mdb
├── gcodes
│   ├── test_gcode_one.gcode
│   └── test_gcode_two.gcode
├── logs
│   ├── klippy.log
│   └── moonraker.log
├── systemd
│   └── moonraker.env
└── moonraker.secrets (optional)

En el caso de que nuestra instalación no funcione, podremos usar links simbólicos para mapear los directorios antiguos a los nuevos:

/home/pi/printer_data
├── backup
│   └── 20220822T202419Z
│       ├── config
│       │   ├── include
│       │   │   ├── extras.conf
│       │   │   ├── power.conf
│       │   │   └── updates.conf
│       │   └── moonraker.conf
│       └── service
│           └── moonraker.service
├── certs
│   ├── moonraker.cert -> /home/pi/certs/certificate.pem
│   └── moonraker.key -> /home/pi/certs/key.pem
├── config -> /home/pi/klipper_config
├── database -> /home/pi/.moonraker_database
├── gcodes -> /home/pi/gcode_files
├── logs -> /home/pi/logs
├── systemd
│   └── moonraker.env
└── moonraker.secrets -> /home/pi/moonraker_secrets.ini

Dentro de la propia actualización de Moonraker ya dispones de un script para poder adaptar la estructura de directorios:

En caso de que no dispongas de el por una actualización incorrecta puedes obtenerla de esta forma entrando en el terminal por SSH:

cd ~/moonraker
git pull
./scripts/data-path-fix.sh
~/moonraker/scripts/scripts/data-path-fix.sh
#!/bin/bash
# Data Path Fix for legacy MainsailOS and FluiddPi installations running
# a single instance of Moonraker with a default configurationer
DATA_PATH="${HOME}/printer_data"
DATA_PATH_BKP="${HOME}/.broken_printer_data"
DB_PATH="${HOME}/.moonraker_database"
CONFIG_PATH="${HOME}/klipper_config"
LOG_PATH="${HOME}/klipper_logs"
GCODE_PATH="${HOME}/gcode_files"
MOONRAKER_CONF="${CONFIG_PATH}/moonraker.conf"
MOONRAKER_LOG="${LOG_PATH}/moonraker.log"
ALIAS="moonraker"

# Parse command line arguments
while getopts "c:l:d:a:m:g:" arg; do
    case $arg in
        c)
            MOONRAKER_CONF=$OPTARG
            CONFIG_PATH="$( dirname $OPTARG )"
            ;;
        l)
            MOONRAKER_LOG=$OPTARG
            LOG_PATH="$( dirname $OPTARG )"
            ;;
        d)
            DATA_PATH=$OPTARG
            dpbase="$( basename $OPTARG )"
            DATA_PATH_BKP="${HOME}/.broken_${dpbase}"
            ;;
        a)
            ALIAS=$OPTARG
            ;;
        m)
            DB_PATH=$OPTARG
            [ ! -f "${DB_PATH}/data.mdb" ] && echo "No valid database found at ${DB_PATH}" && exit 1
            ;;
        g)
            GCODE_PATH=$OPTARG
            [ ! -d "${GCODE_PATH}" ] && echo "No GCode Path found at ${GCODE_PATH}" && exit 1
            ;;
    esac
done

[ ! -f "${MOONRAKER_CONF}" ] && echo "Error: unable to find config: ${MOONRAKER_CONF}" && exit 1
[ ! -d "${LOG_PATH}" ] && echo "Error: unable to find log path: ${LOG_PATH}" && exit 1

sudo systemctl stop ${ALIAS}

[ -d "${DATA_PATH_BKP}" ] && rm -rf ${DATA_PATH_BKP}
[ -d "${DATA_PATH}" ] && echo "Moving broken datapath to ${DATA_PATH_BKP}" && mv ${DATA_PATH} ${DATA_PATH_BKP}

mkdir ${DATA_PATH}

echo "Creating symbolic links..."
[ -f "${DB_PATH}/data.mdb" ] && ln -s ${DB_PATH} "$DATA_PATH/database"
[ -d "${GCODE_PATH}" ] && ln -s ${GCODE_PATH} "$DATA_PATH/gcodes"
ln -s ${LOG_PATH} "$DATA_PATH/logs"
ln -s ${CONFIG_PATH} "$DATA_PATH/config"

[ -f "${DB_PATH}/data.mdb" ] && ~/moonraker-env/bin/python -mlmdb -e ${DB_PATH} -d moonraker edit --delete=validate_install

echo "Running Moonraker install script..."

~/moonraker/scripts/install-moonraker.sh -f -a ${ALIAS} -d ${DATA_PATH} -c ${MOONRAKER_CONF} -l ${MOONRAKER_LOG}

En el caso de que uses RatOS y gracias a los compañeros de RatOS podremos usar un script para poder realizar estos ajustes:

#!/bin/bash
if [ -d "/home/pi/printer_data" ]; then
  echo "Deleting printer data config, database, gcodes and logs directories.."
  rm -rf /home/pi/printer_data/config
  rm -rf /home/pi/printer_data/database
  rm -rf /home/pi/printer_data/gcodes
  rm -rf /home/pi/printer_data/logs
else
  mkdir /home/pi/printer_data
fi

echo "Restoring printer data config, database, gcodes and logs directories.."
ln -s /home/pi/klipper_config /home/pi/printer_data/config
ln -s /home/pi/.moonraker_database /home/pi/printer_data/database
ln -s /home/pi/gcode_files /home/pi/printer_data/gcodes
ln -s /home/pi/klipper_logs /home/pi/printer_data/logs

Enero 2022 - Moonraker... problema permisos PolicyKit

Desde enero 2022, Moonraker ha cambiado su forma de comunicarse con el sistema, pasando de usar comandos sudo a D-Bus.

Normalmente si tenemos un problema de este tipo veremos que nos aparece un aviso de este tipo:

Para resolver este problema deberemos de lanzar un script ya preparado y disponible en nuestro host de Klipper mediante el terminal SSH:

cd ~/moonraker/scripts  
./set-policykit-rules.sh  
sudo service moonraker restart

En ocasiones si vemos errores en la ejecución del script es aconsejable actualizar el componente packagekit:

sudo apt update
sudo apt install packagekit

Podemos encontrar más información en la documentación de Moonraker.

Acceder al log de Moonraker

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:

Reinicio del servicio Moonraker

Para reiniciar el servicio Moonraker podemos hacerlo de diferentes formas:

KlipperScreen

Disponeis de una completa guía de troubleshooting aquí.

Creality Sonic Pad

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.

AnteriorVPN con ZeroTierSiguienteEnraged Rabbit Carrot Feeder (ERCF)

Última actualización