Se trata de un pequeño parche:
Esta es la versión estable, que incluye mejoras menores y varias correcciones de errores.
Implementamos cambios en la configuración del volumen de impresión y nuevas rutinas de punta de filamento utilizadas por la MMU3 en la MK4.
Cuando se utiliza el modo vaso en espiral, las trayectorias de herramienta se generan de la forma habitual y las extrusiones resultantes se extruyen mientras se incrementa gradualmente Z. Este enfoque provocó artefactos similares a costuras en la impresión en lugares donde normalmente estarían las transiciones de capa. Además, la última capa terminaba bruscamente, creando un “borde” afilado donde terminaba la extrusión.
Ambas cuestiones fueron abordadas por @andrewboktor interpolando entre capas adyacentes y reduciendo gradualmente el flujo de extrusión al final de la impresión. La mejora se fusionó recientemente en OrcaSlicer, y recibimos un pull request con un port a PrusaSlicer. Después de evaluar la característica, decidimos fusionarla porque está bien escrita, funciona bien y es muy útil.
Gracias a @andrewboktor por el tiempo y el esfuerzo invertidos en el tema, y a ambos @vovodroid y @tg73para proporcionar un pull request con un port de OrcaSlicer
PrusaSliceres ahora capaz de abrir archivos 3MF generados por BambuStudio y cargar geometría desde ellos. (#10718, PR #10808, gracias a @cmguo). Ten en cuenta que BambuStudio permite guardar un 3MF que contenga solo código G, que no es compatible con PrusaSlicer y la carga de tales 3MFs fallará.
Los metadatos del código G binario tienen un nuevo elemento denominado objects_info, que enumera todos los objetos de la impresión y sus polígonos límite. La misma información se añadió en los comentarios al final de los códigos G de ASCII. Esto es útil para controlar la función Cancelar objeto de forma remota a través de Prusa Connect.
Esta es la versión estable, que aporta mejoras menores y varias correcciones de errores.
Implementamos varios mecanismos para detectar un diagrama de Voronoi inválido, y manipulando la entrada, podíamos asegurar que el diagrama de Voronoi sería válido. También hemos reimplementado una parte significativa del pintado multimaterial desde cero, lo que, junto con los cambios anteriores, debería resolver todos los problemas con las capas derramadas para la segmentación multimaterial.
Anteriormente, PrusaSlicer colocaba el cambio de color (M600) justo después de terminar la capa anterior. La implementación por defecto del cambio de color en casi todos los firmwares devuelve la boquilla a la misma posición exacta que antes de que comenzara el cambio de color. Como resultado de este comportamiento, una pequeña mancha de filamento con el color recién cargado se quedaba pegada a la impresión.
Nuestra comunidad, especialmente @Nohus, se le ocurrió la solución de colocar el cambio de color después de pasar a la siguiente capa y posición, lo que resultó ser una solución mucho más fácil y universal que cambiar la implementación del M600 en el lado del firmware. Gracias, Nohus, por tu implementación y a todos los que participasteis en probar su cambio.
Hemos sustituido los cambios de capa helicoidal introducidos en la 2.7.1 por un perfil de rampa más refinado. Aunque los cambios en las capas helicoidales ayudaban a reducir los hilos, a veces provocaban manchas de color y artefactos. Con el nuevo y refinado perfil de rampa se sigue mitigando la aparción de hilos sin los inconvenientes de los movimientos helicoidales.
Para la impresión SLA, hemos introducido Anulaciones de Materiales. Esta nueva función, que refleja la flexibilidad del laminado FDM, permite anular las opciones de configuración seleccionadas de las Configuraciones de Impresión o de Impresora en la Configuración del Material. Hay una nueva página de parámetros en la Configuración del material, que permite comprobar los parámetros que se anulan y redefinir su valor.
El origen de PrusaSlicer se basa en el proyecto Slic3r, escrito originalmente en lenguaje de scripting Perl. A lo largo de los años, hemos reescrito casi todo el código. Primero el núcleo de laminado, luego la interfaz de usuario. Ahora hemos reescrito en C++ todas las pruebas unitarias restantes que aún dependían de Perl. Adiós, Perl. No te echaremos de menos.
Esta es la versión estable, que incluye mejoras menores y varias correcciones de errores.
Se ha eliminado la opción Exportar como código G binario de la Configuración de Impresión. En su lugar, hay una nueva opción en Configuración de la Impresora llamada Soporta código G binario para que se pueda configurar a nivel de impresora. También hay un nuevo interruptor global en Preferencias->Otros, que controla si se generará código G binario para las impresoras que lo soportan. Ahora es mucho más fácil activar o desactivar esta función sin realizar ningún cambio en los perfiles.
El peso de la torre de limpieza se ha añadido a los metadatos del código G para que pueda mostrarse fácilmente en las estadísticas de impresión de la pantalla de la impresora.
Se ha solucionado el problema por el que, cuando se activaban los recorridos en rampa, a veces faltaba un perímetro en la capa donde comienza la espiral.
Se ha corregido un fallo al seleccionar texto en relieve mientras está abierta una herramienta SVG.
Se ha corregido un caso en el que los cambios de capa helicoidal podían provocar movimientos fuera de la cama.
Se ha corregido un caso en el que se activaba el cambio de capa helicoidal incluso cuando no había retracción en el cambio de capa.
Además de la herramienta de texto en relieve presentada por primera vez en PrusaSlicer 2.6.0, ahora es posible estampar imágenes SVG en los modelos. Se puede acceder a esta función haciendo clic con el botón derecho y permite opciones de proyección y manipulación similares a las de la herramienta de texto. Ahora basta con arrastrar y soltar un logotipo SVG, un título o incluso un código QR y fusionarlo con un modelo 3D existente.
Los archivos de código G son fáciles de leer e interpretar, pero su inconveniente es que los datos no se guardan de forma eficiente y el tamaño del archivo suele ser muy grande. La compresión del archivo es problemática porque las impresoras suelen funcionar con un hardware limitado y puede que no tengan suficiente memoria y/o potencia de CPU para descomprimirlo. Los miembros de la comunidad han propuesto varias soluciones al problema, como por ejemplo la codificación con MeatPack (utilizando el hecho de que el conjunto de caracteres de un código G típico es muy limitado) o el algoritmo de compresión heatshrink (diseñado para requerir muy poca memoria).
Estamos proponiendo una nueva norma para un formato binario de código G para codificar y comprimir archivos ASCII de código G (véase la especificación). El formato es flexible y la codificación y compresión de los bloques individuales es variable. También proporcionamos libbgcode que contiene las rutinas para convertir códigos ASCII G a binario y viceversa. La biblioteca está escrita en C++ y el repositorio incluye bindings para Python.
En cuanto a la comparación del tamaño del código G ASCII frente al binario, el resultado depende del contenido del código G. Nuestras pruebas muestran que el uso de código G binario reduce el tamaño en un 70% de media. El uso simultáneo del ajuste de arco (descrito anteriormente) puede reducir aún más el tamaño. El siguiente gráfico muestra la comparación de 10 proyectos 3MF seleccionados al azar:
El soporte para el nuevo formato de archivo .bgcode fue implementado en PrusaSlicer, incluyendo su exportación, carga de configuraciones, previsualización de código G o asociaciones de archivos. La exportación de código G binario se puede activar en Configuración de impresión->Opciones de salida->Exportar como código G binario. Se ha añadido al menú Archivo una opción para convertir el código G ASCII en binario (o al revés).
Para imprimir un código G binario, tiene que ser soportado por el firmware de la impresora. Para las impresoras Original Prusa MINI, MK4 y XL, esto es soportado desde la versión 5.1.0-alpha2. Es necesario actualizar el firmware de la impresora antes de utilizar el formato de código G binario.
Queremos dar las gracias a Scott Vokes (@atomicobject) por su trabajo en heatshrink y a
Scott Mudge (@scottmudge) por desarrollar y mantener MeatPack.
es
en
cs
pl
ja
de
it