¿Hay un mejor explorador de archivos Moonraker?
El gestor de archivos de Moonraker lista la salida del slicer de una máquina. Cómo saber si necesitas otro front-end, una biblioteca detrás o ninguna.
Detrás de esta pregunta se esconden dos quejas distintas, y cada una tiene su propia respuesta.
Si lo que te molesta es el explorador en sí, porque subir archivos es incómodo o no encuentras uno que está tres carpetas más abajo, lo que quieres es otro front-end de Moonraker. Fluidd y Mainsail hablan con la misma API de Moonraker, y sus gestores de archivos no son el mismo producto. Cambiar es un cambio en el compose o una opción del menú de KIAUH, así que pruébalo antes que nada.
Si lo que quieres es saber cuál de los cuatro archivos llamados bracket.gcode se imprimió de verdad, o llegar desde un laminado hasta el STL del que salió, ningún front-end de Moonraker te va a llevar hasta ahí. Eso no es un problema de interfaz. La raíz gcodes de Moonraker solo lista la salida del slicer, y su historial de impresión guarda un nombre de archivo. La información que pides nunca se registró, así que ningún explorador, por bueno que sea, la va a sacar a la luz.
Identifica el muro antes de salir a buscar herramientas.
Qué es en realidad el gestor de archivos de Moonraker
Moonraker expone un sistema de archivos. La API del gestor de archivos sirve un conjunto de raíces, de las cuales gcodes y config son de escritura y logs, config_examples y docs son de solo lectura. La raíz gcodes filtra por extensión y acepta .gcode, .g, .gco, .ufp y .nc. Un STL o un 3MF no es algo que pueda mostrarte en absoluto. Es un explorador de la salida del slicer por diseño, y juzgarlo como una biblioteca fallida es no entender para qué se construyó.
Sí extrae bastantes metadatos de cada archivo: altura del objeto, altura de capa, diámetro de boquilla, tipo y peso de filamento, tiempo estimado, temperaturas de la primera capa y miniaturas. La documentación es directa sobre de dónde sale todo eso: “la disponibilidad de cada campo de metadatos depende de la aplicación de laminado y de su configuración. Si un campo no se puede extraer del slicer, se omite”. Las miniaturas funcionan igual. Moonraker lee los bloques de vista previa en base64 que incrustó tu slicer y los escribe como archivos PNG junto al G-code. Nunca renderiza la geometría por su cuenta, así que un archivo exportado con las vistas previas desactivadas no tiene miniatura en ninguna parte de la pila, en ningún front-end.
El historial de impresión es un componente aparte con un límite de la misma forma. Cada entrada recibe un id de trabajo incremental y guarda el nombre del archivo de G-code, el estado, las duraciones, el filamento consumido y una instantánea de esos metadatos. Ningún campo apunta a un modelo de origen, porque en el sistema no hay ningún modelo de origen. Cada archivo lleva además un uuid, pero se genera de forma aleatoria cuando se extraen los metadatos, no a partir del contenido, así que dos copias de un laminado idéntico con nombres distintos no tienen ninguna relación para Moonraker. Las entradas del historial llevan también una marca exists que pasa a falso en cuanto el archivo se modifica, lo cual es honesto por su parte pero no es lo mismo que conservar el registro.
Una cosa más que importa si tienes más de una máquina: una instancia de Moonraker sirve a una impresora. Lo que sea que estés explorando, estás explorando esa impresora.
Con qué muro te has topado
Cinco preguntas que ordenan el problema rápido:
- ¿Puedes ver en una sola lista lo que hay en todas tus máquinas?
- Con cuatro archivos que son alguna variante de
bracket, ¿sabes cuál se imprimió limpio? - ¿Puedes ir de un archivo de G-code al STL o al 3MF del que se laminó?
- ¿Obtienes una vista previa de un archivo cuyo slicer no incrustó ninguna?
- ¿Sobrevive el registro a borrar el archivo para liberar la tarjeta SD?
Moonraker responde no a las cinco, y los dos front-ends heredan esas respuestas porque leen la misma API. La primera y la cuarta no las puede arreglar nadie en la capa de interfaz. Las otras tres piden datos que nunca se capturaron.
Si has leído esa lista y ninguna te importa, no necesitas otra herramienta. Una impresora, una carpeta por proyecto y unas pocas decenas de archivos al año es una situación que el gestor de archivos de Fluidd cubre por completo, y añadirle una biblioteca encima es administración de la que te vas a arrepentir. Vuelve cuando una de las cinco empiece a escocer.
Si el muro es la interfaz
La mayor parte del trabajo es terreno común, así que empieza por ahí. Fluidd 1.37.4 y Mainsail 2.18.2, los dos comprobados el 17 de agosto de 2026, te dan una tabla ordenable con un selector de columnas que se reordena arrastrando, selección múltiple con borrado en lote, descarga en ZIP de una selección, creación de carpetas, renombrado, duplicado, mover arrastrando sobre una carpeta, subida arrastrando desde el escritorio y, por archivo, imprimir, precalentar, volver a leer los metadatos, editar, descargar y un visor 3D de G-code integrado. Los dos permiten mostrar u ocultar los archivos ocultos y los ya impresos. Los dos muestran en línea las miniaturas que incrustó el slicer. Ninguno tiene vista de cuadrícula o galería, por si era eso lo que esperabas.
Las diferencias son reales, pero más estrechas de lo que sugieren las discusiones sobre ellas. El gestor de archivos de Fluidd tiene una búsqueda difusa de tipo “ir al archivo” que abarca la raíz entera en vez de filtrar el directorio actual, y es la única función que echaría más de menos después de haber convivido con ella. Una acción de análisis de tiempo entrega el archivo al componente [analysis] de Moonraker, que ejecuta klipper_estimator sobre él y reescribe las estimaciones de tiempo en el propio archivo. Muestra vistas previas de imágenes, vídeo y Markdown renderizado, no solo de G-code. Trae más columnas de metadatos, incluidos los colores de filamento y de extrusor, los pesos por filamento, el fabricante y el modelo de la impresora, y la versión del slicer. Sus filtros conocen específicamente los archivos de copia de seguridad de Klipper, Moonraker y Crowsnest. Te avisa cuando el disco baja del menor de 1 GB o el 20 por ciento, y acepta una carpeta entera arrastrada desde el sistema operativo.
El explorador de archivos de Mainsail no está documentado en su sitio de documentación, así que lo que sigue sale de leer su código. Pone el historial de impresión en la fila del archivo de forma más útil que Fluidd, con columnas para la hora de inicio y la hora de fin de la última impresión, la duración de la última impresión, la última duración total y el filamento consumido en ella. Fluidd expone columnas de historial que se solapan, pero no la hora de fin. Mainsail ofrece además añadir a la cola en lote directamente desde la fila del archivo, con un contador, que es la vía más rápida que conozco para encolar ocho copias de una pieza. Donde Fluidd incluye mover entre sus operaciones de archivo y te deja activar arrastrar y soltar en los ajustes, Mainsail no tiene ninguna orden de mover en sus menús, así que arrastrar la fila sobre una carpeta es la única forma de reorganizar.
La cola de trabajos merece una mención aquí, porque hay gente que sale a buscar un explorador de archivos mejor cuando lo que quería era una cola. Es un componente opcional de Moonraker, [job_queue], y los dos front-ends lo exponen. Fluidd documenta una tarjeta de cola con reordenación, una acción de multiplicar y totales al pie para el filamento y el tiempo de impresión combinado. El panel de cola de Mainsail también admite reordenar. Guarda nombres de archivo de esa única impresora, así que es un gestor de cola de impresión y no tiene nada que ver con organizar una colección.
Ninguno de los dos front-ends te da una vista de archivos combinada entre impresoras, y aquí es donde la expresión “varias impresoras” induce a error. Fluidd cambia de impresora en una sola pestaña del navegador, pero se reinicia por completo contra la instancia de Moonraker que acabas de seleccionar, así que estás viendo una máquina a la vez. Mainsail añade varias impresoras y encima tiene una página de resumen de la granja, que muestra el estado, el nombre del archivo actual, el progreso y una webcam opcional por máquina. No incluye ningún explorador de archivos. Explorar archivos siempre está limitado a la instancia que tengas seleccionada.
Si el muro son los datos
Una biblioteca se pone detrás del explorador de archivos en vez de sustituirlo, y guarda las cuatro cosas para las que Moonraker no tiene campo: la malla de origen, el vínculo entre un laminado y esa malla, un veredicto sobre cada laminado y un registro que sobrevive al archivo.
La unidad de almacenamiento pasa a ser el modelo, no el archivo que hay en una máquina. En PrintStash 0.11.4, un modelo guarda su malla de origen junto al G-code laminado a partir de ella, y cada laminado se almacena como una revisión numerada con una etiqueta opcional, notas de texto libre y un resultado entre known_good, needs_test, failed y archived. Solo una revisión de G-code por modelo puede marcarse como recomendada, y un índice único parcial en la base de datos lo garantiza, así que la interfaz no puede equivocarse. Esa es la respuesta a la segunda pregunta de la lista de arriba, y seguir las revisiones verificadas explica cómo se fija el resultado.
Los ajustes del slicer se extraen del archivo y se guardan en la revisión: material, altura de capa, diámetro de boquilla, temperaturas, peso de filamento y tiempo estimado de la salida de OrcaSlicer, PrusaSlicer, Bambu Studio y Cura. Hasta aquí se solapa con lo que Moonraker ya extrae. La diferencia está en dónde vive. Queda pegado a una revisión de un modelo, sobrevive a que el archivo se borre de la impresora, y puedes poner dos laminados de la misma pieza uno al lado del otro.
Las vistas previas son una cosa que una biblioteca puede hacer y Moonraker no. PrintStash rasteriza la propia malla de origen, con numpy y Pillow y sin GPU de por medio, así que una pieza cuyo G-code no lleva miniatura sigue teniendo imagen, sacada del STL. Con 3MF recurre a la vista previa incrustada en el archivo comprimido cuando el renderizado falla o el archivo excede el límite configurado. STEP y STP necesitan la teselación de OpenCASCADE, que la imagen completa ya hace tanto en amd64 como en ARM; la imagen lite los guarda sin generar vista previa.
Para los archivos que están en la impresora, PrintStash lee el inventario de la máquina y hace corresponder cada nombre remoto con una revisión que ya tiene, marcando el resto como externos. No copia los archivos de vuelta, y la correspondencia tiene modos de fallo que conviene entender antes de confiar en ella, ambos cubiertos en sincronizar los archivos de una impresora con la biblioteca. El inventario tampoco es universal entre proveedores. Moonraker es el proveedor estable y lo admite, PrusaLink y OctoPrint lo admiten en beta, y Bambu LAN y Elegoo Centauri no exponen ningún inventario de archivos, así que en esas máquinas no hay nada que leer. La matriz de compatibilidad es la lista actualizada por proveedor.
Qué se queda en Fluidd o Mainsail
Todo lo que tiene que ver con manejar la máquina. La webcam, la consola, las macros, las gráficas de temperatura, el homing y el movimiento manual, la edición de la configuración, los reinicios de firmware y la intervención a mano durante una impresión se quedan exactamente donde están, y una biblioteca no tiene por qué intentar quitárselos. PrintStash se conecta a la misma instancia de Moonraker que ya usa Fluidd o Mainsail, así que un archivo que suba aparece en su lista como cualquier otro, y conectar una impresora Klipper son una URL y una clave de API opcional. El resumen de controladores entra más en dónde está la frontera.
Hay una advertencia que cambia cómo trabajas, no lo que instalas. Cuando una impresión arranca desde Fluidd o Mainsail y no desde la biblioteca, PrintStash se da cuenta a través del flujo de estado de Moonraker y registra el trabajo, pero hace corresponder los trabajos por impresora y nombre de archivo remoto, y no tiene ningún trabajo activo al que asociar esa impresión. El resultado acaba en un registro interno de relleno en vez de en el modelo, así que las duraciones y el filamento se capturan mientras el resultado nunca llega a la revisión que estabas probando. Si quieres que el historial de impresión se acumule sobre tus modelos, manda el trabajo desde la biblioteca y usa el front-end para vigilarlo. Las reimpresiones lanzadas desde Fluidd son la forma más habitual de que el historial de una revisión deje de estar completo sin que te des cuenta.
Preguntas que surgen
¿Es mejor Fluidd o Mainsail para gestionar archivos?
Están lo bastante igualados como para que la gestión de archivos por sí sola sea una razón débil para cambiar, y los dos cubren las mismas operaciones básicas. Fluidd es más fuerte encontrando cosas e inspeccionándolas: tiene búsqueda difusa en toda la raíz en vez de un filtro sobre la carpeta actual, más columnas de metadatos, vistas previas de imágenes, vídeo y Markdown, filtros que reconocen los archivos de copia de seguridad, un aviso de disco casi lleno e integración con el componente [analysis] de Moonraker para reescribir las estimaciones de tiempo. Mainsail es más fuerte en la parte de impresión de la fila del archivo, con columnas de hora de inicio y de fin y de filamento consumido sacadas del historial, más una acción de añadir a la cola en lote desde el propio archivo. Instala el que prefieras por todo lo demás y luego trata el gestor de archivos como un pequeño desempate, no como el factor decisivo.
¿Todos los archivos de G-code tienen miniatura?
No, y no es algo que un front-end pueda arreglar. Moonraker extrae las miniaturas de los bloques de vista previa en base64 que tu slicer incrustó en el G-code, y nunca renderiza la geometría del modelo. Lo único que renderiza es reducir una vista previa incrustada existente a 32 por 32 cuando falta ese tamaño. Si exportaste sin activar las miniaturas en OrcaSlicer, PrusaSlicer, Bambu Studio o Cura, ningún cliente de Moonraker te va a mostrar una imagen de ese archivo. Activar las vistas previas en el slicer lo arregla para las exportaciones futuras, pero no hace nada por los archivos que ya están en la máquina, que hay que volver a laminar.
¿Puedo ver los archivos de todas mis impresoras en una sola lista?
No con Moonraker, Fluidd ni Mainsail. Una instancia de Moonraker sirve a una sola impresora, así que no hay una API de archivos entre instancias sobre la que construir esa vista. Fluidd cambia de impresora en una sola pestaña, pero se reinicia por completo contra la instancia seleccionada, y la página de resumen de granja de Mainsail muestra el estado por máquina, el nombre del archivo actual, el progreso y la webcam sin ningún explorador de archivos dentro. Los dos son de una máquina a la vez por diseño. Una vista combinada tiene que venir de algo que indexe cada impresora por separado y correlacione los resultados, que es lo que hace la sincronización de inventario de una biblioteca.
¿El historial de impresión de Moonraker me dice qué laminado funcionó?
Solo en el sentido más débil. Las entradas del historial registran el estado, las duraciones y el filamento consumido contra un nombre de archivo de G-code, así que si nunca renombras ni vuelves a laminar nada, puedes leer en ellas el resultado de un archivo. En cuanto exportas una segunda variante con un nombre nuevo, nada conecta las dos, porque no hay un modelo al que pertenezcan los dos archivos y el uuid de cada archivo es aleatorio, no un hash del contenido. Las entradas llevan además una marca exists que pasa a falso en cuanto el archivo se modifica. Así que el historial sabe que hubo un trabajo y más o menos cómo fue, sin saber de qué versión de qué pieza se trataba.
Si le doy a imprimir en Fluidd, ¿llega el resultado a mi biblioteca?
En parte, y la diferencia importa. PrintStash vigila el flujo de estado de Moonraker, así que un trabajo arrancado fuera de la biblioteca se captura igual, con su duración y el filamento medido. Como hace corresponder los trabajos por impresora y nombre de archivo remoto y no encuentra ningún trabajo activo esperando, el registro acaba en un relleno interno en vez de en el modelo del que salió el archivo. La revisión que estabas probando no ve su resultado actualizado. Enviar desde la biblioteca y luego vigilar la impresión en Fluidd o Mainsail te da a la vez la interfaz que te gusta y un historial que se queda pegado a la pieza.
¿Tengo que sustituir Fluidd para añadir una biblioteca?
No, y no deberías. Una biblioteca habla con la misma instancia de Moonraker por la misma API, así que Fluidd o Mainsail sigue funcionando igual y los archivos enviados desde la biblioteca aparecen en su lista como cualquier otro. Lo que te cuesta es otro servicio y otra base de datos que respaldar, que es un precio real en una instalación de una sola impresora con un árbol de directorios ordenado. El cambio solo tiene sentido cuando tienes tantas piezas, tantos laminados de la misma pieza o tantas máquinas que los nombres de archivo han dejado de ser un índice usable.
Fuentes
- La API del gestor de archivos, la API de historial, la API de cola de trabajos y la referencia de configuración de Moonraker, para las raíces, las extensiones válidas de G-code, los campos de metadatos, la extracción de miniaturas y la clave del historial. Comprobado el 17 de agosto de 2026.
- Documentación de Fluidd sobre el gestor de archivos, la cola de trabajos y varias impresoras, contra Fluidd 1.37.4. Comprobado el 17 de agosto de 2026. Ten en cuenta que el sitio de documentación de Fluidd se construye desde la rama de desarrollo del proyecto, así que puede describir un comportamiento algo por delante de la versión etiquetada.
- Documentación de Mainsail sobre miniaturas y ajustes de impresora, contra Mainsail 2.18.2. Comprobado el 17 de agosto de 2026. El gestor de archivos de G-code de Mainsail no tiene página de documentación, así que los detalles de la fila de archivo y de las columnas que hay más arriba se leyeron del código del proyecto.
- La matriz de compatibilidad de PrintStash y la guía de impresoras para el soporte de inventario por proveedor en la versión publicada.