Interrogar la impresora con Moonraker

La K2 Pro corre Klipper por dentro, y expone Moonraker, su API HTTP, en el puerto 7125. Eso significa que se le puede preguntar a la máquina qué ha pasado, en vez de deducirlo de una foto de espaguetis.

Es la herramienta que más tiempo me ha ahorrado diagnosticando fallos.

Antes de nada: seguridad

Moonraker responde sin autenticación en la red local. Eso es cómodo dentro de casa y es un problema serio si la impresora queda expuesta a internet: cualquiera podría lanzar trabajos o mover ejes.

• No abras el puerto 7125 en el router. Nunca.
• Si necesitas acceso remoto, hazlo por VPN.

Localizar la impresora

ping K2Pro-XXXX.local

El sufijo son los últimos caracteres del identificador que muestra la propia impresora en su pantalla de red. Si mDNS no resuelve, barre el puerto 7125 en tu rango local.

Comprobación de que responde:

curl -s "http://<IP>:7125/printer/info"

Devuelve el estado (ready, startup, error), el hostname y las rutas de configuración.

Historial de trabajos

El primer sitio donde mirar tras un fallo:

curl -s "http://<IP>:7125/server/history/list?limit=10"

De cada trabajo interesan tres campos:

• status — completed, cancelled, error, in_progress.
• print_duration — tiempo imprimiendo.
• end_time − start_time — tiempo de reloj.

Que esos dos últimos difieran delata una pausa. En un fallo que investigué, 43 minutos impresos dentro de 5 h 34 min de reloj: la máquina había estado pausada casi cinco horas sin que nadie lo supiera.

Este endpoint también sirve para medir el sesgo del estimador de tiempo. En mi máquina, comparando estimado contra real en decenas de trabajos, sale un factor consistente de ×1,06: Creality Print siempre se queda corto.

Los ficheros: gcode, logs y configuración

curl -s "http://<IP>:7125/server/files/list?root=gcodes"
curl -s "http://<IP>:7125/server/files/list?root=logs"
curl -s "http://<IP>:7125/server/files/roots"

Descargar el gcode que la máquina ejecutó es la única forma fiable de saber con qué ajustes se laminó de verdad:

curl -s "http://<IP>:7125/server/files/gcodes/<fichero>.gcode" \
  | grep -aE "^; (print|filament)_settings_id|^; (hot_plate_temp|slow_down_layer_time)"

Los klippy.log diarios pueden pasar de 100 MB. Descarga solo el tramo final con HTTP Range:

curl -s -r "-900000" -o cola.log "http://<IP>:7125/server/files/logs/klippy.log"

La línea que da la capa exacta del fallo

Klipper escribe esto en cada capa, para poder recuperar tras un corte de luz:

record_power_loss_info to eeprom layer:33 last_position[2]:6.4

Da número de capa y altura Z exactos. Es el dato de oro de cualquier diagnóstico, por dos motivos:

• Cruzando esa Z con la altura de cada pieza de la placa sabes qué estaba imprimiéndose y qué había terminado. En un fallo mío, la impresión murió justo en la capa donde acababan los tapones más bajos, con las bases al 48 % — eso señalaba directamente al problema de mezclar alturas dispares en una misma cama.
• La cadencia entre esas líneas es la señal de salud. Si el intervalo se mantiene constante hasta el último segundo, se descarta una degradación progresiva; si se va alargando, hay algo que se está atascando.

La rueda de medición: extrusión real

Si tienes CFS, registra el avance real del filamento:

[get_measuring_wheel] data_hex: 0xc5bf2700, data:-6116.875

Su derivada delata un atasco antes de que salte ningún error. En un heat creep que sufrí, la rueda se paró en seco y la máquina no reportó nada hasta cuatro minutos después. Quien mira solo los códigos de error diagnostica el síntoma; la rueda da la causa y el minuto exacto.

Distingue además dos fallos que se confunden:

• Rueda parada con el estado en printing → atasco o falta de material.
• Rueda avanzando con normalidad y aun así espaguetis → es adherencia, la pieza se ha soltado. El filamento salía bien.

Estado del CFS y del material

curl -s "http://<IP>:7125/printer/objects/query?box"

Da por hueco: material declarado, color, longitud restante, temperatura y humedad. Útil para no secar una bobina que no lo necesita — en un caso marcaba 18 % de humedad relativa y me ahorró ocho horas de secado inútil.

Aviso: el nombre del fichero .gcode puede mentir sobre el material. He visto un _PLA_ en el nombre de un trabajo hecho en PETG. Este endpoint dice lo que hay realmente cargado.

Otros objetos útiles

curl -s "http://<IP>:7125/printer/objects/query?print_stats&virtual_sdcard&extruder&heater_bed&bed_mesh"

• print_stats — estado, fichero, duración, mensaje de error.
• virtual_sdcard — progreso real (0 a 1).
• extruder / heater_bed — temperatura actual y objetivo. Sirve para verificar que tu perfil se aplicó: si pediste cama a 60 y aquí ves objetivo 50, no se aplicó.
• bed_mesh — malla activa, perfiles guardados y matriz de puntos palpados.

Filtrar el ruido

El klippy.log está inundado de líneas que no aportan nada al diagnóstico. Filtra siempre:

• buf_len, buf[0] = 0x... — volcados del bus RS-485. Aparecen marcados como ERROR] y no son errores de impresión. Me costó un rato entenderlo la primera vez.
• Serial_485 — tráfico del mismo bus.
• GET_BOX_STATE, cur_temp — sondeos periódicos.

grep -a "ERROR" cola.log | grep -avE "buf\[|buf_len|Serial_485"

Una advertencia sobre la detección por IA

En mi máquina, la detección por IA del cabezal solo corre seis segundos al arrancar (execute_toolhead_ai_waste_management: enciende la cámara, analiza, la apaga). La detección continua durante la impresión la hace un subsistema propietario que no deja una sola línea en el log.

No la busques ahí. Si esperas encontrar por qué la máquina paró (o por qué no paró), ese registro no existe.

Resumen: la secuencia de diagnóstico

1. /server/history/list — estado, duración impresa vs reloj.
2. Descargar el gcode — con qué ajustes se laminó realmente.
3. Cola del klippy.log con Range — buscar record_power_loss_info para la capa exacta.
4. Cruzar esa Z con las alturas de las piezas de la placa.
5. Cadencia entre capas — ¿degradación progresiva o corte abrupto?
6. Rueda de medición — ¿extrusión o adherencia?
7. Solo entonces, opinar sobre la causa.