Organiza tu biblioteca STL sin complicarla
Cuatro formas de ordenar una colección de modelos, desde un árbol de carpetas hasta una biblioteca conectada a impresoras y cómo saber cuál le queda pequeña.
La mayoría de las colecciones necesitan menos estructura de la que supone quien las está reorganizando. La pregunta útil no es qué disposición es mejor en abstracto, sino qué pregunta sigues sin poder responder. Elige el método que la responde y párate ahí, porque cada capa de estructura que añades es una capa que tienes que mantener.
Hay más o menos cuatro métodos, y se apilan. Cada uno resuelve un fallo concreto que el anterior no puede.
Encuentra la pregunta que sigues sin poder responder
Antes de elegir nada, fíjate en qué falla de verdad. Las quejas se ordenan en un conjunto pequeño, y cada una apunta a un método distinto.
Si no encuentras un modelo que sabes que tienes, el problema son los nombres y la disposición. Si encuentras el modelo pero no el fichero correcto dentro de él, el problema es que la geometría de origen, los proyectos del slicer y el G-code están mezclados. Si encuentras el fichero pero no recuerdas si imprimió bien, el problema es que nada registró el resultado. Y si el mismo modelo existe cinco veces con cinco nombres, el problema es que nada compara el contenido de los ficheros.
Son cuatro problemas distintos. Reorganizar carpetas arregla el primero y no hace nada por los otros tres, y por eso las limpiezas de carpetas dejan tan a menudo un sabor a poco.
Carpetas y disciplina con los nombres
Un árbol poco profundo por proyecto o por finalidad, más nombres de fichero lo bastante cortos para leerlos en la pantalla de la impresora, aguanta unos cientos de modelos en una sola máquina. Es una respuesta real y no un apaño provisional, y hay mucha gente que nunca necesita más.
El modo de fallo es predecible. Los nombres de fichero empiezan a absorber metadatos, y bracket_016_15pct_brim_FINAL_GOOD_v3.gcode es una base de datos que nada puede consultar. Separar la geometría de origen de los proyectos del slicer y del G-code es el arreglo más barato. Organizar archivos STL, 3MF y G-code explica la disposición completa.
Carpetas más un registro de impresión escrito
Añade un fichero Markdown junto a cada proyecto donde anotes qué G-code se imprimió, en qué máquina y qué cambiaste. No cuesta nada y resuelve la pregunta más cara de una biblioteca que crece.
También es lo que se degrada más rápido. La nota hay que escribirla mientras sacas la pieza de la cama, no tres semanas después, cuando el detalle ya se ha perdido. Si lo has intentado y las notas se pararon al mes, esa es la señal para pasar al método siguiente en lugar de insistir más.
Una biblioteca indexada
Cuando la colección llega a unos miles de ficheros, o cuando has dejado de confiar en tus propias notas, un índice se gana el mantenimiento que cuesta. Lo que consigues y las carpetas no te pueden dar es identidad por hash del contenido, de modo que los mismos bytes con dos nombres se resuelven en una sola entrada, y búsqueda estructurada sobre los ajustes que el slicer ya escribió dentro de cada fichero.
El detalle importante es que adoptar uno no exige mover nada. Un volumen compartido en PrintStash escanea una carpeta local o de un NAS montada, deja cada fichero de origen en su ruta actual y guarda por separado el índice, los metadatos y la miniatura. Tu slicer sigue abriendo las mismas ubicaciones. Organizar miles de archivos STL es la migración, y qué buscar en un gestor de archivos 3D autoalojado es la lista de criterios si estás eligiendo entre herramientas.
Una biblioteca conectada a las impresoras
La última capa cierra el círculo: envías un laminado a una máquina y el resultado del trabajo vuelve y queda pegado a la revisión que lo produjo. Esa es la parte que una controladora no puede guardar, porque una controladora solo conoce nombres de fichero en una impresora.
Conviene ser concreto sobre de qué depende esto. En PrintStash, Moonraker es el proveedor estable y el único que devuelve duración y uso de filamento medidos. PrusaLink, OctoPrint, Bambu LAN y Elegoo Centauri están en beta con huecos reales, listados en la matriz de compatibilidad. Si todas tus máquinas están en la columna de beta, esta capa vale menos que la anterior.
Qué hacer primero
Indexa antes de reorganizar. El índice casi siempre muestra que la biblioteca no tiene la forma que recuerdas, y las decisiones que se toman después son mejores que las que se toman antes.
Después deja que el primer escaneo termine por completo antes de tocar la taxonomía. Luego añade colecciones para los proyectos que existen de verdad, y un vocabulario de etiquetas lo bastante corto para acordarte de cómo se escribe cada una. Añadir estructura para una categoría que todavía no has necesitado es la forma en que las bibliotecas acaban con doscientas etiquetas y nadie usándolas.
Preguntas frecuentes
¿Reorganizo las carpetas antes de indexarlas o después?
Después, en casi todos los casos. Un índice es barato de ejecutar y reversible, mientras que mover miles de ficheros no es ninguna de las dos cosas, y el primer escaneo suele decirte que el árbol no es el que te imaginabas. Apunta el índice a las carpetas tal como están, deja que calcule los hashes y parsee todo, y luego mira lo que los filtros te revelan sobre qué grupos son reales. Reorganiza solo las partes donde el índice te da un motivo concreto, y cuenta con que sea un trabajo más pequeño que el que tenías planeado.
¿Puedo tener un sistema manual y una biblioteca a la vez?
Sí, y es el estado normal durante una temporada, no un error de transición. Una biblioteca que indexa en el sitio no toma posesión de tu árbol de carpetas, así que los ficheros siguen abriéndose desde el slicer, el explorador de archivos y cualquier otra cosa que ya apunte a ellos. Lo que suele pasar es que las notas manuales son lo primero que se cae, porque es la parte que la biblioteca sustituye de forma más completa, mientras que la estructura de carpetas sobrevive indefinidamente porque sigue funcionando.
¿Tengo que decidir un vocabulario de etiquetas antes de empezar?
No, y decidirlo pronto tiende a producir etiquetas que nunca usas. Las etiquetas inventadas por adelantado describen una biblioteca que imaginas; las que añades al mes describen la que tienes. La ruta práctica es empezar sin ninguna, añadir una etiqueta la segunda vez que quieres filtrar por algo y no puedes, y mantener la lista lo bastante corta para recordar exactamente cómo se escribe cada una. print-in-place y print_in_place son dos filtros y una sola intención.
¿En cuál de estos métodos me paro?
Párate en el que responde tu queja actual, y añade el siguiente solo cuando una pregunta concreta se quede sin respuesta una y otra vez. El coste de cada capa es real: un registro de impresión hay que escribirlo, una biblioteca necesita actualizaciones y una copia de seguridad que se haya restaurado de verdad, y una conexión con la impresora necesita máquinas cuyo proveedor soporte lo que quieres. Si ya encuentras todos los ficheros y te acuerdas de qué laminado funcionó, más estructura no va a mejorar nada.
Fuentes
- Las capacidades de PrintStash y las limitaciones conocidas de la versión actual, y la matriz de compatibilidad para lo que soporta cada proveedor de impresoras.
- Volúmenes compartidos para la indexación en el sitio, el modo espejo y el comportamiento del escaneo.
El resto de este grupo de artículos profundiza en cada capa: la mejor forma de organizar archivos STL sobre la entrada de ficheros, gestionar una biblioteca grande sobre lo que cambia después del primer escaneo, y qué es el software de gestión de archivos STL sobre la categoría en sí.