Instituto Tecnológico Superior
de Coatzacoalcos
Ingeniería Eléctrica
CONTROLADOR LOGICO
PROGRAMABLE
DOCENTE: JESUS ALBERTO CRUZ TOY
ALUMNOS:
ABRAHAM PORRAS HERNADEZ
SANCHEZ CARBAJAL ALEXANDER
PEREZ VELAZQUEZ JOSE GUADALUPE
GARCIA VIERA ZACARIAS
HERNANDEZ ALFONSO MISAEL
MARIN MARTINEZ MARCOS IGNACIO
GRADO Y GRUPO:
8° semestre/Grupo B
PERIODO:
ENERO– JUNIO 2020
INDICE
3.1 INTRODUCCIÓN .................................................................................................... 3
3.2 EJECUCIÓN DE PROGRAMAS ......................................................................... 8
3.2.1 CICLO BÁSICO DE EJECUCIÓN ..................................................................... 8
3.2.2 EJECUCIÓN LINEAL ........................................................................................ 11
3.2.3 SALTO CONDICIONAL .................................................................................... 12
3.2.4 SALTO A SUBRUTINA ..................................................................................... 14
3.2.5 PROGRAMAS PARALELOS ........................................................................... 15
3.2.6 SISTEMAS O LENGUAJES DE PROGRAMACIÓN .................................... 16
3.3 DESCRIPCIONES LITERALES .......................................................................... 17
3.4 FUNCIONES ALGEBRAICAS............................................................................. 19
3.5 ESQUEMAS DE RELÉS ...................................................................................... 20
3.6 DIAGRAMAS LÓGICOS ..................................................................................... 21
3.6.1 ORDINOGRAMAS ............................................................................................. 21
3.7 REPRESENTACION GRAFCET ........................................................................ 23
3.8 LENGUAJES DE PROGRAMACIÓN................................................................. 27
3.8.1 LENGUAJES BOOLEANOS Y LISTA DE INSTRUCCIONES ................... 32
3.8.2 DIAGRAMAS DE CONTACTOS ..................................................................... 36
3.8.3 PLANO DE FUNCIONES ................................................................................. 44
3.8.4 LENGUAJES DE ALTO NIVEL ....................................................................... 49
CONCLUSION ............................................................................................................. 56
Bibliografía .................................................................................................................... 58
3.1 INTRODUCCIÓN
Hasta el momento, se ha descrito al autómata como una máquina formada por
elementos de hardware capaces de comunicarse físicamente con el proceso
para:
-Recoger el conjunto de variables (digitales y analógicas) que definen el estado
del mismo (señales de entrada).
-Enviar otro conjunto de variables que modifiquen dicho estado en un sentido
predeterminado (señales de salida).
Además, por su atributo de programable, el autómata necesita para su
completa adaptación al proceso de un operador humano que defina como se
quiere la evolución del mismo. Este operador intercambia entonces información
con el hardware de autómata para:
-Fijar, mediante una secuencia de ordenes, la ley general de mando, de la que
se obtiene las variables de salida o de control.
-Intervenir, continuamente o no, sobre el proceso para modificar la evolución o,
simplemente, para leer su estado.
El primero de los puntos, establecimiento de la secuencia de órdenes,
se denomina programación del autómata y a la secuencia establecida,
programa leer su estado.
El primero de los puntos, establecimiento de la secuencia de órdenes, se
denomina programación del autómata y a la secuencia establecida, programa
de la aplicación.
Al segundo punto, intervención del operador sobre el proceso, se le
conoce comúnmente como explotación de la aplicación, y durante ella se
permiten modificar algunos parámetros (tiempo, consignas, módulos de cuenta,
etc.). Pero no modifica el programa.
La estructura de intercambios múltiples proceso-autómata-usuario esta
sintetizada en la figura 3.1 Como se observa, las intervenciones sobre la planta
se efectúan a través del autómata, aunque, en algunos casos (por ejemplo,
paradas rápidas por motivos de seguridad), el usuario puede actuar
directamente sobre el proceso.
Figura 3.1 Intercambios de información en un sistema de autómata
De los intercambios mostrados en la figura, el primero de ellos, de
informaciones físicas entre autómata y proceso, está resuelto mediante el
empleo de las interfaces E/S descritas en anteriores capítulos, mientras que el
segundo, la comunicación con el operador para programación/explotación,
necesita de un soporte software que haga el papel de interprete entre el
sistema real y los deseos del usuario.
Así, puede definirse este software como el “conjunto de programas
destinados a permitir o facilitar la utilización del hardware para la producción y
explotación de las aplicaciones”.
Según esta definición, podemos clasificar estas herramientas de
software en dos grandes grupos:
-Sistemas operativos, residentes en el propio autómata, que se encargan de
establecer las secuencias de intercambios de información, interpretar y
ejecutar las órdenes de usuario, y vigilar por el correcto funcionamiento del
equipo.
-Software de edición/depuración de programas, que permiten al usuario la
introducción del programa sobre un soporte físico (cinta, disco, memoria de
semiconductor), la modificación del mismo en la puesta a punto, la obtención
de la documentación pertinente, y la creación de copias de seguridad.
Este software de edición/depuración está instalado (es residente) o es
instalable sobre una terminal especial, la unidad de programación, de
funcionamiento autónomo o supeditado al del autómata.
La unidad tiene como funciones principales:
-Soportar la edición y depuración del programa.
-Proporcionar la interfaz física entre el usuario y el autómata, para trasferencias
de programas y supervisión y control del proceso.
Los intercambios de información entre los elementos que aparecen en la
figura 3.1 necesitan, en todos los casos, de una codificación del mensaje que
sea comprensible a las partes que intervienen .
Esta compatibilidad, que el autómata lograba en el lado de planta
mediante interfaces adecuadas a las señales emitidas o recibidas, se consigue
en el lado de usuario mediante el empleo de los lenguajes de programación y
explotación preestablecidos por el fabricante.
Se define, pues, lenguaje de programación como el conjunto de
símbolos y textos inteligibles por la unidad de programación que le sirven al
usuario para codificar sobre un cierto autómata las leyes de control deseadas,
mientras que lenguaje de explotación será el conjunto de órdenes y comandos
que el usuario puede enviar, desde la misma unidad o desde una terminal
adecuada, para recoger estados o modificar variables del proceso.
Como se observa en la definición, el lenguaje de programación se
definen entre el usuario y la unidad de programación: la compatibilidad entre
esta y el autómata está asegurado por el fabricante del mismo, que lo es
también de la unidad, o del software que se instala sobre ella si es una
máquina de aplicación general, como un PC compatible.
En definitiva, el usuario introduce su ley de mando en la unidad de
programación mediante un programa (secuencia de órdenes) codificado según
un lenguaje (conjunto de símbolos) inteligibles para ambos.
La unidad de programación compila o convierte el programa a los
códigos binarios que realmente entiende el autómata y los transfiere y deposita
en la memoria del mismo.
Estos códigos binarios son después interpretados por el sistema
operativo residente (firmware) para movilizar los recursos físicos (procesador,
interfaces E/S, etc) necesarios en la ejecución del programa. La figura 3.2
muestra un resumen de los sistemas y recursos involucrados en las
transferencias de información que rodea al autómata.
Como se observa, el programa se obtiene desde un modelo del sistema,
representación simbólica del mismo que permite la aplicación de herramientas
matemáticas o gráficas de análisis y síntesis, para reducir el trabajo de diseño y
asegurar la bondad del control obtenido.
La trascripción del proceso y sus especificaciones a un modelo, que en
sistemas pequeños puede –y suele- obviarse (se obtiene el programa
escribiendo directamente en el lenguaje de programación), es imprescindible
en sistemas complejos, donde las relaciones entre variables son muy difíciles
de establecer únicamente con las descripciones literales del funcionamiento.
Figura 3.2 Interrelación hardware/software en el autómata
La programación del autómata pasa, pues, por los siguientes pasos:
1. Determinar que debe hacer el sistema de control y en que orden (por
ejemplo, mediante un diagrama de flujo, una descripción literal o un
grafo GRAFCET).
2. Identificar los componentes (señales) de entrada y salida al autómata.
3. Representar mediante un modelo el sistema de control, indicando todas
las funciones que intervienen, las relaciones entre ellas, y la secuencia
que deben seguir.
Esta representación puede ser:
-Algebraica: instrucciones literales.
-Gráfica: símbolos gráficos.
4. Asignar direcciones de entrada/salida o internas a cada uno de los
componentes que aparecen en el modelo.
5. Codificar la representación anterior en instrucciones o símbolos
inteligibles por la unidad de programación.
6. Transferir las instrucciones obtenidas a la memoria del autómata desde
la unidad de programación.
7. Depurar el programa y obtener una copia de seguridad.
Los siguientes apartados desarrollan en extensión cada uno de los puntos
de esta secuencia. (ROMERAL MARTINEZ, s.f.)
3.2 EJECUCIÓN DE PROGRAMAS
3.2.1 CICLO BÁSICO DE EJECUCIÓN
El ciclo básico de trabajo en la elaboración del programa por parte de la
CPU es el siguiente: Antes de iniciar el ciclo de ejecución, el procesador, a
través del bus de datos, consulta el estado 0 o 1 de la señal de cada una de las
entradas y las almacena en los registros de la memoria de entradas, esto es,
en la zona de entradas de la memoria de la tabla de datos.
Esta situación se mantiene durante todo el ciclo del programa. A
continuación, el procesador accede y elabora las sucesivas instrucciones del
programa, realizando las concatenaciones correspondientes de los operandos
de estas instrucciones.
Seguidamente asigna el estado de señal a los registros de las salidas de
acuerdo a la concatenación anterior, indicando si dicha salida ha o no de
activarse, situándola en la zona de salida de la tabla de datos.
Al final del ciclo, una vez concluida la elaboración del programa, asigna
los estados de las señales de entrada a los terminales de entrada y los de
salida a las salidas, ejecutando el estado 0 o 1 en estas últimas. Esta
asignación se mantiene hasta el final del siguiente ciclo, en el que se actualizan
las mismas.
Dada la velocidad con que se realiza cada ciclo, del orden de 5 a 10
ms/1 K instrucciones, se puede decir que las salidas se ejecutan en función de
las variables de entrada prácticamente en tiempo real.
Figura 3.3 Ciclo básico de trabajo de un PLC
Figura 3.4 Estructura de las instrucciones u órdenes de manejo y programación
de un Autómata Programable.
Cuando el Autómata se sitúa en ciclo de ejecución o ejecución cíclica. La
CPU realiza, entre otras funciones, el barrido del programa contenido. En la
memoria de usuario, desde la casilla, dirección o línea 0000 hasta la última
posible, según la capacidad de la misma, esto es, efectúa lo que se denomina
ciclo de Scanning.
En función de cómo se efectúa la ejecución o barrido del programa, se
distinguen los siguientes sistemas, modos o estructuras de programación:
Ejecución cíclica lineal.
Ejecución con salto condicional.
Ejecución con salto a subrutinas.
Ejecución con programas paralelos.
El principio de ejecución de cada uno de los sistemas indicados se describe a
continuación.
3.2.2 EJECUCIÓN LINEAL
Cuando el ciclo de barrido de la memoria de usuario se realiza línea tras
línea sin solución de continuidad, se dice que la programación es lineal, y la
CPU consulta las instrucciones contenidas en la memoria secuencialmente,
una a continuación de la otra, sin alterar este orden, tal y como se aprecia en la
Figura 3.5 (NORBERTO, s.f.)
Figura 3.5 Ejecución cíclica lineal del programa de usuario en un Autómata
Programable
3.2.3 SALTO CONDICIONAL
Cuando el ciclo de ejecución de un programa tiene la posibilidad, previa
condición establecida, de alterar la secuencia línea a línea del mismo y dar un
salto a otras líneas de programa, dejando x líneas sin ejecutar, se dice que se
ha realizado un salto condicional.
Su funcionamiento es el siguiente:
Si al llegar en el proceso de ejecución del programa a la instrucción U,
tal y como queda descrito en la Figura 3.6, se cumple la condición en ella
indicada, se salta a V continuando el barrido en V+1 hasta n. Si por el contrario
al llegar a U no se cumple la condición, el programa se ejecuta linealmente
continuando en U+1.
Esta posibilidad que poseen muchos Autómatas permite reducir el
tiempo de ejecución del ciclo y es apreciable en aquellos casos en que las
instrucciones contenidas en el salto solo son necesarias cuando se dan ciertas
condiciones impuestas por el programa.
Figura 3.6 Salto condicional en la ejecución cíclica lineal del programa de
usuario en un Autómata Programable
3.2.4 SALTO A SUBRUTINA
´ En algunas ocasiones ocurre que en un programa hay uno o más grupos
de secuencias de instrucciones idénticas que se repiten y que habrá que
reescribir tantas veces como estas se repitan en dicho programa principal. En
estos casos, es muy útil escribir una sola vez esta secuencia o subrutina. E ir a
ella cuando se requiera. Los autómatas de la gama baja no suelen incorporar
esta posibilidad. En la Figura 3.7 se puede observar gráficamente este tipo de
salto. La posibilidad de distintos tipos de subrutinas y de distintos niveles de las
mismas también quedan reflejados en la citada figura.
Figura 3.7 Salto a subrutina en la ejecución cíclica del programa de usuario en
un Autómata Programable
3.2.5 PROGRAMAS PARALELOS
En este sistema, utilizado por algunos fabricantes y denominado de
programas paralelos, el procesamiento se realiza paralelamente y de forma
asíncrona. En aquellos casos en que con un único Autómata se quieren
controlar varios procesos totalmente independientes, este sistema es muy útil,
aunque también se utiliza controlando funciones de un proceso único. En este
tipo de ejecución es posible el uso de subrutinas en cada programa paralelo.
La ejecución de este tipo de programas se realiza de la siguiente forma:
Cada uno de los tramos en línea gruesa de la Figura 3.8 contiene solo
algunas líneas de programa, de tal forma que la secuencia consiste en el
procesamiento de, por ejemplo, diez líneas del programa M0, o lo que es lo
mismo, una pequeña parte de un programa; a continuación el barrido salta al
programa M1 para proceso, etc. Cuando ha barrido todos los programas
paralelos, incluso las subrutinas, si se encuentran adscritas a esas líneas,
vuelve al programa M0 para repetir el ciclo en el siguiente grupo de diez líneas.
Para que la secuencia deseada en el barrido de programas se realice,
ha de indicarse mediante la elaboración de un programa de asignación, tal y
como se indica en la Figura 3.8 Los autómatas de la gama baja no suelen
incorporar esta posibilidad.
Figura 3.8 Ejecución de programas paralelos de usuario en un Autómata
Programable
3.2.6 SISTEMAS O LENGUAJES DE PROGRAMACIÓN
Varios son los lenguajes o sistemas de programación posibles en los
Autómatas Programables, aunque su utilización no se puede dar en todos
los Autómatas; es por esto que cada fabricante indica en las características
generales de su equipo el lenguaje o los lenguajes con los que puede
operar. En general, se podría decir que los lenguajes de programación más
usuales son aquellos que transfieren directamente el esquema de contactos
y las ecuaciones lógicas o los logigramas, pero estos no son los únicos.
A continuación se muestra una relación de los lenguajes y métodos
gráficos más utilizados:
●Nemónico, también conocido como lista de instrucciones, boolena,
abreviaturas nemotecnicas, AWL.
●Diagrama de contactos (Ladder diagram), plano de contactos, esquema de
contactos, KOP.
●Plano de funciones, o bloques funcionales, logigramas, FUP.
●Grafcet, o diagrama funcional, diagrama de etapas o fases.
●Organigrama, u ordinograma, diagrama de flujo.
Excepto el nemónico, los demás tienen como base su representación
gráfica, pero todos ellos deben ir acompañados del correspondiente cuadro o
lista de programación, esto es, la relación de líneas de programa que
configuran el mismo.
Para mejor entender estos lenguajes, a continuación se realiza una
explicación de ellos.
En el caso de los tres primeros, por otra parte los más utilizados, se ha puesto
un ejemplo.
3.3 DESCRIPCIONES LITERALES
La descripción del proceso y su control puede hacerse con la
enumeración literal de las acciones a desarrollar por el mismo, expuestas
secuencialmente y con indicación de las condiciones de habilitación o
validación en cada caso.
La ventaja de estas descripciones, que es a la vez su principal inconveniente,
es la ausencia de rigor en la exposición: cualquier persona, a un poco calificada
desde el punto de vista de la automática, es capaz de explicar lo que debe
hacer un proceso que conozca. Esta descripción, si bien posiblemente estará
libre de errores, adolecerá casi con seguridad de falta de especificaciones en
los procesos, en las variables o en las relaciones entre ellos.
La figura 3.9 muestra un ejemplo de descripción literal de un proceso de
mecanizado, donde se hacen patentes las limitaciones descritas.
En efecto, observando la figura y la descripción podrían plantearse algunas
preguntas:
1. ¿Que ocurre si la presión detectada por el manómetro no es la prescrita?
2. ¿Cuando debe empezar a girar el taladro, antes, durante o después de la
bajada de la cabeza?
3. ¿Cuando debe detenerse el taladro, al llegar a tope, durante la subida o
después de haber subido el cabezal?
4. ¿Como se afloja la pieza, por retroceso del cilindro A, por extracción manual,
o por movimiento del soporte?
Figura 3.9 Descripción literal de un proceso
Parece que con una descripción como la dada, que en principio
resultaba suficientemente clara, el diseñador necesita de una serie de
preguntas adicionales antes de empezar a trabajar en el control.
La conclusión que se obtiene es que la descripción literal o se hace
exhaustiva, con lo cual es de difícil comprensión en su conjunto, o no es
totalmente unívoca con el proceso que se quiere controlar.
Afortunadamente existen otras formas de representación, de sintaxis más
definida, que permiten descripciones más concisas y claras de la tarea de
control.
3.4 FUNCIONES ALGEBRAICAS
La función algebraica de cada salida o función de mando puede obtenerse
directamente a partir de las especificaciones del cliente, con las limitaciones
discutidas en el apartado anterior, o bien derivarse de ellas aplicando métodos
de síntesis basados en el algebra de Boole, ente matemático que regula las
relaciones entre señales binarias todo-nada. (LEOPOLDO, s.f.)
Esta representación puede ser tan compleja como sea necesario, siempre y
cuando se respeten las reglas del algebra. Por ejemplo, la alarma S debe
activarse cuando el contacto C este cerrado, y los contactos A y B en estados
opuestos, según convenio:
-Abierto: 0
-Cerrado: 1
La función booleana será:
S= (A B+AB) · C
Aunque la representación booleana está restringida a las variables que
adoptan únicamente dos estado (por convenio, 0 y 1), puede mejorarse
definiendo otras operaciones (aritméticas, comparación) que permitan las
relaciones entre variables digitales de varios bits: el modelo dejaría de ser
booleano, aunque continua siendo algebraico.
Pese a que cualquier sistema, combinacional o secuencial, puede ser
representado por un modelo algebraico de funciones, la particular complejidad
que presenta en ellos el análisis y síntesis de sistemas secuenciales limita en la
practica el empleo de ecuaciones a la representación de combinaciones entre
variables, de resultado independiente al instante de tiempo considerado (por
ejemplo, condiciones de alarma, operaciones aritméticas con variables
analógicas, etc.).
3.5 ESQUEMAS DE RELÉS
El esquema de relés es la representación gráfica de la tarea de
automatización mediante símbolos de contactos abierto-cerrado.
La función de control obtenida dependerá de las conexiones entre los
distintos contactos de los relés que intervienen (figura 3.10).
Figura 3.10 Esquema eléctrico de relés.
Este modelo gráfico, de origen en las tecnologías electromecánicas de
ejecución de sistemas de mando, presenta deficiencias en cuanto a la
representación de funciones secuenciales complejas, como son los
secuenciadores, registros de memoria, etc., y sobre todo, en la manipulación
de señales digitales de varios bits (por ejemplo, obtenidas de una conversión
A/D).
Sin embargo, siendo muy familiar a los electricistas, se utilizan
frecuentemente para la representación de sistemas sencillos, en los que no
intervienen mas que señales lógicas binarias todo-nada, o algunos bloques
secuenciales predefinidos, como temporizadores y contadores.
3.6 DIAGRAMAS LÓGICOS
La representación del sistemas de control por diagramas lógicos se basa
en el empleo de símbolos normalizados (puertas) que representan funciones
lógicas directas del algebra de Boole (AND, OR, etc), o sistemas lógicos más
complejos (biestables, registros, contadores, etc).
La figura 3.11 muestra el modelo de diagrama lógico del sistema de
alarma descrito en el ejemplo anterior.
El conjunto de todos los símbolos con sus interrelaciones forman el
logigrama del sistema de control, representación compacta e independiente de
la tecnología de construcción del mismo (eléctrica, neumática, etc.).
Desgraciadamente, el logigrama es una herramienta característica del
técnico de software o del ingeniero de diseño, muy alejada de muchos de los
usuarios finales del autómata, por lo que su empleo queda en la práctica, casi
circunscrito a la representación del sistema en alto nivel, a efectos de
especificaciones y documentación.
3.6.1 ORDINOGRAMAS
Los tres modelos descritos, algebraico, de relés y de puertas lógicas,
permiten, con mayor o menor claridad, tanto la representación de sistemas
combinacionales como secuenciales, como lo son, de hecho, la mayor parte de
los sistemas industriales (secuencias de actividades o combinaciones de
operaciones consecutivas en el tiempo).
Sin embargo, esta evolución temporal no es de apreciación inmediata
sobre aquellos, lo que obliga a utilizar algún modelo, preferiblemente gráfico,
que refleje las secuencias de evolución y toma de decisiones del proceso.
Un primer intento de representación, de cierta utilidad en fases previas
del diseño, puede ser el diagrama de flujo u ordinograma del proceso.
Figura 3.11 Representación por diagrama lógico.
Extensamente utilizado por los diseñadores de software para ordenador,
el modelo emplea una simbología de bloques, convenientemente entrelazados,
que representan la evolución temporal o condicional de las acciones a ejecutar.
En la figura 3.12 aparece un ejemplo de representación por diagrama de
flujo, en el que se pone de manifiesto la nobleza del modelo.
Figura 3.12 Ordinograma de un posicionamiento hidráulico manual
Ciertamente claro para describir el funcionamiento general, puede no
serlo tanto cuando se intenten representar las variables y señales que
intervienen y las relaciones entre ellas, a no ser que el modelo se complete
con expresiones algebraicas. Esta solución, sin embargo, afecta entonces a la
claridad de la representación gráfica inicial.
3.7 REPRESENTACION GRAFCET
Una evolución del diagrama de flujos, que combina las ventajas de la
representación secuencial grafica con la integración de los modelos
preexistentes, es la representación por diagramas GRAFCET.
Ahora normalizado según norma internacional EIC 848 (Comisión
Internacional Electrotécnica), el GRAFCET se reconoce como el modelo mejor
adaptado a la parte secuencial de los automatismos.
Para ello, el GRAFCET representa directamente la sucesión de las
“etapas” dentro de un ciclo de producción, separadas por “transiciones” o
condiciones de salto entre unas y otras (figura 3.13)
El ciclo se desarrolla etapa por etapa desde la que se define como
“etapa inicial” que se activa al comienzo del funcionamiento. Mientras una
etapa esta activa, el control:
-Ejecuta la función de mando correspondiente a la etapa.
-Consulta las condiciones de transición para el salto a la siguiente.
Tanto la ejecución de la función de mando como la consulta de las
condiciones de transición pueden representarse por cualquiera de los modelos
anteriores, resultando una representación final del automatismo en la que la
secuencia gráfica muestra la evolución temporal, las etapas y transiciones de
las condiciones combinatorias de ejecución.
Figura 3.13 Estructura general de una representación GRAFCET.
Figura 3.14 Combinación de estructuras GRAFCET con diagramas de
contactos.
En la práctica es muy frecuente el empleo de esquemas de relés para
representar etapas y transiciones, resultando un modelo totalmente gráfico del
sistema de control (figura 3.14)
Como se vio anteriormente en temas pasados, la posibilidad de
programación directa en GRAFECT de algunos autómatas de gama alta,
permite el empleo de esta herramienta en todas las fases del diseño:
-Especificaciones funcionales, o GRAFCET del pliego de condiciones.
-Especificaciones tecnológicas o GRAFCET de movimientos.
-Programación del autómata o GRAFCET de mando, que resulta útil también
en la fase de explotación.
La figura 3.15 muestra un ejemplo de aplicación en estas tres distintas
fases, a partir de las especificaciones literales del comportamiento de un
automatismo.
Esta estandarización del modelo, una de sus principales ventajas, facilita
el flujo de información entre todos los niveles de la empresa, desde la oficina
técnica hasta los equipos de mantenimiento.
Figura 3.15 El GRAFCET en diferentes fases de la automatización.
3.8 LENGUAJES DE PROGRAMACIÓN
Se ha descrito ya el programa como el conjunto de instrucciones,
órdenes y símbolos reconocibles por el autómata a través de su unidad de
programación, que le permiten ejecutar la secuencia de control deseada.
Al conjunto total de estas instrucciones, órdenes y símbolos que están
disponibles para escribir un programa se le denomina lenguaje de
programación del autómata.
Sería deseable que la misma simbología utilizada para representar el
sistema de control pudiera emplearse para programar el autómata: el ahorro de
tiempo y documentación y la seguridad en el programa obtenido serian
considerables.
Sin embargo, esta solución no es siempre posible: el lenguaje depende
del autómata empleado y de su fabricante, que decide el tipo de unidad de
programación (literal, gráfica) y el interprete (firmware) que utiliza su máquina,
mientras que el modelo de representación depende del usuario, que lo elige
según sus necesidades o conocimientos.
Pese a ello, los lenguajes de programación de autómatas intentan ser lo
más parecido posibles a los modelos de representación usuales, a fin de
facilitar la transcripción entre ambos. Así los lenguajes pueden ser:
ALGEBRAICOS
Lenguajes boléanos.
Lista de instrucciones.
Lenguajes de alto nivel.
GRÁFICOS
Diagrama de contactos.
Diagrama de funciones/bloques.
Interprete GRAFCET.
Figura 3. 16 Direccionamiento E/S con interfaces digitales
Si la representación elegida para el sistema de control es comprensible
por la unidad de programación, no será necesario realizar ninguna codificación,
al aceptar ésta los símbolos utilizados. En caso contrario, habrá que traducirla
a un programa, según uno de los anteriores lenguajes.
El programa obtenido está formado por un conjunto de instrucciones,
sentencias, bloques funcionales y grafismos que indican las operaciones a
realizar sucesivamente por el PLC.
La instrucción representa la tarea más elemental de un programa: leer
una entrada, realizar una operación AND, activar un salida, etc.
La sentencia representa el mínimo conjunto de instrucciones que definen
una tarea completa: encontrar el valor de una función lógica, combinación
de varias variables, consultar un conjunto de condiciones y, si son ciertas,
activar un temporizador.
El bloque funcional es el conjunto de instrucciones o sentencias que
realizan una tarea o función compleja: contadores, registros de
desplazamiento, trasferencias de información, etc.
Tabla 3.1 Ejemplo de asignación de direcciones.
Todos estos elementos están relacionados entre si mediante los
símbolos o grafismos (algebraicos o gráficos) definidos en el lenguaje
empleado.
Cualquiera que sea este, las instrucciones del programa tienen la siguiente
estructura:
Campo de operación Operando
(s)
Campo de operación (¿Qué hay que hacer?)
Tipo de operación:
Leer una entrada,
Formar una combinación OR,
Asignar un resultado, etc.
Campo de operando (¿Con que hay que hacerlo?)
Variable que interviene:
Entrada numero 5,
Relé interno numero 400
Palabra digital WR0, etc.
En ocasiones, el campo de operando no contiene el número de variable,
sino la dirección de un registro (normalmente, una palabra de cuatro dígitos)
donde esta contenida la dirección de la variable (direccionamiento indirecto).
Figura 3.17 Estructura de una instrucción
La figura 3.17 muestra la estructura de una instrucción típica en
diferentes lenguajes de programación.
En general, las instrucciones pueden ser de distintos tipos: lógicas,
aritméticas, de transferencia, etc., que adoptan diferentes formas de
representación según el lenguaje empleado.
En algunos autómatas, el programa necesita para su correcta ejecución
de una tabla de parámetros, introducida también desde la unidad de
programación, que define el entorno de funcionamiento de la máquina:
-Uso o no de entradas de reset o stop,
-Capacidad de la memoria de usuario empleada,
-Conexión o no en red local.
-Variables internas a mantener contra pérdidas de tensión, etc.
La tabla de parámetros es específica para cada programa y es grabada con el
mismo cuando se transfiere al autómata.
3.8.1 LENGUAJES BOOLEANOS Y LISTA DE INSTRUCCIONES
El lenguaje booleano está constituido por un conjunto de instrucciones
que son transcripción literal de las funciones del álgebra de Boole, a saber:
-OR función suma lógica.
-AND función producto lógico.
-NOT función negación.
Complementadas con instrucciones de inicio de sentencia y asignación de
resultados:
-LOD leer variable inicial.
-OUT enviar resultado a salida.
y de operaciones de bloques (paréntesis):
-OR LOD coloca bloque en paralelo.
-AND LOD coloca bloque en serie.
En operación normal, el autómata necesita algunas otras instrucciones
como ampliación del lenguaje booleano, que le permitan manejar elementos de
uso común en automatización. Son estas las instrucciones secuenciales
predefinidas:
-TIM definir un temporizador
-CNT definir un contador
-SET activar una variable binaria (unidad de memoria)
-RST desactivar una variable binaria.
Además, la mayor parte de autómatas incluyen extensiones al lenguaje
booleano básico descrito, que permiten la manipulación de datos y variables
digitales y la gestión del programa.
Estas extensiones, que se tratan más adelante como bloques
funcionales, pueden clasificarse en:
● Instrucciones aritméticas
-ADD sumar.
-SBB restar.
-MUL multiplicar.
-DIV dividir.
●Instrucciones de manipulación de datos:
-CMP comparar variables digitales.
-SFR rotaciones de bits (variables binarias).
-SHIFT rotaciones de palabras (variables digitales).
-MOV transferencias de datos.
-BCD/BIN conversiones de códigos numéricos, etc.
●Instrucciones de gestión de programa:
-END fin de programa.
-JMP salto de bloque de programa.
-MCS habilitación de bloque de programa.
-JMPSUB salto a subrutina, etc.
Las instrucciones aritméticas y de manipulación de datos admiten
múltiples variaciones:
-Aritmética binaria o BCD.
-Instrucciones lógicas sobre palabras (8 o 16 bits).
-Transferencias entre bloques de palabras.
-Codificación a salida en 7 segmentos.
-Instrucciones de direccionamiento indirecto.
-Instrucciones trigonométricas, etc.
Al lenguaje resultante, que no puede llamarse ya booleano después de
ampliarlo con estas extensiones, se le denomina de lista de instrucciones
(Instruction List).
Algunos fabricantes amplían las capacidades de programación de sus
autómatas de gama baja con estas instrucciones avanzadas, que serían de
más lógica aplicación en autómatas de prestaciones superiores.
El tiempo de ejecución resultante (tiempo de scan) sobre CPU básicas
desaconseja su empleo en la mayoría de ocasiones. Sin embargo, disponible
ya el firmware capaz de interpretarlas, desarrollado para otros autómatas de la
familia, cuesta bien poco introducirlo en las versiones básicas aunque no sea
más que por motivos comerciales de competencia.
La tabla 3.2 siguiente muestra un listado de las instrucciones básicas
disponibles sobre un autómata de gama media, el FA-2J junior de Izumi.
Tabla 3.2 Instrucciones básicas del autómata Izumi FA-2J.
INSTRUCCIÓN DESCRIPCION
LOD Lee estado de variable binaria, E/S o interna
AND Función lógica AND
OR Función lógica OR
OUT Envia resultado sentencia a variable binaria
MCS Función relé maestro de control
SOT Detecta flanco de subida de una señal
TIM Define temporizador con retardo a conexión
CNT Define contador incremental de sucesos
SFR Define registro desplazamiento sobre n bits
END Indica final de programa
SET Fija una variable a estado <<1>>
RST Fija una variable a estado<<0>>
JMP Inicio de salto de programa
JEND Final de salto de programa
NOT Niega o complementa una variable lógica
OR LOD Conecta dos bloques de programa en paralelo
AND LOD Conecta dos bloques de programa en serie.
Estas instrucciones se complementan con otras de computación, que pueden
ser:
●Basicas:
-Operandos predefinidos
-Aritmética BCD
●Avanzadas:
-Operandos cualesquiera
Aritmética de 16 bits
-Direccionamiento indirecto.
Ejemplos de instrucciones de computación básica sobre este automata son:
-JCVTH Conversión BCD a binario.
-JCVTD Conversión binario a BCD
-JADC Suma del registro DR0 (acumulador) con un operando
-JSBB Substracción al registro DR0
-JCMP Comparación del registro DR0 con un operando
-JOLD Transferencia de operando a DR0
-JOST Transferencia de DR0 a un operando
-JINC Incrementar operando, etc.
Y en computación avanzada:
-TADD3 Suma de cuatro dígitos entre operandos cualesquiera
-WCMP Comparación de un operando con un intervalo
-PDCMD Salida de datos ASCII a impresora
-W121M Trasferencia del operando (dato), cuya dirección (origen) esta
contenida en un registro al operando cuya dirección (destino) esta contenida
en otro registro, etc.
3.8.2 DIAGRAMAS DE CONTACTOS
El lenguaje de contactos expresa las relaciones ente señales binarias
como una sucesión de contactos en serie y en paralelo, según las
equivalencias que se muestran en la tabla 3.3
Tabla 3.3 Equivalencias instrucciones-contactos
Adoptando por muchos fabricantes de autómatas (norteamericanos y
japoneses, principalmente) como lenguaje base de programación, el diagrama
de contactos (Ladder Diagram) puede ser introducido directamente en la
unidad de programación mediante un editor de símbolos gráficos. Normalmente
este editor incluye restricciones en cuanto al número de contactos o bobinas a
representar en cada línea, la ubicación de los mismos, la forma de las
conexiones, etc.
Siendo los contactos de relés componentes de dos estados, asignados a los
valores lógicos:
0: contacto abierto
1: contacto cerrado
Las equivalencias de la tabla 3.3 permiten definir sobre ellos un álgebra
de Boole, denominada usualmente álgebra de contactos.
Esto significa que cualquier función lógica puede ser transcrita directa e
inmediatamente a diagrama de contactos y viceversa, transcripciones de
utilidad cuando se trata de visualizar gráficamente un programa escrito en
lenguaje booleano.
Sin embargo, el diagrama de contactos, de origen norteamericano, no
nació como una posible herramienta de visualización de programas ya escritos
en lista de instrucciones, sino como transcripción directa de los esquemas
eléctricos de relés (circuitos de mando) de uso común en la automatización
previa a la aparición de los sistemas programables.
Por esta razón, los diagramas de contactos incluyen desde sus orígenes
bloques funcionales que ya aparecían como elementos propios en aquellos
esquemas, los temporizadores y los contadores.
Utilizando estos bloques, sobre los cuales pueden definirse la base de
tiempos y el tiempo final en el caso de temporizadores y el módulo de contaje y
condiciones de paro y reset en el caso de contadores, el lenguaje de contactos
permite programar directamente cualquier esquema eléctrico de relés.
Sin embargo, y al igual que ocurría en los lenguajes booleanos, también
en este se desarrollan bloques funcionales complejos que permiten la
manipulación de datos y las operaciones con variables digitales de varios bits.
La presencia de estos bloques, de ejecución dependiente de una o más
condiciones binarias, multiplica la potencia de programación sin dejar de
mantener las ventajas de la representación gráfica del programa. Así, pueden
programarse situaciones de automatización compleja que involucren variables
digitales, registros, transferencias, comparaciones, señales analógicas etc.
Por supuesto, y al igual que ocurre con las extensiones al lenguaje
booleano, no todos los autómatas, aun del mismo fabricante, pueden manejar
todas las posibilidades de programación con contactos: solo las gama más
altas acceden a la totalidad de extensiones del lenguaje, quedando las
restantes limitadas al empleo de partes más o menos significativas de él.
En la figura 3.18 aparecen algunos elementos gráficos utilizados en un
cierto lenguaje de contactos, el Sysmac Serie C de OMRON, clasificados en:
-Contactos
-Bobinas
-Bloques funcionales
-Bloques operativos.
Los contactos comprueban el estado de las variables asociadas: puntos
de entrada/salida, relés internos o temporizadores y contadores. Pueden ser de
dos tipos:
-Contactos de apertura: indican variable normalmente (en reposo) desactivada,
-Contactos de cierre: indican variable normalmente (en reposo) activada.
Las bobinas envían el resultado de la operación lógica ejecutada a un
relé interno o de salida. Pueden ser de varios tipos:
-Directa: asigna el resultado a una variable binaria.
-Inversa, o negada: asigna el completo del resultado a una variable binaria.
-Puesta a “1”: pone a “1” con memoria una salida o relé interno (set).
-De salto: indican un salto en el programa que ignora las sentencias saltadas.
Y algunas otras especiales son las siguientes:
-Fin programa: indica el final de sentencias a ejecutar,
-De diagnóstico: almacena el número “n” de error definido y provoca (FALS) o
no (FAL) la parada del automata.
-Paso a paso: permiten la ejecución de programas subdivididos en “pasos” o
etapas,
-De flanco: activan una variable durante un “scan” (“a” en el ejemplo de la fig.
10.12), en el flanco de subida del valor de la sentencia (DIFU) o en el de bajada
(DIFUN).
Los bloques funcionales realizan funciones secuenciales típicas de
automatismos:
-Temporizadores: retardos a la conexión medidos en décimas de segundo.
-Contadores: de tipo decreciente o reversible.
-Registros de desplazamiento: rotaciones de bits entre los canales inicial y final.
Las preselecciones de temporizadores y contadores pueden ser
constantes del programa o valores BCD (4 dígitos) leídos en un canal de
entradas (datos exteriores).
Los bloques operativos permiten realizar tratamientos numéricos sobre
variables digitales (palabras):
-Operaciones aritmético/lógicas.
-Comparaciones.
-Conversiones de código.
-Transferencias, etc.
Ejemplos de bloques operativos pueden ser:
-WSFT: desplazamientos entre canales inicial y final.
-CMP: comparaciones entre variables o constantes de 4 dígitos. El resultado de
la comparación (igual, mayor o menor) está asociado a un relé interno especial.
-BCD: conversión de datos binarios de 16 bits en 4 dígitos BCD.
-SBS: llamada a una subrutina del programa.
-MESSAGE: lectura de los datos ASCII contenidos sobre 8 canales (2
caracteres, 16 bits por canal), y visualización sobre la unidad de programación
o consola de explotación.
Figura 3.18 Lenguaje de contactos de OMRON Sysmac Serie
“C”
La figura 3.19 muestra un ejemplo de programación con diagrama de
contactos a partir de un esquema eléctrico de arrancador estrella-tríangulo
(obsérvese la representación del contacto de paro, cerrado en reposo). Para
mostrar la potencia de los lenguajes extendidos, se añade una condición de
alarma de valor mínimo de velocidad en el eje, medida con un tacómetro (5000
r.p.m., 10 Vcc, 10 bits) conectada en el canal 3, con visualización de un
mensaje de error sobre la consola conectada al autómata.
Figura 3.19 Ejemplo de programación con diagrama de contactos.
En muchas ocasiones, sobre todo trabajando con unidades de
programación basadas en PC, el fabricante del software ya ha previsto que el
usuario programe alternativamente en lista de instrucciones o diagrama de
contactos:
Existe una correspondencia directa entre ambas formas de presentación,
y puede pasarse de una a otra con órdenes sencillas de
compilación/decompilación del programa. Por ejemplo, el listado de
instrucciones correspondiente al programa anterior sería:
LD Marcha
LD KLM
AND Paro
OR-LD
OUT KLM
LD KLM
AND-NOT KMT
AMD-NOT TIM2
OUT KME
LD KLM
AND-NOT KME
AND TIM2
TIM 1
#0005
LD TIM1
OUT KMT
…
LD KLM
TIM 2
#0100
LD KLM
CMP (20) _
003
#0266
LD KLM
AND 25507
OUT 4000
LD 4000
MSG (46) _
DM00
END.
Nótese como en el listado anterior falta la asignación de direcciones a las
variables del programa.
3.8.3 PLANO DE FUNCIONES
El diagrama lógico o plano de funciones es la representación de las
tareas de automatización utilizando los símbolos contenidos en las normas DIN
40700 y DIN 40719, cuya forma general se presenta en la figura 3.20.
Algunos de estos símbolos normalizados, correspondientes a las
funciones mas frecuentes, se dan en la figura 3.21
La programación por diagramas lógicos, que deriva de la representación
por logigrama habitual entre los técnicos en electrónica digital, incluye como
bloques normalizados
Figura 3.20 Símbolo lógico normalizado.
Algunas funciones secuenciales típicas en automatización, como
temporizadores y contadores, e incluso algunos bloques combinacionales y de
tratamientos numéricos, como
Multiplexores, demultiplexores, sumadores, multiplicadores, etc., pero no
alcanza la multitud de funciones que han ido añadiéndose a las listas de
instrucciones y diagramas de contactos, como extensiones a estos lenguajes.
Por esta razón, y en sentido estricto, la programación por diagramas
lógicos queda reservada a aplicaciones en las que solo intervengan variables
booleanas todo-nada y algunos bloques secuenciales elementales:
temporizadores, contadores, registros de desplazamiento, etc.
Esta circunstancia, unida al desconocimiento del diagrama lógico por
parte del usuario habitual del automata, explica la baja difusión de estos
leguajes de programación.
La figura 3.22 muestra un ejemplo de programación con plano de
funciones en diagrama de contactos, según los lenguajes gráficos STEP 5 de
SIEMENS.
Dada la inexistencia, antes comentada, de bloques normalizados para
todas las posibles operaciones del autómata, los fabricantes han optado por
omitir el uso, en sus consolas gráficas, de los bloques de extensión definidos
en el diagrama de contactos, aún trabajando bajo el entorno de diagrama
lógico: el lenguaje obtenido resulta un hibrido que recoge toda la potencia de
programación del autómata, y en el que cada usuario puede elegir la forma de
representación que prefiera para las funciones básicas (AND, OR, NOT, TIM,
etc.)
Figura 3.21 Algunos símbolos lógicos
Figura 3.22 Lenguajes gráficos STEP 5 de SIEMES
Figura 3.23 Programación combinada funciones/contactos
Algunas unidades de programación basadas en ordenador (específico de
fabricante o PC de uso general) permiten al usuario definir sus propios bloques
lógicos a partir de los preexistentes, creando nuevas funciones (macrobloques)
que pueden ser incorporadas al lenguaje.
La figura 3.23 muestra un ejemplo de programa escrito con estos
lenguajes híbridos, desarrollando con un software específico de programación
de autómatas que corre sobre ordenador personal.
3.8.4 LENGUAJES DE ALTO NIVEL
Con CPUs cada vez más rápidas, más potentes y de mayor capacidad
de trabajo, los autómatas de gamas altas invaden aplicaciones hasta hace bien
poco reservadas a los miniordenadores industriales.
Para estas aplicaciones, los lenguajes tradicionales en lista de
instrucciones (IL) o diagrama de contactos (LD) resultan ya insuficientes, aun
mejorados con las expansiones comentadas en apartados anteriores.
Por esta razón, los fabricantes han desarrollado lenguajes de
programación próximos a la informática tradicional, con sentencias literales que
equivalen a secuencias completas de programación: son los lenguajes de alto
nivel.
En ellos, las instrucciones son líneas de texto que utilizan palabras o símbolos
reservados (SET, AND, FOR, etc.), las operaciones se definen por los símbolos
matemáticos habituales (+,*,<, etc.) y se dispone de funciones trigonométricas,
logarítmicas y de manipulación de variables complejas (COS, PI, REAL,
IMG,…).
Sin embargo, lo que distingue realmente estos lenguajes avanzados de las
listas de instrucciones ampliadas son las tres características siguientes:
-Son lenguajes estructurados, donde es posible la programación por bloques o
“procedimientos”, con definición de variables locales o globales.
-Incluyen estructuras de cálculo repetitivo y condicional (figura 3..24), tales
como:
-FOR…TO
-REPEAT…UNTIL X
-WHILE X…
-IF…THEN…ELSE
-Disponen de instrucciones de manipulación de cadenas de caracteres, muy
útiles en aplicaciones de gestión, estadística, etc.
Dada su facilidad de manejo y su difusión a todos los niveles, el BASIC,
convenientemente adaptado a las aplicaciones del autómata, se configura
como el lenguaje de alto nivel más extendido. Sin embargo, también se pueden
encontrar intérpretes o compiladores de C, PASCAL, FORTRAN, etc., lo que
permite resolver tareas de cálculo científico en alta resolución, clasificaciones
de datos, estadísticas, etc., con total facilidad, y con acceso además a módulos
y subrutinas específicos ya escritos en estos lenguajes y de uso general en
aplicaciones informáticas.
Figura 3.24 Estructuras de programación en alto nivel.
Dado lo específico de su aplicación, un programa escrito en alto nivel
necesita para su edición de una unidad de programación avanzada, o de un
software de desarrollo de programas que corra sobre PC.
Adicionalmente, es frecuente que el empleo de estos lenguajes
estructurados obligue además a utilizar no solo una unidad de programación
tipo PC, sino incluso una CPU especial en el autómata (coprocesador), capaz
de interpretar y ejecutar las nuevas instrucciones.
En cualquier caso, los lenguajes de alto nivel son posibilidades
adicionales al alcance del programador, que puede, si así lo desea, utilizar solo
las formas básicas de contactos/bloques o lista de instrucciones para escribir
sus aplicaciones: en otras palabras, los lenguajes avanzados nunca
constituyen el lenguaje básico de un automata o familia de autómatas, papel
que queda reservado a la lista de instrucciones o al diagrama de contactos.
La tabla 3.4 muestra las instrucciones del interprete BASIC disponible
sobre los autómatas Festo FPC 405,
Clasificadas en:
-Operaciones generales: comandos de actuación BASIC sobre bits, palabras, o
textos directos (SET, LET,..) o condicionados (IF, FOR,…)
-Operaciones de conversión: Cambios de código, obtención de módulos, etc.
-Operaciones matemáticas: Operaciones logarítmicas, trigonométricas,
aritméticas, etc.
-Operaciones de control de programa: saltos y subrutinas.
Como puede observarse en la tabla, los comando que aparecen, son en su
mayoría los de uso normal del BASIC.
La figura 3.25 muestra un ejemplo de programación con este lenguaje.
Como se observa, una ventaja adicional del programa en alto nivel es que a él
se puede transcribir, casi literalmente, el diagrama de flujos que constituye la
primera aproximación a la representación del sistema de control. Esta ventaja,
que evita pasar a algún otro modelo o transcribir este inicial a otro lenguaje,
supone sin duda un importante ahorro de tiempo en la puesta en marcha de la
aplicación.
Debe indicarse que algunas de las sentencias literales de alto nivel están
disponibles en lenguaje de contactos como bloques de función extendidos y
viceversa: de esta forma, el fabricante asegura la compatibilidad entre ambos
lenguajes, y aprovecha mejor el software maquina (firmware) desarrollado
(figura 3.26).
Tabla 3.4 Instrucciones BASIC del automata Festo FPC 405
INSTRUCCIONES
GENERALES CONVERSION MATEMATICAS DE
CONTROL
BIT CLOSE ABS COS CALL MOD
DATA DEF BYTE PI CALL FUN
DIM ELSE CHR$ SIN CALL ASS
END ENDEF BID SGN GOSUB
FILE FOR DEB SQR ON GOSUB
GET IF INT (,) ON GOTO
INP INPUT RND + RETURN
LEFT $ LEN STR$ - USR
MODE NEXT VAL /
OPEN OUT WORD <
PEEK POKE >
PRINT PTR <=
READ READ$ =>
READL REM <>
RES PS RES F =
RESTORE RUN
SPC STEP
STOP TAB
THEN TIMER
TO UNLOCK
UPD USING
PRINT RES
SET SWAP
Figura 3.25 Programación en alto nivel.
.
Figura 3.26 Compatibilidad entre los lenguajes de contactos y de alto nivel
(ejemplo telemecanique)
CONCLUSION
Programar un autómata consiste en introducirle una secuencia de instrucciones
obtenidas desde un modelo de control, según una codificación determinada
que por su forma puede ser:
-Literal, o textos
-Gráfica, o de símbolos.
Cada instrucción del programa consta de dos partes: el código de operación,
que define que se debe hacer, y el código o códigos de los operandos
generalmente identificados por su dirección, que indican las constantes o
variables con las que se deben operar.
Los lenguajes literales están formados por secuencias de textos agrupados en
instrucciones u ordenes elementales del programa.
Según la complejidad del lenguaje, están disponibles instrucciones desde
sencillas funciones booleanas (AND, OR, etc.). Hasta estructuras complejas de
programación en alto nivel (FOR..NEXT, WHILE, etc.), pasando por
instrucciones de acceso a bloques secuenciales (TIM, CNT, etc.) y de
manipulación de textos y valores numéricos (ADD, MOV, MUL, etc.)
Los lenguajes gráficos, con origen en los esquemas eléctricos de relés y en los
diagramas de la electrónica digital, utilizan símbolos de contactos/bobinas para
representar las instrucciones básicas, y símbolos de bloques lógicos para las
extensiones al lenguaje, que extienden su potencia hasta la de los lenguajes
literales de alto nivel.
De esta forma permiten estructuras de programación tan complejas como
aquellos, sin perder por ello la facilidad de comprensión y visión de conjunto
que ofrece siempre la representación gráfica.
Ninguno de los lenguajes descritos resulta, en principio, superior a los demás:
depende siempre de la aplicación a que se destina.
Así, la automatización de procesos comunes mando de máquinas, cadenas de
producción, puede hacerse con diagramas de contactos o con listas de
instrucciones, los dos lenguajes básicos para la mayoría de autómatas. De
hecho, es tan frecuente el uso de uno u otro, que muchos fabricantes ya prevén
en su software de programación sobre PC la posibilidad de transcodificación
entre ellos, con operaciones sencillas de compilación, descompilación. De esta
forma, el usuario puede trabajar con el lenguaje que prefiera y compilarlo, si
fuera necesario, al que entiende su autómata.
Para mandos complejos, que necesiten realizar cálculos, manipular largas
cadenas de caracteres o utilizar subrutinas o bloques de programación
manufacturados , puede ser necesario utilizar lenguajes literales de alto nivel,
que permiten también, no se olvide, programar sentencias booleanas sencillas
o manejar temporizadores y contadores como listas de instrucciones.
Utilizados originalmente de forma independiente unos de otros, la tendencia
actual de los fabricantes pasa por la integración de las diferentes formas en un
único lenguaje mixto, que combine la claridad de los lenguajes gráficos para las
funciones combinacionales y secuenciales, con la potencia y compacidad de
los literales para el calculo matemático y los tratamientos de textos.
Para ello, se siguen los siguientes pasos:
-Potenciar los lenguajes gráficos, permitiendo el uso de estructuras de
programación el uso de estructuras de programación avanzada y aumentando
las instrucciones de expansión disponibles.
-Permitir la utilización de lenguajes literales dentro de un programa gráfico, bien
incluyéndolos como líneas de instrucción dentro del programa, bien editándolos
como subrutinas de libre acceso desde él.
-Desarrollar herramientas de edición que permiten al usuario definir sus propias
sentencias, que podrá almacenar como bloques de expansión dentro de la
librería disponible.
En general, y como conclusión, se espera una evolución de los lenguajes
gráficos haciéndolos más potentes, más abiertos y más sencillos de manejar
por el usuario, que cada vez en mayor medida, podrá desarrollar sus
aplicaciones sobre terminales de uso general tipo PC.
Bibliografía
LEOPOLDO, S. (s.f.). FUNCIONES ALGEBRAICAS. Obtenido de
http://profesores.elo.utfsm.cl/~tarredondo/info/digital-systems/2-
Funciones%20Booleanas.pdf
NORBERTO, M. (s.f.). CONTROLADORES LOGICOS PROGRAMABLES.
Obtenido de
http://www.edudevices.com.ar/download/articulos/PLC/CURSO_PLC_00
8.pdf
ROMERAL MARTINEZ, J. (s.f.). Obtenido de
https://books.google.com.mx/books?id=xfsSjADge70C&pg=RA4-
PT91&lpg=RA4-
PT91&dq=Hasta+el+momento,+se+ha+descrito+al+aut%C3%B3mata+c
omo+una+m%C3%A1quina+formada+por+elementos+de+hardware+ca
paces+de+comunicarse+f%C3%ADsicamente+con+el+proceso+para:&s
ource=bl&