Slic3r: Detectar arcos y generar G2/G3

Todavía hay algunas fallas en la detección o el centro del arco.

Algunas notas de @bkubicek aquí: http://bernhardkubicek.soup.io/post/191097625/If-you-have-a-path-of-segments

Además, parece que el radio no siempre es correcto.

http://www.thingiverse.com/cosa:13976

Cortar este modelo con --gcode-arcs da como resultado este error alrededor del 70% del camino hacia arriba del modelo:

No se puede llamar al método "distance_to" en un valor indefinido en /home/sparr/src/slic3r/git/Slic3r/lib/Slic3r/ExtrusionPath.pm línea 168.

Sospecho que esto se debe a que ray_intersection no puede devolver un punto.

Agregue una casilla de verificación en la pestaña avanzada para habilitar/deshabilitar la compatibilidad con el corte en arco.

Me gusta la sugerencia de @jgeerds .
Me encantaría ver a Arcs trabajando en Slic3r.

También estaría muy contento si el soporte de arco pudiera ser útil, lo que daría como resultado una mayor precisión de los objetos impresos y evitaría algunos problemas de extrusión con segmentos muy cortos de arcos pequeños.

@furynick , ¿puede proporcionar más detalles sobre los problemas de extrusión con segmentos muy cortos de arcos pequeños? Incluso con el firmware G2 y G3 se subdividirá la curva en muchos segmentos pequeños.

no es un problema de Slic3r sino un problema físico, compré un extrusor todo en uno donde el paso a paso está directamente "enchufado" en el filamento, por lo que la longitud mínima de extrusión para 1 paso (controlador RAMPS configurado con 1/16 micropasos) es de aproximadamente 0,02 mm (49 pasos por mm).
El gcode de la balsa, por ejemplo, contiene después de cada línea de relleno una extrusión muy pequeña de 0,0031 mm por ejemplo (yo uso una boquilla de 0,2 mm). Los arcos también contienen pequeños segmentos que necesitan menos de 0,02 mm de filamento y creo que deberían extruirse correctamente con los comandos G2/G3 (necesito hacer algunas pruebas para verificar esta hipótesis).
En todos los casos, planeo imprimir piezas mecánicas de precisión y casi todas las piezas pueden tener caras redondeadas que se imprimirán mejor con comandos G2/G3.
Estoy planeando agregar un gusano como reductor para multiplicar la cantidad necesaria de pasos para avanzar 1 mm de filamento y evitar este problema ya que, en mi opinión, el valor mínimo de pasos/mm no debería ser inferior a 1000.

¿Se admiten los comandos de arco en la GUI? Me gustaría generar gcode con comandos de arco para que haya menos código cuando estoy imprimiendo objetos cilíndricos.

Tengo una máquina que ejecuta smoothieware y me encantaría probar esta característica para posiblemente incluirla en una versión futura.
Parece estar deshabilitado. ¿Cómo hago para habilitarlo nuevamente?

@qharley , ese código no se mantiene y probablemente ni siquiera funcione a menos que se haga algún trabajo en él

Veo. Podría trabajar un poco en eso. Parece ser una de esas características que entusiasman a todo el mundo y luego se dan por vencidas...

Tal vez lo haga dependiente del sabor de gcode, y solo admita el firmware que realmente lo admita correctamente.

+1 en esto

Hola

He estado trabajando en un detector de curvas gcode para implementar arcos de código G2 y G3 durante un tiempo, y parece estar funcionando muy bien y deja de tartamudear por completo a través de USB.

Un ejemplo del cambio que puede hacer:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

se convierte en:

G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

Si está interesado en el código, puedo subirlo a GitHub si lo desea (aunque es bastante _crudo_ en este momento, parece hacer el trabajo).

sí, por favor comparte tu código, estoy muy interesado.

Bien, aquí tienes:

https://github.com/manticorp/GCodeArcOptimiser

Todo el código de trabajo principal está en:

https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php

Está escrito en PHP (¡lo siento!) pero debería ser fácilmente traducible a Perl/C++.

Un problema que tengo es probarlo: es difícil saber dónde está fallando, nunca obtuve una impresión completamente funcional, pero muchos de los movimientos parecen correctos, por supuesto, cualquier cantidad de cosas pequeñas pueden hacer una impresión falla, sin embargo...

PHP no es una mala elección :)
Le echaré un vistazo y probaré, gracias por tu trabajo.

Está bien. Actualizaré el archivo LÉAME en un momento con una descripción general básica de cómo funciona. Sé lo críptico que puede ser leer el código pirata de otra persona...

@qharley ahora hay un sabor gcode de Smoothieware, por lo que puede trabajar en arcos si lo desea.

Sería más feliz si esto viviera en slic3r propiamente dicho y no como un posprocesador gcode :)

También me gustaría ver esto dentro de slic3r, por lo que estoy trabajando para que el algoritmo ya implementado vuelva a funcionar.

Enlace a la sucursal: https://github.com/Salandora/Slic3r/tree/arcFix
Progreso hasta ahora:

• Se detectan arcos
• Los puntos centrales del arco se calculan correctamente
• Gcode se reemplaza con G2, G3
• todavía algunos pequeños errores como:
  
  
  
  • radio en la capa superior un poquito demasiado grande. (Comprobado visualmente a través de Repetier Host)
  
  
  • una línea de aspecto extraño en el primer objeto (lo probé con 3 veces el mismo objeto, que básicamente es un hexágono con un pequeño y un gran agujero)
  
  

@Salandora alguna noticia de tu sucursal? Noté que tu repositorio parece no tener nuevas actualizaciones desde hace 3 meses. ¿Crees que estaría listo para fusionarse con slic3r normal?

No, no está listo, quería portar esto a C++ pero no tenía idea de por dónde empezar.
De hecho, arreglé algunos errores en el script de posprocesamiento que ya estaba incluido, pero aún tengo errores abiertos, como el cálculo incorrecto del valor E, creo que fue un movimiento E relativo.

Y en realidad casi no tengo tiempo para echar un vistazo a esto de nuevo.
Ni siquiera estoy seguro de si la rama arcFix era real o si eliminé los últimos cambios antes de enviarlos :-/

Estoy por comenzar la implementación de un modelo matemático para esto. ¿Algún apoyo del desarrollador? Porque va a suponer mucho trabajo y simulación xD. Tengo una convergencia matemáticamente demostrada, por lo que es una detección de arco segura.

Haga preguntas, las personas que pueden ayudar y quieren participar. No puedo
Sin embargo, garantizo algo específico en términos de soporte, tengo un montón de
cosas que pasan

El 5 de diciembre de 2017 a las 10:12 a. m., "PurpleSensation" [email protected] escribió:

Estoy por comenzar la implementación de un modelo matemático para esto.
¿Algún apoyo del desarrollador? Porque va a suponer mucho trabajo
y simulación xD. Tengo una convergencia matemáticamente demostrada, por lo que
es una detección de arco segura.

—
Estás recibiendo esto porque fuiste asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-349353693 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAB8CsVQiOxmu_4hQbcmUS1RsZr6p5dNks5s9WtogaJpZM4CPczH
.

Está bien, está hecho. Ahora tengo que comprobar si el algoritmo es sólido, pero estoy bastante seguro de que lo es. Probablemente voy a publicar un documento con esto, pero no sé absolutamente cómo implementar esto en GitHub, lo hice en MatLab.

Tendría que implementarse en C++ para que sea útil para el proyecto Slic3r.

El 9 de diciembre de 2017 a las 9:12 a. m., "PurpleSensation" [email protected] escribió:

Está bien, está hecho. Ahora tengo que comprobar si el algoritmo es sólido pero estoy
seguro que lo es. Probablemente voy a publicar un artículo con esto, pero
Absolutamente no sé cómo implementar esto en GitHub, lo hice en MatLab.

—
Estás recibiendo esto porque fuiste asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350477368 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAB8CilKXqig1mWQQ4k9y66IUGp-vUImks5s-qNUgaJpZM4CPczH
.

Muy interesado en este proyecto y me gustaría ayudar, tengo algo de conocimiento en C++ pero casi ninguna habilidad con matlab.

Estoy esperando registrar la idea para un artículo científico (necesito un plan de estudios para un programa de maestría) y luego lo compartiré. También tengo que verificar los métodos para asegurar la suavidad de la curva en los puntos entre arcos y líneas, etc. Pero el código es perfectamente sólido en este momento y siempre converge y te devuelve una polilínea/arco con un error colineal dado.

Las líneas verdes son arcos, los nodos son los nodos de polilínea originales y la línea roja son líneas rectas. Puede enviarme polilíneas cerradas (dadas en formato de una matriz de posiciones xy ordenadas) para probar el algoritmo.

Entiendo completamente querer escribirlo y publicarlo (una vez fui un graduado
estudiante yo mismo). ¿Cómo es la complejidad del tiempo/espacio?

El 10 de diciembre de 2017 a las 10:53 a. m., "PurpleSensation" [email protected]
escribió:

Estoy esperando registrar la idea para un artículo científico (necesito algunos
plan de estudios para un programa de maestría) y luego voy a compartir. tambien tengo que revisar
métodos para asegurar la suavidad de la curva en los puntos entre arcos y
líneas y etc... Pero el código es perfectamente sólido en este momento y siempre
converge y le devuelve una polilínea/arco con un error colineal dado.

[imagen: imagen]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
Las líneas verdes son arcos, los nodos son los nodos de polilínea originales y
la línea roja son líneas rectas. Puedes enviarme polilíneas cerradas (dadas en
formato de una matriz de posiciones xy ordenadas) para probar el algoritmo.

—
Estás recibiendo esto porque fuiste asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

Slic3r ya puede generar un conjunto de cortes en SVG. Entonces podrías comprobarlo
contra muchos modelos interesantes (que probablemente serían útiles para
puntos de referencia para su trabajo).

El 10 de diciembre de 2017 a las 11:45 a. m., "Joe Lenox" [email protected] escribió:

Entiendo completamente querer escribirlo y publicarlo (una vez fui un graduado
estudiante yo mismo). ¿Cómo es la complejidad del tiempo/espacio?

El 10 de diciembre de 2017 a las 10:53 a. m., "PurpleSensation" [email protected]
escribió:

Estoy esperando registrar la idea para un artículo científico (necesito algunos
plan de estudios para un programa de maestría) y luego voy a compartir. tambien tengo que revisar
métodos para asegurar la suavidad de la curva en los puntos entre arcos y
líneas y etc... Pero el código es perfectamente sólido en este momento y siempre
converge y le devuelve una polilínea/arco con un error colineal dado.

[imagen: imagen]
https://user-images.githubusercontent.com/23365990/33807172-d194e86c-ddd2-11e7-9bd5-9f8c5cc5fa46.png
Las líneas verdes son arcos, los nodos son los nodos de polilínea originales y
la línea roja son líneas rectas. Puedes enviarme polilíneas cerradas (dadas en
formato de una matriz de posiciones xy ordenadas) para probar el algoritmo.

—
Estás recibiendo esto porque fuiste asignado.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/alexrj/Slic3r/issues/23#issuecomment-350561807 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAB8Ch6ym1LE2VxV4hYYlpIGg-W2qSRNks5s_AyMgaJpZM4CPczH
.

La complejidad del espacio puede ser linealmente proporcional al número de nodos que introduzca, pero depende de usted. De hecho, puede usar más memoria para optimizar la complejidad del tiempo.
La complejidad del tiempo puede escalar exponencialmente con la cantidad de nodos (más o menos, no soy un estudiante de ingeniería informática, solo soy un estudiante multidisciplinario de física/industrial). Pero eso solo sucede con curvas ruidosas, si ingresa un dibujo mecánico de alta precisión, la parametrización se resuelve instantáneamente porque los arcos se detectan inmediatamente después del primer análisis.

@PurpleSensation como un trabajo para su información de @platsch también se envió a un documento.

Gracias, pido ayuda a los profesores, y he generalizado el algoritmo para rutas no cerradas, aquí algunos resultados:

Parece un poco extraño comenzar con STL que es lineal interpolado y luego tratar de volver a los círculos. ¿Hay un beneficio convincente para hacer esto?

Para dos segmentos de línea conectados cualesquiera, es bastante fácil encontrar el centro del círculo que incluye sus extremos (siempre que no sean degenerados). - Algo así como 10 multiplicaciones, 14 sumas y 2 divisiones.

Entonces, para cualquier ruta de extrusión, podría generar una serie de centros y luego agrupar segmentos si los centros consecutivos están lo suficientemente cerca entre sí y los segmentos son lo suficientemente cortos en relación con el radio. Supongo que también hay una verificación para asegurarse de que no esté girando más de un círculo completo y que la quiralidad sea consistente.

Este es el problema de STL: no puedes tener un círculo.
Las impresoras modernas admiten G2/G3, los arcos ya no sufren ningún defecto (arcos linealizados) y pueden ser más rápidos de hacer. gcode también es más ligero (solo 1 línea para hacer un arco, no docenas).

Para NateTG:

Lo de hacer un aritmético para esto es bastante más difícil que hacer lo que dices. No es mucho más difícil, pero debe ser capaz de demostrar matemáticamente que el algoritmo SIEMPRE encuentra una solución, que es óptima o semióptima y que se maneja bien con arcos colindantes o múltiples arcos radiales (lo cual no es trivial, pero está resuelto). También debe probar que coincide un cierto error colineal.

Lo de encontrar arcos y usar una trayectoria paramétrica en lugar de una polilineal es una ventaja porque necesitas menos movimientos de memoria en el procesador y puedes mantener una mejor precisión y sincronización de los motores. En las impresoras delta es habitual encontrar pequeñas burbujas en las impresiones por microparadas del extrusor. La velocidad de impresión también está limitada por el número de operaciones por segundo. (cuanto más rápido te mueves, menos densidad de polilíneas tiene tu trayectoria).

Solo voy a dejar esto por aquí:

https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php

Es un script escrito en php que:

1. recorre continuamente los comandos gcode, empujándolos a un búfer
2. comprueba si los puntos en el búfer se ven como un círculo dentro de una tolerancia
3. si los puntos ya no se ven como un círculo, vacíe el búfer y transforme [buffer - 1] en un arco gcode
4. ir al paso 1

Hace esto por:

1. encontrar el círculo que describe los puntos en el búfer usando mínimos cuadrados (ver https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L311)
2. calcular la distancia de error total entre cada línea y el círculo (ver https://github.com/manticorp/GCodeArcOptimiser/blob/master/functions.php#L359)
3. Si el error es menor que una cantidad predefinida, cree un arco gcode del círculo, sumando las extrusiones a lo largo de las longitudes de línea.

No sé si esto ayudará a alguien más con la esperanza de escribir un algoritmo para hacer esto, ¡pero ahí lo tienes! Funcionó bastante bien y obtuve algunas impresiones exitosas, ¡fue un poco lento en php!

... ¡fue un poco lento en php!

Parece que gran parte de ese "lento" tiene que ver con una implementación ineficiente. Estás haciendo algo que debería ser O (N) en O (N ^ 2) (u O (N ^ 4) para el algoritmo que no estás usando) al duplicar el esfuerzo.

Esas implementaciones funcionan bien en polilíneas que se comportan bien. Pero te aseguro (estoy investigando esto para un artículo) que las polilíneas ruidosas introducen muchas situaciones extrañas, como encontrar pequeños arcos que en realidad son parte de los más grandes si buscas otra combinación paramétrica. Si usa solo un algoritmo de anticipación, perderá soluciones óptimas en celosías ruidosas

Bueno, si hay una mejor manera de distinguir un círculo de una serie de líneas rectas que un algoritmo de ajuste, me encantaría escucharlo.

No pude pensar en una mejor manera que recorrer los datos y compararlos con los círculos de ajuste. Tiene límites incorporados que lo hacen mucho más rápido, por ejemplo, el búfer se llena en 100 puntos porque un ahorro de 1/100 en las instrucciones es suficiente para la mayoría de los usos.

Se ocupa bien de las líneas ruidosas, ya que utiliza un ajuste de mínimos cuadrados para afinar el círculo y, siempre que siga encontrando círculos que se ajusten al búfer dentro de una tolerancia, aproximará esos puntos a un círculo.

Si no están dentro de la tolerancia de un círculo, deben reemplazarse con un arco de código G.

Bueno, si hay una mejor manera de distinguir un círculo de una serie de líneas rectas que un algoritmo de ajuste, me encantaría escucharlo.

La forma en que se implementa en el script, si hay un arco con N segmentos, ejecuta getCircleCenterLeastSquares en un búfer de 1 y luego en un búfer de 2... hasta que es un búfer de N+1, por lo que itera sobre aproximadamente N^2 /2 segmentos.

Esto es aún peor con la función getCircleCenter porque se ejecuta alrededor de N^3/6 pasos, por lo que un arco de segmento N toma alrededor de N^4/24 iteraciones.

Si, en cambio, el algoritmo agrega gradualmente segmentos a un arco sin volver a calcular todo para cada nuevo segmento, eso puede suceder en N pasos. No estoy seguro de que haya una manera fácil de hacerlo con el enfoque de "mínimos cuadrados" que está utilizando.

Aun así, siempre que los arcos tiendan a venir en grupos de segmentos, un enfoque de búsqueda binaria es más rápido que uno incremental. La comprobación de los búferes de 1, 2, 4, 8, 16, 32, 64, 127, 96, 112, 104, 100, 102 y 101 se ejecuta a través del bucle en getCircleCenterLeastSquares unas 869 veces, mientras se pasa por 1,2,3 ...100 pasa por ese ciclo 5050 veces.

En realidad, busca documentos de interpolación paramétrica de G0 y encuentra otras formas de hacerlo. El caso es que primero puedes asignar un índice a cada punto que describa cuánto mide el arco en el que está incluido y luego comenzar la asignación desde el índice máximo, o intentar hacer ambas cosas al mismo tiempo. La pregunta es, ¿pierdes soluciones óptimas si haces la asignación antes de tener toda la información?

La idea de búsqueda binaria es buena, ya que las curvas generalmente tienen muchos puntos generados por el software de modelado.

Si se encuentra un búfer de 4 o 5, podría saltar directamente a números más altos.

Esto es teniendo en cuenta que muchos modelos no tienen muchos arcos. Un cubo, por ejemplo, pasaría por el algoritmo actual bastante rápido, ya que el búfer nunca superará los 3 puntos.

Supongo que todo se reduce a los ahorros de tiempo vs marea que desea. Podría tener un búfer máximo de 20 y aún así reducir las líneas de código G 20 veces en el mejor de los casos.

Mi motivación era permitir que mi impresora 3D funcionara a través de octoprint con arcos suaves, ya que la velocidad en baudios de la frambuesa pi significaba que mi impresora tartamudeaba mucho en los arcos; si pasaba un minuto ejecutando el código G a través del algoritmo th8s, era mejor que una impresión que falla después de 10 horas

Actualización: trabajo en progreso. El algoritmo es rápido y sólido, estoy a punto de comenzar a escribir el artículo que se publicará. El proceso se realiza por varios métodos, incluido uno incremental (el más rápido pero el que tiene peores soluciones).

Figura a) -> Error colineal de 0,1 mm, 20 % del peso original.
Figura b) -> Error colineal de 0,05 mm, 26 % del peso original.
Figura c) -> Error colineal de 0,01 mm, 40 % del peso original.
Figura d) -> Error colineal de 0,005 mm, 51% del peso original.

La figura a) se aproxima a la solución incremental de varias maneras (como puedes ver, los arcos superpuestos no se resuelven manteniendo la simetría).

300 de ellos tardan unos 25 segundos en ser procesados. Este número puede volverse más pequeño con la implementación de paralelismo, gpu, etc.

Actualización: el método es perfectamente implementable en este momento:

Una pieza completa de 500 capas como la última que se muestra se procesa en aproximadamente 10 segundos sin ninguna heurística y se ejecuta en MATLAB.

@PurpleSensation entonces, ¿cuándo debo reservar tiempo para revisar una solicitud de extracción?

Ni idea hermano xD. Esto ya es implementable, pero probablemente debería esperar hasta la presentación del documento. Además, no tengo idea sobre la implementación de c ++, esto está completamente implementado en MatLab y estoy seguro de que no sería un buen ingeniero de software. Trataré de obtener una compilación modular plug and play c++.

Una opción sería que alguien lo mirara bajo un NDA o similar para ver cuánto trabajo sería convertir de Matlab a C ++... ¿Está confiando mucho en las bibliotecas de Matlab por conveniencia o velocidad? ¿O es todo matemática básica en código normal?

AFAIK Matlab tiene al menos un compilador para convertirlo en código C independiente (solo lo leo porque nunca he usado Matlab). Sin embargo, no tengo idea si se debe comprar por separado o si está incluido en la licencia predeterminada. Esto al menos ya estaría mucho más cerca de C ++.

Si está hablando de la solución con la que estoy familiarizado, no funcionará, ya que ese enfoque incrustará el script en una biblioteca que contiene (parte de) el motor Matlab, además de un código auxiliar C que se puede usar para vincular contra la biblioteca . Será grande, no portátil y no distribuible.

Solo tengo información de segunda mano, pero al menos quería tenerla documentada aquí, incluso solo por haber sido rechazada. :-)

@purplesensation si quisiera, podría enviarme en privado una copia anticipada del artículo y el guión básico y puedo esbozar el algoritmo en C++.

Estoy muy familiarizado con el proceso de publicación académica. :)

Obviamente, cuán cómodo te sientes con eso es un factor.

¡Este software se ve muy bien para hacer arcos y quiero probarlo lo antes posible!

¿Es posible crear un ejecutable a partir del archivo MATLAB que pueda tomar una
GCODE generado por Slicer y procesar el GCODE para cambiar las líneas en
arcos? Eso sería un software separado, pero al menos permitiría que más
la gente lo prueba y lo prueba.

Si compila como un ejecutable, no necesita preocuparse por el código
siendo copiado/robado y otros pueden intentarlo mientras tanto....

El jueves 14 de junio de 2018 a las 8:06 a. m., Manuel [email protected] escribió:

solo tengo informacion de segunda mano pero al menos queria tenerla
documentado aquí, incluso solo por ser rechazado. :-)

—
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/slic3r/Slic3r/issues/23#issuecomment-397288841 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AJ2tvqINaxvNnhhnfj0e4bK0XPDTzwwYks5t8l_IgaJpZM4CPczH
.

Mientras el algoritmo no se publique, no lo empaquetaría usando Matlab, estoy bastante seguro de que se puede extraer mucho de la biblioteca C. Lo que no significa que no me gustaría verlo terminar pronto en una herramienta como Slic3r, pero solo como una advertencia justa :)

@lordofhyphens Vale, revisa tu correo electrónico.

@PurpleSensation ¿Me permite compartir este documento con un estudiante de GSoC (entendiendo que no se compartirá más allá de eso)?

Sí, sólo dame unas horas. Ahora mismo estoy aplicando algunas correcciones importantes que lo hacen mucho más comprensible (el inglés y las matemáticas). Voy a reenviar a su correo electrónico.

@PurpleSensation Gracias.

@TheThirdOne está implementando la heurística del artículo escrito por @PurpleSensation en las últimas semanas de GSoC 2018.

@manticorp , agradecería su disponibilidad para imprimirlo y probarlo una vez que se haya fusionado;)

@lordofhyphens seguro que no te preocupes!

@lordofhyphens No dude en ponerse en contacto conmigo para cualquier conversación directa sobre el tema.

@manticorp Señale que el firmware de la impresora debería haber implementado el comando G3 arcs.

@PurpleSensation Le he dicho lo mismo a @TheThirdOne.

@PurpleSensation Creo que el mío sí: lo hizo en mis pruebas, lo difícil fue obtener las cantidades de extrusión exactamente después de igualar la curva

Algunas partes del método pueden tomar mucho tiempo para ser implementadas. Se pueden sustituir por aproximaciones simplistas (y perfectamente funcionales). por ejemplo, el procesamiento posterior del arco se puede realizar simplemente mediante un ajuste de arco de tres puntos.
Probablemente la mejor idea es comenzar aplicando el método a los perímetros debido a su forma orgánica habitual. Debería funcionar perfectamente si se aplica en cada trayectoria, pero no sé.

He hecho un buen progreso para implementar esto según lo guiado por el artículo de @PurpleSensation . Actualmente está funcionando la detección de posibles intervalos en los que las líneas podrían reemplazarse por un arco. Tengo un algoritmo codicioso temporal para elegir cuál de los intervalos elegir. Actualmente estoy trabajando para hacer que la salida sea continua y, de hecho, emita arcos.

@TheThirdOne Estoy a punto de enviar una versión definitiva del documento, ha cambiado mucho y ahora es mucho más comprensible. Si quieres te lo puedo enviar, solo necesito una dirección de correo electrónico. Además, si necesita charlar para aclarar cosas en papel, no tendría ningún problema.

@PurpleSensation Háganos saber cuándo se hace público y cómo podemos comprarlo/obtenerlo.

@PurpleSensation , lo que es más importante, agregaré la cita a los comentarios cuando se publique.

Puedes enviármelo y yo también puedo reenviarlo a @thethirdone .

@mamoit erudito.google.com mostraría el título del artículo y dónde está publicado.

No creo que haya ningún apoyo financiero para @PurpleSensation comprando una copia del número de la revista o del artículo en el que llega.

Probablemente también pasarán meses antes de que se publique.

@purplesensation una cosa que ayudaría, creo, es verificar que las pruebas escritas por @thethirdone sean correctas (es decir, dado que A, B es la salida)

Voy a enviar a ArXiv por lo que si se acepta no debería tomar mucho tiempo. Mi único problema en este momento es mi falta de afiliación a alguna Institución (que comúnmente se pregunta). ArXiv proporciona una versión temporal del documento, por lo que debería estar disponible en unos días. @lordofhyphens no hay problema con la verificación, incluso espero compartir el código de MATLAB en mathworks

@TheThirdOne para tu información https://en.wikipedia.org/wiki/G-code#I cuando llegas a la generación de gcode.

El centro cuando se usa I/J/K es un desplazamiento relativo de la posición actual.

Hice un intento de implementar la generación GCode para esto como un filtro. La implementación de perl da una idea bastante buena de cómo debería verse, pero se aplica a todo en una capa. Parece que el ajuste del arco probablemente no tiene sentido con el soporte, y solo tiene sentido con un relleno diseñado específicamente.

Iba a preguntar si había una buena forma de detectar si una línea era de relleno o perimetral, pero mientras escribía esto me di cuenta de que solo puedo filtrar antes por perímetro.

También investigué un poco sobre no analizar y regenerar gcode. Como era de esperar, requiere tocar un montón de clases diferentes para agregar soporte de arco. No parece una solución limpia, particularmente con la realización anterior.

Aquí está el artículo: Parametrización de trayectorias NC definidas por polilíneas.

Estoy a punto de cargar la implementación del código en MatLab, debería ayudar.
@TheThirdOne El relleno podría filtrarse un poco usando los parámetros de control del método. Obligar a cada par de puntos consecutivos dentro de cualquier arco a tener una distancia máxima entre ellos puede evitar la generación de arcos en los rellenos de línea y otras cosas. Probablemente 0,5 mm sea un buen requisito.

¿No hay ninguna etapa en el proceso de corte en la que tenga una descripción de nodo sin procesar del proceso de impresión? Partir de eso podría ser más fácil que deconstruir el GCode.

@purplesensation lo mejor que tenemos son las polilíneas que forman las superficies en PrintGcode.cpp.

@thethirdone sube tus actualizaciones a tu bifurcación y puedo echar un vistazo más de cerca.

@PurpleSensation , tengo una pregunta sobre el papel. ¿Cómo se garantiza 4a? 3.1 solo parece garantizar que ningún intervalo sea un subconjunto de otro.

@TheThirdOne Tienes razón. La condición de no trabajar con intervalos incluidos en la unión de otros dos intervalos se tiene en cuenta en la búsqueda de intersecciones. Intentaré explicarme mejor:
Mire el Listado 2 en 3.3. Cuando analiza un intervalo (llámelo A) para encontrar intersecciones a su derecha, básicamente busca otros intervalos que comiencen desde el interior de A y mantenga el que alcanza una mayor distancia en su final (llame a este intervalo seleccionado B). Con este comportamiento estás descartando todos los intervalos contenidos en la unión de A y B.

Ese es un punto difícil de describir. Estaba esperando la pregunta.

Aquí está el código
Aproximación de polilíneas con arcos y segmentos.

Tengo una implementación completa además de la configuración y solo tengo un controlador de intersección codicioso simple. Es posible que haya algunos problemas importantes con la interfaz de GCode, ya que todavía no se ha probado.

¿Cifras de @TheThirdOne ? ¿Quieres enviarme una polilínea para comparar?

Aquí tienes una cápsula de código publicada. Con una cuenta puede ejecutar, editar y revisar el código. Hay una interfaz para el ajuste de parámetros.

https://codeocean.com/2018/09/07/aproximacion-de-polilineas-con-arcos-y-segmentos/codigo

Estoy trabajando en un plotter de arco real eficiente en el firmware de mi impresora 3D. Este es un buen momento. :+1:

@phord Eso es genial, sigo trabajando en el reconocimiento. ¿Quieres algunas muestras para probar tu trabajo? Podría proporcionar códigos g de 1 capa para intentarlo. @TheThirdOne ¿Cómo te va?

@PurpleSensation Claro. ¿Pueden enviarme versiones de arco y no arco del mismo archivo? De esa manera puedo comparar para asegurarme de que estamos interpretando las cosas de la misma manera.

En eso, ¿emite arcos con centro I, J o con radio R? Planeo admitir ambos, pero me pregunto qué tan útil es R, realmente.

@phord Tendría que comenzar a trabajar en un script de generación de gcode primitivo, es un trabajo fácil. Puedo implementar ambos, trabajo fácil. ¿Vas a usar un bolígrafo para la impresión monocapa o quieres que agregue extrusión? No sé las matemáticas sobre la inercia de extrusión y esas cosas.

No hay necesidad de extrusión; Empezaré por simularlo. Pensé que estabas trabajando en alguna conversión del código g existente para agregar arcos, ¿verdad? Así que pensé que tendrías ambos en tus pruebas. ¿Quiere que le envíe un código g lineal con muchos arcos para convertir? Tengo algunos. :-D

https://gist.githubusercontent.com/phord/02c87e5c60c744f3998c7ee3cde0a419/raw/6611c6e7eaef8f803467f82e744bf1c1373babd7/Pure2-lego.gcode

Este código g tiene muchos arcos, pero están cortados con pequeñas facetas. Otros pueden usar menos facetas y también podrían ser buenos casos de prueba.

Oh ya veo. Fue @TheThirdOne quien está trabajando en las conversiones de código g. Perdón por confundirlos a ustedes dos.

@PurpleSensation , he estado ocupado con otras cosas por un tiempo. He querido hacer algo de tiempo para retomar esto.

@phord eche un vistazo a la cápsula de código https://codeocean.com/2018/09/07/polyline-approximation-with-arcs-and-segments/code.

Con muy pequeños ajustes, puede modificar la secuencia de comandos de formato (dentro de la secuencia de comandos FitPolyline) para escribir instrucciones gcode. Eventualmente lo haré, pero ahora mismo estoy ocupado con el curso inicial.

todo esto suena interesante y estaba buscando g2 g3 en una cortadora. También descubrí que es clave detectar arcos en un entorno de polilínea (stl) antes de que se confirmara en esta publicación. Pensaría en una forma de saber si 3 líneas consecutivas comparten un radio tangencial común y tienen aproximadamente la misma longitud, ¿podría ser un arco? pero ¿cómo podría calcularse esto?

También sugeriría que las rutas o el segmento de la ruta (líneas) se puedan seleccionar y "etiquetar como arco" para que la cortadora tenga más información sobre dónde g2/g3.

@leozolt hay una rama en la bifurcación @TheThirdOne GitHub donde se estaba haciendo el trabajo para ingresarlo a Slic3r.

¿Existe un formato de archivo que slic3r pueda usar para comunicar 3D con arcos? stl son líneas solo si recuerdo bien.

@leozolt no, por eso se solicitó el trabajo de @PurpleSensation .

Si alguien quiere construir un reemplazo para TriangleMesh y el código basado en Polygon relacionado para poder usar STEP o algo relacionado.

No tengo tiempo para codificar la cosa en slic3r, pero conozco a alguien que podría serlo. Se lo diré. ¿Qué debo explicarle? No conozco la estructura de slic3r. ¿Sería esto un script de procesamiento posterior?

@PurpleSensation sería una extensión de https://github.com/slic3r/Slic3r/blob/master/xs/src/libslic3r/PrintGCode.cpp muy probablemente.

https://github.com/TheThirdOne/Slic3r/tree/arc-fitting es probablemente una buena línea de base inicial (eche un vistazo a estos archivos tocados en esa rama), y espero que las autopruebas se escriban de acuerdo con las expectativas de cómo funcionaría el ajustador de arco para algunas geometrías de ejemplo.

Hola
He estado trabajando en un detector de curvas gcode para implementar arcos de código G2 y G3 durante un tiempo, y parece estar funcionando muy bien y deja de tartamudear por completo a través de USB.
Un ejemplo del cambio que puede hacer:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.84105
G1 X117.874 Y63.038 E5.94500
G1 X118.846 Y63.205 E6.05141
G1 X119.789 Y63.405 E6.15536
G1 X120.745 Y63.645 E6.26177
G1 X121.670 Y63.915 E6.36572
G1 X122.606 Y64.226 E6.47213
G1 X123.508 Y64.565 E6.57608
G1 X124.417 Y64.947 E6.68248
G1 X125.290 Y65.353 E6.78644
G1 X126.168 Y65.803 E6.89284
G1 X127.009 Y66.274 E6.99679
G1 X127.850 Y66.788 E7.10320
G1 X128.652 Y67.322 E7.20716
G1 X129.452 Y67.898 E7.31356
G1 X130.212 Y68.491 E7.41751
G1 X130.966 Y69.126 E7.52392
G1 X131.679 Y69.775 E7.62787
G1 X132.383 Y70.465 E7.73428
G1 X133.044 Y71.166 E7.83823
G1 X133.507 Y71.694 E7.91402
G1 X134.301 Y72.656 E8.04857
G1 X134.892 Y73.445 E8.15498
G1 X135.441 Y74.237 E8.25893
G1 X135.971 Y75.068 E8.36534
G1 X136.458 Y75.900 E8.46929
G1 X136.924 Y76.769 E8.57570
G1 X137.347 Y77.635 E8.67964
G1 X137.746 Y78.537 E8.78605
G1 X138.102 Y79.432 E8.89001
G1 X138.431 Y80.361 E8.99641
G1 X138.718 Y81.281 E9.10036
G1 X138.977 Y82.233 E9.20677
G1 X139.194 Y83.171 E9.31072
G1 X139.379 Y84.140 E9.41713
G1 X139.524 Y85.092 E9.52108
G1 X139.636 Y86.072 E9.62749
G1 X139.709 Y87.033 E9.73144
G1 X139.746 Y88.018 E9.83784
G1 X139.746 Y88.982 E9.94180
G1 X139.709 Y89.967 E10.04821
G1 X139.636 Y90.928 E10.15215
G1 X139.524 Y91.908 E10.25856
G1 X139.379 Y92.860 E10.36252
G1 X139.194 Y93.829 E10.46892
G1 X138.977 Y94.767 E10.57287
G1 X138.718 Y95.719 E10.67928
G1 X138.431 Y96.639 E10.78323
G1 X138.102 Y97.568 E10.88964
G1 X137.746 Y98.463 E10.99359
G1 X137.347 Y99.365 E11.10000
G1 X136.924 Y100.231 E11.20395
G1 X136.458 Y101.100 E11.31036
G1 X135.971 Y101.932 E11.41431
G1 X135.441 Y102.763 E11.52072
G1 X134.892 Y103.555 E11.62466
G1 X134.301 Y104.344 E11.73107
G1 X133.694 Y105.092 E11.83503
G1 X133.044 Y105.834 E11.94143
G1 X132.383 Y106.535 E12.04538
G1 X131.679 Y107.225 E12.15179
G1 X130.966 Y107.874 E12.25574
G1 X130.212 Y108.509 E12.36215
G1 X129.452 Y109.102 E12.46610
G1 X128.652 Y109.678 E12.57250
G1 X127.850 Y110.212 E12.67646
G1 X127.009 Y110.726 E12.78287
G1 X126.168 Y111.197 E12.88682
G1 X125.290 Y111.647 E12.99322
G1 X124.417 Y112.053 E13.09718
G1 X123.508 Y112.435 E13.20358
G1 X122.606 Y112.774 E13.30754
G1 X121.670 Y113.085 E13.41394
G1 X120.745 Y113.355 E13.51789
G1 X119.789 Y113.595 E13.62430
G1 X118.846 Y113.795 E13.72825
G1 X117.874 Y113.962 E13.83466
G1 X116.919 Y114.089 E13.93861
G1 X115.938 Y114.182 E14.04502
G1 X114.976 Y114.237 E14.14897
G1 X113.990 Y114.255 E14.25538
G1 X113.026 Y114.237 E14.35933
G1 X112.042 Y114.181 E14.46573
G1 X111.083 Y114.090 E14.56969
G1 X110.105 Y113.960 E14.67609
G1 X109.156 Y113.797 E14.78004
G1 X108.191 Y113.593 E14.88645
G1 X107.256 Y113.358 E14.99040
G1 X106.310 Y113.082 E15.09681
G1 X105.396 Y112.777 E15.20076
G1 X104.738 Y112.530 E15.27655
G1 X103.584 Y112.057 E15.41110
G1 X102.690 Y111.642 E15.51751
G1 X101.832 Y111.203 E15.62146
G1 X100.972 Y110.720 E15.72787
G1 X100.150 Y110.218 E15.83182
G1 X99.329 Y109.672 E15.93822
G1 X98.547 Y109.108 E16.04218
G1 X97.770 Y108.502 E16.14859
G1 X97.033 Y107.881 E16.25254
G1 X96.304 Y107.218 E16.35895
G1 X95.616 Y106.543 E16.46289
G1 X95.134 Y106.032 E16.53868
G1 X94.304 Y105.101 E16.67324
G1 X93.683 Y104.335 E16.77964
G1 X93.105 Y103.564 E16.88359
G1 X92.543 Y102.754 E16.99000
G1 X92.025 Y101.941 E17.09395
G1 X91.670 Y101.335 E17.16974
G1 X91.072 Y100.241 E17.30430
G1 X90.639 Y99.355 E17.41070
G1 X90.249 Y98.474 E17.51465
G1 X89.885 Y97.558 E17.62106
G1 X89.563 Y96.649 E17.72501
G1 X89.269 Y95.708 E17.83142
G1 X89.017 Y94.778 E17.93537
G1 X88.795 Y93.818 E18.04178
G1 X88.614 Y92.871 E18.14573
G1 X88.465 Y91.896 E18.25214
G1 X88.356 Y90.939 E18.35609
G1 X88.281 Y89.956 E18.46250
G1 X88.245 Y88.993 E18.56645
G1 X88.245 Y88.007 E18.67285
G1 X88.281 Y87.044 E18.77680
G1 X88.356 Y86.061 E18.88322
G1 X88.465 Y85.104 E18.98716
G1 X88.571 Y84.409 E19.06295
G1 X88.795 Y83.183 E19.19750
G1 X89.017 Y82.222 E19.30392
G1 X89.269 Y81.292 E19.40786
G1 X89.563 Y80.351 E19.51427
G1 X89.885 Y79.442 E19.61822
G1 X90.249 Y78.526 E19.72463
G1 X90.639 Y77.645 E19.82858
G1 X91.072 Y76.759 E19.93499
G1 X91.527 Y75.910 E20.03894
G1 X92.025 Y75.059 E20.14535
G1 X92.543 Y74.246 E20.24930
G1 X93.105 Y73.436 E20.35570
G1 X93.651 Y72.707 E20.45399
G1 E17.45399 F12000.00000

se convierte en:
G1 X115.938 Y62.818 E5.73464 F1200.000
G1 X116.919 Y62.911 E5.841
G3 X93.651 Y72.707 I-2.924 J25.589 E20.454
G1 E17.45399 F12000.00000

Si está interesado en el código, puedo subirlo a GitHub si lo desea (aunque es bastante crudo en este momento, parece hacer el trabajo).

Hola,

Estoy muy interesado en su convertidor G1 a G2/G3. Lamentablemente no puedo ejecutarlo.

¿Es correcta mi forma de ejecutar el software?
Tomo index.php y lo arrastro y lo suelto en Firefox.

Ahora tengo una página que me pide que busque un archivo .gcode.
Selecciono mi GCODE del HDD y hago clic en Enviar.

Ahora me vuelve a pedir que busque un archivo GCODE.

¿Qué estoy haciendo mal? No obtengo un archivo convertido.

Saludos desde Alemania

¿Tuviste suerte hasta ahora de obtener el soporte ARC adecuado 9 años después? Estoy de acuerdo en que mejoraría muchas impresiones.

Creo que el soporte de arco necesita una aceleración de curva s adecuada para tener buenos resultados, lo que debe resultar en chips más fuertes. Sé que está fuera de tema, pero el soporte de arco en combinación con movimientos de impresión 3D no planos debe ser el siguiente nivel en unos pocos años para las impresoras fdm.
Me gustaría tener algunas ideas más sobre esto, comencemos una discusión.
Sin embargo, ¿qué motor de una cortadora existente sería la mejor base para comenzar una implementación de este tipo? Hay un tema en el proyecto cura donde uno de los desarrolladores dijo que tendrían que rediseñar todo el motor; está diseñado para trabajar capa por capa.

Hola, llevo varios años trabajando en el tema de forma profesional. La segmentación 3D ya existe, solo necesitamos que alguien haga una implementación. Lamentablemente, no puedo encargarme de esa tarea por estar demasiado ocupado, pero puedo ayudar con los algoritmos.

reviviendo

La pregunta es: ¿Cómo se implementaría tal característica (en el núcleo principal o como programa externo/biblioteca/complemento/....) y cuáles son los ingredientes? Una cosa es, por supuesto, la detección del arco desde la perspectiva matemática/algorítmica. Lo segundo es cómo conectar cosas en Slic3r. ¿Puede alguien implementar este soporte de uso del equipo de desarrollo principal (por ejemplo, cómo integrarse en el resto del sistema)?

@PurpleSensation ¿Qué tendría que implementarse? Si las cosas son algo confidenciales, puede encontrar una dirección de correo en mi perfil de Github. Me gustaría echar un vistazo rápido a las cosas si pudiera ayudar aquí un poco.

Mmmmmm definitivamente no soy un ingeniero de software, y tengo poca idea de cómo integrar esto en el núcleo principal. Lo ideal sería codificar los métodos en un nivel bajo y no como una cosa de procesamiento posterior, pero esa es una posibilidad. Alguien que se meta en la experimentación es todo lo que necesitamos. Puedo proporcionar los algoritmos codificados en python/MATLAB. El primer enfoque sería aplicar solo en los perímetros.

Soy capaz tanto de Mathlab como de C++. Entonces, mi opinión personal es que sería mejor seguir este camino: volver a implementar el algoritmo propuesto como una "biblioteca" en C++. Esto permite realizar pruebas y todas las cosas sofisticadas. Como los archivos STL son solo poliedros/politopos. Entonces, la información del arco ya se perdió durante la conversión de CAD a STL. Por lo tanto, sería mejor trabajar en cada capa de forma independiente para detectar cualquier arco.
Un segundo paso sería implementar esto en la GUI y hacer que la funcionalidad sea utilizada por Slic3r.

Para mi propia referencia ver aquí .

Entiendo tu punto. Este próximo año podría tener algo de tiempo extra para trabajar en esto (además, necesito una impresora nueva porque mi delta hecha por mí mismo está en pésimas condiciones). Si alguien (como usted) quiere mi asistencia directa y el código original, estoy más que complacido. Además, dado que estoy trabajando con C ++ en este momento para mi doctorado, es posible que yo mismo construya esa biblioteca. Espero que este problema se lleve adelante.

@christianlupus, el trabajo realizado por @PurpleSensation involucró un algoritmo para ajustar curvas en 2d.

Ver GCode.cpp en libslic3r. Slic3r tiene todos los polígonos ya presentes en cada capa (y cada capa se realiza en paralelo) tal como se lee en el modelo 3D como ExtrusionEntities.

La última vez que lo miré, fue más trabajo del que estaba dispuesto a realizar (especialmente porque quiero pruebas reproducibles), y todavía hay algunas conjeturas relacionadas con la cláusula de rescisión.

Mis pensamientos al respecto fueron implementarlo en GCodeWriter (uso inmediato) o detectar los arcos de los polígonos incrustados de ExtrusionEntities y extender Polyline, etc. para almacenar la información del arco para su posterior procesamiento con GCodeWriter.

La salida SVG es probablemente un buen lugar para comenzar, para ser honesto, ya que le dará una representación más clara de cómo lo ve Slic3r (y ese código tiene menos que hacer).

Cualquier prueba que escriba puede probarla en libslic3r, sin necesidad de reinventar sus primitivas.

@FormerLurker está trabajando en https://github.com/FormerLurker/ArcWelderPlugin , un complemento de Octoprint que posprocesa los archivos cargados para generar arcos; creo que el algoritmo central ya está en C, por lo que podría ser factible transferir el código.

@floppy , la versión de consola ya se puede usar como posprocesador, para tu información.

@Floppy , también, es posible que desee ver ArcWelderLib , que contiene la aplicación de la consola y varios scripts CMake (no verificados en todos los sistemas operativos). Tengo algunos compromisos para impulsar que mantengan la coherencia entre mayúsculas y minúsculas y formato, que impulsaré en los próximos días.