Links
‼️

Klipper Troubleshooting

Guía de resolución de problemas más comunes con Klipper y algunos de sus componentes
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

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 dmesh > dmesg.txt
    • 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

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:
UI (Mainsail)
SSH CLI
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:
Si no disponemos de UI o esta no es accesible podremos encontrar el log de Klipper en el siguiente path:
$HOME/printer_data/logs/klippy.log
Podremos descargarlo a nuestro ordenador usando la herramienta scp o WinSCP.
También contacmos con un script, logextract.py que es muy útil para extraer información del log ante problemas de apagado inesperado de Klipper, podemos seguir el siguiente proceso:
mkdir work_directory
cd work_directory
cp /tmp/klippy.log .
~/klipper/scripts/logextract.py ./klippy.log
El script va a extraer la configuracion de Klipper y la información de error al directorio work_directory creado.

Reinicio del servicio Klipper

Para reiniciar el servicio Klipper podemos hacerlo de diferentes formas:
UI (Mainsail)
SSH CLI
sudo service klipper stop // para pararlo
sudo service klipper start // para iniciarlo
sudo service klipper restart // para parar e iniciarlo

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:
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}
#!/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

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:
UI (Mainsail)
SSH CLI
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:
Si no disponemos de UI o esta no es accesible podremos encontrar el log de Klipper en el siguiente path:
$HOME/printer_data/logs/moonraker.log
Podremos descargarlo a nuestro ordenador usando la herramienta scp o WinSCP

Reinicio del servicio Moonraker

Para reiniciar el servicio Moonraker podemos hacerlo de diferentes formas:
UI (Mainsail)
SSH CLI
sudo systemctl restart moonraker

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.