Guía de Implementación

Guía de Implementación
Gestión de comunicaciones Ethernet en Unity con sg2 SG2 Revisión Fecha Autor Modificaciones 1.0 15/12/2011 Marc Casanova Primera versión Centro de Competencia Técnica

Puede encontrar esta guía, además de preguntas y respuestas técnicas confeccionadas por nuestro Centro de Competencia Técnica, en: También puede realizar su consulta en cualquier buscador de Internet

Sg2 (Unity) : Gestión comms. Ethernet Índice:
1. Fundamentos bloques Ethernet sg2 2. ¿Qué hace sg2? ¿Qué no hace sg2? 3. Variables START, BUSY y END 4. Variables FAIL y FAILCODE 5. Optimización uso DFBs Ethernet 6. Limitaciones plataformas Ethernet

Contenidos Fundamentos bloques Ethernet sg2
¿Qué hace sg2? ¿Qué no hace sg2? Variables START, BUSY y END Variables FAIL y FAILCODE Optimización uso DFBs Ethernet Limitaciones plataformas Ethernet

1. Fundamentos bloques Ethernet sg2
Sg2 posee 2 tipos de bloques de función para las comunicaciones Ethernet Bloques independientes de la plataforma (genéricos y válidos para cualquier elemento servidor de la red) Bloques dependientes de la plataforma (específico para cada PLC Unity que actuará como cliente de la red) Independiente Plataforma Scanner Client Device Client Client Workmemory Dependiente Plataforma M340, Premium, Quantum Port

La estructura de bloques del software sigue la filosofía de una arquitectura real: Port Workmemory Gateway Client Scanner Client Workmemory Device Client Scanner Client Client Client

Comportamiento interno de los bloques: Client 1 Gestión peticiones Client 2 Gestión peticiones Client n Gestión peticiones Petición única Workmemory Cabecera Petición 1 Petición 2 Petición n Respuesta 1 Respu. 2 Respu. 3 Respu. 4 Petición Estado Prioridad Buffer escritura Read Buffer Port Gestión Puerto Cola: FIFO con prioridad Hasta 4 peticiones simultaneas

Comportamiento interno de los bloques: Los bloques clientes se encargan de montar las peticiones (una a una) en función de la configuración de sus entradas Cada petición de cada cliente se conforma en la variable Workmemory del puerto asociado A través de la Workmemory se gestiona también la política de prioridades de los clientes, estado de las peticiones, y se genera un buffer con ellas La DFB de puerto se encarga de lanzar simultáneamente hasta 4 peticiones a través del puerto de la plataforma en uso (PLC) y serializar el resto La DFB de puerto es la que contiene en su interior las instrucciones de comunicaciones (READ_VAR y WRITE_VAR)

2. ¿Qué hace sg2? En términos de gestión de la comunicación sg2 se encarga, entre otras cosas, de: Gestionar la composición de las peticiones para poder ser lanzadas a través del puerto Gestionar las prioridades de cada petición si en algún momento se producen de forma simultánea desde varios bloques cliente Evitar que se generen nuevas peticiones de un cliente mientras se encuentra ocupado (estado busy) Lanzar las peticiones a través del puerto físico mediante instrucciones de comunicación programadas internamente en las DFB de Puerto Lanzar hasta 4 peticiones simultáneas a través del puerto mediante la DFB EthernetPort Serializar las peticiones que no han podido ser lanzadas de forma simultánea

2. ¿Qué NO hace sg2? En términos de gestión de la comunicación sg2 NO se encarga de: Optimizar al máximo la comunicación Ethernet en función de las limitaciones de la plataforma utilizada Advertir en caso de que la programación de los bloques pueda llevar a un colapso del puerto del PLC Tener en cuenta las limitaciones de comunicaciones Ethernet en función del puerto de cada plataforma

3. Variables START, BUSY y END
El flanco ascendente en la variable START de la DFB permite lanzar una petición hacia la DFB de puerto La variable de BUSY indica que la DFB de cliente está ocupada realizando la petición y esperando a su respuesta. Mientras ésta variable está activa no se deberían realizar nuevos flancos en la entrada START. Pese a ello, cualquier flanco recibido no provocará ningún efecto sobre la Workmemory de la DFB cliente. La variable END indica que la petición ha finalizado y hay una respuesta. Ésta puede ser satisfactoria o puede aparecer un error. Ésta variable sólo se activa durante un ciclo de scan si no se mantiene la señal de START

4. Variables FAIL y FAILCODE
La variable FAIL es un bool que se activa cuando la última petición de la DFB cliente no ha terminado de forma satisfactoria La variable FAIL pasa a 0 en el momento en que se vuelve a recibir un flanco ascendente en la entrada START La variable FAILCODE indica el último error aparecido (por tanto, aunque no exista error es posible que ésta variable contenga valores disintos de 0). La variable FAILCODE se actualiza cada vez que el bit FAIL se activa La variable FAILCODE se compone de 3 palabras (FailCode[0], FailCode[1] y FailCode[2]). Es necesario averiguar los 3 valores para poder realizar un diagnóstico El significado de los valores de la FAILCODE se pueden consultar desde la ayuda de sg2

5. Optimización uso DFBs Ethernet
Las DFBs Cliente poseen una entrada para configurar la prioridad de sus peticiones. Este aspecto es vital cuando existen varios bloques en el proyecto ya que aumenta la probabilidad de que se lancen peticiones de forma simultánea a la DFB de Puerto.

Cada DFB de Puerto admite hasta 4 canales activos o envíos simultáneos hacia el puerto físico de la plataforma. En caso de recibirse más de 4 peticiones por parte de las DFBs de Cliente, antes de solucionar todas o alguna de las que están pendientes, se irán serializando y saliendo hacia el puerto del PLC cuando sea posible Sin embargo, es necesario tener en cuenta que habitualmente los puertos de los PLCs admiten más cantidad de canales abiertos de forma simultánea así como peticiones por ciclo de scan: Puerto PLC DFB Cliente 1 DFB Puerto 1 DFB Cliente 2 Sólo 4 canales ocupados. Resto canales libres. DFB Cliente 3 DFB Cliente 4 DFB Cliente 5 Peticiones 1 a 4 La petición 5 queda en el buffer Peticiones 1 a 5

Por tanto, siempre y cuando no se llegue al límite de canales Ethernet (sockets) abiertos ni peticiones máximas por ciclo de scan que admite una plataforma, una forma de optimizar las comunicaciones es añadiendo una DFB de puerto cada 4 DFBs de cliente (de forma que ya no se genere un embudo en la comunicación): DFB Cliente 1 DFB Puerto 1 Puerto PLC DFB Cliente 2 DFB Cliente 3 DFB Cliente 4 Peticiones 1 a 4 Peticiones 1 a 4 Mejor aprovechamiento de los recursos de la plataforma DFB Puerto 2 DFB Cliente 5 DFB Cliente 6 DFB Cliente 7 DFB Cliente 8 Peticiones 5 a 8 Peticiones 5 a 8

Conviene recordar que la asociación de cada DFB Cliente a un puerto se hace a través de la variable WorkMemory: Port1 Port2 Workmemory1 Workmemory2 Client1 Scanner Client3 Scanner Client2 Client4 Port3 Workmemory3 Client5 Scanner Client6

6. Limitaciones plataformas Ethernet
Para optimizar al máximo las comunicaciones es vital conocer las limitaciones (sockets por puerto y peticiones por ciclo de scan) que tiene cada plataforma Las limitaciones de cada plataforma se pueden consultar en su manual, sin embargo algunas de ellas se aportan en el siguiente fichero:

Make the most of your energy

Guía de Implementación

Presentaciones similares

Presentación del tema: "Guía de Implementación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Guía de Implementación

Presentaciones similares

Presentación del tema: "Guía de Implementación"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback