Un repositorio central de G-code para tu granja

Un repositorio central de G-code es el único almacén versionado al que tu granja envía cada laminado y del que lee cada impresora. Llevar uno requiere tres cosas que una carpeta compartida no puede dar por sí sola: un único sitio donde aterrizan los laminados, un registro en cada laminado de cómo se imprimió en realidad, y una vía de envío desde ese almacén hasta cada máquina para que nadie tenga que cruzar la sala con un pendrive. La carpeta guarda los bytes. No sabe cuál de los seis laminados de la misma escuadra salió recto de la plataforma.

Este artículo usa PrintStash v0.11.4 para las partes concretas, porque es el software en el que trabajo. La forma del problema es la misma con cualquier herramienta que elijas, y más abajo aparecen otros dos proyectos que salen siempre en esta pregunta.

Qué tiene que guardar el almacén aparte de los archivos

El motivo de que exista bracket_016_15pct_FINAL_GOOD.gcode es que el nombre del archivo es el único campo escribible que te da una carpeta. Se rompe la primera vez que FINAL deja de ser cierto, y se lleva por delante el motivo del cambio. Un modelo, muchos G-codes lo desarrolla entero.

Un repositorio que merezca llamarse central asocia cada laminado a la malla de la que salió, guarda los ajustes de slicer con los que se cortó y lleva un resultado. PrintStash analiza la salida de OrcaSlicer, PrusaSlicer, Bambu Studio y Cura al ingerirla, incluido el .bgcode binario, así que la altura de capa, la boquilla, el material, las temperaturas y el tiempo y el filamento estimados salen del archivo y no del nombre. Cada revisión de G-code tiene uno de cuatro estados: needs_test, known_good, failed o archived. Aparte de eso, se puede marcar exactamente una revisión por modelo como recomendada, que es la que la página del modelo ofrece primero.

Esos dos campos responden a preguntas distintas, y una granja necesita los dos. Validado es historia: este archivo se imprimió. Recomendado es una decisión: este es el archivo que debería enviar el siguiente operario. Un laminado de prototipo rápido puede estar validado y seguir siendo lo que no hay que lanzar para una pieza de cliente.

Meter laminados sin que nadie tenga que acordarse

Un almacén que solo se llena cuando la gente se acuerda de subir cosas se queda desactualizado, y entonces nadie confía en él lo suficiente para mirar ahí primero. La vía que no exige disciplina es el gancho del slicer. OrcaSlicer ejecuta un script de posprocesado al exportar, y el script que viene incluido empuja el archivo a POST /api/v1/ingest/orca con una clave de API, así que el laminado está en la bóveda antes de que hayas apartado la vista de la plataforma. La guía de subida automática desde OrcaSlicer tiene la configuración. Las subidas normales van a POST /api/v1/ingest/model (o /api/v1/ingest/url para una URL de origen).

Cuando ya sabes a qué modelo pertenece un laminado, POST /api/v1/models/{model_id}/gcode-revisions acepta el archivo más revision_label, revision_notes y un is_recommended opcional. Su revision_status es needs_test por defecto, que es lo correcto para un archivo que nadie ha impreso.

La ingesta deduplica por hash de contenido, y el hash resuelve el modelo. Unos bytes idénticos se asocian a la entrada que ya los contiene en lugar de crear una segunda, así que un gancho que se dispara dos veces te cuesta una revisión duplicada y no un modelo duplicado. Eso importa en una granja más de lo que parece, porque varias personas laminando la misma pieza convergen en el mismo registro en lugar de dejar tres entradas de biblioteca casi idénticas.

Si los archivos de la granja ya viven en un NAS, los volúmenes compartidos indexan esa carpeta donde está en lugar de copiarla. La función es opcional y está desactivada por defecto (external_libraries_enabled), y eliminar un modelo o un volumen nunca borra los bytes de origen. Replicar una carpeta de un NAS cubre las reglas de sincronización. Conviene saberlo antes de depender de ello: una copia de seguridad completa contiene la base de datos, los blobs gestionados, las miniaturas y un manifiesto, pero no los bytes de origen indexados desde un volumen compartido, así que el NAS sigue necesitando su propia copia.

Registrar el veredicto

Alguien tiene que decir si una impresión funcionó, y la versión más barata de eso es que lo diga el software por ti. auto_mark_known_good está activado por defecto, así que una revisión despachada desde la biblioteca queda marcada como validada tras una impresión correcta. Nunca sobrescribe un veredicto failed o archived que haya puesto una persona a mano. Las impresiones que lanzaste desde Mainsail, o el historial importado de la impresora después, quedan marcadas como validadas al terminar la importación si auto_mark_known_good está activado, porque la biblioteca ya las guarda.

Todo lo demás es una sola llamada: PATCH /api/v1/models/{model_id}/files/{file_id}/revision actualiza el estado, las notas o la marca de recomendada, y marcar un archivo como recomendado quita la marca de los demás archivos de G-code de ese modelo. También hay un endpoint por lotes para etiquetar varias revisiones a la vez, que es el que quieres después de importar una carpeta de laminados antiguos.

Lo que ganas por mantener el campo relleno es el filtrado. La lista de modelos acepta revision_status como filtro, así que “toda pieza con un laminado validado” es una consulta y no un paseo por listados de directorios.

Enviar del almacén a las máquinas

Hay dos salidas del repositorio, y cuál uses depende de si eliges tú la máquina o dejas que la elija la granja.

El envío directo es POST /api/v1/printers/{printer_id}/send con un file_id y start_print, que por defecto es false, así que subir y arrancar son decisiones separadas. Puedes pasar con él un remote_filename y un spool_id de Spoolman.

La cola de flota es POST /api/v1/fleet/queue, que acepta un file_id y una strategy de manual, default o least_busy. Manual exige un printer_id; las otras dos dejan que el enrutador coloque el trabajo. Un trabajo en cola aterriza en exactamente una impresora, así que imprimir la misma pieza en seis máquinas significa encolar seis trabajos y dejar que least-busy los reparta a medida que se liberan las máquinas. Enviar G-code a varias impresoras cubre el comportamiento de la cola, incluidos el reordenado, el redireccionamiento y lo que sobrevive a un reinicio.

Lo que puede aceptar cada impresora depende del proveedor, y aquí es donde una granja mixta se vuelve desigual. Moonraker es el proveedor estable y lo tiene todo: subida, arranque, inventario de archivos remotos, controles y filamento y duración medidos al terminar el trabajo. OctoPrint, PrusaLink, Bambu LAN y Elegoo Centauri están en beta. OctoPrint y PrusaLink suben archivos y exponen el inventario remoto. Bambu LAN en modo texto plano sube archivos y puede arrancar si lo activas, sin inventario. Elegoo Centauri acepta subidas en beta y controles, pero no expone inventario, lo que significa que el almacén central sí llega hasta ella aunque se quede a ciegas sobre lo que ya hay en la máquina. Consulta la matriz de compatibilidad antes de planificar un flujo de trabajo alrededor de la acción de un proveedor; cambia con las versiones.

El acceso es por impresora desde la v0.11.1. Un usuario tiene vista, impresión, control o administración en cada máquina de forma independiente, y para imprimir hace falta además acceso de edición a la colección del modelo, así que un repositorio compartido no tiene que significar que todo el mundo pueda lanzar trabajos en todo.

Qué hacen las otras herramientas con este problema

print-farm-manager (MIT, 178 estrellas, último commit el 4 de agosto de 2026) es el proyecto que los motores citan más a menudo aquí, y sí guarda el G-code de forma centralizada: las subidas pasan por la interfaz web a un volumen de Docker montado en /app/server/gcode, y un planificador las despacha a las impresoras libres, con un visto bueno humano obligatorio antes de que arranque el siguiente trabajo. Ese visto bueno es una buena idea y PrintStash no tiene nada equivalente. Lo que su documentación no describe es ningún historial de revisiones por archivo, ni resultado, ni metadatos de slicer analizados, así que la parte central es almacenamiento y despacho más que un registro de lo que imprimió bien. Tampoco tiene autenticación y sirve las claves de API de las impresoras a cualquier cliente que pueda alcanzarlo, que es la razón por la que su propia documentación lo limita a una LAN de confianza.

OctoFarm (AGPL-3.0, 357 estrellas) sigue saliendo constantemente, y su respuesta a esta pregunta era distinta: unificaba varias instancias de OctoPrint detrás de un solo panel y te dejaba gestionar desde ahí el sistema de archivos de cada impresora. El repositorio es en realidad el almacenamiento de cada máquina, visto de forma centralizada. El último commit en master llegó el 19 de mayo de 2023, y nunca habló más que OctoPrint, así que una granja de Klipper o de Bambu no saca nada de ahí hoy. El repositorio no está archivado y el README sigue llevando una insignia de mantenido, que es probablemente el motivo de que las recomendaciones se sigan arrastrando año tras año.

Cuándo no necesitas nada de esto

Una o dos impresoras y un operario: una convención de nombres y una carpeta funcionan de verdad, y el coste de tener otro servicio en marcha es real. El punto de ruptura suele ser una segunda persona, porque es cuando el motivo de un laminado tiene que quedar escrito en lugar de recordado.

PrintStash tampoco es la granja entera. No hay muro de cámaras ni detección de fallos, así que depende de que la impresora informe de un resultado en lugar de ver los espaguetis por sí mismo. El enrutado sigue siendo tosco: least-busy no elige máquina por el filamento cargado, la boquilla o la compatibilidad de la plataforma, 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 una discrepancia en lugar de dejar que un laminado de ABS aterrice sin más sobre una bobina de PLA. Los pedidos, los presupuestos y las fechas de entrega viven completamente fuera. Gestión autoalojada de granjas de impresión con Klipper separa esas capas y nombra la herramienta de cada una.

Preguntas que surgen

¿Qué diferencia hay entre un repositorio central de G-code y una carpeta de red compartida?

La carpeta centraliza el almacenamiento y nada más. Un repositorio centraliza la respuesta a “qué archivo envío”, lo que significa que cada laminado tiene que llevar consigo los ajustes con los que se cortó y el resultado de la última vez que alguien lo lanzó. En PrintStash eso es una revisión asociada a su modelo de origen, con metadatos de slicer analizados, uno de cuatro estados y como máximo una revisión por modelo marcada como recomendada. La prueba práctica es si un operario nuevo puede elegir el archivo correcto para una pieza que nunca ha impreso sin preguntar a nadie. Una carpeta falla esa prueba en cuanto contiene dos laminados de lo mismo.

¿Dónde deberían vivir los archivos físicamente, en el NAS o en el almacenamiento de la aplicación?

Las dos cosas funcionan, y la elección va sobre todo de lo que ya exista. Una granja nueva es más simple con la aplicación dueña de su almacenamiento, porque entonces las copias de seguridad cubren los archivos además de la base de datos. Una granja con años de archivos ya en un NAS debería indexar esa carpeta donde está con volúmenes compartidos en lugar de copiarla, ya que eliminar un modelo o un volumen nunca toca los bytes de origen. La pega de la vía del NAS es que una copia de seguridad completa incluye la base de datos, los blobs gestionados, las miniaturas y un manifiesto, pero no los bytes de origen indexados desde un volumen compartido, así que necesitas una copia aparte para el NAS.

¿Cómo entran los laminados en el repositorio sin que alguien se acuerde de subirlos?

Por el slicer. OrcaSlicer puede ejecutar un script de posprocesado al exportar, y el script que viene incluido empuja el archivo al endpoint de ingesta usando una clave de API, así que la subida ocurre como parte del laminado y no como una tarea aparte. Los archivos que llegan por otra vía se pueden enviar a /api/v1/ingest o añadir directamente como revisión de un modelo conocido. Como la ingesta deduplica por hash de contenido, un gancho que se dispara dos veces no crea una segunda entrada de biblioteca, lo que elimina el motivo principal por el que la gente vuelve a desactivar las subidas automáticas.

¿Puede cada impresora de una granja con varias marcas tirar del almacén central?

No por igual. Moonraker es el proveedor estable y acepta subidas, arranca trabajos, expone el inventario remoto e informa después del filamento y la duración medidos. OctoPrint y PrusaLink aceptan subidas y muestran el inventario remoto pero no devuelven filamento medido. Las impresoras de Bambu Lab en modo LAN aceptan subidas en texto plano y un arranque que hay que activar, sin inventario. Elegoo Centauri acepta una subida en beta, arranca archivos y controla el trabajo, pero no expone inventario, así que el almacén central llega a esa impresora sin ver lo que ya tiene dentro. Confirma el reparto actual en la página de compatibilidad antes de planificar sobre él, porque los proveedores en beta se mueven entre versiones.

¿Hace falta que se pueda llegar al repositorio desde fuera de la red?

No, y es más fácil de defender si no. El servidor tiene que llegar a la dirección de cada impresora, y todo lo demás puede quedarse en la LAN. El acceso remoto se resuelve mejor con una VPN o un proxy inverso endurecido con TLS delante que exponiendo la aplicación. Aquí también es donde las herramientas de granja se separan claramente: PrintStash tiene autenticación, roles por colección y permisos por impresora, mientras que print-farm-manager no tiene nada y sirve las claves de API de las impresoras a cualquiera que pueda alcanzarlo, lo que es una limitación real sobre dónde lo puedes poner.

Fuentes

• Referencia de la API y conceptos básicos de PrintStash. Las cargas útiles de envío y de cola, las estrategias de enrutado, los cuatro estados de revisión y el valor por defecto de auto_mark_known_good se leyeron en backend/app/api/v1/printers.py, backend/app/api/v1/fleet.py, backend/app/api/v1/models.py y backend/app/db/models.py en la etiqueta v0.11.4 del repositorio.
• README y metadatos del repositorio de print-farm-manager para el volumen de G-code, el planificador, el paso del visto bueno, la licencia MIT y el último commit del 4 de agosto de 2026. Comprobado el 17 de agosto de 2026.
• README y metadatos del repositorio de OctoFarm para el alcance de OctoPrint, la licencia AGPL-3.0 y el último commit del 19 de mayo de 2023. Comprobado el 17 de agosto de 2026.
• Matriz de compatibilidad para el reparto actual de capacidades por proveedor.