APORTE COMO CONTINUAR UNA IMPRESIÓN DONDE PARÓ

[Simemart]

Sensores que detecten el movimiento del filamento ya los hay disponibles en el mercado (el Smart Filament Sensor de Bigtreetech, por ejemplo) y Marlin tiene una configuración específica para usarlos.
Para solucionar el problema del atasco, se podría utilizar la funcionalidad Filament Runout, con uno de estos sensores para detectarlo y lanzar la rutina de cambio de filamento, dado que esta espera a que el usuario vuelva a introducirlo y confirme para continuar donde se paró la impresión, lo que permitiría solucionar el atasco antes de continuar.
También se me ocurre que sería posible implementar la reanudación de la impresión, para lo que habría que activar tanto el Power Loss Recovery como el Filament Runout Sensor, configurando este último para utilizar ese tipo de sensor y definiendo un nuevo gcode para colocar en el parámetro FILAMENT_RUNOUT_SCRIPT, donde se realice una llamada a la función que desencadena el PLR: el PLR habría que configurarlo con un pin ficticio y en modo UPS.
Como es lógico, imprimir en el aire no es posible, pero sí que se pueden puentear distancias que no sean demasiado largas: que yo sepa, todos los programas de corte tiene parámetros para definir cómo se comporta la impresión al realizar puentes, solo es cuestión de ajustarlos correctamente.

[Luis Jiménez I]

Estimado Simemart. Aunque ya habías comentado algo al respecto, no tengo claro aún el ¿porqué estos aparatos no hacen arcos y en su lugar cada curva es hecha como una sucesión de rectas? ¿Limitante en el procesador de la impresora, o en algo en su tarjeta de control de movimiento, en el rebanador (slicer, en este caso Cura), o en la resolución de los motores a pasos (típicamente se pueden configurar los micropasos a resoluciones bastante finas), o en qué? ¿Sería posible hacer alguna modificación para que hagan arcos en lugar de rectas? Comentaste que los equipos de maquinado CNC industriales si hacen arcos.

Saludos. Luis J.

[Simemart]

La única razón por la que no se hacen arcos en estas impresoras 3D, es que no se utilizan los comandos correspondientes (G2 y G3): no hay limitaciones por la parte hardware, ni tampoco por el firmware (Marlin soporta esos comandos), simplemente los programas de corte que se utilizan para generar los comandos de impresión no los usan.
Entiendo que solo se debe a que el sistema que utilizan dichos programas para generarlos, se basa en intersecciones (que son rectas) de planos (capas y caras), por lo que es eso lo que plasman en las trayectorias.
En entornos CNC, CAD y CAM están integradas y de esa forma se pueden generar dichos comandos a partir de la geometría de la pieza: los programas de corte desconocen dicha geometría (o la ignoran), utilizando solo las caras de los triángulos que forman la superficie exterior de la pieza.

[Luis Jiménez I]

Estimado Simemart y comunidad 3D

Dejo una liga de un programa open source que convierte rectas a curvas.  No lo he probado aún, pero parece que reduce tiempos y además, llevaría el faceteado a la mínima expresión.   Cuestión de que lo prueben y comenten
https://hackaday.com/2020/11/03/this-gco...into-arcs/

Luis

Hay un comentario importante, complementario a lo dicho ahí:
There’s a workaround to that problem: “setting #define MM_PER_ARC_SEGMENT to 0.0 in Configuration_adv.h”
lo que definiría la resolución, y supongo que poniéndolo a cero, usaría la resolulción máxima de los motores a pasos.  
Otro tema sería ver si se puede definir en la tarjeta controladora y/o marling también la resolución de los motores, pues hay configuraciones a micropasos.   El caso es que parece ser que con estas maniobras reduciría uno al mínimo el faceteado, no sé si disminuyendo la velocidad de impresión o al revés.   Quizá debiera cada quien saber la velocidad a la que puede procesar su tarjeta controladora y hacer algunas cuentas, para saber si al configurar micropasos no alenta mucho su impresora. Supongo que una basada en ST32 será más rápida que un arduino, y ver también qué velocidad de reloj porta la tarjeta.

[Simemart]

Una funcionalidad interesante, pero creo que no has leído o entendido bien cuales son los beneficios que consigue y que su autor especifica claramente en su página web:

"Arc Welder attempts to replace G0/G1 (linear move) GCodes with G2/G3 (arc move) GCodes. This can substantially compress many GCode files and may reduce stuttering caused by sending many tiny movements in rapid succession over a slower serial connection."

que Google traduce así:

"Arc Welder intenta reemplazar los GCodes G0/G1 (movimiento lineal) con GCodes G2/G3 (movimiento de arco). Esto puede comprimir sustancialmente muchos archivos GCode y puede reducir el tartamudeo (las microparadas durante la impresión, esto lo añado yo) causado por el envío de muchos movimientos pequeños en rápida sucesión a través de una conexión en serie más lenta."

De ahí que tenga la impresión, en vista de tu interés en utilizar los comandos de arcos, que piensas que estos realmente realizan arcos perfectos, que no están formados por segmentos de recta encadenados y que de esa forma se pueden mejorar los resultados de la impresión, algo que también propicia el autor de Arc Welder al decir que los comandos de movimiento lineal, se sutituyen por comandos de "movimiento de arco".
En estás máquinas y en cualquier otra de tipo CNC, no existen "movimientos de arco" sino "comandos de arco" y esa aplicación lo único que hace es sustituir unos por otros sin más.
No se pueden realizar movimientos de arco propiamente dichos, combinando el movimiento realizado por 3 ejes coordenados, que solo puede obtener tramos rectos; más grandes o pequeños, eso sí, lo que hará que los arcos se aproximen más o menos al arco perfecto (algo que realmente no existe físicamente, pues la naturaleza es discreta): cuando preguntaste si había limitaciones en el hardware y te dije que no, me refería a utilizar los comandos, no a realizar los arcos propiamente dichos (dí por supuesto que era evidente esto último, aunque quizá debería haberlo aclarado).
Cuando el firmware recibe un comando de arco, lo traduce en los segmentos de recta correspondientes en función de la configuración que tenga para estos comandos (en Marlin, los parámetros que siguen al de activación) de ahí que, si se configuran con el mismo número de segmentos, tanto el programa de CAD con el que se crea la figura, como los comandos de arco en el firmware, no hay ninguna diferencia en los resultados de la impresión, pues al final se realizarán las mismas trayectorias: la única diferencia será que en el primer caso irán todas en el archivo de impresión y en el segundo no.

[Luis Jiménez I]

complementé el comentario anterior, hay que ver lo de los micropasos.  Pero además, ¿Qué nos garantiza que los comandos rectos de cada curva, por ejemplo del Cura, se hacen a partir de la máxima resolución disponible para la tarjeta-motores particulares de una impresora?

---

Y ya entrados en gastos, y abusando de tu amabilidad, te pregunto lo siguiente: La impresión me está generando un efecto raro, en un cierto ángulo la faceta es vertical y conforme se alcanzan los 180 grados, la faceta se ve inclinada, lo que seguramente implica deformación respecto del modelo original. ¿A qué pueda deberse y cómo se arregla?

[Simemart]

Vamos por partes, que hay muchos temas distintos en tu mensaje.

Hay un comentario importante, complementario a lo dicho ahí:
There’s a workaround to that problem: “setting #define MM_PER_ARC_SEGMENT to 0.0 in Configuration_adv.h”
lo que definiría la resolución, y supongo que poniéndolo a cero, usaría la resolulción máxima de los motores a pasos.

Lo primero, decir que ese parámetro es de las versiones anteriores de Marlin.
Actualmente se ha mejorado mucho la implementación de arcos y ahora hay dos parámetros que controlan el tamaño de los segmentos en que se divide el arco, uno el mínimo (MIN_ARC_SEGMENT_MM, por defecto 0,1mm) y otro el máximo (MAX_ARC_SEGMENT_MM, por defecto 1mm).
Además, existe un parámetro para vincular el número de segmentos en que se dividirá el arco, a la velocidad de impresión que se utilice (ARC_SEGMENTS_PER_SEC, por defecto desactivado) y otro que fija el número mínimo de segmentos en una circunferencia completa (MIN_CIRCLE_SEGMENTS, por defecto 72).
Si se configura a 0 cualquiera de esos parámetros, probablemente se produzca un error durante la ejecución, pues se utilizan dividiendo y, como es bien sabido, no se puede dividir por 0: en todo caso, no afecta para nada a la resolución, como explico en el siguiente punto.

Otro tema sería ver si se puede definir en la tarjeta controladora y/o marling también la resolución de los motores, pues hay configuraciones a micropasos.

La resolución de los motores viene fijada por su construcción, no se puede modificar y son los pasos que puede realizar en una vuelta completa (normalmente 200, aunque ya se ven mucho los de 400).
Los micropasos por milímetro no se configuran al libre albedrío, se fijan en función de cuanto se mueve el eje por cada revolución del motor y de los micropasos a enviar para que gire una vuelta completa, que es el producto de los pasos del motor por los micropasos configurados en el driver (lo más habitual son 16 o 32, aunque depende del driver).
La resolución teórica del eje, es el inverso de los micropasos por milímetro configurados: si son 100 micropasos por milímetro, el movimiento más pequeño que puede realizar el eje es 1/100=0,01mm (como digo es la teórica, en la práctica es difícil conseguirlo).
Resumiendo, para una impresora concreta, todos estos valores son fijos y no se pueden cambiar si se quiere que haga bien su trabajo.

El caso es que parece ser que con estas maniobras reduciría uno al mínimo el faceteado, no sé si disminuyendo la velocidad de impresión o al revés.

Supongo que con faceteado, quieres indicar las caras del prisma en que se convierte un cilindro impreso y eso puede reducirse de varias formas, aunque siempre hasta unos límites, tanto físicos como del software.
Sin necesidad de tocar nada más, simplemente configurando adecuadamente el programa con el que se diseña la pieza, ya se consigue esa reducción: si el programa no es paramétrico, aumentando el número de segmentos con que se dibujan arcos y círculos; si es paramétrico, configurando el exportador a STL.
Yo en mis diseños, utilizo circunferencias de 60 segmentos para las que son de pequeño diámetro y si son muy grandes, lo aumento en consecuencia.

Quizá debiera cada quien saber la velocidad a la que puede procesar su tarjeta controladora y hacer algunas cuentas, para saber si al configurar micropasos no alenta mucho su impresora. Supongo que una basada en ST32 será más rápida que un arduino, y ver también qué velocidad de reloj porta la tarjeta.

Me temo que saber a qué velocidad procesa la MCU de la impresora los comandos puede ser complicado y, en todo caso, no tiene mucha utilidad práctica: la impresión FDM es mucho más sencilla que todo eso y ajustar los parámetros que mejores resultados dan en nuestra impresora no necesita hilar tan fino, por la razón que indico en el siguiente punto.

¿Qué nos garantiza que los comandos rectos de cada curva, por ejemplo del Cura, se hacen a partir de la máxima resolución disponible para la tarjeta-motores particulares de una impresora?

En impresión FDM, la mecánica de la impresora no es lo que limita la máxima resolución a la que se puede imprimir, pues el plástico fundido acaba haciendo lo que quiere antes de solidificarse: a partir de una resolución mecánica mínima, es casi imposible distinguir una mejora apreciable en el resultado impreso.
Lo normal es que estas impresoras tengan una resolución mecánica teórica, en los ejes XY, de una centésima de milímetro, pero el plástico fundido puede contraerse o dilatarse mucho más que eso, condicionando de forma clara el resultado.
Por otra parte, los programas de corte no deciden cuantos segmentos tienen los arcos y círculos, les vienen definidos en el archivo STL de la pieza: es el programa de CAD con el que se generan dichos archivos el que tiene ese valor, que el susuario puede configurar como más le convenga.

Y ya entrados en gastos, y abusando de tu amabilidad, te pregunto lo siguiente:  La impresión me está generando un efecto raro, en un cierto ángulo la faceta es vertical y conforme se alcanzan los 180 grados, la faceta se ve inclinada, lo que seguramente implica deformación respecto del modelo original.  ¿A qué pueda deberse y cómo se arregla?

Incluso las impresoras mejor afinadas y los perfiles de impresión más ajustados, tienen un ángulo límite de desplome, pues no se puede imprimir en el aire (solo en el caso de puentes y no demasiado largos).
Cuando la parte a imprimir de la pieza lo sobrepasa, es necesario utilizar soportes y, así todo, probablemente no se impidan las deformaciones: la tecnología FDM tiene sus límites y hay piezas que no se pueden imprimir con ella.
En todo caso, la forma de conseguir minimizar estos problemas, pasa por calibrar perfectamente la impresora, tanto en el apartado mecánico como en la extrusión y por configurar correctamente el perfíl de impresión: quizá te interese lo que indico en estos dos post (Configuración inical de la impresora y Calibración dimensional).
Un buen ventilador de capa, correctamente orientado y un impulsor de filamento robusto también ayudan mucho en este aspecto.

[Luis Jiménez I]

Alguien propone que se suavice (se reduzca el faceteado) en Autocad moviendo los parámetros de visualzación (ver imagen)


Voy a probar y comento.  Seguramente es mayor la resolución de esos parámetros a lo que se puede imprimir, pero seguramente reduce el faceteado.  Ya si no, habrá que ver en Cura qué parámetros logran algo.  Ya luego veo lo de la calibración dimensional y el otro apartado.   De hecho también tengo que ver que estén bien las tensiones de las bandas X e Y.

[Luis Jiménez I]

Haré esos procedimientos, pero por lo pronto, comparto que el cambio en los parámetros de visualización del Autocad DIERON BUEN RESULTADO!!  Es decir, se redujo de tal forma el FACETEADO que al tacto se siente una superficie circular y a la vista SE REDUJERON NOTABLEMENTE  !!!!  Ver foto
Y no noté ningún alentamiento en la impresión. 

Imprimiendo con PETG transparente de Sunlu.


Por cierto, mis parámetros fueron 8,000;  500;  10;  500, es decir, menores que los propuestos.

[Luis Jiménez I]

Por cierto, comparto que EL NOBREAK (FUENTE ININTERRUMPIDA) FUNCIONÓ MARAVILLOSAMENTE ante un fallo del suministro eléctrico. La impresora no se detuvo y no hubo ningún efecto visible, continuó sin problemas. Uso un Sola Basic (de transformador resonante) de por ahí de 70 euros, que funciona como regulador mientras hay suministro y que aunque ofrece una señal cuasi-senoidal cuando éste falla, la Anet et4 funcionó perfectamente. Esto era de esperarse ya que los motores a pasos trabajan a partir de la fuente de la tarjeta controladora (entiendo que son unos mosfet alimentados por la señal que genera un ST32), es decir, no trabajan con la señal del nobreak directamente, sino que esa señal sólo alimenta al transformador y a la salida hacia los motores hay una etapa de rectificación. ¡El caso es que de maravilla ! Me falta hacer la prueba de suplir la batería original por la de un coche, pues espero que me alargue significativamente el tiempo de respaldo, tal vez unas 4 veces al menos y lo que promete ésto para el consumo de la Anet et4, es como 30 minutos, de suerte que tal vez podría tener un respaldo de 2 o 3 horas. Cuando lo pruebe comento.