Buenas, este es mi primer post y me estoy por armar una i3 (cuando compre todos los componentes) con la electronica de repic (con micro pic)
**********************
El año pasado hice un programa de cinematica inversa para un brazo robotico que simula y controla los motores y posicion a travez del usb directo a un microcontrolador pic (cinematica inversa = movimiento automatico de diferentes articulaciones para lograr que la punta del brazo se mueva a una posicion (x,y) deseada en un plano)
este programa funciona perfectamente en la vida real con un brazo robotico real (controles con las teclas w,a,s,d)
http://www.mediafire.com/download/n0bj6nn79j43qj8/CinInv.rar
nota:el programa esta hecho en vb pero tambien lo hice con qt para multiplataforma(hasta android en un celular)
como pueden ver con el programa, poniendole un hotend a la punta del brazo ya podria empezar a hacer capa por capa y cuando termine una capa que suba 1 y siga con la siguiente (3 motores son suficientes) creeria que tambien se le pueden poner varios hotend a lo largo del segundo brazo para que todos impriman a la vez e imprima mucho mas rapido

ok, todo va bien, tendria el software, el firmware y el hardware listo para crear una nueva reprap, pero no se como interpretar esa capa por capa, por ejemplo, en el cura-view mode-layers se puede ver algo como esto
/////////ver imagen abajo////////
si podria saber como hace el cura esto o algun programa similar que sea codigo abierto ya podria empezar con la construccion, no necesitaria gcode y se podria imprimir directamente del .stl tambien le podria hacer unas mejoras
*como impresion por internet o gsm(inalambrico desde cualquier parte) y testear el proceso de construccion
*añadirles unos baratos acelerometros para saber la posicion de los hotend adicionales y saber cuando imprimir y cuando no(aceleraria y corregiria su posicion) tambien se usarian para autocalibracion
ventajas del sistema
*3 motores para movimiento 1 para hotend(no necesita como minimo motores nema 17, podrian ser mucho mas inferiores y con menos piezas sabiendo los calculos de torque y aceleracion para un brazo robotico de pla o abs de 20cm)
*electronica mucha mas barata y eficiente(usando un pic que se conecta al pc sin ninguna interface serial-usb ni gcode, accionamiento directo del soft con el controlador) tambien los datos de senseo como la temperatura de la cama y del hotend y la posicion de los motores son directamente al instante ya que usb en modo hid no necesita drivers y trasmite 12mbs(con 12 bits ya se transportan todos los datos, nos sobraria)
*(a priori) menos piezas imprimibles ya que el brazo son 2 barras de abs o pla y tampoco necesitaria correas, por ende no necesitaria poleas ni rulemanes y usaria un solo tornillo para el eje z
desventajas
aun no esta construido y no puedo sacar mas conclusiones
espero que me puedan ayudar, todo es codigo abierto saludos!

esta es la segunda imagen, la que tiene el cura y no se como interpretar estos datos

Lo ideal sería que entiendas que el gcode son las coordenadas de movimiento en los 3 ejes los cuales previamente cargaste en la configuración del soft como medidas máxima de la impresora.

ok, osea, yo tendria que programar mi gcode para mi maquina? creo que ya entendi

no exactamente, deberias hacer que tu controlador, leyera el estandar gcode y lo interpretara al estilo de movimientos X,Y,Z.
por ejemplos las maquinas delta o scara interpretan el mismo gcode con alguna que otra variacion...

---

--
[maquinaslibres.tk]
[4232.cf]

les juro que lei y trate de profundizar sobre gcode pero me parece innesario, porque si por ejemplo yo quiero hacer un cuadro de 10x10x10cm
el programa haria esto:
empezaria desde el punto (0,0,0)cm
brazo se mueve por eje y hasta (0,10,0)cm
brazo se mueve por eje x hasta (10,0,0)cm
brazo se mueve por eje x hasta (0,-10,0)cm
brazo se mueve por eje y hasta (-10,0,0)cm
despues subir 1 en el eje z osea (0,0,1) y repetir el proceso hasta z=10cm
PD: puse cm para dar una idea pero la precision de los motores y del acelerometro es muchisimo mayor
y estas instrucciones las mande desde una pc al brazo con cinematica inversa y lo hacia y no necesite de gcode, por eso no le veo utilidad al gcode o sere muy ignorante ^^ siguiendo este modelo cualquier celular podria enviar las instrucciones al microcontrolador y enviarias y recibirias informacion practicamente en tiempo real sin necesidad de una pc conectada al usb o una memoria sd o un microntrolador de 32 bits(con uno de 8 bits son baratos y sobra memoria de instrucciones)
digo esto porque vi una prusa i3 que tenia arduino y cuando enviaban informacion o recibian era muy muy lento y cuando lo querias parar demoraba como 5 minutos y hasta que corrigas las instrucciones por software ya estaban los gcodes enviados y trabaja con instrucciones viejas y por eso me parece innecesario el gcode, es mas, hace daño desde mi punto de vista todabia ignorante
por eso lo que quiero hacer es interpretar el modelo por capas del cura, vi que es codigo abierto asi que le voy a echar una mano, una vez que tenga el codigo del modelo por capas empezaria desde cualquier punto y ese lo haria su punto de referencia y lo trabajaria como explique arriba siguiendo las lineas asi se mueven las articulaciones definido un punto y eso seria todo, si quisieramos poner mas extrusores tambien se podria, poner un extrusor y el otro a la mitad y que el software tome el segundo extrusor como si su punta fuera la mitad del brazo y calculas cuantas lineas podria imprimir mientras va imprimiendo el extrusor principal sin modificar la del extrusor principal, como mucho ahorrarias un 50% con un segundo extrusor y podrias poner mas
encontre algo parecido con un scara industrial y gcode http://transistor-man.com/3dprintbot.html

¿tu idea es guardar la secuencia en el controlador en lugar de enviarla por serial?

a mi lo que me parece es que deberías intentar que tu controlador (o precontrolador) escriba gcode al vuelo y se las envie a una ramps común y corriente...

se que parece mucho usar un mega pero no es tanto: la mayoría de las cosas que uno imprime no llevan esa secuencia tan prolija que propones, no es todo vacio, la mayoria de las cosas o las mas lindas llevan estructuras internas que sostiene el exterior.

seria expectacular que un micro pueda interpretar un stl, pero no creo que lo logres tan facil menos con 8bits y pensando que un stl puede llegar a pesar 100mb

Edited 1 time(s). Last edit at 10/27/2015 11:06PM by qubotica.

---

--
[maquinaslibres.tk]
[4232.cf]

la idea es enviar las secuencias por tcp(cable rj45 o wifi) o por usb o por gsm o bluetooth cualquiera sirve y ya las aplique, solamente mandas los strings y el microcontrolador los transforma en enteros y listo para usar, entonces la pc o smartphone o tablet hacen todo el trabajo y unicamente envian los string, no son calculos matematicos tan complejos ni tampoco llevan tantos decimales asi que se lo procesa bien y mas que suficiente y las secuencias que enviaria por ejemplo seria "1" para mover el motor en el eje x positivo "2" para el eje z y asi sucesivamente, como ves el micro no tiene mucho trabajo ni levanta .stl ni nada de eso
arduino es mas facil de aprender y programar y hay mucha informacion pero no vale la pena gastar $1000 en electronica con arduino y ramps cuando te lo podes hacer con $200 con pic y transistores y ademas es mucho mas rapido sorry si ofendi a alguien no fue la intencion, yo tambien programe en arduino no soy cerrado ^^

Hola está buena la idea de armar la electronica con pic, hay mucha gente que habla de lo superior que es en muchos aspectos (nunca los use, aprendí a usar micros con un 8051 y nunca me puse con pic de paja nada mas...) . Lo que si creo que si te pones a diseñar y escribir un soft que interprete un STL y directamente lo envíe a la impresora, vas a tener que lidiar con TODO lo que hoy tienen que lidiar los soft tipo slic3r, Cura, Simplify, etc... que tienen un par de años de desarrollo y tantos parametros para mejorar o empeorar las impresiones que es como arrancar de cero con algo que va a llevar mucho tiempo de desarrollo y perfeccionamiento. (el cura es bastante automático en muchas cosas, pero por ejemplo si ves las opciones que tiene Slic3r o Kisslicer vas a ver todo lo que se puede modificar y variar para tunear una interpretación de un STL y luego convertirlo en movimientos)
En cambio si dejas que eso lo maneje un soft que ya existe (inclusive algunos son abiertos y tenes los fuentes para ver) y te encargas de interpretar el GCODE y convertirlos a movimientos de tu impresora me parece mas efectivo (es solo un punto de vista). Inclusive con CURA, si ves en github, tenes el engine y el frontend, podrías usar el engine solamente para convertir el STL a GCODE... luego tu soft solo tendría que ir interpretando secuencialmente el GCODE (convertirlo de X,Y,Z, E1(E2, E3... etc) a tu cinemática) y enviar las secuencias en tiempo real a la electrónica.
Para ir un poco mas allá, si ves la especificación del formato STL (http://www.fabbers.com/tech/STL_Format) son un monton de caras definidas por tres puntos que se van uniendo hasta formar el objeto sólido.



Lo que te muestra el CURA cuando activas la visualicación por capas (por eso también cuando pones esa opción tarda un toque en mostrarla), ya es el resultado del proceso de análisis y corte transversal de ese solido en cada capa (definida por un valor variable según los parametros que cargues de la impresora) y los movimientos de X y Y también dependiendo del ancho de la extrusión, etc, etc... si vos quisieras interpretar el STL, primero vas a tener que aprender a interpretarlo (solucionar todos los posibles problemas que suelen tener), recién ahi hacer los cortes por capas, calcular si lleva o no relleno y luego convertirlo a los movimientos de tu cinemática. En cambio si usas el un GCODE ya generado, todo ese laburo lo haces con el soft que prefieras y te convenga según el caso (te da libertad y flexibilidad) y lo que vos diseñes solo leeria ese standard de movimientos y se encargaría de mandarlos directamente con el método que quieras.

Todo esto es solo una humilde opinión si querés encarar algo así a lo mejor está buenisimo como proceso, no se si como aplicación generalizada porque sería un desarrollo enorme solo para un conjunto específico...

listo ahora si lo tengo claro, tengo que hacer un soft que interprete el gcode de mi brazo y mandar las instruccion al pic, no parece complicado https://www.marginallyclever.com/blog/2013/08/how-to-build-an-2-axis-arduino-cnc-gcode-interpreter/
tambien tendria que ajustar los parametros de una nueva maquina en cura para que los interprete correctamente con mi cinematica inversa, tendria que hacer algo como esto http://www.imprimalia3d.com/recursosimpresion3d/imprimir-g-code-generado-cura-impresora-3d-beethefirst
y finish him!!! creo que eso seria todo en las vacaciones traigo resultados

creo que estas mezclando conceptos, rj45, wifi o lo que uses va a ser una conexion serie, la velocidad solo va a depende de lo rapido que pueda procesar el pic y cuanta memoria tenga adentro... creo que estas pensando todo muy en abstracto.

Yo uso mi impresora por rj45 con octoprint o con wifi con router que arme, tambien podes usar bluetooth con la ramps, pero no deja de ser una conexion serial, tanto sobre usb, wifi, bluetooth o difectamente conectandote con un rs232

---

--
[maquinaslibres.tk]
[4232.cf]

De entrada con interpretar los G0 G1 ya tenes los 3 ejes, solo tenes que tirar un OK como respuesta y en lugar de usar cura podes usar un control de cnc así te ahorras todo eso de la temperatura (hotend y cama)

Según entiendo con enviar un "ok" cada vez que se recime un mensaje basta, el protocolo de comunicacion es bastante simple

se que pensas que lo lento de la comunicacion es por la velocidad pero principalmente se debe a que lo mensajes solo se recibe una vez ejecutado

---

--
[maquinaslibres.tk]
[4232.cf]

depende, vi modulos de arduino y los adapte a pic con codigo propio como los hc05 o los esp8266 que si manejan serial por comandos at, pero el usb del pic al pc es puramente nativo y podes elegir entre diferentes modos de trabajo de usb, hid sin drivers, cdc o bulk transfer para los pendrive(http://s.eeweb.com/members/mark_harrington/answers/1333179451-USB_Complete_3rdEdition.pdf) por eso la superioridad de repic frente a marlin con arduino (http://reprap.org/wiki/Repic) que usa rs232 para comunicarse con el usb, microchip tambien ofrece una completa red tcp ip nativa(para rj45 o wifi) sin interface uart de por medio y totalmente configurable y encriptada directa para pic32 ademas de otras redes para gsm y gps que no probe
ademas se podrian usar interrupciones para modificar las temperaturas y velocidades durante la impresion, cuando hacia el curso para cambiar estas coordenadas demoraba como 5 minutos y aveces no tomaba los cambios, me puse a investigar y el problema es que arduino no tiene comunicacion usb nativo con el microcontrolador sino una interface serial, hasta hoy en dia los fabricantes de interface rs233-usb tienen muchos problemas y en su mayoria no funcionan(yo compre 2 y ninguno funciono, casi a nadie les funciona) ademas arduino trabaja con un bootloader preprogramado que permite que se "programe" desde el "compilador" arduino, tiene mucho codigo innecesario que lo hace lento
pero bueno ya vamos a ver, si sirve y funciona mejor para la comunidad

Gracias a todos los que me ayudaron a orientarme
[forums.reprap.org]