Versiones de perfiles slicer entre impresoras

Los perfiles del slicer son archivos de texto pequeños que cambian a menudo y que importan mucho, que es exactamente la forma de cosa con la que Git se lleva bien. Pon el directorio de perfiles de usuario del slicer en un repositorio, haz commit cuando cambies algo a propósito, y la pregunta de qué toqué antes de que esto empezara a fallar pasa a ser un diff en lugar de una discusión.

Lo que Git no puede responder es qué perfil produjo una impresión concreta, porque en el momento en que editas un perfil, la versión que hizo la pieza buena del mes pasado desaparece del slicer. Esa respuesta vive dentro del propio G-code, y una biblioteca que interpreta esas cabeceras la conserva a posteriori.

Mete los perfiles en un repositorio

OrcaSlicer guarda los perfiles de usuario como JSON en su directorio de configuración, repartidos en las carpetas filament, machine y process de cada perfil de usuario. Localízalo desde Help > Show Configuration Folder en lugar de adivinar la ruta, porque cambia entre Windows, macOS y Linux. PrusaSlicer y Bambu Studio siguen el mismo patrón con sus propios formatos y directorios.

Inicializa el repositorio en la carpeta user y no en el directorio de configuración completo. El directorio padre guarda cachés, logs, perfiles de sistema descargados y el estado de las ventanas, y nada de eso te interesa en un diff. Haz commit de los perfiles, añade un .gitignore para todo lo que cambia en cada arranque y súbelo a algún sitio al que lleguen tus otras máquinas.

Dos hábitos hacen que el historial se pueda leer. Cierra el slicer antes de hacer commit, porque reescribe los archivos de perfil al salir y si no acabarás guardando un estado a medio escribir. Y haz commit de un cambio intencionado a la vez: “proceso PETG, boquilla de 0,6, primera capa más lenta” es un mensaje que ayuda dentro de seis meses, y “perfiles” no.

Todo el montaje son cuatro comandos una vez que tienes la carpeta abierta:

cd "/path/to/slicer-config/user"   # Help > Show Configuration Folder la abre
printf '*.log\n*.bak\n.cache/\n' > .gitignore
git init && git add . && git commit -m "baseline presets"

Mantener varias máquinas sincronizadas

La mecánica es Git normal, con un detalle: el slicer es dueño de esos archivos mientras se ejecuta y sobrescribirá encantado lo que acabas de traer con un pull.

El flujo que aguanta es tratar una máquina como el sitio donde editas los perfiles, hacer commit ahí y hacer pull en el resto con el slicer cerrado. Si editas en dos máquinas la misma semana, espera conflictos en un JSON que genera un programa y es incómodo de fusionar a mano. Resolverlos quedándote con un lado entero suele ser lo correcto, porque un perfil a medio fusionar es peor que cualquiera de las dos versiones.

Los ajustes propios de cada impresora son la otra trampa. Un perfil de máquina que codifica un tamaño de cama, una boquilla o un G-code de inicio con el nombre de una macro concreta no es portable a otra impresora, así que guarda eso como perfiles separados en lugar de como un perfil que vas editando. Lo compartible suelen ser los ajustes de proceso y de filamento, no los de la máquina.

Los paquetes de exportación como puntos de control, no como mecanismo de sincronización

Todos los slicers de esta familia pueden entregarte sus perfiles en un único archivo. PrusaSlicer lo llama instantánea de configuración, y su artículo sobre instantáneas de configuración cubre tanto guardar una como restaurarla después. La página del wiki sobre perfiles de usuario de OrcaSlicer documenta esa misma exportación para sus carpetas de perfiles. Un paquete tomado antes de una ronda de cambios de calibración es un punto de retorno barato, y es la forma más fácil de llevar un montaje completo a una máquina recién estrenada.

Como mecanismo de sincronización rutinaria, en cambio, los paquetes envejecen mal. Son archivos opacos, así que no hay diff ni historial por perfil, y restaurar uno sobrescribe todos los perfiles que contiene en lugar de solo el que querías tocar. Deja que el historial de Git sea el registro de verdad y trata los paquetes como puntos de control que nombras a mano.

Las herramientas de sincronización y lo que te cuestan

Syncthing o un simple rsync programado pueden mantener la carpeta de perfiles idéntica en todas las máquinas sin que nadie ejecute comandos de Git. Para una sola persona con una única máquina de edición, eso es un arreglo perfectamente bueno, y la propia documentación de Syncthing describe lo que pasa cuando no lo es: si dos máquinas editan el mismo archivo entre sincronizaciones, cada una se queda con su versión, renombrada como copia sync-conflict, y alguien las reconcilia a mano. La carpeta se mantiene consistente; la intención que había detrás del cambio no sobrevive, y nada te cuenta qué aspecto tenían los perfiles el mes pasado.

Si los perfiles importan lo bastante como para mantenerlos sincronizados entre máquinas, normalmente importan lo bastante como para hacerles commit. La herramienta de sincronización y el historial de Git no se excluyen: sincroniza la carpeta por comodidad, y deja que la única máquina de edición lleve el repositorio que recuerda por qué se hizo cada cambio. Para mirar ese compromiso más de cerca con archivos de modelo en lugar de perfiles, sincronizar archivos STL entre un PC y un NAS cubre la misma elección con montajes, rsync y Syncthing.

Qué añade la biblioteca que Git no puede

Un repositorio registra el perfil tal y como está hoy, y cada commit te dice cómo estaba en una fecha. Lo que no te dice es qué perfil produjo el archivo que imprimió bien, porque el G-code que salió de él vive en otro sitio completamente distinto.

PrintStash interpreta cada laminado que subes y guarda los ajustes que el slicer escribió en la cabecera: nombre y versión del slicer, modelo de impresora, diámetro de boquilla, altura de capa y de primera capa, porcentaje de relleno, número de perímetros, capas de las cáscaras superior e inferior, si los soportes estaban activados, temperaturas de hotend y cama, tiempo estimado, peso, longitud y coste del filamento, y el tipo y la marca del material. Esos valores quedan congelados en el momento del laminado. Editar el perfil después no los cambia.

Ese es el registro que hace reproducible una buena impresión. Compara la revisión que funcionó con la que no y la diferencia enseña los ajustes que cambiaron de verdad, que es más rápido que leer dos archivos JSON esperando dar con la línea que importa. Y una revisión marcada como verificada es una afirmación sobre valores concretos, no sobre el nombre de un perfil que se ha editado tres veces desde entonces.

Merece la pena conocer un efecto secundario: la primera vez que un archivo nombra un perfil de impresora o un material, PrintStash crea a partir de él un perfil local de impresora o de filamento, rellenando el modelo, el diámetro de boquilla y, cuando el slicer escribió tanto el coste total del filamento como el peso, un coste por kilo inferido. Esos perfiles locales sirven para costes y filtros. No son copias de los perfiles de tu slicer y no se pueden exportar de vuelta al slicer.

El reparto honesto del trabajo

Git versiona los perfiles. La biblioteca versiona la salida y registra con qué se hizo cada laminado. Ninguno sustituye al otro, y forzar a uno a hacer las dos cosas termina mal: una biblioteca no es un gestor de configuración, y un repositorio de archivos de perfil no puede contarte que el proceso de 0,16 salió limpio en la Voron y se combó en la Ender.

Una rutina que funciona se parece a esto:

1. Mantén la carpeta user de perfiles del slicer en Git, un commit por cambio deliberado.
2. Edita los perfiles en una máquina y haz pull en las demás con el slicer cerrado.
3. Deja que cada exportación aterrice en la biblioteca con sus ajustes interpretados, a mano o mediante el hook de OrcaSlicer.
4. Etiqueta la revisión con la intención que había detrás del cambio de perfil, porque el analizador registra qué cambió y nunca por qué.
5. Cuando una impresión sale bien, marca la revisión como verificada. Eso congela los ajustes que la produjeron, al margen de lo que diga el perfil hoy.

Preguntas frecuentes

¿Puede PrintStash guardar o versionar los perfiles de mi slicer?

No, y no lo pretende. PrintStash guarda los ajustes que aparecen dentro de cada archivo laminado, no los archivos de perfil, así que no hay nada que sacar, comparar ni restaurar en tu slicer. Los perfiles locales de impresora y de filamento que crea a partir de los metadatos interpretados existen para calcular costes y filtrar, y contienen un puñado de campos como el modelo de impresora, el diámetro de boquilla, el tipo de material y el coste por kilo. Para versionar los perfiles de verdad, usa Git sobre la carpeta de configuración de usuario del slicer.

¿Dónde guarda OrcaSlicer los perfiles de usuario?

En el directorio de configuración de OrcaSlicer, en una carpeta user que contiene subcarpetas filament, machine y process con archivos JSON por perfil. La forma fiable de encontrarlo en cualquier plataforma es Help > Show Configuration Folder dentro de OrcaSlicer, porque la ruta cambia entre Windows, macOS y Linux. Los perfiles de sistema viven al lado en una carpeta aparte y se reemplazan al actualizar, así que versiona la carpeta user y deja el resto en paz.

¿Cómo sé qué versión del perfil produjo una buena impresión?

Léelo del laminado y no del perfil. Los ajustes se escriben en la cabecera del G-code, se interpretan al subirlo y se guardan contra esa revisión, así que una revisión marcada como verificada lleva la altura de capa, la boquilla, las temperaturas, el relleno, el número de perímetros y el material con los que se hizo en realidad. Comparar dos revisiones muestra las diferencias directamente. Esta es la única respuesta fiable una vez que el perfil se ha editado, porque el slicer no guarda historial propio.

¿Le va bien Git también al G-code?

No. Los perfiles son archivos de texto pequeños que cambian de vez en cuando, y eso encaja con Git. El G-code ocupa entre 10 y 30 MB por laminado, cambia por completo cada vez y produce diffs de miles de líneas de coordenadas sin sentido. git-lfs arregla el tamaño y elimina el diff, que era la razón para usar Git en primer lugar. Guarda las entradas en control de versiones y deja que una biblioteca se encargue de las salidas, algo que se cubre en seguir las revisiones de G-code. Si prefieres regenerar un laminado antes que guardarlo, versionar G-code como software explica el enfoque de sistema de compilación, donde el slicer fijado a una versión sustituye al archivo archivado.

¿Y los perfiles de impresoras que no son idénticas?

Guárdalos como perfiles de máquina separados en lugar de como un perfil que vas ajustando. El tamaño de cama, el diámetro de boquilla, el G-code de inicio y de fin y los nombres de las macros son hechos de la máquina, y un perfil que los mezcla con ajustes de proceso deja de ser compartible. Los perfiles de proceso y de filamento son la parte portable, y son los que más ganan estando en un solo repositorio para todas las máquinas.

¿Debería usar Syncthing en lugar de Git para los perfiles?

Para una sola persona editando en una sola máquina, sí: es más simple y no hay nada que aprender. El coste aparece el día en que dos máquinas editan el mismo perfil entre sincronizaciones: Syncthing conserva las dos versiones como copias de conflicto renombradas y alguien las reconcilia a mano, y no hay historial al que recurrir cuando hay que deshacer un cambio del mes pasado. Si los perfiles importan lo bastante como para sincronizarlos entre máquinas, un repositorio de Git en la máquina de edición, junto a la sincronización, te da el historial gratis.

Fuentes

• OrcaSlicer user profiles para saber cómo se organizan los perfiles de usuario, y el Help > Show Configuration Folder de la propia aplicación para la ruta de cada plataforma. Comprobado el 12 de agosto de 2026.
• PrusaSlicer configuration snapshots para exportar y restaurar un conjunto completo de perfiles como un único paquete. Comprobado el 22 de agosto de 2026.
• Documentación de Syncthing sobre cambios en conflicto para saber qué pasa cuando dos máquinas editan el mismo archivo entre sincronizaciones. Comprobado el 22 de agosto de 2026.
• Guía de usuario de PrintStash para los metadatos que se extraen de cada laminado y dónde aparecen en un modelo.

Si el objetivo son resultados reproducibles y no una configuración ordenada, un modelo, muchos G-codes cubre el lado de los resultados, y organizar una biblioteca automáticamente cubre qué más hacen los metadatos interpretados una vez guardados.