Archive for marzo, 2010

Refresco de variables

Nota nueva referida a una pregunta de un compañero en relación con el tiempo de refresco de las variables en Vijeo Citect. He ordenado un poco los comentarios e indagado algo acerca del tema.

La cuestión era cómo cambiar el tiempo de refresco de las variables.

Por defecto, las variables de la tabla VARIABLE.DBF, no comunican. La comunicación dependerá del lugar donde se halle la llamada a esta variable.

Alarmas

En el caso de las alarmas, el tiempo de refresco del sistema de alarmas afectará a la CPU. Debe ajustarse a las necesidades del proceso para no perder alarmas y no sobrecargar la CPU innecesariamente.

Páginas

Dentro de una página, dependiendo del tiempo de refresco de ésta. Se puede definir un tiempo general para todas las páginas en la última ventana del Asistente de configuración del Computador.

Por defecto se refresca cada 250 milisegundos y afecta a todas las páginas. Se trata del parámetro: Tiempo de búsqueda de página (traducido: ciclo de scan de la página)

Es posible configurar tiempos de refresco diferentes para cada página. Con el botón derecho del ratón en una página, se abren sus propiedades. El parámetro: Tiempo de búsqueda permitirá cambiar el tiempo de refresco de esa página en particular.

Tendencias

Dependerá del tiempo de muestreo definido para la variable de tendencia.

En la figura aparece una gráfica con una señal muestreada cada 0.2s y una visualización directa en página cada 3s. El valor de la variable se actualizará en la página cada 3s, pero su valor real será el de la tendencia (ésta “irá por delante”)

Controlador

Se pueden tocar más cosas para el tema de refresco, como el controlador. En este caso la pregunta iba con MODNET (Modbus sobre Ethernet) y se refería a cambiar el tiempo de polling al dispositivo. Se puede hacer peeeeeeeero…..

MODNET.Delay es un parámetro que aplica un tiempo de espera entre la contestación del dispositivo y la siguiente petición que se le envía al mismo. Todos los dispositivos que utilicen este controlador tendrán el mismo retardo.

Esto quiere decir que si estamos trasteando con históricos, nos podemos encontrar con algo como lo siguiente (Retardo de 5s):

Y a lo mejor no interesa…

Alarmas, vamos a meternos en líos…

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…

SG2

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!

Jugando con Unity…

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á…