desktop

Duda para comenzar una interface de una CNC

Hola, despues de un tiempo, he realizado una pequeña interfase basada en la interfase de esteca55, utilizando el puerto paralelo, con algunas pequeñas modificaciones realizadas a mi gusto. Dejo adjunto el esquematico y PCB hecho en Eagle al igual que unas fotos de la placa ya montada, para que vean como queda, a quien le interese. Dentro de poco cuando tenga listo los drivers para motores DC los estaré subiendo aquí mismo. Saludos.
 

Adjuntos

  • Interfase CNC.part1.rar
    5 MB · Visitas: 5
  • Interfase CNC.part2.rar
    5 MB · Visitas: 4
  • Interfase CNC.part3.rar
    5 MB · Visitas: 6
  • Interfase CNC.part4.rar
    5 MB · Visitas: 5
  • Interfase CNC.part5.rar
    5 MB · Visitas: 6
  • Interfase CNC.part6.rar
    4 MB · Visitas: 7
Diseño de un driver para motores DC con encoder incremental para cnc

La idea de hacer un diseño de un driver, para motores DC con encoder incremental, para emplearse en CNC, surge de la necesidad de que en la web no se cuenta con ninguno en forma de open-hardware y open-source. Los driver que hoy día se encuentran en la web, son todos para motores PaP. Es por ello que encaré este proyecto, por un lado a modo de reto personal, por otro lado como una necesidad para realizar mi CNC con motores DC y por último porque no hay nada en la web para poder hacer uno en la casa, lo que hay solo lo venden.

Pues bien, comenzaremos con el diseño de la rutina para detectar si el motor está girando a la izquierda o hacia la derecha, en función de las señales provenientes del encoder incremental. Veremos primero como son estas señales para entender como saber el sentido de giro del motor.

Encoder incremental.png

Como podemos ver la señal A está 90° adelantada a la señal B o la señal B está 90° atrasada con respecto a la A, dependiendo de cómo uno quiera verlo.
Hay 3 formas de trabajar este tipo de encoders, en modo X1, X2 o X4.


Modos encoders.jpg

Cuando se necesita más resolución, es posible para el contador contar los flancos ascendentes y descendentes del tren de pulsos de un canal, lo cual duplica (X2) el número de pulsos contados para una rotación o milímetro de movimiento. Contando ambos flancos, para ambos canales, dará resolución X4, brindando la mayor resolución posible al encoder.
En mi caso, voy a utilizar la mayor resolución posible que brinda el encoder, o sea el modo X4. Para ello voy a utilizar las interrupciones por cambio de estado de un puerto de un PIC, en concreto el PIC16F684. La mejor forma de encarar es realizar una máquina de estados para resolver el problema de identificar si la secuencia es de incremento o de decremento.

Estados.png

Tabla de estados.jpg

El diagrama de estados en función de la tabla de estados es el siguiente:


Diagrama de estados.jpg
A continuación expongo el código desarrollado para dicha máquina de estados utilizado para leer los pulsos del encoder en modo X4.

Código:
  signed int32 Pul_act
  int Estado_anterior,Estado_actual;
  
  #INT_RA
  void  RA_isr(void) 
  {   
     Estado_actual = input_a() & 3;
     switch (Estado_anterior)
     {
        case 1:
        {
           if (Estado_actual == 3)
              Pul_act++;
           else
              Pul_act--;
        }break;
        case 3:
        {
           if (Estado_actual == 2)
              Pul_act++;
           else
              Pul_act--;
        }break;
        case 2:
        {
           if (Estado_actual == 0)
              Pul_act++;
           else
              Pul_act--;
        }break;
        case 0:
        {
           if (Estado_actual == 1)
              Pul_act++;
           else
              Pul_act--;
        }break;
     }
     Estado_anterior = Estado_actual;
  }


A medida que siga avanzando, iré subiendo las diferentes partes del driver.​
 
Última edición:
Juanma

Te aconsejo que le des una mirada a esto: http://ww1.microchip.com/downloads/en/AppNotes/00696a.pdf

Yo estuve haciendo un driver basado en pic con comunicacion serial a un master controller. Basicamente cada driver era:

- Micro, bien chico, no recuerdo ahora si use 12F675 o 16F628, probablemente este ultimo.
- Un flip flop 74LS74 asociado a unos capacitores para filtrar posible ruido de encoder.
- Electronica de potencia para el motor DC

Con esto logre mover los motores DC + encoder optico (rueda con rayas) de una impresora EPSON.

Lo interesante de la application note es como usa los timers del micro en modo externo para contar los ticks.

En mi driver (que lo hice funcionar pero no lo termine) podias hacer girar con precision X pasos para cualquier lado, liberar, enclavar, etc.

Habia un par de trucos:

- En la electronica de potencia (puente H), tenia 1 señal de enable, si la desactivo no hay corriente al motor
- Si enable estaba activada, la señal de pwm funcionaba asi: 1=hacia la derecha; 0=hacia la izquierda
- Entonces, si queria enclavar el motor, ponia un pwm 50% de duty.
- Si queria girar hacia un lado, ponia un pwm con duty proporcional a la velocidad. 50% era el punto medio y 0-50 es para un lado, 50-100 es para el otro.

En el software, tenia ordenes que venian por una red RS-232 como "motor A muevase X cantidad de pasos en tal direccion" entonces el soft calculaba rampa de aceleracion-meseta-frenado.

El frenado (o desaceleracion) es importante porque si no lo haces no hay forma que la inercia no te gane y hagas "pasos" de mas.

Lo mas complejo para el caso de CNC o plotter es cuando tenes un movimiento coordinado de dos ejes a la vez. No es tan controlable como un stepper pero desde el protocolo serial se le podia enviar a los motores un comando que involucra un solo paso, obviando aceleracion meseta y frenado.

En ese caso, se comportan como steppers pero repito, se pone bien complejo de controlar corriente, pwm, etc. Tene en cuenta los movimientos combinados en tu diseño.

Una forma de solucionarlo es que el soft haga una rampa creciente de corriente hasta que se detecte que cambio un tick en el encoder. Y ahi lo frenas.

Espero que la descripcion te sirva
 
Última edición:
Gracias por tu consejo, lo tendré muy en cuenta. En cuanto a la nota de aplicación luego la veré. La forma en que voy a hacer la comunicación es a través del puerto paralelo, por lo que solo recibo los pulsos del programa Mach3, que a priori no se cuantos van a ser, por lo que se me habia ocurrido hacer un lazo de control con un PID levantando los parametros del motor para poder obtener la función transferencia y asi seguir los pasos como si fuera una referencia, lo que no se es como se va a comportar con movimientos combinados de X e Y. Tenia pensado hacer un sistema de tipo 1 para tener error cero a la posición, la velocidad no me importaría demasiado en principio, y la idea es usar un láser por lo que los ejes no harían fuerza mas que para moverse ellos mismos, aun así requiero sensar su corriente?


PD: La nota de aplicación esa ya la tengo. [emoji6]
 
Última edición:
Atrás
Arriba