¿Puedes versionar el G-code como el software?

Sí, con una sustitución: versiona la compilación, no el artefacto. Guarda el modelo de origen y los ajustes del slicer en el repositorio, fija el slicer para que el mismo commit produzca el mismo G-code, y pon el registro de qué laminado salió bien en algún sitio que entienda de impresiones. Git maneja bien la primera mitad y la última parte no la maneja en absoluto, que es donde suele encallar la idea.

Commitear los laminados directamente falla de formas que cualquiera que lo haya intentado puede recitar. Un archivo de 20 MB por exportación, un diff de miles de líneas de coordenadas alrededor del puñado de comentarios de cabecera que querías comparar, y .bgcode binario que Git no puede leer en absoluto. Seguir las revisiones de G-code trabaja esa comparación al completo, así que este artículo la da por zanjada y mira lo que ha cambiado hace poco: laminar se ha convertido en algo que puedes ejecutar como un paso de compilación reproducible.

Laminar como paso de compilación

El G-code pareció inversionable durante mucho tiempo porque producirlo significaba que una persona hiciera clic por una interfaz gráfica, contra un perfil que vivía en el directorio de configuración del slicer, donde nada más podía verlo. Una compilación hecha a mano no es reproducible, así que el archivo de salida se convierte en la única evidencia de lo que pasó, y esa es exactamente la presión que empuja a la gente a commitear la salida.

estampo le da la vuelta. Piezas, ajustes del slicer y máquinas de destino van en un único estampo.toml, y el laminado se ejecuta sin interfaz a través de una imagen de slicer fijada en Docker: OrcaSlicer para máquinas de Bambu Lab, CuraEngine para todo lo demás. Como la versión del slicer está fijada en lugar de ser la que tu portátil actualizó la semana pasada, se espera que la misma configuración produzca el mismo G-code en otra máquina o dentro de un año. Lee STL, STEP y 3MF, empaqueta las piezas en la cama y trae una GitHub Action que lamina en cada push y sube el resultado como artefacto de compilación. La instalación es pip install estampo. Estaba en la 0.4.4 bajo Apache 2.0 cuando lo comprobé, el 15 de agosto de 2026.

Eso cambia qué pertenece al repositorio. El G-code deja de ser algo que conservar y pasa a ser algo que regeneras, igual que no commitearías un binario compilado cuando la compilación es determinista. Lo que guarda el commit es el modelo y el TOML.

Lo que una compilación reproducible sigue sin poder decirte

Un sistema de compilación puede demostrar que un commit produce un archivo concreto. No puede decirte que la pieza se combó con la boquilla de 0,4 mm y salió recta de la máquina de 0,6 mm, porque esa información no existe hasta que alguien lanza la impresión y mira la pieza. estampo no lo registra y no pretende hacerlo: no hay resultados, ni registro de impresiones, ni biblioteca en ninguna parte.

Así que el resultado necesita un hogar que no sea un nombre de archivo ni un mensaje de commit. PrintStash asocia cada laminado a su modelo de origen como una revisión y parsea los ajustes que el slicer escribió en el archivo, incluidos el perfil de impresora y boquilla, la altura de capa, el número de perímetros, el relleno, los soportes, el material, las temperaturas y la duración y el consumo de filamento estimados. Cada revisión lleva un resultado: needs_test, known_good, failed o archived. Exactamente una revisión por modelo lleva la marca de recomendada, así que la página del modelo responde a la pregunta de qué reimprimir una vez, en lugar de ofrecerte cuatro candidatas. Seleccionar dos revisiones pone sus ajustes parseados uno al lado del otro, lo que encuentra el cambio que importaba más rápido que leer coordenadas.

Entregar el artefacto desde CI

El endpoint de ingesta, POST /api/v1/ingest/orca, acepta un source_hash opcional, el sha256 de la malla de origen. Cuando está presente, PrintStash lo usa como clave de deduplicación en lugar del hash del propio G-code, así que el laminado se resuelve sobre el modelo que creó esa malla en lugar de llegar como su propia entrada de biblioteca. El hook de posprocesado de OrcaSlicer no puede usarlo, porque el slicer nunca le dice al script qué malla produjo la exportación. Un trabajo de CI gobernado por un archivo de configuración que nombra la pieza ya lo sabe.

Lo que eso te compra es más estrecho de lo que parece al principio. source_hash archiva el artefacto contra el modelo correcto, y nada más. La etiqueta, el resultado y la marca de recomendada vienen de otra llamada, POST /api/v1/models/{model_id}/gcode-revisions, que acepta revision_label, revision_status (con needs_test por defecto) e is_recommended. Así que una subida desde CI deja el laminado en el sitio correcto con sus metadatos parseados y nada marcado como probado, que es el valor por defecto correcto para un archivo que nadie ha impreso todavía.

El veredicto sigue viniendo de una persona con la pieza terminada en la mano. El marcado automático puede cubrir parte de ello, pero solo para trabajos lanzados desde la propia biblioteca: una impresión que arrancaste en Mainsail, o el historial importado después desde la impresora, no promociona nada. La duración y el filamento medidos vuelven solo de Moonraker, y los demás proveedores están en beta y recurren a las estimaciones del slicer, algo que la matriz de compatibilidad desglosa por proveedor. La guía de automatización con la API cubre el flujo de inicio de sesión, ya que una clave de API es una credencial de acceso y no un token de portador.

Cuando esto es más maquinaria que problema

estampo quiere Docker, una imagen fijada y un archivo de configuración para piezas que quizá laminarías a mano en menos de un minuto. Si modelas en una herramienta CAD gráfica y rara vez vuelves a laminar, el TOML es sobrecoste sin beneficio a cambio. PrintStash es un servicio que hay que mantener y respaldar, y para una impresora y veinte modelos una convención de nombres cuidadosa de verdad basta; la tabla comparativa de seguir las revisiones de G-code trata sobre todo de dónde deja de escalar cada enfoque.

La combinación se gana su sitio bajo condiciones bastante concretas: piezas que se vuelven a laminar muchas veces, más de una máquina en juego, o trabajo de CAD programático donde el modelo ya es un archivo de texto en el repositorio. Ese es también el caso en el que commitear G-code duele más, ya que los relaminados son frecuentes y cada uno son otros 20 MB.

Ninguno de los dos proyectos cubre la mitad del otro, y no se han integrado entre sí. estampo no menciona PrintStash en ninguna parte de su documentación, así que encadenarlos es pegamento que escribes tú: un trabajo de CI que sube su propio artefacto.

Preguntas que surgen

¿Puedo regenerar un archivo de G-code antiguo desde un commit antiguo?

De eso va fijar el slicer dentro de una imagen de contenedor. Si el commit guarda el modelo y la configuración, y la configuración nombra una imagen de slicer exacta en lugar de “lo que esté instalado”, entonces hacer checkout de ese commit y volver a lanzar la compilación debería devolverte el mismo archivo. Sin fijarlo no lo hará, porque las versiones del slicer cambian valores por defecto, ajuste de arcos, colocación de la costura y generación de soportes entre versiones, y tu instalación local se actualiza a su propio ritmo. Esta es la pieza que un repositorio de STL sueltos y G-code exportado no puede darte con ningún nivel de disciplina.

¿Fijar el slicer produce de verdad una salida idéntica byte a byte?

La afirmación de estampo es G-code idéntico entre máquinas a partir de una imagen fijada y perfiles bloqueados, y el mecanismo tiene sentido: la misma versión del motor y los mismos ajustes aplicados a la misma malla. Yo no he medido la igualdad byte a byte entre plataformas, así que trátalo como una afirmación del proyecto y no como algo verificado aquí. En cualquier caso, el beneficio práctico no depende de que coincida el último byte. Quitar la deriva de versión del slicer y la deriva de perfiles elimina las dos cosas que de verdad cambian una impresión de un mes al siguiente.

¿Cómo asocia un trabajo de CI un laminado al modelo correcto en lugar de crear una entrada nueva?

Envía source_hash con la subida, con el sha256 de la malla que laminaste. Sin él, la deduplicación recurre al hash del propio G-code, con el que no coincide ningún modelo existente, así que obtienes una entrada nueva cada vez. Un sistema de compilación puede aportarlo porque la configuración ya nombra el archivo de la pieza, lo que hace del hash una línea de script. El hook de OrcaSlicer que viene incluido no puede, ya que solo recibe la ruta del G-code exportado y no tiene forma de saber qué malla lo produjo.

¿Es estampo un sustituto de una biblioteca de archivos?

No, y las dos cosas no se solapan mucho. estampo es un sistema de compilación: define piezas y ajustes de laminado en TOML, fija la versión del slicer en Docker y genera G-code en local o en CI. No tiene concepto de resultados de impresión, ni historial de qué archivo imprimió bien, ni vista compartida de una flota, ni navegador de archivos. Eso son asuntos de biblioteca. Tener un sistema de compilación no quita la necesidad de registrar resultados, y tener una biblioteca no hace reproducible tu laminado.

¿Necesito hardware de Bambu para usar una compilación con slicer fijado?

No. estampo elige el motor según el destino: OrcaSlicer cubre las máquinas de Bambu Lab y CuraEngine cubre todo lo demás, con 643 perfiles de máquina de Cura frente a 35 de Orca. Una Voron, una Prusa o una Creality con Klipper van por la vía de CuraEngine. La elección del motor sí cambia qué nombres de perfil y qué sobrescrituras escribes en el TOML, así que una configuración no es portable entre las dos vías sin editarla.

Fuentes

• estampo y su ficha en PyPI para el pipeline en TOML, las imágenes fijadas de OrcaSlicer y CuraEngine en Docker, la GitHub Action, los recuentos de perfiles de máquina incluidos y la versión 0.4.4 bajo Apache 2.0. Comprobado el 15 de agosto de 2026.
• Conceptos básicos y referencia de la API de PrintStash para el modelo de la bóveda y el flujo de autenticación. El parámetro source_hash, los cuatro resultados de revisión y la regla de una sola recomendación se leyeron en backend/app/api/v1/ingest.py, backend/app/db/models.py y backend/app/api/v1/models.py en el repositorio, que los documenta con más detalle que la página de referencia.

Para el lado de los resultados por su cuenta, un modelo, muchos G-code cubre las reglas de estado con más profundidad, y llevar los perfiles de laminado bajo control de versiones atiende el caso en el que quieres los propios preajustes en Git y no un sistema de compilación gobernándolos.