Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
¿Algún fileteador que trabaje con interpolaciones circulares?
#1
Buenas.

Estoy ahora probando a hacer piezas un poco más complejas y se me generan programas de más de doscientas mil líneas. Y ya me pasó dos veces de estar imprimiendo varias horas y que en un momento dado pare la impresión y haga un G28.

Revisando el código no aparece esa G en ese momento, solo al inicio y la final, y parece estar generado hasta el final, la última Z coincide con la teórica. Y simulándolo me genera la figura completa.

Lo achaco, quizá erróneamente a programas demasiado largos para la impresora y que en determinado punto no da más de si. Así que buscaba un CAM que generase G2 y G3 para que el código quedase más limpio. ¿Hay de eso?

resim
Citar
#2
No será problema de procesamiento o traspaso de gcode? Quizás se satura el buffer y reinicia. Deberías comentar que electronica usas y como manejas la impresión
Citar
#3
De todos los slic3r que he usado, ninguno incluye esa opción.. y si la incluyese, probablemente es algo experimental. Los Slic3r generan unicamente g0 y g1 para su movimiento (Que realmente al firmware le da igual un g0 o un g1... no los diferencia), haciendo así muchas trayectorias rectas pequeñitas para realizar las curvas.

Marlin por lo visto tiene soporte para los comandos g2 y g3, aunque ni idea de si es recomendable utilizarlos o están libres de posibles errores... todavía no he sabido de nadie que utilizase estos comandos en una impresión. Por lo que he leido por ahí hace tiempo, parece que el simplify3d permite generar código con g2 y g3, pero comentan que ejecutar estes códigos es un poco cargante para el arduino (Normal, ningún microcontrolador se lleva bien con operaciones que requieran cálculos de senos, cosenos, tangentes... etc, les lleva mucho tiempo calcular los resultados)
Por otro lado, por lo que tengo entendido, a ciertos, si no todos los slicer les cuesta determinar con que tipo de código generar la trayectoria... tengamos en cuenta que actualmente utilizamos STLs, que son ficheros basados en superficies triangulares, ya de por si en programas de edicion 3D tener un stl es una guarrada pues es complicada su edición, más aun el reconocimiento de operaciones o curvas, si la pieza es cilindrica... el slic3r deberia de determinar si ese conjunto de lineas juntas que hay equivale a una curva y además realizarla sin añadir material a más... teniendo en cuenta que los círculos en stl no son círculos, es difícil.

Si descubres como va, estaria bien que lo comentases pues podria ser interesante tener a mano algún slic3r con esta capacidad... es mas, yo habia hecho un interprete de gcode para un proyecto que tenia y echaba en falta los movimientos circulares... ahí es cuando descubrí que nunca se generaban estos comandos con fileteadores como cura o slic3r.
Citar
#4
(23-07-2017, 07:06 PM)PrimeraRata escribió: No será problema de procesamiento o traspaso de gcode? Quizás se satura el buffer y reinicia. Deberías comentar que electronica usas y como manejas la impresión

La placa es una Arduino Mega 2560.

(23-07-2017, 09:42 PM)Shellmer escribió: De todos los slic3r que he usado, ninguno incluye esa opción.. y si la incluyese, probablemente es algo experimental. Los Slic3r generan unicamente g0 y g1 para su movimiento (Que realmente al firmware le da igual un g0 o un g1... no los diferencia), haciendo así muchas trayectorias rectas pequeñitas para realizar las curvas.

Marlin por lo visto tiene soporte para los comandos g2 y g3, aunque ni idea de si es recomendable utilizarlos o están libres de posibles errores... todavía no he sabido de nadie que utilizase estos comandos en una impresión.  Por lo que he leido por ahí hace tiempo, parece que el simplify3d permite generar código con g2 y g3, pero comentan que ejecutar estes códigos es un poco cargante para el arduino (Normal, ningún microcontrolador se lleva bien con operaciones que requieran cálculos de senos, cosenos, tangentes... etc, les lleva mucho tiempo calcular los resultados)
Por otro lado, por lo que tengo entendido, a ciertos, si no todos los slicer les cuesta determinar con que tipo de código generar la trayectoria... tengamos en cuenta que actualmente utilizamos STLs, que son ficheros basados en superficies triangulares, ya de por si en programas de edicion 3D tener un stl es una guarrada pues es complicada su edición, más aun el reconocimiento de operaciones o curvas, si la pieza es cilindrica... el slic3r deberia de determinar si ese conjunto de lineas juntas que hay equivale a una curva y además realizarla sin añadir material a más... teniendo en cuenta que los círculos en stl no son círculos, es difícil.

Si  descubres como va, estaria bien que lo comentases pues podria ser interesante tener a mano algún slic3r con esta capacidad... es mas, yo habia hecho un interprete de gcode para un proyecto que tenia y echaba en falta los movimientos circulares... ahí es cuando descubrí que nunca se generaban estos comandos con fileteadores como cura o slic3r.

Las interpolaciones circulares dan muchos menos errores, además de no ser necesario ajustar la tolerancia para hacer los perfiles perfectos, y a la electrónica no le cuesta, el código tiene casi 70 años y desde el inicio existieron las interpolaciones circulares, ejecutadas con lógica cableada... la electrónica de los equipos da para ello. He usado máquinas con Fagor 8010 en las que ejecutábamos algunos programas con CAM moderno (PowerMill 2016) usando como memoria un PC conectado por puerto serie porque la memoria de 256kb de la máquina no daba para más... y tiraba sin problema. 

También probé a generar a mano algún programa y los ejecuta bien, las interpolaciones circulares van sin problema, lo malo es que no puedo parametrizarlos para hacer viable la progrtmación, escribir todo a mano es un coñazo y es muy fácil meter la pata. Probé con los parámetros estándar del ISO, con los P, pero me da error, no me los reconoce, por lo que tampoco se si las sentencias de comparación, las condicionales y los saltos me las acepta.

Y tienes razón con los STL´s difícilmente se puede hacer, de hecho se me antoja imposible. Quizá ajustando un postprocesador de un CAM convencional se podría hacer, alguno que trabajase con formatos de Catia, Solid o Autodesk, pero se me antoja una tarea titánica... y desde mi conocimiento la generación de rellenos sería poco menos que imposible.

resim
Citar
#5
(24-07-2017, 03:06 AM)Fendetestas escribió:
(23-07-2017, 07:06 PM)PrimeraRata escribió: No será problema de procesamiento o traspaso de gcode? Quizás se satura el buffer y reinicia. Deberías comentar que electronica usas y como manejas la impresión

La placa es una Arduino Mega 2560.

(23-07-2017, 09:42 PM)Shellmer escribió: De todos los slic3r que he usado, ninguno incluye esa opción.. y si la incluyese, probablemente es algo experimental. Los Slic3r generan unicamente g0 y g1 para su movimiento (Que realmente al firmware le da igual un g0 o un g1... no los diferencia), haciendo así muchas trayectorias rectas pequeñitas para realizar las curvas.

Marlin por lo visto tiene soporte para los comandos g2 y g3, aunque ni idea de si es recomendable utilizarlos o están libres de posibles errores... todavía no he sabido de nadie que utilizase estos comandos en una impresión.  Por lo que he leido por ahí hace tiempo, parece que el simplify3d permite generar código con g2 y g3, pero comentan que ejecutar estes códigos es un poco cargante para el arduino (Normal, ningún microcontrolador se lleva bien con operaciones que requieran cálculos de senos, cosenos, tangentes... etc, les lleva mucho tiempo calcular los resultados)
Por otro lado, por lo que tengo entendido, a ciertos, si no todos los slicer les cuesta determinar con que tipo de código generar la trayectoria... tengamos en cuenta que actualmente utilizamos STLs, que son ficheros basados en superficies triangulares, ya de por si en programas de edicion 3D tener un stl es una guarrada pues es complicada su edición, más aun el reconocimiento de operaciones o curvas, si la pieza es cilindrica... el slic3r deberia de determinar si ese conjunto de lineas juntas que hay equivale a una curva y además realizarla sin añadir material a más... teniendo en cuenta que los círculos en stl no son círculos, es difícil.

Si  descubres como va, estaria bien que lo comentases pues podria ser interesante tener a mano algún slic3r con esta capacidad... es mas, yo habia hecho un interprete de gcode para un proyecto que tenia y echaba en falta los movimientos circulares... ahí es cuando descubrí que nunca se generaban estos comandos con fileteadores como cura o slic3r.

Las interpolaciones circulares dan muchos menos errores, además de no ser necesario ajustar la tolerancia para hacer los perfiles perfectos, y a la electrónica no le cuesta, el código tiene casi 70 años y desde el inicio existieron las interpolaciones circulares, ejecutadas con lógica cableada... la electrónica de los equipos da para ello. He usado máquinas con Fagor 8010 en las que ejecutábamos algunos programas con CAM moderno (PowerMill 2016) usando como memoria un PC conectado por puerto serie porque la memoria de 256kb de la máquina no daba para más... y tiraba sin problema. 

También probé a generar a mano algún programa y los ejecuta bien, las interpolaciones circulares van sin problema, lo malo es que no puedo parametrizarlos para hacer viable la progrtmación, escribir todo a mano es un coñazo y es muy fácil meter la pata. Probé con los parámetros estándar del ISO, con los P, pero me da error, no me los reconoce, por lo que tampoco se si las sentencias de comparación, las condicionales y los saltos me las acepta.

Y tienes razón con los STL´s difícilmente se puede hacer, de hecho se me antoja imposible. Quizá ajustando un postprocesador de un CAM convencional se podría hacer, alguno que trabajase con formatos de Catia, Solid o Autodesk, pero se me antoja una tarea titánica... y desde mi conocimiento la generación de rellenos sería poco menos que imposible.

como te dicen, te quedas sin memoria...

vas a necesitar cambiar a una electronica de 32 bits, como la mks base 1.4

saludos
Citar
#6
La otra opción, aunque aparatosa, es que imprimas a través de un portátil o bien pilles una raspberry y le metas ahí el Slic3r (Si es que se puede... que supongo que si), y que te vaya enviando los gcode poco a poco a la impresora. Teniendo en cuenta que te tiras horas y horas imprimiendo, puede que lo del portatil no te sea comodo... yo imprimo siempre desde portatil, pero tampoco lo necesito mientras imprimo.

La cantidad de lineas de código generadas también proviene del nivel de detalle del STL, puede que estés utilizando un stl con demasiadas facetas y se te genere demasiado código, una forma de hacerlo más ligero seria reducir el nivel de detalle del STL y por tanto, reduciendo las instrucciones generadas. Puede que notes algún cambio en la calidad... o puede que no.
Citar
#7
Nunca comento si el problema es imprimiendo por USB o sd. Si es por USB no le sirve de nada lo que dijiste. Además de que no puede meter el slicer ahi, debería usar repetier server o alguno similar
Citar
#8
(24-07-2017, 08:30 AM)Shellmer escribió: La otra opción, aunque aparatosa, es que imprimas a través de un portátil o bien pilles una raspberry y le metas ahí el Slic3r (Si es que se puede... que supongo que si), y que te vaya enviando los gcode poco a poco a la impresora. Teniendo en cuenta que te tiras horas y horas imprimiendo, puede que lo del portatil no te sea comodo... yo imprimo siempre desde portatil, pero tampoco lo necesito mientras imprimo.

La cantidad de lineas de código generadas también proviene del nivel de detalle del STL, puede que estés utilizando un stl con demasiadas facetas y se te genere demasiado código, una forma de hacerlo más ligero seria reducir el nivel de detalle del STL y por tanto, reduciendo las instrucciones generadas. Puede que notes algún cambio en la calidad... o puede que no.

La Raspberry ya lleva unos días en camino, a ver si no me cuesta mucho pegarme con ella, que no mío es la mecánica, no la electrónica.

Tengo el PC conectado a la impresora, pero no me gusta imprimir desde él, no quiero verme obligado a tenerlo encendido por el artículo 13 y además Windows es caprichoso, el 10 no tanto pero aún así... y en el momento más idiota se reinicia, y eso no es bueno.

La resolución es la que es, eso no quería tocarlo, en muchos casos no va a afectar, pero prefiero dejarlo así.

Y a todo esto, ¿alguien sabe que variables se usan como parámetros en esta ISO, o si funcionan las instrucciones lógicas, saltos y demás?, se que es una variante de la ISO RS274 específica para impresión 3d, pero nos parámetros P no me funcionan o los esté programando mal.

resim
Citar