Motion Control TIP Representación gráfica

Fecha de publicación
Cateogría del artículo Motion Control
Visualizaciones del artículo Leído  1139  veces
Tags del artículo

Pere Garriga nos explica las diferencias entre las diversas formas de monitorizar datos durante la puesta en marcha de una aplicación y como sacar provecho de las herramientas de traza, u osciloscopio

Motion Control TIP Representación gráfica

El propósito de este Tip es explicar la utilidad de las herramientas de trace (también llamadas funciones de osciloscopio) que implementan todos los entornos de programación actuales, enfocándolo a Motion Control por ser una tecnología en la que dicha funcionalidad es básica.

Podríamos hacer una comparación de las funciones watch con un tester o polímetro y las de trace con un osciloscopio. La gran diferencia está en que un tester se emplea para medir valores “estáticos” que no varían en el tiempo o lo hacen muy lentamente y el osciloscopio se emplea para ver la forma de onda que describen esas magnitudes al variar en el tiempo de manera muy rápida (desde unos pocos Hz hasta GHz).

Podríamos listar la utilidad de las funciones de Trace en cinco apartados:

1) Ajuste de los lazos de regulación del eje
2) Detección de Glitches en los movimientos del eje
3) Depuración del programa
4) Medición de valores y tiempos
5) Captura de eventos esporádicos

Veamos cada uno de los apartados:

1) Ajuste de los lazos de regulación del eje

Puede parecer que el eje se mueve bien, suave y posicionándose correctamente, pero para ver cuál es la realidad del movimiento y si está bien ajustado, hay que ver con el osciloscopio su velocidad y su corriente, como se muestra en la siguiente imagen:

En el gráfico de la izquierda se aprecia una oscilación de alta frecuencia en la corriente, esto provoca desgastes prematuros en todo el sistema. Gracias al osciloscopio lo podemos visualizar y ajustar las ganancias de los lazos de regulación en busca de la gráfica perfecta (la de la derecha) que no se podrá llegar a conseguir, pero se podrá mejorar mucho.

2) Detección de Glitches en los movimientos del eje

Un glitch es una anomalía de funcionamiento que se autorrecupera en muy poco tiempo y que en el caso del movimiento en un eje puede pasar desapercibida, pero tiene su impacto negativo en el sistema.

En el siguiente gráfico se visualiza el movimiento de un sistema de corte rotativo, del que el usuario está muy satisfecho, corta con gran precisión y a la velocidad máxima requerida. Pero hay un problema oculto, que solo descubriremos o bien por casualidad o bien graficando lo que está ocurriendo en el eje. Para ello creamos un Trace con los canales que se muestran en el gráfico, de hecho, con la aceleración y la velocidad sería suficiente.


Se observa que al inicio y al final de la aceleración aparece un glitch, que también refleja su efecto en la velocidad y ya más difícil de ver en la posición (la pendiente del primer segmento no coincide con la del siguiente). ¿Qué está ocurriendo? Pues que el tramo de velocidad ascendente no empalma bien con los de velocidad constante, los de velocidad constante tienen un valor ligeramente superior, por ello se produce el impulso de deceleración al inicio, que intenta igualar velocidades y el impulso de aceleración al final.

El problema lo genera un error de cálculo en la pendiente del movimiento al generar el perfil CAM, al activar la señal xNewCAM -Instante 1- previa corrección del cálculo, el siguiente ciclo ya no muestra el Glitch. Ahora sí que, al siguiente ciclo -Instante 2- el funcionamiento del sistema de corte rotativo parece y es totalmente correcto.

De no haberse corregido, todos los componentes mecánicos y eléctricos estarían sometidos a un desgaste prematuro.

3) Depuración del programa

Lo más habitual es tener una máquina de estados para controlar la secuencia de movimientos del eje, si algo no funciona como era de esperar, lo más efectivo es poner en un trace las señales más representativas de su funcionamiento y ver lo que está pasando exactamente.



En este ejemplo se trata de una simple aplicación en la que el eje está en la posición Pz, en espera de una señal de marcha [ DI_Marcha], con el flanco ascendente de la misma se inicia el movimiento al punto Pa, en espera de la señal [ DI_Retro].

Con los cursores 1 y 2 (veremos en el siguiente apartado) mediremos el tiempo desde que se alcanza la posición Pa y llega la señal de retroceso. Cuando esto ocurre el eje se tiene que desplazar hasta la posición fijada en Pb y esperar el tiempo según el preset de [ #TRetCero], transcurrido el cual hay que volver al punto de origen Pz y permanecer en este estado hasta que la señal [• DI_Marcha] caiga a false.

Uno de los canales más interesante a graficar es [ intEstado] que corresponde a la variable de estado de la secuencia, con este canal vemos si todo funciona como se espera, seguidamente se listan los estados:

0) En espera del flanco de subida de la señal de marcha para ir al estado 1
1) Se inicia el movimiento a Pb y se espera la señal de retroceso a Pb para ir al estado 2
2) Se espera que el eje alcance la posición Pb para ir al estado 3
3) Se espera el tiempo de retorno a cero para ir al estado 4
4) Se espera que el eje alcance la posición Pz y que la señal de marcha pase a cero para volver al estado 0 y cerrar el bucle.

4) Medición de valores y tiempos

En ocasiones no coinciden ni las velocidades ni los tiempos esperados en los movimientos. La forma de medirlos con total exactitud es graficando los valores deseados y empleando los cursores.

Podemos elegir entre uno o dos cursores, con un solo cursor podemos tomar la medida de cada canal en un punto, como ejemplo el valor de cada canal en la posición del cursor, como en el gráfico de la derecha. Con dos cursores podremos tomar, además, el Δt (Diferencia de tiempo entre cursores) y /o el Δv (Diferencia entre el valor del cursor 1 y el del cursor 2).

En el gráfico de la izquierda el Δt nos indica el tiempo total del movimiento y el Δv la distancia recorrida. En el gráfico central el Δt nos indica el tiempo de aceleración y el Δv la distancia recorrida durante la aceleración.

5) Captura de eventos esporádicos

En ocasiones se producen fallos esporádicos, difíciles de capturar y cuando ocurren ya nos lo hemos perdido todo, no sabemos cual era la posición del eje, ni el error de seguimiento, ni nada que nos facilite la resolución del fallo. Con la función de disparo del Trace por evento tenemos una gran herramienta, que nos hará la “foto” de los valores que nos interesan en el momento del fallo. Hay que pensar bien que queremos visualizar y con que señal y con que nivel dispararemos la foto.



En este ejemplo el eje se bloqueaba en ocasiones, siempre al alcanzar la posición Pa. Configuramos el Trigger para que dispare cuando el valor de error de seguimiento alcance un valor determinado y obtenemos la “foto”, la cual podemos analizar a posteriori y tomar medidas con los cursores.

Observamos que a pesar de que el eje ha alcanzado la posición Pa, el error de seguimiento sigue en aumento y provoca el fallo del eje.
De ahí deducimos que la única forma de que el error de seguimiento siga aumentando, es porque el eje está presionando contra el tope mecánico y efectivamente este era el problema, la posición Pa era la misma que la del tope, de forma que por unas centésimas de milímetro fallaba en algunos ciclos.

RESUMEN:

La funcionalidad Trace es una herramienta imprescindible en las aplicaciones de Motion Control. Reduce considerablemente el tiempo de puesta en marcha y evita sorpresas en movimientos que parecían correctos y en realidad ocultaban fallos, tanto de diseño de perfiles, como de regulación. También será imprescindible para captura de fallos esporádicos.

La misma utilidad tienen en cualquier otro tipo de lazos de regulación y también a modo de analizador de estados lógicos para cualquier aplicación.

Linkedin Pere Garriga

/blogs-automatizacion/marcas/498-motion-control

Motion Control

Blog dedicado a la introducción en los conceptos de Motion Control (Control de movimiento) en sistemas de automatización




Descargas