Entre dos puntos, la distancia es una recta, calcular la pendiente, generar los "triangulos" para los avances de cada motor.... ¿seria algo asi Esteban?
Un menú, que yo creo que es totalmente necesario, es el de elegir el centro de coordenadas y que el micro recalcule todos los puntos del sistema.
Modificación:
PD.: ¿Qué lenguaje de programación queréis usar? Por mi el C-CCS con la librería de PalitroqueZ (sólo con su permiso) de las MMC y SD. Si no el C18 que trae librerías para las tarjetas.
Qué os parece hacer la estructura del compañero cucaracha http://webs.ono.com/cucaracha/fresadora3D.htm
Me gusta por seguir con la idea de hacer una CNC barata con medios accesibles y sencilla (aunque parezca de bricomania)
Lo de usar una pantallita me parece que es importante, no para ver los gráficos del mecanizado, sino para ver el programa que se ha enviado, y cuando este esté ejecutándose se vea la línea de código sombreada. Me inclinaría más por usar una pantalla más grande a la de un celular, mínimo 128x64 si es el doble mucho mejor. También se tiene que tener la posibilidad de modificar y/o corregir el código enviado en el mismo control, para esto es importante tener un teclado.
........
También hay que tener un puerto de expansión para las señales del PLC, algunas pueden ser:
Entradas:
Xhome, Yhome, Zhome
Stop de emergencia
Salidas
Pin de M3_M4 del husillo
Pin M5 parada del husillo
Bombda de agua.
Un G0 que pueda llegar por ejm a 4000mm/min, con opción de modificarlo estaría bien para empezar.
También hay que programar aceleración y desaceleración.
....
Os cuelgo dos amplificadores de corriente. Los transistores aguantan 100A y 100V.
El mosfet es el BUK9575 cuesta como 1€ y el resto que lleva es un 1n4007 y un par de resistencias de 0.25W
Los bipolares son el MJD122 (es smd) cuesta como 0,25€ y lleva 4 resistencias de 0.25W
Os pongo los dos para que decidáis si lo hacemos smd o no
A mi me interesa, yo me apunto. No obstante, lo primero que propongo es centrarnos en un solo objetivo porque si no se va a dispersar el esfuerzo. Es decir, lo primero que habría que hacer es una especificación de objetivos, o dicho de otro modo, aclarar es lo que se pretende hacer. Me explico:
Si en un conjunto 'completo' CNC descartamos la parte CAD y nos centramos en la parte CAM yo distingo cuatro partes:
1.- generador de codigos G
2.- interprete de codigos G
3.- generador de pulsos de salida (step/dir, on/off de pínola, on/off de refrigerante, on/off de aspiracion) y receptor de señales de entrada (limites, home, e-stop..)
4.- drivers de motores
5.- mecanica
Mi propuesta se basa en que lo me parece mas lógico es dejar 1) en el PC donde vive la parte CAD, y partir de un fichero en formato *.nc -o txt de lineas con GCodes- almacenado en una SD/MMC. O dicho de otro modo, no creo que debiéramos preocupamos de como se generan los códigos G en el alcance de este proyecto.
Por otro lado, 4) tampoco me parece que debiera estar en el alcance, primero porque 4) se dedica basicamente a controlar potencia, luego porque el mundo PaP y el mundo servo se parecen muy poco, y por ello tambien sus drivers son muy distintos, con lo cual es otra posibilidad de diluir el esfuerzo.
Del mismo modo, para 5) hay tantisimas soluciones, tan dependientes de lo que este al alcance de cada uno, que intentar definir un estándar me parece un poco demasiado complicado.
b) interprete los códigos G y genere las secuencias de pulsos que se deriven de ellos en un formato step/dir, para motores paso a paso (es decir, sin soporte de encoders de cuadratura para servos, al menos en una version inicial), y para un numero de ejes por definir.
3º Ir almacenando los pulsos que se envian en alguna especie de buffer mientras se calculan los siguientes, ya que calcularlos todos y guardarlos en algun sitio, si el programa es muy grande, se hace imposible. Tambien es importante tener en cuenta que la diferencia de tiempos entre pulsos no sera constante, y que habrá que enviar los de cada eje con su frecuencia, lo que dista mucho de ser trivial.
Lo único que creo que ya es fijo es que vamos a usar pap. Como estos motores tienen una velocidad máxima, creo q no se complica tanto (puede que cuando empecemos me de cuenta de lo equivocado que estaba).
La idea es que un micro convierta las instrucciones a pasos y otro controle los pap y los mueva de acuerdo con esos pulsos.
Lo bueno de hacer esto es que el buffer se agranda y se puede conseguir más velocidad.
Eso es verdad, en lo que creo que vamos a diferir un poco es que vos vas a usar un driver convencional, sin control de corriente, la idea mía es aplicarlo a un driver con control de corriente, seguramente use alguno de los de mi web, la idea de esto es porque cuando termine mi nueva máquina, para probar va a ser muy censillo, desconecto la interfaz de la pc, conecto esta placa y listo, ya estoy controlando la máquina.
A lo que me refería es que con los driver con control de corriente al menos voy a tener 3 o 4 veces mas velocidad en los motores, con lo cual voy a necesitar mas velocidad de procesamiento, pero para empezar eso no es problema, lo primero es que ande bien, aunque sea despacio.
Obviamente la de desligar a la etapa del procesamiento la del control de las bobinas del motor es lo mejor, como vos decís ahí se gana en velocidad.
Es mas, yo estoy pensado en utilizar dos micros para procesar el G, asi se puede con uno leer el g, y hacer el calculo del movimiento, para los ejes, y después se lo pasa al otro que genera los pulsos teniendo en cuenta la aceleración velocidad y demás, y mientras ese produce eso el otro va haciendo los cálculos para las siguientes líneas de G.
Es mas, lo que mas me resulta complicado va a ser como poder generar supongamos para 3 códigos g tres trene de pulsos de distinta frecuencia, y con rampas de aceleración distintas, hasta pensé poner un micro para eso por eje de esa manera al independizarse es mas fácil, ahi el problema seria el sincronismo de los movimientos.
Pasa como queres hacer un drive con un solo pic para tres ejes, yomo uso paso y dirección, eso no puedo usarlo, ya que la mejor forma de tratar eso es por interrupción, uso la interrupción de cambio de flanco, pero que pasa si los dos ejes se mueven al mismo tiempo, el pic no puede detectar dos cosas al mismo tiempo, perderíamos pasos, por ejemplo en el mach los pulsos de paso son de 1 microsegundo.
Respecto al lenguaje, nunca use CCS, la idea mia es usar C18, ya que además cuento con un ICD2 para debuggear desde el MPLAB, pero me puedo adaptar a otra cosa, no hay tanto problema.
Vale, usamos el C18 (si el maestro es el que maneja mejor hacerle caso....)
No entiendo este párrafo :(
Yo tampoco, jaja, ahi lo reformule, lo modifique, se ve que ya me estaban haciendo efecto las pastillas por la gripe anoche jejejeje
Pues podríamos empezar con un PIC4550 que todos tenemos en casa y con la SD empezar a entender en formato FAT16 para que se pueda así capturar la información generada en el PC y almacenada en la SD.
Les parece?
me gustaria empezar a familiarizarme con los comandos propios del G-code si alguien me puede faciltar un link al respecto se lo agradeceria.
Deberia ser un compilador Free y/u open source.Por lo que vi todavía no soporta programación de PIC o ¿leí mal en la página?
por ejemplo el SDCC.