[DUDA] Envío de g-code a Sprinter/Marlin 'a mano'. ¿existe manual o información de como proceder?

[thingmaker]

Estoy enviando 'a mano' mandatos g-code fuera de los programas host y tengo la intención de enviar de un modo controlado un fichero gcode ... es decir, muchísimos mandatos uno detrás de otro :-)

Ante esta situación, lo único que conozco, de momento es:

 -existen mandatos que van "a buffer" es decir, se encolan y cuando les toque se ejecutan y otros que se ejecutan inmediatamente.

 -el firmware (Sprinter/Marlin) devuelve 'ok' cuando lo ha recibido y 'rs' cuando pide un reenvío.

Al ser todos los mandatos candidatos a "encolar" lo que no se, es que cuando llene el buffer ¿que pasará? ¿me responderá con "rs" hasta que haya "hueco"? ¿fallará?, ¿toca hacer algun control de tiempos? etc ...

Antes de ir al código fuente de Sprinter/Marlin para ver claramente 'como lo hace' me gustaría saber si existe alguna convención/protocolo a seguir en el envío de gcode al firmware que solemos usar.

Muchas gracias,

thingmaker

[Iceflow]

Se ve que nadie tiene mucha idea thingmaker :( yo no puedo ayudarte tampoco, soy un mero usuario jejejje

Me da que te toca "estudiarte" como lo hacen los firmwares para saber mas del tema... :S

Suerte!!

--
 
---
Has recibido este mensaje porque estás suscrito al grupo "Clone Wars: Imprimiendo impresoras 3D" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a asrob-uc3m-impreso...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a asrob-uc3m-i...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Andres Maroto]

hay una cosa que no acabo de entender......

Al ser todos los mandatos candidatos a "encolar" lo que no se, es que cuando llene el buffer ¿que pasará? ¿me responderá con "rs" hasta que haya "hueco"? ¿fallará?, ¿toca hacer algun control de tiempos? etc ...

 

¿estamos dando por hecho, que un Gcode con 10.000 líneas van todas al bufer?? ¿o quizá sólo aquellas líneas que son necesarias para toda la operación? temperatura ?? fan_on/off?? velocidades??

si el buffer lo entendemos como una memoria RAM, no todos los datos van a la ram, algunos se quedan en el disco duro hasta su uso..... ¿no? ¿¿estoy equivocado??

voy a buscarte un programa en MS-DOS que es un simulador de Gcode de hace MUUUUUUUchoooossss años, y si lo encuentro te lo envío... para que juegues con él..... Te diré que es más para CNC que para impresión, claro está, pero el funcionamiento es el mismo, o mejor dicho similar. (la máquina, usa disquettes de 1,44 y creo que todavía funciona.....) jajajjjaajja

Yo lo usaba para enviar los Gcode de un dibujo 2d similar al "coche-CAD" para ver como quedaría el dibujo con una fresadora en una madera/dm/contrachapado.....

saludos.

[Antonio Navarro]

Yo no tengo ni prusa idea, pero me iría más bien al código de pronterface a cotillear cómo lo hace, más que a los firmwares. Pronterface se encarga de enviar los g-codes de un fichero, que es lo mismo que quieres hacer tú...

[Andres Maroto]

¿Alguien puede usar una analogía para entendernos por si las moscas??

¿es similar a un control de alcoholemia donde todos esperan pero solo unos pocos se paran?? 

¿es similar a pistola donde los Gcode están en el cargador y esperan a que la anterior línea sea ejecutada??

¿es similar a hacer una pizza en casa, donde la temperatura del horno es lo primero, mientras lees las instrucciones para poner los ingredientes???

ya me ha picado la curiosidad...........

[Antonio Navarro]

En mi opinión, sin tener ni prusa idea, me parece que es más como 'una pistola', se mandan los g-code en orden y se van ejecutando. Si tenemos en cuenta el buffer que tendrá el firmware, pues supongo que desde el pronterface/repetier-host o el que sea se irán mandando en bloques.

Me baso en lo que he observado, por ejemplo, cuando está imprimiendo la primera capa y ves que empieza mal, le das al stop en el repetier y en general sigue haciendo varias líneas hasta que se para, no es instantáneo. Ahora que lo pienso, creo que si le das a 'parada de emergencia' sí que para instantáneamente, pero debe ser más un reset para el arduino que un g-code (supongo).

Lo de las temperaturas, es que hay dos g-codes diferentes. Hay uno que dice 'Ponte a calentar la cama/hotend, pero no esperes a que se alcance la temperatura' y otro g-code diferente que dice 'Calienta la cama/hotend y no hagas nada hasta que se alcance esa temperatura'.

Un saludo,

[thingmaker]

@Ice, @Andres, @Antonio gracias

No os preocupéis ... preguntaba por evitar hacer el tonto si es que ya existía la información.

Resulta que el Pronterface no le gusta nada enviar ficheros que no sean para imprimir ... o sea, que usar el Pronerface para fresar no rula ...

Hay un simulador ... http://www.dietzm.de/gcodesim/ y voy a probar que tal  responde al enviar ficheros por el programita https://github.com/winder/Universal-G-Code-Sender

No tengo problema en ver el código, pero quería evitarlo :-P

Saludos,

thingmaker

[Andres Maroto]

tienes la fresadora???

es para una 3d con cabezal de fresar o para una CNC???

que me interesa.. jejej

 

[thingmaker]

¿cómo que si tengo una fresadora ...? tengo 'mi fresadora' o proyecto de eso mismo :-D

https://groups.google.com/forum/?hl=es#!category-topic/reprap3dvalencia/yvaOgBHPzMw


Saludos,

thingmaker

[Andres Maroto]

jajajajajaja

y éso que lo he estado leyendo, para ver como seguia el asunto.... sigue vivo,, 

estaré atento.

[Iceflow]

Has probado el software de txapuzas para cnc? parece sencillo y para toda la familia jejejeje

--

[Iceflow]

Y porque dices que no le gustan ficheros que no son para imprimir a pronterface? O.o la gente que dibuja con boli por ejemplo... o gente que si que ha fresado con su impresora 3D... no han tenido problema, explicate mejor.

El 2 de diciembre de 2013 23:51, thingmaker <enric...@gmail.com> escribió:

--

[thingmaker]

Pues viendo el código del Sprinter y sin mirar mucho más podría decir que 'entiendo' que el programa que envía los gcodes, es decir, el programa host, se espera a recibir respuesta del firmware antes de enviar otro mandato ...

...

//------------------------------------------------
//READ COMMAND FROM UART
//------------------------------------------------
void get_command()
{
  while( Serial.available() > 0 && buflen < BUFSIZE)

...

Por esta razón cuando enviamos comandos de que detenga la impresión no lo hace inmediatamente ... quizás estos gcode cuando entran en el buffer se pone el primero pero hasta terminar la ejecución del actual no hace nada ... ahora empiezo a enternder porque no es posible evitar ciertos desastres ... :-S

Supongo que no es posible en 'arduino' "consultar sin consumir" el valor del puerto serie ... en fin, tampoco vamos a hilar tan fino :-D


@Ice, lo de txapuzas, que es muy chulo no usa hardware reprap ... yo quiero usar electrónica reprap para mi fresadora.

@Ice, igual es que lo he hecho mal, pero el Pronterface al tener el Z valores negativos en el gcode decía que "tururú" que cero capas y que me fuera a tomar viento fresco :-D ... si alguien sabe algo que yo no sepa que por favor me lo diga ;-)

El software para generar el gcode que uso es pyCAM y Inkscape+gcodetools ... se que el pyCAM tal como saca los gcode no le gusta al firmware reprap pero hay un script que lo modifica ... en fin os mantendré informados cuando lo consiga :-D

Saludos,

thingmaker

[Iceflow]

Quiza tu primer problema es intentar usar un firmware que no esta pensado precisamente para esa tarea :( porque no un grbl? que esta mas orientado a ello...

El software de txapuzas esta orientado a un hardware, pero no creo que tengas problemas en que funcione en otros... no lo he mirado, pero seguramente es posible y no seria muy dificil.

Igual ese script que usas para "adaptar" el gcode del pyCAM a algo que le guste al firmware reprap no funciona muy bien... realmente andar haciendo eso es algo txapuzas ;) jejejje

--

[Iceflow]

Has echado un ojo a esto?

http://reprap.org/wiki/PCB_Milling#Software_suites

Puede que encuentres algo interesante :P

Y este post del foro de reprap aclara muchas cosas, o eso creo :P quiza, como dije, el firmware no es el mas adecuado... :S

http://forums.reprap.org/read.php?131,232233