¿Cuál es el mejor sistema de programación para

Motion Control?
Propósito del artículo.
Este articulo pretende dar una visión general de diferentes
sistemas de programación para Motion Control, desde los más
populares a otros no tan conocidos. Cada sistema tiene pros y
contras y estos varían también en función del tipo y/o la
dificultad de cada aplicación.
A tener en cuenta.
En esta publicación pretendo ser lo más objetivo y neutro
posible, pero está basado en mi experiencia con los sistemas que
conozco, por lo que puede que algunos fabricantes dispongan de
sistemas muy interesantes y yo no los nombre por falta de
experiencia con los mismos.
Por otra parte, para determinar cuál es el mejor sistema
intervienen tantos factores que no se puede determinar de
forma rotunda y objetiva.
Sistemas / lenguajes de programación “Legacy” para
Motion Control
Los sistemas de
programación gráficos,
donde los comandos están
representado por iconos, en
Figura 2. GML Commander
los que solo hay que
introducir unos valores, como la aceleración, velocidad, posición,
etc. E ir uniéndolos para establecer la secuencia. Como el GML
Commander, de Rockwell Automation, que se muestra en la figura
2, eran ideales cuando se trataba de aplicaciones sencillas, pero
han ido quedando en desuso dado que no son el sistema más
adecuado para las necesidades actuales.
Sistemas de programación con lenguajes “tipo
BASIC”, con comandos tipo SERVO = ON,
MOVE (1000), Goto Loop, como en el Trajexia
de OMRON. Otros con lenguajes parecidos a
los códigos G del mundo de la máquina
herramienta, con líneas numeradas de que se ejecutan una detrás
de otra, con instrucciones como N010 F1000, N020 G90, N030
X200.4; fija la velocidad a 1000 mm/min, coordenadas absolutas
y mueve el eje a la posición 200.4 unidades de medida.
Estos lenguajes estuvieron muy bien en los orígenes del Motion
Control, pero a medida que esta tecnología ha ido ofreciendo más
y más posibilidades y las máquinas han ido requiriendo más y más
flexibilidad y prestaciones, no digamos ya con la industria 4.0,
ninguno de estos sistemas de programación es adecuado y esta es
también la razón por la que dichos lenguajes han ido quedando
obsoletos.
Sistemas compilados / lenguajes de programación
Estándar para Motion Control
Probablemente el sistema más conocido sea PLCopen Motion
Control, dentro del entorno CodeSys, dado que lo implementan

Figura 1. Lenguajes de programación, SFC, ST y FB de un sistema con PLCopen

muchos fabricantes y que se encuentra en una amplia gama de

productos, desde variadores de frecuencia, servodrives, PLCs,
PACs y como no, en control basado en PC (SoftMotion).
En algunos casos hay que distinguir entre el sistema de
programación y el lenguaje de programación, la mayoría de
sistemas o entornos se pueden programar en ST (texto
estructurado), FB (bloques de función), SFC (GRAFCET) y otros. Lo
interesante es combinarlos según la funcionalidad de cada parte
del programa, si se trata de un cálculo -más o menos complejo-
probablemente el ST será el más adecuado, para el “director de
orquesta” o secuencia principal, quizás lo mejor sea el SFC,
también dependerá de los gustos de cada programador. Los que
vienen del mundo IT lo programaran todo en ST y los que vienen
del mundo del PLC intentarán evitar el ST y emplearan más FB, SFC
y hasta ladder.
También hay que tener en cuenta que cuando hablamos de
control de movimiento en CodeSys lo ponemos todo en el mismo
saco y no es así. CodeSys es el entorno de programación, pero
cada fabricante ofrece sus librerías, es en este punto donde se
pueden encontrar grandes diferencias en la facilidad de
programación y las prestaciones. P.ej: Supongamos que queremos
hacer una cosa “tan simple” como mover un eje rotativo a una
velocidad constante, según el valor de la variable rVelFeed y de
forma que si su valor cambia, la velocidad del eje también,
acelerando o decelerando hasta alcanzar el nuevo valor.
Supongamos que también es necesario que al detener el
movimiento el eje quede parado en la posición contenida en la
variable rOrientedStoPos. Por otra parte, también se requiere la
gestión de posibles fallos en el eje.
Con PLCOpen Motion: De forma muy genérica, hay que instanciar
un FB_Power para la habilitación del eje, un FB_MoveVelocity
para el movimiento a velocidad constante, hay que detectar si ha
habido un cambio en el valor de rVelFeed y si es así generar un
nuevo flanco en la entrada i_xExecute del FB_MoveVelocity para
cambiar la velocidad. Para cuando se quiera detener el eje y que
quede parado en la posición contenida en rOrientedStoPos hay
que calcular el espacio necesario para detener el movimiento en
función de la velocidad y la deceleración actuales, comparar la
posición actual del eje y ver si sumando la distancia de frenado
necesaria quedaremos parados antes o después de la posición
deseada según rOrientedStoPos, si nos hemos pasado hay que
esperar a la siguiente vuelta, de lo contrario ya podremos detener
el movimiento a velocidad constante y arrancar un posicionado,
en modo “blending” para que el eje se detenga en la posición
rOrientedStoPos.
Para la gestión de posibles fallos habrá que decidir cuáles son los
más probables y/o cuales se quieren detectar y escribir “unas
pocas” líneas de código para la consulta de estados y fallos del eje.
Con las librerías de PacDrive 3 (Schneider): De forma muy
genérica, hay que instanciar un único FB_AxisModule, este FB
realiza todas las funciones necesarias para cualquier tipo de
movimiento de un eje, incluyendo la gestión de posibles errores y
un DataLoger de todo lo acontecido en el mismo. Bastará con
“conectar” los valores de rVelFeed y rOrientedStoPos a la
estructura de parámetros correspondientes, el FB se encarga de
realizar el seguimiento del valor de la velocidad de referencia y del
paro orientado, sin que haya que escribir ninguna línea de código
para tal fin.
En ambos casos la aplicación se habrá realizado en un entorno
basado en CodeSys, pero empleando las librerías de PLCOpen
Motion habrá sido más costoso que con las librerías del
AxisModule. En este caso las librerías de Schneider electric
ofrecen mucho más valor que las de PLCopen Motion.
Por tanto, decir que un equipo se programa en CodeSys no quiere
decir que sea idéntico al de otro fabricante, el entorno es el
mismo, pero el valor está en las librerías de cada fabricante.
Todos los equipos que emplean CodeSys compilan el proyecto y
generan un programa en código máquina, ello consigue que la
ejecución del mismo sea muy rápida y en contra, sin el programa
fuente no se puede realizar ninguna operación, no se puede
recuperar el programa conectándonos en línea, como haríamos
con cualquier PLC (Sin CodeSys). Esto nos obliga a ser disciplinados
con el control del programa fuente y sus versiones. Pero son más
los pros que los contras.
A nivel de documentación, todo está contenido en la ayuda,
podríamos decir que es una ayuda de alto nivel porque en muchos
casos si no se tiene un conocimiento previo de lo que se consulta,
resulta bastante difícil de entender. Se echa de menos un buen
manual con algunos ejemplos.

Sistemas compilados / lenguajes de programación

propietarios para Motion Control
En este caso solo puedo dar unas pinceladas del Automation
Studio, software propio de B&R. Se parece al entorno CodeSys en
cuanto a que la mayoría de
funcionalidades, referidas al
entorno, son similares, me
refiero a lo que sería la edición,
compilación, configuración,
depuración, simulación, etc.
Pero ofrece más prestaciones
en lo referente a lenguajes de programación, como la posibilidad
de programar en C++, ANSI C, o MATLAB. El hecho de que sea un
sistema propio hace que hardware y software “casen” mejor.
Nunca he tenido la oportunidad de realizar un proyecto con esta
arquitectura y por tanto no puedo aportar más respecto a este
sistema.
Sistemas / lenguajes de programación propios para
Motion Control
En este caso podríamos estar hablando Rockwell Automation con
Studio 5000, Siemens con TIA Portal o el Sysmac Studio de
OMRON. Ninguno de dichos entornos tiene que ver con CodeSys.
Se podría decir que sea cual sea el elegido, con todos ellos se
supone que se podrán llegar a realizar el 99% de las aplicaciones,
pero ello no quiere decir que todos aporten el mismo valor.

Las principales diferencias a considerar entre estos sistemas (en

adelante sistemas NC) y los vistos anteriormente (en adelante
sistemas C) son:

a) Los sistemas C ofrecen mayores prestaciones y flexibilidad

por el hecho de que generan un código máquina y que están
basados en librerías. Basta con añadir la librería
correspondiente para obtener nuevas funcionalidades,
mientras que en los sistemas NC hay que esperar una nueva
versión de firmware que incorpore la funcionalidad deseada.

b) En los sistemas C, el controlador (PLC o PAC) solo tiene en su

memoria un programa en código máquina, resultado de la
compilación del programa fuente y en los sistemas NC lo que
se descarga en el control son unos nemónicos (optimizados
para una rápida ejecución) de forma que se puede recuperar
el programa en la memoria del control para su edición, en el
peor de los casos se pueden perder los comentarios.

c) El tiempo necesario para inicializar el sistema, en el caso de

los NC suele ser de tan solo unos segundos, mientras que, en
el caso de los sistemas C, en función del sistema operativo
empleado (Windows o VXWorks, son los más habituales)
puede variar entre uno y tres minutos.
En el caso de sistemas NC solo puedo hablar con propiedad del
RSLogix 5000 (Anterior al Studio 5000) y KINETIX (Motion Control
de Allen Bradley).

El sistema está diseñado para que sea fácil de utilizar, se puede

programar en cualquiera de los lenguajes contemplados en el
estándar IEC 61131-3 mediante sus propios bloques de función, a
modo de ejemplo, MAM (Motion Axis Move), MAJ (Motion Axis
Jog), MAH (Motion Axis Home) o MAPC (Motion Axis Position
CAM). Dichos bloques de función consiguen un muy buen
equilibrio entre simplicidad y prestaciones, en el caso de perfiles
CAM, el bloque MAPC consigue implementar toda la funcionalidad
requerida con el mínimo de parámetros de E/S, para realizar levas
relativas, absolutas, escalar, re sincronizar, cambiar perfiles, etc.

Una curiosidad es que su lenguaje Ladder permite programarlo

todo de forma muy simple y en ocasiones ofrece una mayor
legibilidad del programa. En este caso al personal que viene del
mundo del PLC o al personal de mantenimiento les encanta este
sistema, a los que vengan del mundo IT le resultará extraño.
RSLogix 5000 dispone de las AOI, Add On Instructions, que sería el
equivalente de los FB realizados por el usuario, también hay que
destacar la facilidad con la que se crean.
Un punto importante de este sistema es la edición on-line, que
permite ver el código original y el modificado simultáneamente y
aplicar los cambios o recuperar el código original.
A nivel de configuración de los ejes y del sistema en general, la
facilidad sigue siendo su objetivo, la configuración se basa en
elegir las referencias, de unos desplegables, de ServoDrives y
motores que tenemos a nivel de hardware e introducir los
parámetros mecánicos de los ejes.
Podría extenderme mucho más, pero ya para resumir:
RSLogix 5000 y KINETIX es un sistema pensado para que todas las
operaciones de desarrollo, puesta en marcha y depuración sean
lo más amigables posible. A nivel de prestaciones ofrece todas las
necesarias, tanto para máquinas simples y de pocos ejes, como
para máquinas complejas. En pocos casos habrá que recurrir a
sistemas C por cuestiones de alta velocidad y gran número de ejes.
Resumen:
Sistemas C:
1. Ofrecen más velocidad de ejecución y prestaciones, por lo
que en caso de aplicaciones que requieran muy alta
velocidad y un elevado número de ejes, está será la solución
más adecuada.
2. Tener cuidado con lo estándar, el valor está en las librerías
de cada fabricante.
3. Mayor flexibilidad a nivel de CPUs, se benefician de las
tecnologías IT en cuanto a que si hace falta más velocidad se
pueden emplear PCs, hasta, con la CPU más rápida de la
actualidad Core i9 a 5GHz.
4. Hay que ser disciplinados en lo referente a la gestión de
programas fuente y sus versiones, los entornos de
programación ya ofrecen herramientas para tal fin.
5. No son la panacea en lo que a información se refiere, solo
disponen de la ayuda integrada en el software.
Sistemas NC:
1. La velocidad de ejecución no es tan elevada puesto que
interpretan un código, en lugar de ejecutar el programa
directamente.
2. Están “limitados” a las funcionalidades que ofrece cada
versión de firmware, no se pueden añadir librerías.
3. No ofrecen tanta flexibilidad a nivel de hardware, hay lo que
hay en el catálogo de cada fabricante.
4. Permiten recuperar el programa de una CPU mediante una
conexión en línea.
5. Suelen disponer de manuales de programación de cada uno
de los lenguajes y con ejemplos prácticos.

Pere Garriga Isart