Revisiones de G-code en tu flujo de impresión

Sigue las revisiones de G-code adjuntando cada laminado a su modelo de origen como una revisión, en lugar de poniendo nombres cuidadosos a los archivos. Una biblioteca que entiende de revisiones extrae los ajustes del slicer de cada archivo, registra qué laminado imprimió limpio y pone dos revisiones una al lado de la otra cuando necesitas saber qué cambió. Pasadas unas pocas piezas, eso funciona mejor que los nombres de archivo, Git y las estadísticas de impresión del controlador.

Un STL se convierte en varios archivos de G-code más rápido de lo que casi nadie espera. Una escuadra se lamina a 0,2 mm para una prueba rápida y luego a 0,16 mm porque la superficie superior salió rugosa. Se rompe con carga, así que el relleno pasa del 15 al 25 por ciento en OrcaSlicer. Alguien cambia PLA por PETG y con ello cambian las temperaturas. Dos de esos laminados eran para la boquilla de 0,4 mm y uno para la máquina de 0,6 mm que está en la esquina.

Tres meses después la carpeta contiene bracket-final.gcode, bracket-final-v2.gcode y bracket_FINAL_good.gcode, y ninguno de los nombres dice qué boquilla, qué material ni cuál salió recto de la cama. Equivocarse cuesta una impresión de 6 horas y 80 gramos de PETG, y normalmente te enteras cuatro capas antes del final.

El problema no es que la gente sea descuidada con los nombres de archivo. Es que un nombre de archivo tiene sitio para una cadena corta, mientras que el registro útil es un conjunto de ajustes más un resultado más un motivo. Esta guía cubre cuatro formas de mantener ese registro, cuándo basta con cada una y una configuración real para el enfoque que automatiza la mayor parte.

Cuatro enfoques que se usan de verdad

Convenciones de nombres

Codifica lo que importa en el nombre del archivo y sé consistente: bracket_016_25pct_petg_0.4_v3_GOOD.gcode. Cero configuración, funciona con cualquier slicer, sobrevive a una copia en un USB.

Se degrada de dos formas previsibles. La cadena se queda sin sitio mucho antes que los ajustes, así que algo se cae, normalmente el motivo del cambio. Y meter el estado dentro del nombre implica renombrar archivos, lo que rompe cualquier cosa que apuntara al nombre antiguo. Suficiente para unas pocas piezas que imprimes una vez al mes. Doloroso pasadas unas decenas.

Control de versiones

Git es el recurso obvio para cualquiera que escriba software. El G-code en texto plano es texto, así que técnicamente un diff funciona, y los mensajes de commit son el único sitio para el que una convención de nombres no tiene espacio.

En la práctica encaja mal. Un archivo de G-code de 20 MB por laminado hace crecer el repositorio rápido, y git-lfs arregla el tamaño pero se lleva por delante el diff. El propio diff son miles de líneas de coordenadas donde lo que de verdad querías comparar son dos o tres comentarios de cabecera. El .bgcode binario de PrusaSlicer es completamente opaco para Git. El control de versiones es una opción razonable para los perfiles del slicer y las configuraciones de Klipper que producen el G-code, y mala para la salida. La mejor versión de la idea es hacer el laminado reproducible en lugar de archivarlo, que es lo que cubre versionar G-code como si fuera software con un slicer fijado ejecutándose en CI.

Estadísticas de impresión del controlador

Los dos stacks de controlador principales ya registran algo, y la gente olvida que lo tiene.

OctoPrint guarda el historial por archivo en su lista de archivos: su modelo de datos documenta prints.success, prints.failure, last.date, last.printTime y last.success. Así que el archivo que subiste dos veces, imprimiste una vez bien y otra mal, lo dice.

El componente de historial de Moonraker registra cada trabajo con filename, status, start_time, end_time, print_duration, total_duration y filament_used, además de los totales por trabajo, y Mainsail y Fluidd lo muestran. Son datos medidos de verdad, no estimaciones del slicer.

El límite es lo importante. Los dos siguen el historial contra un nombre de archivo en esa impresora, no contra el modelo del que salió el archivo. Borra el archivo, vuelve a subirlo con otro nombre o lamina una cuarta variante, y la conexión desaparece. Aquí nada compara dos laminados por ti, y el registro vive en una sola máquina.

Una biblioteca que modela revisiones

Las bibliotecas de modelos hechas para esto tratan un archivo laminado como una revisión de su modelo de origen, con los ajustes extraídos del archivo automáticamente y un estado por el que puedes filtrar. PrintStash es el ejemplo que esta guía recorre en detalle. GyroidVault tiene una forma parecida, con versionado de modelos, análisis de G-code y registros de impresión, y Manyfold indexa y previsualiza G-code hoy, con el control de versiones en su hoja de ruta para el cuarto trimestre de 2026.

El coste es mantener un servicio en marcha y con copias de seguridad. La ganancia es que el registro sobrevive a los renombrados, guarda el motivo junto a los ajustes y vive con el modelo en lugar de en una sola impresora.

Cómo elegir entre ellos

No hay respuesta equivocada para una sola impresora y veinte modelos. El motivo para subir en la tabla es la repetición: las mismas piezas, relaminados, más de una máquina o más de una persona.

Lo que asume el recorrido

El resto de esta guía implementa el cuarto enfoque con PrintStash. Necesitarás:

• Docker y Docker Compose en un host amd64 o arm64, con unos 2 GB de RAM libres si subes mallas grandes.
• Un slicer que escriba comentarios de metadatos, lo que cubre OrcaSlicer, PrusaSlicer, Bambu Studio y Cura.
• Opcionalmente, una impresora accesible en la LAN. Moonraker/Klipper es el proveedor estable; PrusaLink, OctoPrint, Bambu LAN y Elegoo Centauri están en beta, y la matriz de compatibilidad enumera las carencias de capacidades de cada uno.

Nada de esto necesita una impresora conectada. Los resultados se pueden marcar a mano, y ese es el punto de partida normal.

Montar el registro de revisiones

1. Poner el servicio en marcha

git clone https://github.com/xiao-villamor/PrintStash.git
cd PrintStash

cp .env.example .env
# Set VAULT_JWT_SECRET to a long random string before this is reachable
# from anything but localhost.

docker compose up -d

Eso descarga imágenes ya construidas en lugar de compilar nada. Abre http://localhost:3000 y el asistente de configuración pide la primera cuenta de administrador, un backend de almacenamiento y los directorios de datos. No hay ningún inicio de sesión por defecto. SQLite y el disco local son la opción por defecto y la más probada; Postgres y el almacenamiento compatible con S3 están ahí cuando una instalación se queda pequeña. La guía de instalación cubre el archivo Compose endurecido y las variables del proxy inverso.

Si tus modelos ya viven en un NAS, añade esa carpeta como volumen compartido en lugar de subir nada. Los archivos se quedan donde están, se hashean y se indexan en el sitio, y las subidas nuevas escriben en el mismo árbol sin sobrescribir rutas existentes. Tu slicer sigue abriendo las mismas rutas que siempre.

2. Añade primero el modelo de origen y luego los laminados

Sube el origen STL, 3MF, OBJ o STEP como modelo. Después añade cada archivo de G-code o BGCODE a ese modelo, en lugar de importarlo como una entrada propia. Este es el paso que decide si el resto funciona: un laminado importado como modelo aparte no es más que una carpeta con otra forma.

Al ingerir, se hashea el contenido del archivo, y unos bytes idénticos se resuelven al modelo que ya los contiene en lugar de empezar una segunda entrada. El archivo en sí se registra igualmente como otra versión, así que un hook que se dispara dos veces deja una revisión duplicada que limpiar, no un modelo duplicado.

3. Deja que el parser rellene los ajustes y escribe la parte que no puede saber

Los metadatos salen del propio archivo. Según el slicer y el perfil, eso incluye el perfil de impresora y boquilla, la altura de capa, las paredes, el relleno, los soportes, el material, las temperaturas, la duración estimada y el consumo de filamento. El .bgcode binario también se analiza. No todos los slicers emiten los mismos comentarios, así que es normal que falten campos y no vale la pena pelearse con eso.

Lo que el parser no puede recuperar es la intención. Añade una etiqueta corta para eso: 0.16 finish for visible face, brim after corner lift, 0.6 nozzle for the farm machine. Seis meses después, la etiqueta es lo que te dice por qué existen dos laminados casi idénticos.

4. Registra los resultados y mantenlos separados de tu recomendación

Cada revisión lleva un resultado:

• needs_test para un laminado que aún no se ha probado;
• known_good para uno que imprimió bien;
• failed para uno que no quieres repetir;
• archived para el historial que debe quedarse fuera del camino.

Por separado, exactamente una revisión de cada modelo lleva la marca de recomendada. El primer G-code que subes se la queda automáticamente, y marcar otra la quita del resto, así que la página del modelo siempre tiene exactamente una respuesta en lugar de ninguna o cuatro.

Mantener esos dos campos separados es lo importante. Un prototipo rápido puede estar en known good mientras una revisión más lenta y más limpia sigue siendo la recomendada para la pieza que realmente entregas. La guía de estados de revisión cubre las reglas de estado con más detalle.

Con Auto-mark known good on successful print activado, un trabajo completado en una impresora conectada promociona su propia revisión. Nunca sobrescribe un veredicto manual failed o archived, y no toca la marca de recomendada, que sigue siendo tu decisión.

5. Compara revisiones en lugar de leer G-code

Selecciona dos revisiones y sus ajustes de slicer, material e impresión ya extraídos aparecen uno al lado del otro. Este es el paso que responde a la pregunta que de verdad tienes: la segunda imprimió limpia, ¿fue por el brim, por los 5 grados más de temperatura o por la pared extra?

Compara ajustes extraídos, no líneas en bruto. Las macros específicas del firmware, el G-code de inicio y los retoques de aceleración siguen necesitando un editor de texto o el slicer cuando son los sospechosos.

6. Conecta una impresora, si tienes una que encaje

Añade la impresora en Printers → Add printer. Para Moonraker/Klipper, eso es un nombre y la URL de la LAN donde ya vive Mainsail o Fluidd; el indicador de estado debería ponerse en directo en unos segundos.

Pruébala en una máquina donde un error sea inocuo: confirma que el estado cambia cuando lo hace la impresora, sincroniza el inventario de archivos de la impresora y luego envía un archivo pequeño y conocido sin inicio automático antes de probar iniciar, pausar, reanudar y cancelar.

Después de eso, enviar una revisión registra el trabajo contra esa revisión. Moonraker devuelve la duración y el consumo de filamento medidos cuando la impresión termina, que es lo que alimenta las cifras de coste. Los proveedores en beta registran el trabajo igualmente, pero recurren a las estimaciones del slicer. La Elegoo Centauri acepta subidas por trozos, aunque la subida sigue en beta y el inventario de archivos está desactivado. Moonraker también puede importar el historial existente de una impresora sobre los modelos que coincidan, lo que rellena las impresiones que hiciste antes de montar todo esto.

Quitar el paso de la subida

El hook de posprocesado de OrcaSlicer puede empujar el G-code exportado directamente. Inicia sesión con un usuario y una clave de API con nombre, recibe un JWT y publica el archivo en el endpoint de ingesta, que es la misma ruta que usa la interfaz web. La clave de API se puede revocar desde Settings sin tocar tu contraseña.

Ahorra el paso de subir, pero no el de archivar. La ingesta empareja por hash de contenido, así que cada laminado llega como su propia entrada de la biblioteca en lugar de como revisión del modelo del que salió, y adjuntarlo con una etiqueta y un resultado sigue siendo una acción deliberada. Apunta el hook a una colección de entrada y archiva desde ahí. La guía de subida automática desde OrcaSlicer cubre la configuración y esa limitación, y la referencia de la API tiene el flujo de autenticación y la llamada de ingesta.

Errores que cuestan filamento

No marcar el resultado mientras lo recuerdas

Una revisión que se queda en needs_test después de una impresión perfecta es indistinguible de una que no se probó nunca. Dos semanas después reimprimes el archivo equivocado, o vuelves a laminar desde cero porque no te fías de ninguno. Activar el marcado automático en las impresiones correctas elimina casi todo esto en impresoras conectadas; para los trabajos manuales es un hábito, y el más barato de esta lista.

Reimprimir sin comparar ajustes

El modo de fallo es una deriva de ajustes que no notaste: una actualización de perfil movió la temperatura de la cama, un cambio de material cambió la retracción, los soportes volvieron a activarse. La pieza imprimió bien en marzo y se deforma en agosto, y nada cambió en el nombre del archivo. Compara la revisión que estás a punto de enviar con la que funcionó antes de comprometer seis horas.

Perder qué revisión produjo un trabajo

El historial del controlador va por nombre de archivo, así que subir bracket.gcode dos veces desde dos laminados distintos te deja estadísticas que no puedes atribuir. Con la herramienta que uses, haz que la identidad del archivo sobreviva: hashéalo, versiónalo o, como mínimo, no reutilices nunca un nombre para contenido distinto.

Tratar un relaminado como un modelo nuevo

Fragmenta todo. Dos entradas para una escuadra significan dos historiales, dos conjuntos de etiquetas y ninguna comparación. Añade los laminados al modelo existente, siempre.

Dar por hecho que todas las impresoras devuelven los mismos datos

El filamento y la duración medidos vienen de Moonraker. Bambu LAN no tiene inventario remoto, la subida de la Elegoo Centauri está en beta mientras su inventario sigue sin estar disponible, y los proveedores en beta varían en lo que confirman. Planifica el flujo de trabajo alrededor del proveedor que tienes de verdad, no de la mejor fila de la matriz.

Cuando hay más de una impresora

Una granja cambia la forma del problema. El mismo modelo necesita un laminado para boquilla de 0,4 mm y otro de 0,6 mm, y los dos son legítimamente known good para máquinas distintas. Uno de ellos sigue llevando la marca de recomendado, así que mantén las etiquetas explícitas sobre para qué máquina es cada uno, ya que la marca no puede expresar “depende”.

Encolar G-code en las impresoras configuradas con enrutado manual, por impresora predeterminada o por menos ocupada llegó en la v0.11.0, junto con ventanas de mantenimiento para sacar una máquina de la rotación. El enrutado en sí no puntúa los trabajos por el filamento cargado ni por la boquilla, aunque desde la v0.12.0 una comprobación previa compara los metadatos de material y boquilla antes de un envío directo y avisa de un desajuste, así que el operador sigue eligiendo la máquina, pero recibe un aviso cuando el archivo no le va bien. El recorrido por una granja con Klipper cubre cómo encaja esto junto a Mainsail, y las impresiones reproducibles en una flota cubren por qué un archivo idéntico imprime distinto en cada máquina.

Vale la pena conectar Spoolman una vez que el registro de revisiones es real. Seleccionar una bobina por trabajo y dejar que el consumo medido se escriba de vuelta te da gramos reales por revisión en lugar de estimaciones, con protección contra el doble conteo. Es solo para Moonraker, como el resto de los datos medidos. La guía de Spoolman tiene la configuración, y lo que cuesta de verdad una impresión cubre cómo convertir eso en dinero.

Preguntas que surgen

¿Debería usar Git para el G-code y ya está?

Úsalo para las entradas, no para las salidas. Los perfiles del slicer, las configuraciones de Klipper y los scripts de posprocesado son archivos de texto pequeños que se benefician de diffs reales y de mensajes de commit. El G-code son 10 a 30 MB por laminado, y un repositorio lleno de ellos crece rápido; git-lfs resuelve el tamaño y elimina el diff, que era la razón por la que querías Git. El diff también tiene la forma equivocada, ya que miles de líneas de coordenadas rodean el puñado de comentarios de cabecera que te importan, y el .bgcode binario es opaco. Una herramienta que extrae los metadatos y compara ajustes responde antes a la pregunta real.

¿Se puede marcar el estado known good automáticamente?

Sí, para las impresiones enviadas a través de una impresora conectada. Con Auto-mark known good on successful print activado, un trabajo que se completa promociona su propia revisión a known_good. No sobrescribirá un veredicto que hayas puesto a mano, así que una revisión que marcaste como failed o archived se queda así aunque un trabajo posterior sobre ella salga bien. La marca de recomendado no se pone nunca de forma automática después de la primera subida, porque “imprimió bien” y “la que hay que imprimir la próxima vez” son juicios distintos, y solo tú puedes hacer el segundo.

¿Qué metadatos se extraen de un laminado?

Lo que haya escrito el slicer. Para la salida habitual de OrcaSlicer, PrusaSlicer, Bambu Studio y Cura, eso suele cubrir el perfil de impresora y boquilla, la altura de capa, el número de paredes, el relleno, los soportes, el material, las temperaturas de hotend y de cama, la duración estimada y el consumo estimado de filamento. Los metadatos y las miniaturas del .bgcode binario también se leen, aunque la previsualización de trayectorias y el envío a la impresora no están disponibles para él mientras el cuerpo comprimido siga sin descodificar. Los campos varían según el slicer y el perfil, así que las carencias son esperables y no un fallo, y lo útil que se puede reportar es un archivo de ejemplo que se pueda compartir sin problema.

¿Cómo gestiono un modelo que se imprime en dos impresoras distintas?

Mantén los dos laminados como revisiones del mismo modelo y pon la máquina en la etiqueta, por ejemplo 0.6 nozzle, farm A y 0.4 nozzle, desk printer. Los dos pueden estar en known_good a la vez, ya que el resultado es por revisión. Solo uno puede ser el recomendado, así que dale esa marca al laminado que enviarías si tuvieras que reimprimir la pieza hoy, y apóyate en las etiquetas y en el tamaño de boquilla extraído para el resto. Filtrar por modelo de impresora o por estado de revisión encuentra el correcto rápido en una biblioteca grande.

¿Funciona algo de esto sin una impresora conectada?

Sí, y es el punto de partida normal. La extracción de metadatos, las revisiones, las etiquetas, las notas, los estados de resultado, la marca de recomendado y la comparación de ajustes son todos independientes de las impresoras. Marcas los resultados a mano después de cada impresión, lo que lleva unos segundos mientras todavía tienes la pieza en la mano. Conectar una impresora añade el marcado automático de resultados, el historial de trabajos adjunto a la revisión, y la duración y el filamento medidos desde Moonraker. El registro es la parte valiosa; la automatización solo te quita teclear.

Fuentes

• OctoPrint data model para las estadísticas de impresión por archivo y Moonraker’s history API para los campos de trabajo registrados. Los dos consultados el 3 de agosto de 2026.
• Manyfold features para el control de versiones de su hoja de ruta, y GyroidVault para su versionado y sus registros de impresión.
• PrintStash: core concepts, installation, printers guide y known limitations.

Si estás decidiendo entre bibliotecas en lugar de implementando una, PrintStash frente a Manyfold y STL Shelf compara cómo tres de ellas manejan las revisiones. Si el problema más amplio es la organización de archivos, empieza por un modelo, una carpeta, un historial.