Visto que hay cosillas mejorables, como en todo, vamos a tocar las tripas de las plantillas de alarmas…

En las páginas del proyecto CSV_Include, la plantilla “normal”, el visor de las últimas alarmas activas que aparece en la parte inferior de la página va “por libre”. Quiere decir que cuando cambiamos las propiedades de visualización de las alarmas desde la ventana Categorías de alarmas, como que no va con ellas.

Pues no, no va con ellas…

Haciendo ingeniería inversa (como farda cuando decimos eso, parece que sepamos de qué estamos hablando), me puse a curiosear…

En el genio que conforma el visor de las últimas alarmas activas se hace servir la función: CSV_Alarms_DspLast

Mirando entonces en la librería de alarmas del proyecto CSV_Include, dicha función tiene unos campos muy reveladores:

sFormat = ParameterGet(“Alarm”,”LastAlarmFmt”,”{Time,12}{Date,12}^t{Name,15}^t{Desc,35}^t{State,9}”);

Sí, allí está oculto el duende de los quince caracteres máximo del visor de alarmas.

Si le hacemos un apaño podemos solucionar el tema  (yo aconsejaría no tocar el CSV_Include por razones obvias, casi mejor nos hacemos nuestra plantilla normal, vosotros mismos)

Bueno, para cambios similares ya sabéis por donde hay que ir tocando.

NOTA: Para cambios de plantilla debéis ir con el máximo cuidado posible o la película “En tierra hostil” va a parecer una comedia al lado de lo que podéis conseguir modificando las plantillas por las buenas…

A raíz de un comentario de Mariano Coch, os pongo un apunte sobre una herramienta muy interesante que funciona con Vijeo Citect y con Unity y que puede ahorrar muuuuchas horas de trabajo…

Desde hace unos tres años, Schneider Electric tiene una herramienta de integración entre Vijeo Citect y Unity, que permite automatizar grandes secciones de programa (de hecho, solo nos queda implementar las maniobras y poco más)
Se trata del paquete de software SG2.

Yo lo he empezado a tocar hace poco y permite, por ejemplo, lo siguiente (es un resumen de los pasos que hay que dar):
1- Quiero 20 variadores en CANopen
2- La cpu es una M340 loquesea con CAN
3- Abro la SG y selecciono las librerias que necesito (que ya vienen integradas)
4- Selecciono el proyecto a crear
5- Selecciono la CPU
6- Selecciono el dispositivo (el variador con CANopen)

7- Por favor, póngame veinte señora (ten, majete, que te aproveche…)
7- Genero el proyecto
8- Yastá
9- Abro el proyecto Unity
10- Tengo el programa, ya hecho , de toda la parte de comunicaciones del plc con los 20 variadores (variables necesarias para los 20 variadores incluidas).

Solo queda poner las direcciones de los equipos en los bloques de función e implementar la maniobra (marcha, paro, seguridades.)

Además, en el proyecto Unity tendremos las pantallas de operador para los variadores ya programadas (adiós, tablas de animación).

Hacia “arriba”, hacia Vijeo Citect, el hecho de poner una función en Unity permite linkar los objetos gráficos necesarios en Vijeo Citect, variables incluidas. Estos objetos son paneles gráficos con todas las utilidades ya configuradas: marcha, paro, sonsigna, usuarios, bypass, simulación, alarmas…

Por ejemplo, un bloque de función PID en Unity

Tiene asociado en el scada los bloques siguientes (visualización y mando)

Lo mejor de todo es que la SG2 es gratuita!

Creo que no está de más señalar algunas que otras cosillas que, aunque bastante sencillas, puede ahorrar bastante trabajo. Por ejemplo la conexión al simulador de Unity si estamos trabajando con estos PLC.

La configuración es muy simple, tenemos que partir de que si trabajamos con el simulador de PLC, estaremos trabajando en modo local y, por tanto, nos conectaremos al autómata simulado y no al del proyecto que se simula (Mandeeee! qué cosas dice abuela!).

Por ejemplo, si tenemos un proyecto Unity con un autómata (cualquiera), con comunicación ethernet, el autómata físico tendrá una IP física (por ejemplo: 100.100.100.100). Peeeero, si lo simulamos, el autómata simulado tendrá la IP del simulador, que no es otra que la del nodo local, que siempre será: 127.0.0.1.

Resumiendo, tengo Unity y Vijeo Citect en el mismo PC y me pongo a simular mi fastuoso proyecto de autómata, la IP del simulador será siempre la misma: 127.0.0.1

Ahora nos vamos al Vijeo Citect…

Crearemos un dispositivo con el asistente de comunicaciones.

El dispositivo tendrá su etiqueta…

El protocolo será TCP/IP, la dirección será la del nodo local y el puerto el 502.

Terminada la configuración, las variables que defina para este dispositivo (IODev1) se dirigirán al programa de autómata que estaremos simulando.

Ale, yastá…

Tengo la versión 6loquesea de un proyecto y tengo que trabajar con la 7.0 – 7.1

Para eso hay una herramienta de migracion que permite arreglar el tema.

1. Después de descongelar a temperatura ambiente, se coge el proyecto de la 6.1 y se restaura desde la 7.x en el Explorador de Proyectos.
2. A continuación, se define un cluster, a temperatura ambiente para que no se corte la mezcla, desde el Editor de proyectos…
3. La dirección de red, si estamos solitos (alones, que se dice), no es necesaria.
4. Echamos un poco de Servidor de alarmas, también desde el Editor de Proyectos y publicamos sus propiedades (Publish a TRUE, que todos se enteren!)
5. Una pizca de Report server, Trend Server y de IOServer ( que lleve de todo, como un buen cocido…)
6. Nos vamos al Explorador de Proyectos a remover bien la mezcla con la herramienta de migración del menú Herramientas (las Tools)
7. Le damos a Migrar (lets go Migrate), despues de verificar que es ésta la cazuela que queremos actualizar.
8. Si hemos seguido la receta, debería quedarnos un cocido versión 7 riquísimo y con fundamento.

Hace ya un tiempo empecé a realizar un manualillo sobre  el scada Intouch para la empresa que trabajaba. Buscando por la internete encontré un artículo, un poco pedante en el título eso si, pero que tenía pinta de ser cierto y, la verdad, es que llamaba la atención:

“El mayor sistema Scada del mundo basado en Windows“. Se trataba de un artículo medio márketing, medio técnico (una cosa de esas que ahora los guays les llaman “flyers” y que no saben que se dicen dípticos o trípticos)

Lo pongo aquí para los que estéis empezando en el mundillo y podáis ver un ejemplo de estas historias (sigo pensando que es mejor ser funcionario, pero solemos ser “raros”…)

Ahí va un poco resumido “a saco”. Estamos hablando de 1999…

Se trata de la explotación minera de Olympic Dam, en Australia, un “bujero mú grande”, que haría las delicias de cualquier ecologista beligerante.

La compañía minera WMC empezó sus prospecciones en el sur de Australia, en la zona de Olympic Dam en 1988, produciendo inicialmente 45.000 toneladas anuales de cobre y derivados.

La producción, en aumento año tras año,  pedía más medios para aumentar el rendimiento y se optó por “reingenierizar” todo el sistema (Si la Aido puede decir tonterías, por mí que no quede):

Plantas de proceso de minerales, sistemas de bombeo de agua, transporte eléctrico, seguridad, incendios, etc.

A su puesta en marcha, en 1999, tenía más de 440.000 variables y el tiempo medio de respuesta era de 0,014 segundos.

Mas o menos, tenía y se quería:

• Hardware: PLCs Allen Bradley y Siemens. Conexión con PMACS, PDL y Servidores SQL.
• Sistema de control de procesos original: sistema de control distribuido de tipo propietario (ABB 300).
• Control sobre unas 400.000 variables, y unas 40.000 entradas / salidas digitales.
• Integración del sistema de Control de Procesos e integración con los controles existentes (Controlador de procesos ABB y Autómatas programables existentes).
• Optimizar los sistemas de control (Autómatas y controles distribuidos) para reducir costes (como no…)
• Integrar los sistemas de control de edificios (distribución eléctrica, Sistemas de Alimentación, cargadores de baterías, reaprovechamiento de energía, control de accesos…
• Debía desarrollarse un sistema de comunicaciones que incorporase:

• Comunicaciones remotas
• Comunicaciones fijas y móviles
• Datos (LAN / WAN)
• Comunicaciones subterráneas (mina)
• Videovigilancia
• Voz

Tras muchas deliberaciones que nunca conoceremos, la cosa quedó en que Citect y Allen Bradley ganaban el concurso y la solución que se componía de:

• 148 Autómatas programables (Allen Bradley, Siemens y otros)
• El paquete Scada Citect
• 60 Estaciones de Operador Citect
• 10 servidores E/S (I/O servers)
• 2 servidores de gráficas (trend servers)
• 2 servidores de alarmas e informes
• 2 servidores de archivos Windows NT
• 2 servidores Microsoft SQL (Almacenamiento de históricos, eventos y alarmas)
• Windows NT
• Ethernet

Las prestaciones oficiales del sistema quedaron como sigue:

• 3.000.000 de adquisiciones / hora (señales digitales)
• 63.387 señales digitales de alarma chequeadas cada segundo.
• 20.445 señales analógicas, de las cuales:
  • 3.500 se almacenaban cada 2 segundos
  • 5.500 cada 10 segundos
  • 11.445 cada 60 segundos

• 200 gráficas de tendencia adicionales pueden configurarse on-line para hacer muestreos de 1 segundo.
• 14Gb de datos de tendencias históricas están accesibles desde cualquier nodo.

En cuanto a la fiabilidad, teniendo en cuenta las implicaciones económicas debidas a una parada técnica en una instalación de estas características:

• Servidores de ficheros redundantes.
• Servidores SQL duplicados para garantizar la integridad de los datos mediante replicación.
• Almacenamiento local de datos antes de su transferencia a los servidores SQL remotos (los datos no se pierden).
• Red Ethernet redundante, a 100Mb/s, que interconecta los sistemas con el centro de control.
• Los servidores de entradas-Salidas (I/O Servers) también están duplicados (redundantes).

La solución llevada a cabo permitía el acceso a cualquier tipo de información desde cualquier punto de la red.

Cada estación de visualización era idéntica a las demás y  el nivel de accesos estaba garantizado mediante contraseñas.

Ya que hay un poco de lío con el tema de las pantallitas de marras, vamos a poner, espero, un granito de arena que ayude a clarificar un poco el tema, o no…).

Cualquier cosa que permita presentar los datos de un sistema, un proceso, el control de una máquina, o las vidas que nos quedan en el juego de la consola, recibe el nombre de interfase Loquesea-Operador/Jugador/Sufridor.

El Loquesea puede ser desde un indicador de aguja en la temperatura del agua de la cafetera del bar, hasta un panel chachi de los que se ven ahora: tropocientas pulgadas, tecnología LED extraplano y la tira de colorines y figuritas que se mueven y cambian de forma y color.

Más tirando al campo industrial, que es lo que nos quita el sueño y nos hace pensar por qué dejamos la agricultura, todo el mundo habla de pantallas.

El tema se pone interesante cuando empezamos a discutir sobre si es un SCADA o una Pantalla, y pocas veces vemos que son realmente lo mismo; con sus más y sus menos, pero lo mismo.

Volvamos a lo del granito de arena…

Para cualquier cosa que nos presenta información de un sistema de una manera más o menos inteligible, todo hay que decirlo, se puede aplicar el nombre:

MMI (Man Machine Interface): Interfase Hombre – Máquina.

Un poco más tarde en el tiempo, y para resultar políticamente correcto, porque acabaríamos viendo cosas WMI o CMI (la primera es fácil ¿quién adivina la segunda? *)  se pasó a denominar:

HMI (Human Machine Interface): Interfase Humano – Máquina.

Esto ya está mejor, más genérico (que hasta los niños tocan cosas de éstas) y menos sexista (que todo el mundo puede meter la pata, no solo nosotros).

Con el tiempo se ha pasado a adoptar este nombre como propio de las pantallitas de marras tengan el formato que tengan (con PC, sin PC, con azúcar…)

Centrados ya en el tema de las “cosas que salen en la pantalla”, pasemos ahora a los formatos de las cosas que tienen esas pantallas.

El equipo que hace la presentación de los datos y nos permite interactuar con el sistema observado (¡ahora si!) se convierte, de mero observador (monitor), a elemento de monitorización y control. Dispondrá de más o menos capacidades gráficas (solo caracteres, gráficas de tendencias, presentación de elementos gráficos, etc.) y permitirá acceder al equipo de control (el autómata) y “hacerle cosas” (si se deja, claro está)

Lo anterior ya sería un sistema SCADA:

SCADA (Supervisory Control And Data Acquisition): Adquisición de datos y supervisión de control.

• Adquisición de datos: La mayoría de pantallitas permiten desde siempre guardar algún tipo de información (alarmas, por ejemplo). El tema es la gracia que tengan para permitir recuperar, por ejemplo, un listado de alarmas (no sería el primero que echa mano de una libreta y un boli…)

• Supervisión de control: En algún rincón del software de visualización encontraremos cosillas interesantes tales como “activar algo cuando pase algo”, y similares…

Lo del nombre HMI/MMI/SCADA lo hemos ido adaptando sin querer a la capacidad del equipo, y se ha llegado a la etiqueta:

• Ordenador (PC) = SCADA
• Pantalla/Panel de Operador = HMI

Esto no es del todo acertado pues, a día de hoy hay Paneles de Operador (etiqueta: HMI) más potentes que algunos SCADA (etiqueta: software de PC), y hay Paneles de Operador que son PC industriales.

Por SCADA, y a grandes rasgos, entendemos una aplicación de software de visualización que permite ciertas cosas:

• Comunicar con dispositivos de campo y monitorizar el proceso/sistema/máquina de forma automática.
• Permitir ciertos grados de control/mando sobre esos dispositivos de campo desde la interfase gráfica (pantalla del ordenador) o desde su sistema de control interno (podemos programar acciones en función de lo que ocurra).
• Proporcionar información del proceso en tiempo real (cuidado con eso del tiempo real), o datos almacenados sobre el mismo, a diversos usuarios a los cuales se les permitirán diferentes grados de acción en el sistema.
• Interactuar con bases de datos para almacenar o recuperar información.
• Etc, etc, etc.

Podéis encontrar algo más de información en el siguiente libro, donde se habla, como tema genérico, de los sistemas SCADA y su entorno: colores, ergonomía, normativa, etc:

Título: SISTEMAS SCADA. 2 ED. (Aquilino Rodríguez Penin) (enlace)

Editorial: MARCOMBO, S.A.
ISBN: 9788426714503

* CMI: Aunque la sugerencia Chimpance Machine Interface es muy buena, la ganadora era Child Machine Interface (Interfase Niño Máquina…  todo llegará…)

Para sacar un resumen de datos del tipo informe,reporte,resumen….

Lo primero es tener un formulario que se rellena con los valores de turno (Report), y esos valores aparecen después en forma de informe en un archivo:

El formulario es una plantilla de texto limpio (por ejemplo, Wordpad) que se guardará en el directorio del proyecto en formato rtf.

Necesitamos un dispositivo de salida (device)

El dispositivo de salida recibirá datos del generador de informes y éste hará servir la plantilla para sustituir valores (Report format file):

Solo queda ejecutar el informe, por ejemplo con un botón que ejecute: Report(“Control_informes”)

No olvidemos que debe existir un servidor de informes!!!

Al igual que en el caso de los dispositivos internos, aquí se seguirán los mismos pasos, pero seleccionaremos el protocolo del plc con el que queramos comunicar.

Dentro de una “carpeta” servidor, crearemos otro dispositivo E/S para configurar el enlace con el plc.

Ese dispositivo tendrá un nombre (NO puede ser el mismo que el servidor o ya os podéis ir a tomar algo…), será de tipo Externo (eeeevidentemente) y luego se le asignará el protocolo.

Con Ethernet y Schneider (Telemecanique) tiraremos por Modbus/TCP a una IP determinada (la del PLC) y SIEMPRE por el puerto 502 (es el de fabricante)

De esta manera tenemos el enlace configurado.

Esta nota indica cómo se configura un acceso a una variable de tipo array con VCitect

Si en un Plc queremos leer-escribir un paquete de variables (Array), por ejemplo, de %MW100 a %MW104. Desde Vijeo Citect, la variable de acceso sería:

Para llamar a cada elemento:

CONSIGNAS[x]  x=1…4 corresponderá %mw100….%mw104

NOTA:

Gracias a la indicación de un compañero he corregido un detalle del array que estaba mal.

CONSIGNAS[5] sería para MW100 a MW104. Lo probé con la utilidad del Tag Debug y no me fijé en el detalle de que esta utilidad coge la base del array (MW100) y el offset que le pongamos, por ejemplo CONSIGNAS[8], y no da problemas. No es así cuando trabajamos desde la página de la aplicación, que daría un error.

Partiendo de un proyecto base ya creado, con sus servidores definidos (por ejemplo, uno de entradas-salidas y uno de alarmas), habría que definir algún dispositivo para comunicarnos con algo. Ese algo serían las variables del proyecto, que pueden ser locales (solo de nuestro PC) o externas (un PLC)

Para trabajar con variables internas (locales),  hay que crear un dispositivo que gestione la comunicación con la aplicación mediante un Protocolo que entienda Vijeo Citect.

En la carpeta Comunicaciones, del Explorador de proyectos Vijeo Citect- Configuración rápida de dispositivo de E/S,  o el Editor de proyectos Vijeo Citect – Comunicaciones – Asistente rápido.

El Asistente de configuración de comunicaciones permitirá definir los dispositivos de E/S de forma cómoda.

Pedirá primero un servidor que contenga al dispositivo (o a varios) y, a continuación, a este Dispositivo habrá que asignarle el protocolo de comunicación.

En nuestro caso, para trabajar con variables internas (del PC), el protocolo a escoger para nuestro dispositivo será: Protocolo genérico Citect.

Compilando el proyecto no debería haber ningún fallo ni aviso.