Conseguir impresiones reproducibles en la flota

Dos problemas distintos comparten la palabra reproducible, y una flota te obliga a resolver los dos.

El primero es el laminado determinista: el mismo modelo con los mismos ajustes debería producir el mismo G-code hoy, el año que viene y en el portátil de un compañero. Ese tiene respuesta. Ancla el slicer dentro de una imagen de contenedor, mantén los perfiles y la lista de piezas en el repositorio, y el archivo deja de moverse por su cuenta.

El segundo es una impresión reproducible: el archivo que salió limpio de la máquina uno debería salir limpio de la máquina cuatro. Ningún sistema de compilación puede prometerlo, porque la variabilidad que arruina la pieza vive en las boquillas, la calibración de caudal y el filamento, no en el software. Lo que el determinismo te da en una flota es más estrecho y aun así merece la pena: cuando el mismo archivo falla en una máquina, sabes que el archivo no es el motivo.

La mitad que se ancla sin problemas

estampo es la herramienta pensada para la primera mitad. Las piezas, los ajustes del slicer y las impresoras de destino van en un estampo.toml, el laminado se ejecuta sin interfaz a través de una imagen de slicer anclada (OrcaSlicer para destinos Bambu Lab, CuraEngine en el resto de casos), y la versión anclada es justo el punto: la configuración nombra 2.3.1 en lugar de lo que tu portátil actualizara la semana pasada. Estaba en la 0.4.4 bajo Apache 2.0 cuando lo comprobé el 17 de agosto de 2026, y su documentación es directa sobre dónde se detiene. Es agnóstica de la impresora y produce archivos, sin impresión con un clic y sin nada que hable con una máquina.

Si prefieres seguir laminando a mano, la deriva que te importa está en los presets, y Git sobre la carpeta de configuración user del slicer lo cubre. Versionar los perfiles de laminado tiene esa configuración, y versionar G-code como si fuera software cubre la vía del sistema de compilación con más detalle del que necesita este artículo.

En cualquiera de los dos casos acabas en la misma posición: la entrada está bajo control, y toda diferencia que quede ocurre después del archivo.

Donde una flota se desvía de todos modos

La suposición que se rompe antes es que un laminado es neutral respecto a la máquina. Nunca lo fue. Cada archivo lleva el G-code de inicio y de fin del preset de la máquina, el tamaño de cama para el que se colocaron las piezas y los nombres de macro que ese preset espera. Envía un archivo laminado para una impresora Klipper cuyo START_PRINT recibe un parámetro de temperatura de cama a una máquina que define la macro sin él, y el trabajo o aborta en la primera línea con sentido o se salta un paso en silencio, que es peor.

Supón que has arreglado eso y que la flota comparte de verdad un único preset de máquina. Todavía se mueve mucho. Una boquilla de 0.4 mm con cuatrocientas horas encima no es la boquilla de 0.4 mm contra la que se ajustó el perfil, y tampoco lo es una de 0.4 mm de otra marca. La distancia de rotación, el multiplicador de caudal y el pressure advance viven en la configuración de cada impresora, no en el G-code, así que dos máquinas ejecutando tu archivo idéntico están extruyendo cantidades de plástico ligeramente distintas. La malla de cama, el offset en Z y la superficie de la bandeja también son de cada máquina, y entre los tres deciden la adherencia antes de que el archivo haya hecho nada interesante. Luego está el filamento: una bobina que ha pasado un mes abierta no se comporta como una recién estrenada, y una máquina cerrada y un chasis abierto en un garaje frío no están imprimiendo el mismo PETG.

Eso es un argumento a favor de anclar la compilación, no en contra. El determinismo te da una entrada idéntica para un proceso que no lo es, y el beneficio es de diagnóstico. Un fallo en una máquina se convierte en una pregunta sobre esa máquina, porque el archivo ya está descartado.

Un laminado por clase de máquina, no un archivo para la flota

La forma práctica que se deriva de esto es laminar por clase de máquina y mantener las clases explícitas. Las máquinas que comparten diámetro de boquilla, volumen de impresión y conjunto de macros pueden compartir archivo. Todo lo demás recibe su propio laminado.

PrintStash lee los ajustes de cada subida y los guarda junto a la revisión, incluidos el nombre y la versión del slicer, el preset de impresora, el diámetro de boquilla, la altura de capa, el número de perímetros, el relleno, los soportes, las temperaturas y el tiempo y el filamento estimados. La primera vez que un archivo nombra un preset de impresora, además crea a partir de él un perfil local de impresora, con el modelo, el slicer y el diámetro de boquilla. Eso te da algo por lo que filtrar más adelante: todas las revisiones laminadas para las máquinas de 0.6 mm, o todas las revisiones que salieron de una versión de slicer que ya has sustituido.

La versión del slicer es el campo que merece vigilancia en una flota. Si la mitad de tus revisiones se laminaron con OrcaSlicer 2.2 y la otra mitad con 2.3, el registro lo dice, y un veredicto de verificado anterior a la actualización es una afirmación más débil que uno posterior.

Qué guarda el registro y qué no te va a decir

Cada trabajo de impresión registra qué impresora lo ejecutó, qué revisión, en qué estado terminó y cualquier error. Un trabajo también puede nombrar una impresora que PrintStash no gestiona, lo que cubre la máquina que todavía no está conectada. En Moonraker, el filamento y la duración medidos vuelven con él, y el coste se congela al completarse. Los demás proveedores están en beta y reportan menos; la matriz de compatibilidad es el desglose por proveedor.

El resultado, sin embargo, es un campo en la revisión, no un campo por impresora. Una revisión es needs_test, known_good, failed o archived, y known_good significa que el laminado se imprimió bien en algún sitio. No significa que se imprimiera bien en la máquina a la que estás a punto de enviarlo. El marcador de recomendada tiene el mismo límite en una forma más estricta: un modelo tiene exactamente una revisión de G-code recomendada, con la restricción aplicada en la base de datos, así que no hay una recomendación por impresora que puedas fijar.

Para una flota de máquinas iguales eso casi no importa. Para una mixta decide cómo etiquetas las cosas. Pon la clase de máquina en la etiqueta de la revisión, mantén una revisión por clase y deja que el historial de trabajos lleve el detalle por máquina, ya que es el único registro que sabe qué impresora ejecutó qué.

Hay un ajuste por defecto que conviene mirar antes de fiarte de los veredictos. Marcar automáticamente como verificado tras una impresión correcta viene activado de fábrica, y promueve una revisión sin probar o sin estado en cuanto cualquier impresora conectada termina un trabajo con ella. Nunca sobrescribe un veredicto failed o archived que hayas puesto a mano, y no comprueba qué máquina ejecutó el trabajo. En una flota de máquinas idénticas eso está bien. En una mixta, o lo desactivas en los ajustes o lees known_good como la afirmación más débil que está haciendo.

El reparto tampoco comprueba la compatibilidad

La asignación al menos ocupado puntúa según cuánto trabajo tiene delante cada máquina y nada más, así que el enrutado no va a apartar un laminado de 0.4 mm de la máquina que lleva una boquilla de 0.6 mm. Desde la v0.12.0 una comprobación previa sí compara los metadatos de material y boquilla del archivo con el destino antes de un envío directo y señala una discrepancia, lo que atrapa la peor versión de esto en el último momento; la anulación queda auditada en lugar de pasar en silencio. Emparejar el trabajo con la máquina de antemano sigue siendo decisión del operador, que es otro argumento a favor de un laminado por clase y etiquetas que puedas leer de un vistazo. Enviar G-code a varias impresoras cubre lo que la cola sí hace, incluidas las ventanas de mantenimiento y el acceso por impresora.

Si un trabajo de CI está produciendo los laminados, súbelos con source_hash fijado al sha256 de la malla de origen. La deduplicación resuelve entonces el artefacto sobre el modelo que creó esa malla en lugar de archivarlo como una entrada nueva de la biblioteca, y la revisión llega como needs_test, que es el estado correcto para un archivo que ninguna máquina ha ejecutado todavía.

Cómo se ve esto cuando algo sale mal

Una flota con una compilación anclada y un historial de trabajos por máquina seguirá sin imprimir piezas idénticas. Lo que hace es acortar la discusión. La máquina cuatro empieza a sacar esquinas levantadas, y puedes ver que el archivo no ha cambiado desde la última tirada buena, que las máquinas uno y dos imprimieron la misma revisión la semana pasada sin problemas, y que el único evento reciente en la cuatro fue un cambio de boquilla. Compara eso con reconstruir la misma foto a partir de los archivos exportados de cuatro personas y una carpeta de nombres que acaban en _FINAL.

Preguntas que surgen

¿Es seguro ejecutar el mismo archivo de G-code en dos impresoras del mismo modelo?

Normalmente sí, y es el único caso en el que compartir un archivo resulta cómodo. Dos máquinas del mismo modelo comparten tamaño de cama, cinemática y, si las montaste desde la misma imagen, los mismos nombres de macro, así que el G-code de inicio del laminado significa lo mismo en las dos. Lo que no comparten es la calibración. La distancia de rotación, el pressure advance, el offset en Z y la malla de cama viven en la configuración de cada impresora, y el desgaste de la boquilla toma caminos distintos desde el día en que las instalas. Espera que el mismo archivo funcione en las dos, y espera que la primera capa sea lo que cambie. Las impresoras de modelos distintos deberían recibir su propio laminado, ya que el preset de máquina incrustado en el archivo es específico del modelo.

¿PrintStash registra el estado de verificado por impresora?

No. El resultado es un único campo en la revisión de G-code, así que known_good registra que el laminado se imprimió bien, sin decir qué máquina lo demostró. El detalle por máquina está en el historial de trabajos de impresión, ya que cada trabajo guarda su impresora, su revisión y el estado en el que terminó. En una flota mixta el patrón que funciona es una revisión por clase de máquina con la clase en la etiqueta, por ejemplo 0.6 nozzle, farm rack junto a 0.4 nozzle, enclosed. Las dos pueden estar verificadas a la vez. Solo una revisión por modelo puede llevar el marcador de recomendada, así que dásela al laminado que reimprimirías hoy y apóyate en las etiquetas para el resto.

¿Debería dejar activado el marcado automático de verificado en una flota?

Desactívalo si tus máquinas no son intercambiables. El ajuste promueve una revisión a known_good después de una impresión correcta desde una impresora conectada, y no registra ni comprueba qué impresora era, así que en una flota mixta produce veredictos que se leen más fuertes que las pruebas que hay detrás. No sobrescribirá un estado failed o archived que hayas puesto tú, así que los veredictos manuales sobreviven en cualquier caso. Con máquinas idénticas la automatización merece la pena, porque la alternativa es acordarte de fijar un estado mientras tienes la pieza en la mano.

¿Cómo sé qué versión de slicer produjo una revisión?

Se extrae de la cabecera del archivo al subirlo y se guarda con la revisión, junto con el preset de impresora y el diámetro de boquilla, así que puedes leerla en la revisión meses después. Esto importa más en una flota que con una sola impresora, porque las actualizaciones de slicer suelen ocurrir en la estación de trabajo que alguien estuviera usando, y el ajuste de arcos, la colocación de la costura y la generación de soportes cambian entre versiones. Una imagen de slicer anclada en la compilación elimina el problema en el origen. El campo extraído es como auditas los laminados que hiciste antes de anclar nada.

¿Puede la cola enrutar un trabajo a una impresora que de verdad pueda ejecutarlo?

No por capacidad. El enrutado ofrece selección manual, una impresora por defecto o asignación al menos ocupado, y el menos ocupado cuenta el trabajo en cola en lugar de comprobar el diámetro de boquilla, el material cargado o el tipo de bandeja. Así que la cola de flota reparte carga, y tú decides qué es seguro repartir. En la práctica eso significa mantener la clase de máquina visible en la etiqueta de la revisión y elegir el destino a mano cuando la flota es heterogénea, o reservar el enrutado al menos ocupado para un grupo de máquinas que de verdad sean intercambiables.

Fuentes

• estampo y su ficha en PyPI para las imágenes ancladas de OrcaSlicer y CuraEngine, la tubería en TOML, la versión 0.4.4 bajo Apache 2.0 y la declaración del propio proyecto de que es agnóstico de la impresora y se detiene en el archivo laminado. Consultado el 17 de agosto de 2026.
• Los conceptos básicos de PrintStash y la guía de impresoras para las revisiones, los resultados y el historial de trabajos. Los cuatro resultados de revisión, la restricción de una sola recomendación en la base de datos, el nombre y la versión del slicer extraídos, los perfiles locales de impresora creados a partir de los presets extraídos y el comportamiento agnóstico de la impresora del marcado automático de verificado se leyeron en backend/app/db/models.py, backend/app/services/print_results.py, backend/app/services/profile_detection.py y backend/app/services/runtime_config.py del repositorio.

Para la versión del mismo flujo de trabajo con una sola impresora, seguir las revisiones de G-code es el recorrido completo, y un modelo, muchos G-code cubre los estados de resultado por su cuenta.