UCPs sin Fuente/Manuales/MU214305
Anuncio
Manual del Usuario UCPs Serie Nexto NX3004, NX3005, NX3010, NX3020, NX3030 Rev. H 07/2016 Cód. Doc.: MU214305 Condiciones Generales de Fornecimiento Ninguna parte de este documento puede ser copiada o reproducida sin el consentimiento previo por escrito de Altus Sistemas de Automação S.A., que se reserva el derecho de modificar sin previo aviso. Como el Código de Defensa del Consumidor en vigor en Brasil, informó, a continuación, los clientes que usan nuestros productos con los aspectos de seguridad de personas y instalaciones. El equipo de automatización industrial fabricado por Altus son robustos y fiables, debido a un estricto control de calidad que se presenta. Sin embargo, el control de equipos electrónicos industriales (controladores programables, controles numéricos, etc.) puede provocar daños en las máquinas o en procesos controlados por ellos en caso de un defecto en partes y piezas o errores en la programación o la instalación y puede incluso poner en peligro vidas. El usuario debe considerar las posibles consecuencias de estos defectos y proporcionar servicios adicionales a la seguridad exterior, en caso necesario, servirá para preservar la seguridad del sistema, especialmente en los casos de primera instalación y pruebas. El equipo fabricado por Altus no traerá riesgos medioambientales directos, que no dará ningún tipo de contaminante durante el uso. Sin embargo, con respecto a la eliminación de los aparatos, es importante destacar que todos los componentes electrónicos integrados en los productos contengan materiales perjudiciales para la naturaleza cuando se eliminan de forma inadecuada. Se recomienda, por tanto, que cuando la destrucción de este tipo, se envía a plantas de reciclaje para dar el tratamiento adecuado de los residuos. Es esencial para completar la lectura de manuales y / o las especificaciones técnicas del producto antes de instalar o usar el mismo. Altus asegurar sus equipos, tal como se describe en términos de la oferta, que se adjunta a la propuesta de comercio. Los ejemplos y figuras (diagramas) de este documento son presentados solo a fines ilustrativos. Debido a las posibles actualizaciones y mejoras que los productos puedan presentar, Altus no asume ninguna responsabilidad por el uso de estos ejemplos y figuras (diagramas) en aplicaciones reales. Estos solo deben ser utilizados para el entrenamiento y para mejorar la experiencia del usuario con los productos y sus características. Altus garantiza sus equipos que operan en conformidad con la descripción que figura explícitamente en sus manuales y / o características técnicas, no garantiza la satisfacción de cualquier tipo de equipo de aplicación. Altus no reconoce ninguna otra garantía, directa o implícita, sobre todo cuando se trata de la oferta de otras empresas. Las solicitudes de información sobre la oferta y características de los equipos y servicios de Altus se harán por escrito. Altus no se hace responsable de la información sobre su equipo sin el registro oficial. Estos productos utilizan la tecnología EtherCAT® (www.ethercat.org). LOS DERECHOS DE AUTOR Nexto y MasterTool son marcas comerciales de Altus Sistemas de Automação S.A. Windows, Windows NT y Windows Vista son marcas comerciales de Microsoft Corporation. NOTIFICACIÓN DE USO DE SOFTWARE ABIERTO Para obtener el código fuente de componentes de software contenidos en este producto que estén bajo licencia GPL, LGPL, MPL, entre otras, por favor contactar a través del correo electrónico [email protected]. Además del código fuente, todos los términos de la licencia, condiciones i Condiciones Generales de Fornecimiento de garantía e informaciones sobre los derechos autorales pueden estar disponibles bajo requerimiento. ii Sumario Sumario 1. INTRODUCCIÓN .......................................................................................................................................1 Serie Nexto ...................................................................................................................................................2 Características Innovadoras ....................................................................................................................3 Documentos Relacionados a este Manual ...................................................................................................4 Inspección Visual .........................................................................................................................................5 Soporte Técnico ...........................................................................................................................................5 Mensajes de Advertencia Utilizados en este Manual ..................................................................................5 2. DESCRIPCIÓN TÉCNICA.........................................................................................................................7 Paneles y Conexiones ...................................................................................................................................7 Características Generales ............................................................................................................................9 Características Comunes ........................................................................................................................9 Características Específicas ................................................................................................................... 10 Interfaces Seriales ................................................................................................................................ 13 Interfaces Ethernet ............................................................................................................................... 14 Fuente de Alimentación ............................................................................................................................. 15 Interfaz de la Tarjeta de Memoria......................................................................................................... 16 Compatibilidad con Demás Productos ...................................................................................................... 16 Desempeño ................................................................................................................................................. 17 Tiempos de Aplicación ........................................................................................................................ 17 Tiempos para Ejecución de Instrucciones ............................................................................................. 17 Tiempos de Inicialización .................................................................................................................... 17 Tiempo de Intervalo ............................................................................................................................. 18 Dimensiones Físicas ................................................................................................................................... 18 NX3004/NX3005................................................................................................................................. 18 NX3010, NX3020 e NX3030 ............................................................................................................... 19 Datos para Compra ................................................................................................................................... 19 Ítems Integrantes.................................................................................................................................. 19 Código del Producto ............................................................................................................................ 20 Productos Relacionados ............................................................................................................................. 20 3. INSTALACIÓN ......................................................................................................................................... 22 Instalación Mecánica ................................................................................................................................. 22 NX3004 y NX3005 .............................................................................................................................. 22 NX3010, NX3020 y N3030.................................................................................................................. 22 Instalación Eléctrica .................................................................................................................................. 22 NX3004 y NX3005 .............................................................................................................................. 22 NX3010, NX3020 y NX3030 ............................................................................................................... 23 Conexión con la Red Ethernet ................................................................................................................... 24 Dirección IP......................................................................................................................................... 24 ARP Gratuito ....................................................................................................................................... 25 Instalación del Cable de Red ................................................................................................................ 25 Conexión con la Red RS-232C................................................................................................................... 26 Comunicación RS-232C....................................................................................................................... 26 Conexión con la Red RS-485/422............................................................................................................... 27 Comunicación RS-485 Sin Terminación............................................................................................... 27 Comunicación RS-485 con Terminación Interna .................................................................................. 28 Comunicación RS-485 con Terminación Externa ................................................................................. 29 Ejemplo de Conexión de Red RS-485 con Terminación Externa y Redundancia de Maestro ................. 30 iii Sumario Comunicación RS-422 sin Terminación ............................................................................................... 30 Comunicación RS-422 con Terminación Interna .................................................................................. 31 Comunicación RS-422 con Terminación Externa ................................................................................. 32 Ejemplo de Red RS-422 ....................................................................................................................... 33 Instalación de la Tarjeta de Memoria ....................................................................................................... 33 Instalación de la Arquitectura ................................................................................................................... 34 Instalación de Módulos en el Bastidor Principal ................................................................................... 34 Instalación del Programador ..................................................................................................................... 35 4. CONFIGURACIÓN .................................................................................................................................. 36 Configuración de la UCP ........................................................................................................................... 36 Parámetros Generales........................................................................................................................... 36 Configuración de Evento Externo......................................................................................................... 46 Configuración del SOE ........................................................................................................................ 48 Sincronización de Tiempo .................................................................................................................... 51 Configuración de las Interfaces Seriales ................................................................................................... 53 COM 1 (NX3010/NX3020/NX3030) ................................................................................................... 53 COM 1 (NX3004/NX3005) y COM 2 (NX3010/NX3020/NX3030) ..................................................... 56 Configuración de las Interfaces Ethernet ................................................................................................. 57 Interfaces Ethernet Locales .................................................................................................................. 57 Interfaces Ethernet Remotas ................................................................................................................. 58 Puertas TCP Reservadas ...................................................................................................................... 58 Configuración del Módulo NX5000 ........................................................................................................... 58 Configuración de Protocolos ..................................................................................................................... 60 Comportamiento de los Protocolos x Estados de la UCP....................................................................... 63 MODBUS RTU MAESTRO ................................................................................................................ 64 MODBUS RTU ESCLAVO ................................................................................................................ 78 MODBUS Ethernet .............................................................................................................................. 87 OPC DA ............................................................................................................................................ 110 EtherCAT .......................................................................................................................................... 123 Desempeño de Comunicación .................................................................................................................. 143 Tasa de Comunicación de un Dispositivo Servidor MODBUS ............................................................ 143 Tasa de Comunicación de un Dispositivo con Servidor OPC .............................................................. 145 Disparo de Relaciones MODBUS Cliente de Forma Acíclica ............................................................. 146 Desempeño del Sistema ............................................................................................................................ 146 Escaneo de E/S .................................................................................................................................. 147 Tarjeta de Memoria ............................................................................................................................ 147 Reloj RTC ................................................................................................................................................ 147 Bloques Funcionales para Lectura y Escritura del RTC ...................................................................... 148 Estructuras de Datos del RTC ............................................................................................................ 152 Memoria de Archivos de Usuario ............................................................................................................ 154 Tarjeta de Memoria ................................................................................................................................. 156 Acceso en el MasterTool .................................................................................................................... 158 Menú Informativo y de Configuración de la UCP .................................................................................. 159 Bloques Funcionales y Funciones ............................................................................................................ 162 Bloques Funcionales Especiales para Comunicación Serial ................................................................ 162 Actualización de Entradas y Salidas ................................................................................................... 178 Bloque funcional PID ........................................................................................................................ 180 Timer Retentivo ................................................................................................................................. 183 Timer No-Redundante ....................................................................................................................... 187 Log de Usuario .................................................................................................................................. 189 SNMP ....................................................................................................................................................... 192 Introducción ...................................................................................................................................... 192 SNMP en UCPs Nexto ....................................................................................................................... 192 Private MIB ....................................................................................................................................... 193 iv Sumario Configuración .................................................................................................................................... 196 Usuario y Comunidades SNMP .......................................................................................................... 197 Gerenciamiento de Usuarios y Derechos de Acceso ................................................................................ 198 5. PROGRAMACIÓN INICIAL ................................................................................................................. 199 Organización y Acceso a la Memoria ...................................................................................................... 199 Perfiles de Proyecto ................................................................................................................................. 201 Simple ............................................................................................................................................... 202 Básico................................................................................................................................................ 202 Normal .............................................................................................................................................. 202 Experto .............................................................................................................................................. 203 Personalizado..................................................................................................................................... 204 Perfil de Máquina .............................................................................................................................. 204 Tabla General .................................................................................................................................... 205 Número Máximo de Tareas ................................................................................................................ 205 Configurar la UCP ................................................................................................................................... 208 Bibliotecas ................................................................................................................................................ 209 Insertando una Instancia de Protocolo ................................................................................................... 209 MODBUS RTU ................................................................................................................................. 209 MODBUS Ethernet ............................................................................................................................ 211 Ubicar la Red ........................................................................................................................................... 213 Login ........................................................................................................................................................ 215 Modo Run ................................................................................................................................................ 216 Modo Stop ................................................................................................................................................ 218 Escritura y Forzamiento de Variables .................................................................................................... 219 Logout ...................................................................................................................................................... 219 Upload del Proyecto ................................................................................................................................. 220 Estados de Operación de la UCP ............................................................................................................. 222 Run.................................................................................................................................................... 222 Stop ................................................................................................................................................... 222 Breakpoint ......................................................................................................................................... 222 Exception .......................................................................................................................................... 222 Reset a Caliente ................................................................................................................................. 222 Reset a Frío........................................................................................................................................ 222 Reset Origen ...................................................................................................................................... 222 6. REDUNDANCIA CON UCP NX3030..................................................................................................... 224 Introducción ............................................................................................................................................. 224 Descripción Técnica y Configuración...................................................................................................... 226 Configuración Mínima de un CP Redundante (Sin utilizar el Panel de PX2612) ................................. 226 Configuraciones Típicas de un CP Redundante .................................................................................. 226 Módulo NX4010 ................................................................................................................................ 227 Panel de Control de Redundancia PX2612 ......................................................................................... 228 Interconexiones entre Half-Clusters y Panel de Control de Redundancia PX2612 ............................... 230 Características Generales ................................................................................................................... 231 Datos para Compra ............................................................................................................................ 234 Principios de Funcionamiento ................................................................................................................. 234 Identificación de un UCP NX3030 ..................................................................................................... 234 Proyecto Redundante Único ............................................................................................................... 235 Estructura del Proyecto Redundante ................................................................................................... 235 Mapeos Múltiples .............................................................................................................................. 239 Estructuras de Datos de Diagnósticos, Comandos y Usuario ............................................................... 241 Servicios de Sincronización Cíclicos a través de NETA y NETB ........................................................ 241 Servicios de Sincronización Esporádicos a través de NETA y NETB ................................................. 242 v Sumario Deshabilitación de la Sincronización de Proyectos ............................................................................. 244 Configuraciones de Redes PROFIBUS ............................................................................................... 245 Redes Ethernet Redundantes con NIC Teaming.................................................................................. 245 Métodos de Cambio de IP .................................................................................................................. 246 Uso Combinado de NIC Teaming y Active IP .................................................................................... 249 Uso de Interfaces Ethernet con Indicación de Falla Vital .................................................................... 250 Uso de Comunicación OPC con Proyectos Redundantes .................................................................... 250 Estados de un CP Redundante ............................................................................................................ 250 Funciones del Panel de Comando de Redundancia PX2612 ................................................................ 253 Transiciones entre Estados de Redundancia........................................................................................ 255 Primeros Instantes en Estado Activo .................................................................................................. 258 Fallas más Comunes Causadoras de Switchovers Automáticos entre Half-Clusters ............................. 258 Fallas Asociadas a Switchovers entre Half-Clusters Gerenciados por el Usuario ................................. 259 Tolerancia a Fallas ............................................................................................................................. 260 Overhead de la Redundancia .............................................................................................................. 262 Programación de un CP Redundante ...................................................................................................... 263 Wizard para Creación de un Nuevo Proyecto Redundante .................................................................. 263 Configuración de los Half-Clusters .................................................................................................... 266 Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2) .................................. 267 Configuraciones de los Módulos NX5001 .......................................................................................... 269 Configuraciones de los Módulos NX5000 .......................................................................................... 271 Configuraciones del Módulo NX4010 ................................................................................................ 272 Configuraciones de I/O Drivers .......................................................................................................... 273 Configuraciones de la MainTask ........................................................................................................ 273 Objeto Redundancy Configuration ..................................................................................................... 275 GVL Diagnostics ............................................................................................................................... 276 GVLs con Variables Simbólicas Redundantes .................................................................................... 276 POUs del Tipo Program con Variables Simbólicas Redundantes ........................................................ 276 Utilización de Breakpoints en Sistemas Redundante ........................................................................... 276 Gerenciamiento de Instancias MODBUS en Sistemas Redundantes .................................................... 276 Limitaciones en la Programación de un CP Redundante ..................................................................... 277 Obtener el Estado Redundante de un Half-Cluster .............................................................................. 278 Lectura de Diagnósticos No-Redundantes .......................................................................................... 278 Carga de Programas en un CP Redundante ........................................................................................... 278 Carga Inicial de un Proyecto Redundante ........................................................................................... 279 Conexión del MasterTool con una UCP NX3030 de un CP Redundante ............................................. 281 Carga de Modificaciones en un Proyecto Redundante......................................................................... 282 Carga de Modificaciones Offline y Online ......................................................................................... 282 Carga Online de Modificaciones ........................................................................................................ 284 Carga Offline de Modificaciones con Interrupción del Control de lo Proceso...................................... 284 Planificación Previa para Modificaciones Offline sin Interrupción del Control del Proceso ................. 285 Explorar la Redundancia para Carga Offline de Modificaciones sin Interrupción del Control del Proceso .......................................................................................................................................................... 290 Mantenimiento ......................................................................................................................................... 294 Cambio a Caliente de Módulos en un CP Redundante ........................................................................ 294 Mensajes de Advertencia del MasterTool ........................................................................................... 294 Diagnósticos de la Redundancia en el Visor Gráfico de la UCP NX3030 ............................................ 295 Estructura de Diagnósticos de la Redundancia .................................................................................... 295 Test del Panel PX2612 ....................................................................................................................... 307 7. MANTENIMIENTO................................................................................................................................ 310 Diagnósticos del Módulo .......................................................................................................................... 310 Diagnósticos One Touch .................................................................................................................... 310 Diagnósticos vía LED ........................................................................................................................ 313 Diagnósticos vía WEB ....................................................................................................................... 314 vi Sumario Diagnostic Explorer ........................................................................................................................... 316 Diagnósticos vía Variables ................................................................................................................. 317 Diagnósticos vía Bloques Funcionales................................................................................................ 332 Visor Gráfico ........................................................................................................................................... 334 Log de Sistema ......................................................................................................................................... 336 No Cargar la Aplicación en la Inicialización ........................................................................................... 336 Falla en la Alimentación .......................................................................................................................... 336 Problemas más Comunes ......................................................................................................................... 337 Solución de Problemas ............................................................................................................................. 337 Mantenimiento Preventivo ...................................................................................................................... 338 8. GLOSARIO ............................................................................................................................................. 339 ANEXO A. INTEROPERABILIDAD DNP3 ......................................................................................... 342 Perfil de Dispositivo DNP3 ...................................................................................................................... 342 DNP3 ........................................................................................................................................................ 342 DOCUMENTO DEL PERFIL DE DISPOSITIVO ............................................................................. 342 DNP V3.0 de Implementación ................................................................................................................. 343 vii 1. Introducción 1. Introducción Las UCPs de la Serie Nexto se desarrollaron para suplir las necesidades de distintos clientes en las más variadas aplicaciones presentes en automatización industrial y control de procesos. Debido al formato compacto y robusto, excelente desempeño de procesamiento y actualización rápida de las E/S proveniente de un único bus de comunicación de alta velocidad, UCPs de la Serie Nexto son la mejor elección para las más exigentes necesidades de aplicación de control. En complejas aplicaciones, donde la confiabilidad, disponibilidad y operación remota de E/S se hacen necesarias, UCPs de la Serie Nexto son igualmente una gran opción, debido a las diferentes topologías de redundancia y posibilidades de expansión de bastidor. Las UCPs de la Serie Nexto están provistas de un innovador y único servicio de diagnóstico, lo que ofrece al usuario una experiencia totalmente nueva. Con una sola tecla ubicada en la parte superior del módulo acoplado al compacto visor gráfico, el usuario tiene acceso directo a muchas informaciones sobre los módulos de E/S, interfaces de redes de campo y muchos otros módulos de la aplicación. Además, posee servicios de sistema de registro de usuarios y facilidad de depuración y gerenciamiento de tareas, lo que reduce el costo de la aplicación y tiempo de instalación. Finalmente, las UCPs Serie Nexto presentan distintas interfaces de comunicación, como puertas seriales y puertas Ethernet, interfaz con tarjeta de memoria y lenguajes de programación según norma IEC 61131-3. Figura 1-1. UCP NX3030 1 1. Introducción Serie Nexto La Serie Nexto es una poderosa y completa línea de Controladores Programables (CP) con características únicas e innovadoras. Debido a su flexibilidad, diseño inteligente, amplia capacidad de diagnosis avanzadas y arquitectura modular, los CPs Serie Nexto se pueden utilizar para control de sistemas en aplicaciones de pequeño, mediano y gran porte. La arquitectura de la Serie Nexto posee una extensa variedad de módulos de entrada y salida. Estos módulos combinados con un poderoso procesador de 32 bits y un bus de alta velocidad basado en Ethernet se adecuan a innúmeros tipos de aplicaciones como controles de alta velocidad para máquinas pequeñas, complejos procesos distribuidos, aplicaciones redundantes y sistemas con gran número de E/S como automaciones prediales. Además, la Serie Nexto posee módulos de comunicaciones con las más populares redes de campo entre otras características más. La Serie Nexto utiliza una avanzada tecnología en su bus que utiliza una interfaz Ethernet de alta velocidad posibilitando que informaciones de entradas, salidas y datos se puedan compartir entre múltiples controladores dentro de un mismo sistema. El sistema se puede fácilmente dividir y distribuir por todo el campo, lo que posibilita el uso de expansiones de bastidores con el mismo desempeño de un módulo local, permitiendo que todos los tipos de módulos se utilicen tanto en el bastidor local como en las expansiones de bastidores sin restricciones. Para la interconexión entre las expansiones de bastidores se utiliza un simple cable estándar Ethernet. Figura 1-2. Serie Nexto – Visión General 2 1. Introducción Características Innovadoras La serie Nexto trae al usuario innúmeras innovaciones en la utilización, supervisión y mantenimiento del sistema. Estas características se desarrollaron enfocando proporcionar un nuevo concepto en automoción industrial. La lista a continuación muestra algunas características que el usuario encontrará en la Serie Nexto: Battery Free Operation: La Serie Nexto no necesita ningún tipo de batería para mantenimiento de memoria ni para operación del reloj de tiempo real. Esta característica es extremamente importante por reducir las necesidades de mantenimiento del sistema bien como por permitir el uso en lugares remotos de difícil mantenimiento. Además, esta característica es ambientalmente correcta. Multiple Block Storage: Innúmeros tipos de memoria están disponibles en las UCPs de la Serie Nexto y ofrecen la mejor opción a cada necesidad. Estas memorias se dividen en memorias volátiles y memorias no volátiles. Para uso de memorias volátiles las UCPs de la Serie Nexto ofrecen variables de entrada de ubicación directa (%I), variables de salida de ubicación directa (%Q), variables de memoria de ubicación directa (%M), memoria de datos y memoria de datos redundantes. Para aplicaciones que necesitan funcionalidades de memoria no volátil la Serie Nexto posibilita la utilización de variables de ubicación directa de memoria retentiva (%Q), memoria retentiva de datos, memoria de ubicación directa de memoria persistente (%Q), memoria persistente de datos, memoria de programa, memoria de código fuente, sistema de archivo en la UCP (Doc, pdf, data) e interfaz para tarjeta de memoria. One Touch Diag: Es una exclusiva característica de los CPs de la Serie Nexto. Con este nuevo concepto el usuario puede verificar las informaciones de diagnóstico de cualquier módulo presente en el sistema directamente en el visor gráfico de la UCP con un único toque en la tecla de diagnóstico del respectivo módulo. OTD es una poderosa herramienta de diagnóstico que se puede usar offline (sin supervisorio o programador) y reduce los tiempos de mantenimiento y comisionamiento. OFD – On Board Full Documentation: Las UCPs de la Serie Nexto pueden almacenar toda la documentación sobre el proyecto en su propia memoria. Este es un recurso interesante para propósitos de backup y mantenimiento, ya que la información completa está almacenada en un único y seguro lugar. ETD – Electronic Tag on Display: Otra característica exclusiva presentada por la Serie Nexto es el ETD. Esta funcionalidad realiza el proceso de verificación del tag de cualquier punto o módulo de E/S usados en el sistema directamente en el visor gráfico de las UCPs. Juntamente con esta información el usuario también puede verificar la descripción. Este recurso es extremamente útil durante el procedimiento de mantenimiento y resolución de problemas. DHW – Double Hardware Width: Los módulos de la Serie Nexto se han proyectado para ahorrar espacio en paneles y máquinas. Por esta razón, la Serie Nexto ofrece dos diferentes anchuras de módulos: Doble (ocupa dos posiciones del bastidor) y Simple (ocupa una posición). Este concepto permite el uso de módulos de E/S compactos con alta densidad de puntos de E/S juntamente con módulos complejos, tales como UCPs, maestros de red de campo y módulos de fuente de alimentación. UCP de Alta Velocidad: Todas las UCPs de esta Serie Nexto se concibieron para proveer al usuario un excelente desempeño y atender a una amplia gama de exigencias en las aplicaciones. Por ejemplo: las UCPs Nexto NX3010, NX3020 y NX3030 pueden ejecutar instrucciones de adición, multiplicación y sustracción en menos de 15 ns para valores de tipo entero y en menos de 23 ns para valores de tipo real. Son igualmente capaces de ejecutar 1000 lazos PIDs en menos de 5 ms. iF Product Design Award 2012: La Serie Nexto fue ganadora del iF Product Design Award 2012 en la categoría Industry + Skilled trades. Este premio es 3 1. Introducción reconocido internacionalmente como un sello de excelencia y calidad, considerado el Oscar del design en Europa. Documentos Relacionados a este Manual Para obtener informaciones adicionales sobre la Serie Nexto se pueden consultar otros documentos (manuales y características técnicas) además de este. Estos documentos se encuentran disponibles en su última revisión en http://www.altus.com.br. Cada producto posee un documento denominado Característica Técnica (CS), donde se encuentran las características del producto en cuestión. Adicionalmente el producto puede poseer Manuales de Utilización (los códigos de los manuales se comentan en la CS). Por ejemplo, el módulo NX1001 tiene todas las informaciones de características de utilización y de compra, en su CS. Por otro lado, el NX5001 posee, además de la CS, un manual de utilización (MU). Se aconsejan los siguientes documentos como fuente de información adicional: Código Descripción Idioma CE114000 Nexto Series – Technical Characteristics Inglés CT114000 Série Nexto – Características Técnicas Portugués CS114000 Serie Nexto – Especificaciones y Configuraciones Español CE114700 Nexto Series Backplane Racks Technical Characteristics Inglés CT114700 Características Técnicas dos Bastidores da Série Nexto Portugués CS114700 Características Técnicas de los Bastidores de la Serie Nexto Español CE114900 NX4010 Redundancy Link Module Technical Characteristics Inglés CT114900 Características Técnicas do Módulo de Redundância NX4010 Portugués CS114900 Características Técnicas del Módulo de Redundancia NX4010 Español CE114902 NX5001 PROFIBUS-DP Master Technical Characteristics Inglés CT114902 Características Técnicas do Mestre PROFIBUS DP NX5001 Portugués CS114902 Especificaciones y Configuraciones Maestro PROFIBUS-DP NX5001 Español CE114908 NX5110 e NX5210 PROFIBUS-DP Heads Technical Characteristics Inglés CT114908 Características Técnicas Interfaces Cabeça PROFIBUS-DP NX5110 e NX5210 Portugués CS114908 Especificaciones y Configuraciones PROFIBUS-DP Interfaz Cabezas NX5110 e NX5210 Español CE114903 Ethernet Module NX5000 Technical Characteristics Inglés CT114903 Características Técnicas do Módulo Ethernet NX5000 Portugués CS114903 Especificaciones y Configuraciones Modulo Ethernet NX5000 Español CT112500 Características Técnicas do Painel de Controle de Redundância PX2612 Portugués MU214600 Nexto Series User Manual Inglés MU214000 Manual de Utilização Série Nexto Portugués MU214300 Manual del Usuario Serie Nexto Español MU214605 Nexto Series CPUs User Manual Inglés MU214100 Manual de Utilização UCPs Série Nexto Portugués MU214305 Manual del Usuario UCPs Serie Nexto Español MU299609 MasterTool IEC XE User Manual Inglés MU299048 Manual de Utilização MasterTool IEC XE Portugués MU299800 Manual del Usuario MasterTool IEC XE Español MP399609 MasterTool IEC XE Programming Manual Inglés MP399048 Manual de Programação MasterTool IEC XE Portugués MP399800 Manual de Programación MasterTool IEC XE Español MU214601 NX5001 PROFIBUS DP Master User Manual Inglés MU214001 Manual de Utilização Mestre PROFIBUS DP NX5001 Portugués MU214301 Manual del Usuario Maestro PROFIBUS DP NX5001 Español MU214608 Nexto PROFIBUS-DP Head User Manual Inglés MU214108 Manual de Utilização da Cabeça PROFIBUS-DP Nexto Portugués 4 1. Introducción MU214308 Manual de Utilización de la Cabeza PROFIBUS-DP Nexto Español MU219000 Ponto Series Utilization Manual Inglés MU209000 Manual de Utilização da Série Ponto Portugués MU209508 Manual de Utilização Cabeça PROFIBUS PO5063V1 e Cabeça Redundante PROFIBUS PO5063V5 Portugués MU219511 PO5064 PROFIBUS Head and PO5065 Redundant PROFIBUS Head Utilization Manual Inglés MU209511 Manual de Utilização Cabeça PROFIBUS PO5064 e Cabeça Redundante PROFIBUS PO5065 Portugués MU209020 Manual de Utilização Rede HART sobre PROFIBUS Portugués Tabla 1-1. Documentos Relacionados Inspección Visual Antes de iniciar la instalación, se recomienda hacer una inspección visual cuidadosa de los equipos y verificar si no hay daños causados por el transporte. Fíjese si todos los componentes de su pedido están en perfecto estado. Caso haya defectos, informe a la compañía transportadora y al representante o distribuidor Altus más próximo. CUIDADO: Antes de retirar los módulos del embalaje, es importante que se descarguen eventuales potenciales estáticos acumulados en el cuerpo. Para eso, toque (con las manos desnudas) una superficie metálica aterrada cualquiera antes de manejar los módulos. Dicho procedimiento garantiza que los niveles de electricidad estática soportados por el módulo no sobrepasen. Es importante que se registre el número de serie de cada equipo recibido, bien como las revisiones de software, caso existan. Estas informaciones serán necesarias, en caso de que se necesite contactar al Soporte Técnico de Altus. Soporte Técnico Para contactar al Soporte Técnico de Altus en São Leopoldo, RS, llame a +55 51 3589-9500. Para conocer los centros de Soporte Técnico de Altus en otros lugares, vaya a nuestro sitio (http://www.altus.com.br) o envíe un email a [email protected]. Si el equipo ya está instalado, tenga en manos las siguientes informaciones al solicitar asistencia: Los modelos de los equipos utilizados y la configuración del sistema instalado El número de serie de la UCP La revisión del equipo y la versión del software ejecutivo, constantes en la etiqueta fijada al costado del producto Informaciones sobre el modo de operación de la UCP, obtenidas a través del MasterTool IEC XE El contenido del programa aplicativo, obtenido a través del programador MasterTool IEC XE La versión del programador utilizado Mensajes de Advertencia Utilizados en este Manual En este manual, los mensajes de advertencia presentarán los formatos y significados, a continuación: PELIGRO: Relacionan causas potenciales, que si no se observan, llevan a daños a la integridad física y salud, patrimonio, medio ambiente y pérdida de la producción. CUIDADO: Relacionan detalles de configuración, aplicación e instalación que se deben seguir para evitar condiciones que puedan llevar a falla del sistema y sus consecuencias relacionadas. 5 1. Introducción ATENCIÓN: Indican detalles importantes de configuración, aplicación o instalación para obtención del máximo desempeño operacional del sistema. 6 2. Descripción Técnica 2. Descripción Técnica Este capítulo presenta todas las características técnicas de las UCPs de la Serie Nexto NX3004, NX3005, NX3010, NX3020 y NX3030. Paneles y Conexiones La figura a continuación muestra el panel delantero de UCP NX3030. Figura 2-1. UCP NX3030 Como se puede observar en la figura, en la parte superior del panel delantero se encuentra el visor gráfico que se utiliza para mostrar el estado y diagnóstico de todo el sistema, lo que incluye los diagnósticos específicos de cada módulo. El visor gráfico también ofrece un menú fácil de usar que trae al usuario un modo rápido para leer o definir algunos parámetros como: temperatura interna (solamente lectura), contraste del visor gráfico, dirección IP para cada interfaz de red (solamente lectura) y hora local (solamente lectura). Abajo del visor gráfico, se encuentran los 2 LEDs que indican la ocurrencia de diagnóstico y del circuito watchdog. La Tabla 2-1. muestra la descripción de los LEDs. Para más informaciones sobre los estados y significados de los LEDs, consultar el capítulo Mantenimiento – Diagnósticos vía LED. LED Descripción DG LED de Diagnóstico WD LED de Watchdog Tabla 2-1. Descripción de los LEDs Las UCPs de la Serie Nexto poseen dos teclas disponibles al usuario. La Tabla 2-2. muestra la descripción de las teclas. Para más informaciones sobre la tecla de diagnóstico, consulte los capítulos 7 2. Descripción Técnica Mantenimiento – Diagnósticos One Touch y Configuración–Menú Informativo y de Configuración de la UCP. Para obtener más informaciones sobre la tecla MS, consulte el capítulo de Configuración – Tarjeta de Memoria. Teclas Tecla de Diagnóstico MS Descripción Tecla ubicada en la parte superior del módulo. Se utiliza para visualización de los diagnósticos en el visor gráfico o para navegación en el menú informativo y de configuraciones de la UCP. Tecla ubicada en el panel delantero. Utilizada para remover la tarjeta de memoria con seguridad. Tabla 2-2. Descripción de las Teclas En el panel delantero están disponibles las interfaces de conexión de las UCPs de la Serie Nexto. Dichas interfaces son de comunicación Ethernet, comunicación serial y la interfaz de la tarjeta de memoria. La Tabla 2-3. presenta una breve descripción de esas interfaces. Interfaces Disponible en los modelos NET 1 NX3004 NX3005 NX3010 NX3020 NX3030 Conector tipo RJ45 de comunicación en el estándar 10/100Base-TX. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS TCP cliente y servidor, MODBUS RTU por TCP cliente y servidor. Para obtener más informaciones sobre la utilización, consulte el capítulo Configuración – Configuración de las Interfaces Ethernet. NX3020 NX3030 Conector tipo RJ45 de comunicación en el estándar 10/100Base-TX. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS TCP cliente y servidor, MODBUS RTU por TCP cliente y servidor. Para obtener más informaciones sobre la utilización, consulte el capítulo Configuración – Configuración de las Interfaces Ethernet. COM 1 NX3010 NX3020 NX3030 Conector tipo DB9 hembra para comunicación en el estándar RS-232C. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS RTU esclavo o MODBUS RTU maestro. Para obtener más informaciones sobre la utilización, consulte el capítulo Configuración – Configuración de las Interfaces Seriales. COM1 NX3004 NX3005 COM 2 NX3010 NX3020 NX3030 Fuente de Alimentación NX3004 NX3005 Conector de seis terminales con fijación. Permite alimentar a los módulos de la Serie Nexto conectados al bus, proporcionando una potencia de 15 W. NX3010 NX3020 NX3030 Conector para tarjeta de memoria. Permite utilizar una tarjeta de memoria para diferentes tipos de almacenaje de datos como: logs de usuario, páginas Web, la documentación del proyecto y archivos de origen. Para obtener más informaciones sobre utilización, consulte el capítulo Configuración – Tarjeta de Memoria. NET 2 MEMORY SLOT Descripción Conector tipo DB9 hembra para comunicación en los estándares RS-485 y RS-422. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS RTU esclavo o MODBUS RTU maestro. Para obtener más informaciones sobre la utilización, consulte el capítulo Configuración – Configuración de las Interfaces Seriales. Tabla 2-3. Interfaces de Conexión 8 2. Descripción Técnica Características Generales Características Comunes NX3004, NX3005, NX3010, NX3020, NX3030 Ocupación del bastidor 2 posiciones secuenciales Lenguaje de programación Lista de Instrucciones (IL) Texto Estructurado (ST) Diagrama Ladder (LD) Secuenciamento Gráfico de Funciones (SFC) Diagrama de Bloques Funcionales (FBD) Gráfico Funcional Continuo (CFC) Tipos de tareas Cíclica (periódica) Disparada por evento (evento de software) Disparado por evento externo (evento de hardware) Continua (ejecución libre) Disparada por estado (evento de software) Alteraciones online Sí Soporte cambio en caliente Sí Soporte redundancia bus expansion Sí Interfaces seriales NX3004/NX3005 – COM 1: 1 x RS-485 / RS-422 NX3010/NX3020/NX3030 – COM 1: 1 x RS-232C NX3010/NX3020/NX3030 – COM 2: 1 x RS-485 / RS-422 Protocolo MODBUS Maestro y esclavo RTU (COM 1 y COM 2) Cliente y servidor TCP (NET 1 y NET 2) Cliente y servidor RTU vía TCP (NET1 y NET2) Protocolo OPC Sí Protocolo EtherCAT Sí, NX3020 y NX3030 Protocolo SNMP Sí, versiones v1, v2c e v3 Reloj en tiempo real (RTC) Sí Resolución de 1 ms y máxima variación de 2 s por día Watchdog Sí Indicación de status y diagnóstico Visor gráfico, LEDs, páginas web y memoria interna de la UCP One Touch Diag (OTD) Sí Electronic Tag on Display (ETD) Sí Aislamiento Lógica para tierra de protección 1250 Vac / 1 minuto Lógica para interfaces Ethernet 1500 Vac / 1 minuto Lógica para puerta serial (COM 2) 1000 Vac / 1 minuto Lógica para puerta serial en NX3004/NX3005 (COM1) 1000 Vac / 1 minuto Interfaces Ethernet para tierra de protección 1250 Vac / 1 minuto Interfaces Ethernet para puerta serial (COM 2) 1500 Vac / 1 minuto Interfaces Ethernet para porta serial na NX3004/NX3005 (COM 1) 1500 Vac / 1 minuto Interfaz Ethernet para Interfaz Ethernet 1500 Vac / 1 minuto Puerta Serial (COM 2) para tierra de protección 1250 Vac / 1 minuto Puerta Serial en la NX3004/NX3005 (COM 1) para tierra de protección 1000 Vac / 1 minuto Temperatura de operación 0 a 60 °C Temperatura de almacenaje -25 a 75 °C Humedad relativa de operación y almacenaje 5 a 96 %, sin condensación 9 2. Descripción Técnica Revestimiento de circuitos electrónicos Sí Índice de protección IP 20 IEC 61131-2 IEC 61131-3 CE, directivas de Compatibilidad Electromagnética (EMC) y Dispositivos de Baja Tensión (Low-Voltage Directive – LVD). Estándares Dimensiones del módulo (L x A x P) 36,00 x 114,63 x 115,30 mm Dimensiones del embalaje (L x A x P) 44,00 x 122,00 x 147,00 mm Peso 350 g Peso con embalaje 400 g Tabla 2-4. Características Comunes Notas: Tipos de tareas: Tarea es un objeto usado para llamar POUs. Una tarea se puede disparar por período, eventos o se puede aún ejecutar en el modo continuo. Cada tarea puede llamar una o más POUs. Reloj de tiempo real (RTC): el tiempo de retención, en el cual el reloj de tiempo real seguirá a actualizar la data y hora después de la desenergización de la UCP, es 15 días para operación con 25 °C. En ambientes con la temperatura máxima soportada por el producto, el tiempo se puede reducir para 10 días. Aislamiento: El témino lógica es usado para describir los circuitos internos como procesador, memoria e interfaces con el bus. Revestimiento de circuitos electrónicos: El revestimiento de circuitos electrónicos protege las partes internas del producto contra humedad, polvo y otros elementos dañosos a los circuitos electrónicos. Características Específicas NX3004 NX3005 NX3010 NX3020 NX3030 Memoria de variables de entrada de representación directa (%I) 32 Kbytes 32 Kbytes 32 kbytes 64 kbytes 96 kbytes Memoria de variables de salida de representación directa (%Q) 32 Kbytes 32 Kbytes 32 Kbytes 64 Kbytes 96 Kbytes Memoria de variables de representación directa (%M) 16 Kbytes 16 Kbytes 16 Kbytes 32 Kbytes 64 Kbytes Memoria de variables simbólicas 2 Mbytes 3 Mbytes 4 Mbytes 5 Mbytes 6 Mbytes 7,5 Kbytes 7,5 Kbytes 64 Kbytes 112 Kbytes 112 Kbytes - - - - 736 Kbytes - - 80 Kbytes - - 80 Kbytes - - 64 Kbytes 512 Kbytes Cantidad máxima de memoria configurable como retentiva o persistente Memoria de datos redundantes total Memoria de variables de entrada de representación directa (%I) - Memoria de variables de salida de representación directa (%Q) - Memoria de variables de representación directa (%M) - Memoria de variables simbólicas Memoria de programa Memoria de código fuente (backup) - - - - - 3 Mbytes 3 Mbytes 4 Mbytes 6 Mbytes 8 Mbytes 32 Mbytes 40 Mbytes 40 Mbytes 80 Mbytes 120 Mbytes 10 2. Descripción Técnica Memoria de archivos de usuario 16 Mbytes 16 Mbytes 16 Mbytes 32 Mbytes 32 Mbytes Número máximo de tareas 16 16 16 24 32 Número máximo de bus de expansión 1 4 8 24 24 Número máximo total de módulos de E/S en los buses 32 64 128 128 128 Ethernet TCP/IP interfaz local 1 1 1 2 2 Número máximo de módulos adicionales de interfaz Ethernet TCP/IP 0 1 0 2 6 No No No Sí Sí 1 1 1 4 4 Soporte de redundancia de red PROFIBUS-DP No No No Sí Sí Soporte a redundancia (half-cluster) No No No No Sí Registro de eventos (SOE) No No No Sí Sí - - - DNP3 DNP3 Soporte de redundancia de interfaces Ethernet TCP/IP Número máximo de redes PROFIBUS-DP (con módulos maestros PROFIBUS-DP) Protocolo - - - 1000 1000 Sincronización del reloj (SNTP) Tamaño máximo de la cola de eventos Sí Sí Sí Sí Sí Desarrollo de páginas Web (accesible a través del protocolo HTTP) No Sí No No No Fuente de alimentación integrada Sí Sí Sí No No - - 800 mA 1000 mA 1000 mA 4W 4W 4W 5W 5W Consumo de corriente en el bus de la fuente de alimentación Disipación Tabla 2-5. Características Específicas Notas: Memoria de variables de entrada de representación directa (%I): Área donde se asignan las variables de representación directa para el tipo de entrada. Variable de representación directa significa que la variable se puede acceder directamente en la memoria utilizando la dirección deseada. Por ejemplo: %IB0, %IW100. Variable de entrada de representación directa puede utilizarse para mapear los puntos de entrada analógicos y digitales. Como referencia, 8 puntos de entradas digitales pueden ser representados por un byte y un punto de entrada analógica puede ser representado por dos bytes. Memoria de variables de salida de representación directa (%Q) total: Área donde se asignan las variables de representación directa para el tipo de salida. Variable de representación directa significa que la variable se puede acceder directamente en la memoria utilizando la dirección deseada. Por ejemplo: %QB0, %QW100. Variables de salida de representación directa se puede usar para mapear puntos de salida analógicos o digitales. Como referencia, 8 puntos de salida digital se pueden representar por un byte y un punto de salida analógica se puede representar por dos bytes. Variables de representación directa de salida aún se pueden configurar como retentivas, persistentes y o redundantes, pero el tamaño total no cambia dependiendo de la configuración. La UCP NX3030 de la Serie Nexto permite definir un área para las variables redundantes en el área de memoria de las variables de representación directa de salida %Q. El subconjunto de los tipos de memoria de variables de representación directa de salida es parte de la memoria total disponible. Memoria de variables de representación directa (%M): Área donde se asignan las variables de representación directa para el tipo marker. Variable de representación directa significa que la variable se puede acceder directamente en la memoria utilizando la dirección deseada. Por ejemplo %MB0, %MW100. Memoria de variables simbólicas: Área donde se asignan las variables simbólicas. Variables simbólicas son variables IEC creadas en POUs y GVLs durante el desarrollo de la aplicación, no direccionadas directamente en la memoria. Variables simbólicas se pueden definir como retentivas o 11 2. Descripción Técnica persistentes, en este caso se utilizan las áreas de memoria de variables simbólicas retentivas o memoria de variables simbólicas persistentes respectivamente. Memoria de variables retentivas y persistentes: Área donde se asignan las variables retentivas y persistentes. Datos retentivos mantienen su respectivo valor, aun después de un ciclo de energización/desenergización de la UCP. Datos persistentes mantienen su respectivo valor aun después del download de una nueva aplicación para la UCP. ATENCIÓN: La declaración y uso de variables persistentes simbólicas deben llevarse a cabo únicamente a través del objeto Persistent Vars, que puede incluirse en el proyecto a través de la tree view en Application -> Add Object-> Persistent Variables. No debe utilizarse la expresión VAR PERSISTENT en el campo de declaración de variables de las POUs. La lista completa que informa cuando las variables simbólicas persistentes mantienen su valor o no se encuentra en la Tabla 2-6. Además del tamaño de la área persistente indicado en la Tabla 2-5, se reservan 44 bytes para almacenar información acerca de las variables persistentes (no disponible para su uso). La Tabla 2-6 muestra el comportamiento de las variables simbólicas, retentivas y persistentes para las diferentes situaciones, donde “-” significa que el valor se pierde y “X” significa que el valor se mantiene. Variable simbólica Variable retentiva Variable persistente Reset a Caliente/ Ciclo de energización Comando - X X Reset a Frío - - X Reset Origen - - - Retirar UCP o Fuente de Alimentación del Bastidor mientras esté energizado - - - Download - - X Alteración Online X X X Reiniciar CP - X X Clean All - - X Tabla 2-6. Comportamiento de las Variables Tras el Evento En las versiones inferiores o iguales a 1.5.0.21 para NX3004 y 1.5.1.0 para NX3010, NX3020 y NX3030 las memorias retentivas y persistentes simbólicas y de salida de representación directa (%Q) tenían tamaño máximo fijo. En la Tabla 2-7 es posible ver el tamaño máximo permitido en versiones anteriores de las UCPs. En versiones superiores, las UCPs tienen la funcionalidad de tamaño de memorias retentivas y persistentes flexibles. Para más informaciones acerca del funcionamiento, consulte la sección Áreas de Memoria Retentiva y Persistente en Configuración. NX3004 NX3010 NX3020 NX3030 Memoria de variables de salida representación directa retentivas (%Q) 2 Kbytes 8 Kbytes 16 Kbytes 16 Kbytes Memoria de variables de salida representación directa persistentes (% Q) 2 Kbytes 8 Kbytes 16 Kbytes 48 Kbytes Memoria de variables simbólicas retentivas 2 Kbytes 32 Kbytes 48 Kbytes 32 Kbytes Memoria de variables simbólicas persistentes 1,5 Kbytes 16 Kbytes 32 Kbytes 16 Kbytes Tabla 2-7. Memorias Retentivas y Persistentes en Versiones Antiguas 12 2. Descripción Técnica En el caso del comando de Clean All, en el caso de que la aplicación haya sido alterada de tal forma que variables persistentes se hayan removido, insertadas en el inicio de la lista o entonces hayan tenido su tipo alterado, el valor de dichas variables se perderá (avisado por la herramienta MasterTool al realizar el download). De esta forma, se recomienda que alteraciones en la GVL de variables persistentes involucren solamente la inclusión de nuevas variables en el fin de la lista. Memoria de datos redundantes total: Memoria de datos redundantes es la capacidad máxima de memoria que se puede usar como memoria redundante entre dos UCPs que forman el par redundante. Este valor no es una memoria diferente, observe que la suma de todas las variables redundantes (variable de entrada de representación directa, variable de salida de representación directa, variable de representación directa, variable simbólica, variable simbólica retentiva, variable simbólica persistente) debe ser igual o menor que la memoria de los datos redundantes. Memoria de programa: Es la memoria del tamaño máximo que se puede usar para la aplicación del usuario. Esta área es compartida con la memoria de código fuente, el área total es la suma de (Memoria de programa + Memoria de código fuente). Memoria de código fuente (backup): Es la memoria que se utiliza como backup del proyecto, es decir, si el usuario desea importar su proyecto, el software MasterTool IEC XE obtendrá la información requerida en esta área. Es importante asegurar que el proyecto guardado como copia de seguridad es actual, evitando que se pierda información crítica. Esta área es compartida con la memoria de programa, el área total es la suma de (Memoria de programa + Memoria de código fuente). Memoria de archivos del usuario: Es la memoria destinada para el almacenaje de archivos tales como doc, pdf, imágenes y otros, es decir, permite la grabación de datos como una tarjeta de memoria. Más informaciones se encuentran en la sección Configuración - Memoria de Archivos de Usuario. Número máximo de tareas: Más informaciones sobre el número máximo de tareas para cada modelo de UCP y entre cada perfil de proyecto se encuentran en la sección Número Máximo de Tareas. Soporte a redundancia (half-cluster): La versión de software 1.1.0.0 o mayor/revisión del producto AB o mayor soportan redundancia de UCPs NX3030. Registro de eventos (SOE): Los tipos de datos se pueden encontrar en el Interoperabilidad DNP3. Número máximo de módulos de E/S en el bus: El número máximo de módulos de E/S se refiere a la suma de todos los módulos del bus y de las expansiones. Número máximo de redes PROFIBUS-DP: Desde la versión 1.22 de MasterTool IEC XE o superior se permiten 4 redes PROFIBUS-DP para las UCPs NX3020 y NX3030. Anteriormente se permitió 2 redes PROFIBUS-DP. Se limita el uso de un máximo de 4 módulos maestro PROFIBUSDP, esto significa que sólo 2 redes redundantes pueden ser utilizadas. Interfaces Seriales COM 1 (NX3010/NX3020/NX3030) NX3010, NX3020, NX3030 Conector DB9 hembra blindado Medio físico RS-232C Señales de modem RTS, CTS, DCD Baud rate 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps Protocolos MODBUS RTU maestro/esclavo Protocolo abierto Tabla 2-8. Características de la Interfaz Serial COM 1 13 2. Descripción Técnica COM 1 (NX3004/NX3005) e COM 2 (NX3010/NX3020/NX3030) NX3004, NX3005, NX3010, NX3020, NX3030 Conector DB9 hembra blindado Medio físico RS-422 o RS-485 (dependiendo del cable seleccionado) Dirección de comunicación RS-422: full duplex RS-485: half duplex Número máximo de transceivers RS-422 11 (1 transmisor y 10 receptores) Número máximo de transceivers RS-485 32 Terminación Sí (opcional vía selección del cable) Baud rate 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps Protocolos MODBUS RTU maestro/esclavo Protocolo abierto Tabla 2-9. Características de la Interfaz Serial COM 2 Notas: Medio Físico: Dependiendo de la configuración del cable que se utiliza, es posible elegir el tipo de interfaz física: RS-422 o RS-485. La lista de los cables se puede encontrar en la sección Productos Relacionados. Número Máximo de Transceivers RS-422: El número máximo de transceivers es la mayor cantidad de interfaces que se pueden utilizar en el mismo bus. Número Máximo de Transceivers RS-485: El número máximo de transceivers es la mayor cantidad de interfaces que se pueden utilizar en el mismo bus. Interfaces Ethernet NET 1 NX3004, NX3005, NX3010, NX3020, NX3030 Conector RJ45 hembra blindado Auto negociación (auto crossover) Sí Tamaño máximo del cable 100 m Tipo de cable UTP o ScTP, categoría 5 Baud rate 10/100 Mbps Capa física 10/100 BASE-TX Capa de enlace de datos LLC (Control de Enlace Lógico) Capa de red IP (Protocolo de Internet) Capa de transporte TCP (Protocolo de Control de Transmisión) y UDP (Protocolo de Datagrama de Usuario) Capa de aplicación Cliente/ Servidor MODBUS TCP Cliente/ Servidor MODBUS RTU vía TCP HTTP (servidor web) Protocolo de programación MasterTool IEC XE DNP3 (informe de datos orientados al evento) SNTP (sincronismo de reloj) EtherCAT OPC SNMP ( gerenciamiento de red Ethernet) Ethernet/IP Scanner/Adapter Diagnóstico LEDs - verde (velocidad), amarillo (link/actividad) Tabla 2-10. Características de la Interfaz Ethernet NET 1 14 2. Descripción Técnica Nota: Capa de Aplicación: Los protocolos DNP3 y EtherCAT no están disponibles para las UCPs NX3004, NX3005 y NX3010. NET 2 NX3020, NX3030 Conector RJ45 hembra blindado Auto negociación (auto crossover) Sí Tamaño máximo del cable 100 m Tipo del cable UTP o ScTP, categoría 5 Baud rate 10/100 Mbps Capa física 10/100 BASE-TX Capa de enlace de datos LLC (Control de Enlace Lógico) Capa de red IP (Protocolo de Internet) Capa de transporte TCP (Protocolo de Control de Transmisión) y UDP (Protocolo de Datagrama de Usuario) Capa de aplicación Cliente/ Servidor MODBUS TCP Cliente/ Servidor MODBUS RTU vía TCP HTTP (servidor Web) Protocolo de programación MasterTool IEC XE DNP3 (informe de datos orientados al evento) SNTP (sincronismo de reloj) EtherCAT OPC SNMP (gerenciamiento de red Ethernet) Ethernet/IP Scanner/Adapter Diagnóstico LEDs - verde (velocidad), amarillo (link/actividad) Tabla 2-11. Características de la Interfaz Ethernet NET 2 Fuente de Alimentación NX3004, NX3005 Tensión nominal de entrada 24 Vdc Potencia de salida máxima 15 W Corriente de salida máxima 3A Tensión de entrada 19,2 a 30 Vdc Corriente de entrada máxima (inrush) 30 A Corriente de entrada máxima 1.4 A Interrupción de voltaje de entrada máximo 10 ms @ 24 Vdc Aislamiento Entrada a salida 1000 Vac / 1 minuto Entrada para protección de 1500 Vac / 1 minuto tierra Entrada de tierra funcional 1000 Vac / 1 minuto Calibre del cable 0,5 mm² Protección de polaridad inversa Sí Fusible reajustable interno Sí Protección a cortocircuito en la salida Sí Protección contra sobre corriente Sí Tabla 2-12. Características de la Fuente de Alimentación 15 2. Descripción Técnica Nota: Potencia de salida máxima: El uso de módulos de E/S NextoJet, es posible extender y vienen utilizando 20 W de potencia de salida. Ver Nota de aplicación NAP152 para cumplir con las restricciones al uso de este límite. Interfaz de la Tarjeta de Memoria Las tarjetas de memoria se pueden usar para diferentes tipos de almacenaje de datos como: logs de usuarios, páginas web, documentación de proyecto y archivos fuentes. Más informaciones sobre cómo usar interfaz de tarjeta de memoria se pueden encontrar en Tarjeta de Memoria. NX3010, NX3020, NX3030 Capacidad máxima 8 Gbytes Capacidad mínima 2 Gbytes Tipo miniSD Sistema de archivo FAT32 Remover tarjeta con seguridad Sí, presionando el botón MS Tabla 2-13. Características de la Interfaz con Tarjeta de Memoria Notas: Capacidad Máxima: La capacidad de la tarjeta de memoria debe ser igual o inferior a este límite para su correcto funcionamiento en la UCP Nexto, y puede que la UCP no reconozca la tarjeta u ocurran pérdidas de datos durante transferencias. Capacidad Mínima: La capacidad de la tarjeta de memoria debe ser igual o superior a este límite para su correcto funcionamiento en la UCP Nexto, y puede que la UCP no reconozca la tarjeta u ocurran pérdidas de datos durante transferencias. Sistema de Archivos: Se recomienda formatear la memoria utilizando la propia UCP Nexto, en caso contrario podrá ocurrir pérdida de desempeño en el acceso a la interfaz de la tarjeta de memoria. Compatibilidad con Demás Productos Hay algunas incompatibilidades entre las UCPs de la serie Nexto y el MasterTool IEC XE. Consulte la Tabla 2-14 para averiguar qué versión de MasterTool IEC XE se puede usar. Versión de software de las UCPs de la Serie Nexto Versión de MasterTool IEC XE compatible NX3004 NX3005 NX3010, NX3020, NX3030 - - 1.2.0.9 o inferior 1.00 a 1.28 - - 1.2.1.0 a 1.2.4.0 1.29 a 1.40 - - 1.3.0.20 1.40 a 1.41 - - 1.4.0.33 2.00 1.5.0.18 - 1.5.0.10 a 1.5.0.16 2.01 a 2.02 1.5.1.2 - 1.5.1.3 2.03 a 2.06 1.6.0.0 1.6.0.0 1.6.0.0 2.07 o superior Tabla 2-14. Compatibilidad entre productos Nota: Compatibilidad entre versiones: algunas funcionalidades están disponibles solo a partir de determinada versión. Consulte la sección del Manual del Usuario MasterTool IEC XE - MU299800, acerca de la funcionalidad para comprobar la disponibilidad de una determinada función en una versión específica del programador. 16 2. Descripción Técnica Desempeño El desempeño de las UCPs de la Serie Nexto dependen de: Tiempo de la Aplicación del Usuario Intervalo de la Aplicación Tiempo del Sistema Operacional Cantidad de módulos (datos de proceso, entradas/salidas, entre otros) Tiempos de Aplicación El tiempo de ejecución de una aplicación de las UCPs de la Serie Nexto depende de las siguientes variables: Tiempo de lectura de las entradas (locales y remotas) Tiempo de ejecución de las tareas Tiempo de escritura de las salidas (locales y remotas) Es importante resaltar que el tiempo de ejecución de la tarea “MainTask” tendrá influencia directa de la tarea de sistema “Configuración”, una tarea de alta prioridad, ejecutada periódicamente por el sistema. La tarea “Configuración” podrá interrumpir “MainTask” y, cuando utilizados módulos de comunicación, como, por ejemplo, el módulo Ethernet NX5000, el incremento de tiempo a la “MainTask” podrá ser de hasta 25% de su tiempo promedio de ejecución. Tiempos para Ejecución de Instrucciones En la Tabla 2-15. , se encuentran los tiempos necesarios para la realización de diferentes instrucciones en las UCPs de la Serie Nexto: Tiempos instrucciones (us) Instrucción Lenguaje Variables 1000 Contactos LD BOOL 6 INT 43 REAL 81 ST 1000 Divisiones IL LD ST 1000 Multiplicaciones IL LD ST 1000 Sumas IL LD NX3004, NX3010, NX3020, NX3030 INT 43 REAL 81 INT 43 REAL 81 INT 15 REAL 23 INT 15 REAL 23 INT 15 REAL 23 INT 15 REAL 23 INT 15 REAL 23 INT 15 REAL 23 Tabla 2-15. Tiempos de Instrucciones Tiempos de Inicialización Las UCPs de la Serie Nexto poseen tiempo de inicialización de 50 segundos, siendo que la pantalla inicial con el logotipo se presenta después de 20 segundos de la energización. 17 2. Descripción Técnica Tiempo de Intervalo El tiempo de intervalo de cada tarea de la UCP, depende del aplicativo y se puede configurar con valores de 5 a 750 ms. Dimensiones Físicas NX3004/NX3005 Dimensiones en mm. Figura 2-2. Dimensiones Físicas de la UCP NX3004 e NX3005 18 2. Descripción Técnica NX3010, NX3020 e NX3030 Dimensiones en mm. Figura 2-3. Dimensiones Físicas de la UCPs NX3010, NX3020 y NX3030 Datos para Compra Ítems Integrantes El embalaje del producto contiene los siguientes ítems: Módulo NX3004, NX3005, NX3010, NX3020 o NX3030 Conector 6 terminales con fijación (solamente NX3004 y NX3005) Guía de Instalación 19 2. Descripción Técnica Código del Producto Los siguientes códigos se deben usar para la compra del producto: Código Descripción NX3004 UCP con 1 puerta Ethernet, 1 canal serial, soporte a expansión de bus y fuente de alimentación integrada. NX3005 UCP con 1 puerta Ethernet, 1 canal serial, soporte a expansión de bus, fuente de alimentación integrada y apoyo a las paginas web de usuario NX3010 UCP de alta velocidad, 1 puerta Ethernet, 2 canales seriales, interfaz para tarjeta de memoria y soporte a expansión de bus NX3020 UCP de alta velocidad, 2 puertas Ethernet, 2 canales seriales, interfaz para tarjeta de memoria y soporte a expansión de bus NX3030 UCP de alta velocidad, 2 puertas Ethernet, 2 canales seriales, interfaz para tarjeta de memoria, soporte a expansión de bus y soporte a redundancia Tabla 2-16. Modelos de UCPs de la Serie Nexto Productos Relacionados Los siguientes productos se deben adquirir separadamente cuando necesario: Código Descripción MT8500 MasterTool IEC XE AL-2600 Derivador y terminador de red RS-485 AL-2301 Cable de red RS-485 (hasta 1000 metros) AL-2306 Cable de red RS-485 (hasta 500 metros) AL-2319 Cable RJ45-RJ45 AL-1729 Cable RJ45-CMDB9 AL-1748 Cable CMDB9-CFDB9 AL-1752 Cable CMDB9-CMDB9 AL-1753 Cable CMDB9-CMDB25 AL-1754 Cable CMDB9-CFDB9 AL-1761 Cable CMDB9- CMDB9 AL-1762 Cable CMDB9- CMDB9 AL-1763 Cable CMDB9-Terminales NX9101 8 Gb Memory Card, MicroSD with MiniSD Adapter NX9202 Cable RJ45-RJ45 2 m NX9205 Cable RJ45-RJ45 5 m NX9210 Cable RJ45-RJ45 10 m Tabla 2-17. Productos Relacionados Notas: MT8500: MasterTool IEC XE está disponible en tres versiones diferentes: LITE, PROFESSIONAL y ADVANCED. Para más informaciones, favor consultar el Manual del Usuario MasterTool IEC XE - MU299800. AL-2600: Este módulo se utiliza para derivación y terminación de una red RS-422/485. Para cada nodo de la red debe existir un AL-2600. Los AL-2600 que están en las extremidades de la red se deben configurar como terminación, excepto cuando hay un dispositivo con terminación interna activa, el restante como derivación. AL-2301: Cable blindado de dos pares trenzados, sin conectores, para utilizar en redes RS-485 y RS422, con tamaño máximo de 1000 metros. AL-2306: Cable blindado de dos pares trenzados, sin conectores, para utilizar en redes RS-485 y RS422 con tamaño máximo de 500 metros. 20 2. Descripción Técnica AL-2319: Cable con dos conectores RJ45 para programación de UCPs de la Serie Nexto y para comunicación Ethernet punto-a-punto con otro dispositivo con interfaz Ethernet. AL-1729: Cable estándar RS-232C con 1 conector RJ45 y 1 conector DB9 macho para comunicación entre las UCPs de la Serie Nexto y los productos Altus de la Serie DUO, de la Serie Piccolo y de la Serie Ponto. AL-1748: Cable estándar RS-232C con 1 conector DB9 macho y 1 conector DB9 hembra para comunicación entre las UCPs de la Serie Nexto y los productos Altus de la Serie Cimrex. AL-1752: Cable estándar RS-232C con 2 conectores DB9 macho para comunicación entre las UCPs de la Serie Nexto y los productos Altus de la Serie H y Serie iX. AL-1753: Cable estándar RS-232C con 1 conector DB9 macho y 1 conector DB25 macho para comunicación entre las UCPs de la Serie Nexto y los productos Altus de la Serie H. AL-1754: Cable estándar RS-232C con 1 conector DB9 macho y 1 conector DB9 hembra para comunicación entre las UCPs de la Serie Nexto y otros productos Altus de la Serie Exter o puerta serial, estándar RS-232C, de una microcomputadora. AL 1761: Cable estándar RS 232C con dos conectores DB9 macho para comunicación entre las UCPs de la Serie Nexto y otros productos Altus de la Serie AL. AL 1762: Cable estándar RS 232C con dos conectores DB9 macho para comunicación entre las UCPs de la Serie Nexto. AL-1763: Cable con 1 conector DB9 macho y terminales para comunicación entre las UCPs de la Serie Nexto y productos con bornes estándar RS-485/RS-422. NX9202/NX9205/NX9210: Cables que se usan para interligar las expansión de bus. 21 3. Instalación 3. Instalación Este capítulo presenta los procedimientos necesarios para la instalación física de las UCPs de la Serie Nexto, bien como los cuidados que se debe tener con otras instalaciones existentes en el armario eléctrico ocupado por el CP. Instalación Mecánica NX3004 y NX3005 Las UCPs NX3004 y NX3005 se deben insertar en la posición 0 del bastidor da Série Nexto. Se requieren dos posiciones secuenciales, esto significa que la UCP ocupa las posiciones 0 y 1 del bastidor. NX3010, NX3020 y N3030 Las UCPs NX3010, NX3020 y NX3030 se deben insertar en la posición 2 del bastidor, luego enseguida del Módulo Fuente de Alimentación. Todas las informaciones sobre al montaje mecánico e inserción del módulo se pueden encontrar en el Manual del Usuario Serie Nexto - MU214300. Instalación Eléctrica PELIGRO: Al realizar cualquier instalación en un panel eléctrico, certifíquese de que la alimentación general del armario esté DESCONECTADA. NX3004 y NX3005 La Figura 3-1 ilustra el diagrama eléctrico de las UCPs NX3004 y NX3005 de la Serie Nexto instalada en un bastidor de la Serie Nexto. La disposición de conectores y terminales en la figura es meramente ilustrativa. Figura 3-1. Diagrama Eléctrico de la UCP NX3004 y NX3005 22 3. Instalación Notas do Diagrama: 1. Interfaz Ethernet estándar 10/100Base-TX para programación, depuración y conexión a la red MODBUS TCP u otros protocolos. 2. Interfaz serial estándar RS-485/RS-422 para conexión a la red MODBUS RTU u otros protocolos. La elección del tipo de interfaz física depende del cable utilizado.O aterramento vindo da fonte de alimentação externa está conectado ao terminal . Utilizar cabos de 0,5 mm². 3. La tierra de la fuente de alimentación externa está conectado al terminal . Utilice cables de 0,5 mm². 4. La fuente de alimentación está conectada al terminal 0 V. Utilice cables de 0,5 mm². 5. La fuente de alimentación está conectada al terminal 24 V. Utilice cables de 0,5 mm². 6. La fuente de alimentación fornece energía al circuito interno directamente 7. Bus de datos local 8. El módulo alimenta los otros módulos de la Serie Nexto a través de la conexión con el bastidor 9. El aterramiento del módulo se realiza a través del bastidor Serie de la Nexto. NX3010, NX3020 y NX3030 La alimentación de las UCPs NX3010, NX3020 y NX3030 es proveniente del Módulo Fuente de Alimentación, el cual provee tensión a las UCPs a través de la conexión al bastidor, lo que hace con que no se necesiten conexiones externas. El aterramiento del módulo se realiza a través del contacto entre el resorte de aterramiento del módulo y el bastidor. La Figura 3-2 ilustra el diagrama eléctrico de las UCPs de la Serie Nexto instalada en un bastidor de la Serie Nexto. La disposición de los conectores y bornes en la figura es meramente ilustrativa. Figura 3-2. Diagrama Eléctrico de las UCPs NX3010, NX3020 y NX3030 de la Serie Nexto Notas del Diagrama: 1. Interfaz para tarjeta de memoria. 23 3. Instalación 2. Interfaz Ethernet estándar 10/100Base-TX para programación, depuración y conexión a la red MODBUS TCP u otros protocolos. 3. Interfaz Ethernet estándar 10/100Base-TX para conexión a la red MODBUS TCP u otros protocolos (solamente para NX3020 y NX3030). 4. Interfaz serial estándar RS-232C para conexión a la red MODBUS RTU u otros protocolos. La elección del tipo de interfaz física depende del cable utilizado. 5. Interfaz serial estándar RS-485/RS-422 para conexión a la red MODBUS RTU u otros protocolos. La elección del tipo de interfaz física depende del cable utilizado. 6. El módulo se pone a tierra a través de los bastidores de la Serie Nexto. 7. La alimentación del módulo es proveniente de la conexión al bastidor, no necesita que se usen conexiones externas. Conexión con la Red Ethernet Las interfaces aisladas de comunicación NET 1 y NET 2 (solamente para NX3020 y NX3030) posibilitan la conexión con una red Ethernet donde la interfaz NET1 es más indicada para comunicación con el MasterTool IEC XE. La conexión con la red Ethernet utiliza cables tipo par trenzado (10/100Base-TX), siendo que la detección de la velocidad se realiza automáticamente por la UCP Nexto. Este cable debe tener una de sus extremidades conectadas a la interfaz que se pretende utilizar y la otra al HUB, switch, microcomputadora u otro punto de red Ethernet. Dirección IP La interfaz de Ethernet NET 1 se utiliza para comunicación Ethernet y para la configuración de la UCP. Para esto, está configurada de fábrica con los siguientes parámetros: NET 1 Dirección IP 192.168.15.1 Máscara de Subred 255.255.255.0 Dirección del Gateway 192.168.15.253 Tabla 3-1. Parámetros de Fábrica de la Interfaz Ethernet NET 1 Los parámetros Dirección IP y Máscara de Subred se pueden ver en el visor gráfico de la UCP a través del menú de parámetros, según lo descrito en el capítulo Configuración – Menú Informativo y de Configuración de la UCP. Inicialmente, se debe conectar la interfaz NET 1 de la UCP a una red o microcomputadora con la misma subred para comunicación con el MasterTool IEC XE, donde los parámetros de red se pueden alterar. Para más detalles sobre la configuración y alteración de parámetros de red, fíjese en el capítulo Configuración – Configuración de las Interfaces Ethernet. La interfaz de Ethernet NET 2 disponible solamente para las UCPs NX3020 y NX3030 se utiliza sólo para comunicación Ethernet y se configura de fábrica con los siguientes parámetros. NET 2 Dirección IP 192.168.16.1 Máscara de Subred 255.255.255.0 Dirección del Gateway 192.168.16.253 Tabla 3-2. Parámetros de Fábrica de la Interfaz Ethernet NET 2 Los parámetros Dirección IP y Máscara de Subred se pueden ver en el visor gráfico de la UCP a través del menú de parámetros, según lo descrito en el capítulo Configuración – Menú Informativo y de Configuración de la UCP. 24 3. Instalación Los parámetros de red de la interfaz NET 2 se pueden alterar a través del MasterTool IEC XE. Para más detalles sobre la configuración y alteración de parámetros de red, fíjese en el capítulo Configuración – Configuración de las Interfaces Ethernet. ARP Gratuito La interfaz de Ethernet NETx envía espontáneamente paquetes del tipo ARP, en broadcast, informando su dirección de IP y MAC para todos los dispositivos interconectados a la red. Estos paquetes se envían durante el download de una nueva aplicación por el software MasterTool IEC XE y en la inicialización de la UCP, cuando la aplicación entra en modo Run. Se disparan 5 comandos ARP con un intervalo inicial de 200 ms, doblando el intervalo entre cada nuevo comando disparado, en total 3s. Ej.: Primer disparo ocurre en el tiempo 0, el segundo disparo en el tiempo 200 ms, el tercer disparo en el tiempo 600 ms y así hasta el quinto disparo en el tiempo 3 s. Instalación del Cable de Red Las puertas Ethernet de las UCPs de la Serie Nexto, identificadas en el panel por NET 1 y NET 2 (NX3020 y NX3030), poseen pinaje estándar, y se usa la misma, por ejemplo, en computadoras personales. El tipo de conector, tipo de cable, nivel físico, entre otros detalles más para interconectar la UCP al dispositivo de acceso a la red Ethernet se definen en el capítulo Descripción Técnica Interfaces Ethernet. La Figura 3-3 y la Tabla 3-3 presentan el conector RJ45 hembra de las UCPs Nexto, con la identificación y la descripción del pinaje válido para los niveles físicos tipo 10Base-T y 100Base-TX. Figura 3-3. Conector RJ45 hembra de las UCPs Nexto Pino Señal Descripción 1 TXD + Transmisión de datos, positivo 2 TXD - Transmisión de datos, negativo 3 RXD + Recepción de datos, positivo 4 UN No utilizado 5 UN No utilizado 6 RXD - 7 UN No utilizado 8 UN No utilizado Recepción de datos, negativo Tabla 3-3. Pinaje del Conector RJ45 Hembra de las UCPs Nexto La interfaz se puede conectar en una red de comunicación a través de un hub o switch, o entonces directamente al equipo con el cual irá comunicarse. En este último caso, debido a que las UCPs Nexto poseen la característica de Auto Crossover, no se hace necesaria la utilización del cable de red crossover, lo mismo utilizado para conectar dos computadoras personales, punto a punto, a través de la puerta Ethernet. 25 3. Instalación Es importante resaltar que se entiende por cable de red, un par de conectores RJ45 machos interconectados entre sí por un cable UTP o ScTP, de categoría 5, bajo la configuración directa o crossover. De esta misma forma se interconectan dos dispositivos con puerta Ethernet. Normalmente estos cables poseen una traba de conexión que garantiza una perfecta conexión entre el conector hembra de la interfaz y el conector macho del cable. En el momento de la instalación, el conector macho del cable se debe insertar en la hembra del módulo hasta que se escuche un sonido característico ("clic"), lo que garantiza la actuación de la traba. Para desconectarlos se debe utilizar la palanca presente en el conector macho. Conexión con la Red RS-232C La interfaz no aislada de comunicación COM 1 de las UCPs NX3010, NX3020 y NX3030 posibilita la conexión con una red RS-232C. El siguiente es el conector DB9 hembra de la UCP con la identificación y la descripción de los signales. Figura 3-4. Conector DB9 Hembra de las UCPs NX3010, NX3020 y NX3030 Pinout Señal Descripción 1 DCD Data Carrier Detect 2 TXD Transmisión de datos 3 RXD Recepción de datos 4 - 5 GND 6 - 7 CTS Clear to Send 8 RTS Request to Send 9 - No utilizado Ground No utilizado No utilizado Tabla 3-4. Pinout del Conector DB9 Hembra de la UCP NX3010, NX3020 y NX3030 Comunicación RS-232C Para la conexión con un dispositivo RS-232C, utilice el cable apropiado como detallado en el capítulo Descripción Técnica – Productos Relacionados. 26 3. Instalación Conexión con la Red RS-485/422 Las interfaces aislada de comunicación COM 1 de la UCP NX3004/NX3005 y COM 2 de las UCPs NX3010, NX3020 y NX3030 posibilitan la conexión con una red RS-485/422. A continuación se presenta el conector DB9 hembra de la UCP Nexto, con la identificación y la descripción de las señales. Figura 3-5. Conector DB9 Hembra COM 1 (NX3004/NX3005) o COM 2 (NX3010/NX3020/NX3030) PIN Señal Descripción 1 - No utilizado 2 Term+ Terminación interna, positiva 3 TXD+ Transmisión de datos, positivo 4 RXD+ Recepción de datos, positivo 5 GND Referencia negativa a la terminación externa 6 +5V Referencia positiva a terminación externa 7 Term- Terminación interna, negativo 8 TXD- Transmisión de datos, negativo 9 RXD- Recepción de datos, negativo Tabla 3-5. Pinout del Conector DB9 Hembra COM 1 (NX3004/NX3005) o COM 2 (NX3010/NX3020/NX3030) Comunicación RS-485 Sin Terminación Para conexión a una red RS-485 sin terminación en la interfaz COM (NX3004 o NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-6. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 No conectado 2 D+ 3 D+ 4 No conectado 5 No conectado 6 No conectado 7 D- 8 D- Tabla 3-6. Conexión de la Interfaz RS-485 sin Terminación 27 3. Instalación El diagrama de la Figura 3-6 indica cómo se debe realizar la conexión de los terminales del AL-1763 a la bornera del dispositivo. Figura 3-6. Diagrama de Conexión de la Interfaz RS-485 sin Terminación Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Comunicación RS-485 con Terminación Interna Para conexión a una red RS-485, utilizando la terminación interna de la interfaz COM 1 (NX3004 or NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-7. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 D+ 2 D+ 3 D+ 4 No conectado 5 No conectado 6 D- 7 D- 8 D- Tabla 3-7. Conexión de Interfaz RS-485 con Terminación Interna Obs.: La terminación interna disponible en COM 1 (NX3004 y NX3005) y en la COM 2 (NX3010, NX3020 y NX3030) es del tipo estado seguro en modo abierto. El diagrama de la Figura 3-7 indica cómo se debe realizar la conexión de los terminales del AL-1763 a la bornera del dispositivo. 28 3. Instalación Figura 3-7. Diagrama de Conexión de Interfaz RS-485 con Terminación Interna Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Comunicación RS-485 con Terminación Externa Para conexión a una red RS-485, en la cual se utiliza la terminación externa de la interfaz COM1 (NX3004 o NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-8. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 No conectado 2 D+ 3 D+ 4 0V 5 +5 V 6 No conectado 7 D- 8 D- Tabla 3-8. Conexión de Interfaz RS-485 con Terminación Externa El diagrama de la Figura 3-8 indica cómo se debe realizar la conexión de los terminales del AL-1763 a la bornera del dispositivo. Figura 3-8. Diagrama de Conexión de Interfaz RS-485 con Terminación Externa 29 3. Instalación Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Ejemplo de Conexión de Red RS-485 con Terminación Externa y Redundancia de Maestro Abajo, la Figura 3-9 muestra un ejemplo de conexión RS-485 con terminación externa utilizando dos UCPs NX3030 de la Serie Nexto con redundancia de half-cluster, como maestro. Figura 3-9. Diagrama de Conexión de Red RS-485 con Terminación Externa y Redundancia de Maestro Comunicación RS-422 sin Terminación Para conexión a una red RS-422 sin terminación en la interfaz COM1 (NX3004 y NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-9. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 No conectado 2 TX+ 3 RX+ 4 No conectado 5 No conectado 6 No conectado 7 TX- 8 RX- Tabla 3-9. Conexión de Interfaz RS-422 sin Terminación 30 3. Instalación El diagrama de la Figura 3-10 indica cómo se debe realizar la conexión de los terminales del AL1763 a la bornera del dispositivo. Figura 3-10. Diagrama de Conexión de Interfaz RS-422 sin Terminación Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Comunicación RS-422 con Terminación Interna Para conexión a una red RS-422, en la cual se utiliza la terminación interna de la interfaz COM1 (NX3004 o NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-10. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 TERM+ 2 TX+ 3 RX+ 4 No conectado 5 No conectado 6 TERM- 7 TX- 8 RX- Tabla 3-10. Conexión de COM 2 con RS-422 con Terminación Obs.: Las terminaciones internas disponibles en la COM1 (NX3004 o NX3005) o COM 2 (NX3010, NX3020 o NX3030) son del tipo estado seguro en modo abierto. El diagrama de la Figura 3-11 indica cómo se debe realizar la conexión de los terminales del AL1763 a la bornera del dispositivo. 31 3. Instalación Figura 3-11. Diagrama de Conexión de COM 2 con RS-422 con Terminación Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Comunicación RS-422 con Terminación Externa Para conexión a una red RS-422, en la cual se utiliza la terminación interna de la interfaz COM1 (NX3004 o NX3005) o COM 2 (NX3010, NX3020 o NX3030), se deben conectar los terminales identificados del cable AL-1763 en los respectivos bornes del dispositivo, según la Tabla 3-11. . Terminales del AL-1763 Señales en la Bornera de la UCP 0 Blindaje 1 No conectado 2 TX+ 3 RX+ 4 0V 5 +5 V 6 No Conectado 7 TX- 8 RX- Tabla 3-11. Conexión de Interfaz RS-422 con Terminación Externa El diagrama de la Figura 3-12 indica cómo se debe realizar la conexión de los terminales del AL1763 a la bornera del dispositivo. Figura 3-12. Diagrama de Conexión de Interfaz RS-422 con Terminación Externa 32 3. Instalación Nota del Diagrama: Los terminales no conectados se deben aislar para que no haya contacto entre ellos. Ejemplo de Red RS-422 A continuación, la Figura 3-13 muestra un ejemplo de utilización de la red RS-422, al utilizar la UCP Nexto como maestro, dispositivos esclavos con interfaz RS-422, y solución Altus para derivadores y terminadores. Figura 3-13. Ejemplo de Red RS-422 Nota del Diagrama: Los módulos AL-2600 que están en las extremidades de la red hacen la función de terminadores. En este caso se debe configurar las claves del AL-2600 en Terminación PROFIBUS. Instalación de la Tarjeta de Memoria En esta sección se describe la manera como la tarjeta de memoria se debe insertar en las UCPs de la Serie Nexto modelos NX3010, NX3020 y NX3030, siendo que, para más informaciones sobre se utilización, consultar el capítulo Configuración – Tarjeta de Memoria. Inicialmente, debe tener se en cuenta cuanto a la posición correcta de la tarjeta de memoria para insertarla. Existe una de las esquinas que se diferencia de las demás y dicha esquina se deberá utilizar como referencia para la inserción correcta de la tarjeta. De esta forma, la tarjeta de memoria se deberá insertar según la imagen ubicada en la parte delantera de la UCP o también como muestra la Figura 3-14. 33 3. Instalación Figura 3-14. Inserción de la Tarjeta de Memoria en la UCP Al estar la tarjeta insertada correctamente aparecerá un símbolo en el visor gráfico de la UCP. Para remover la tarjeta con seguridad, se debe presionar la tecla MS, esperar para que el símbolo de la tarjeta desaparezca del visor gráfico y entonces, sí, retirar el tarjeta. Para que eso sea posible, se debe presionar la tarjeta contra la UCP hasta que se genere un clic. Entonces, basta con soltarla y retirarla del compartimiento, según muestra la Figura 3-15, pues la tarjeta estará suelta. Figura 3-15. Retirada de la Tarjeta Memoria Instalación de la Arquitectura Instalación de Módulos en el Bastidor Principal La Serie Nexto posee un exclusivo método para conectar y desconectar módulos del bus, el cual no exige mucho esfuerzo del operador y garantiza la integridad de la conexión. Para más informaciones sobre fijación de los productos de la Serie Nexto, por favor consulte el Manual del Usuario Serie Nexto – MU214300. 34 3. Instalación Instalación del Programador Para realizar la instalación del software de desarrollo MasterTool IEC XE, es necesario tener en manos el CD-ROM de distribución o efectuar el download del archivo de instalación en el sitio http://www.altus.com.br. Para más informaciones y el paso a paso que se debe ser seguido, consulte el Manual del Usuario MasterTool IEC XE – MU299800. 35 4. Configuración 4. Configuración Las UCPs de la Serie Nexto se configuran y se programan a través del software MasterTool IEC XE. La configuración realizada define el comportamiento y modos de utilización de los periféricos y características especiales de las UCPs. La programación representa la aplicación desarrollada por el usuario, también llamada aplicativo. Configuración de la UCP Parámetros Generales Los parámetros relacionados a continuación hacen parte de la configuración de la UCP insertada en la aplicación. Cada ítem se debe revisar cuidadosamente para el correcto funcionamiento del proyecto. Además de estos parámetros, es posible alterar el nombre de cada módulo insertado en la aplicación. Para esto, haga clic con el botón derecho sobre el módulo, en el ítem “Propiedades”, en la guía “Común”, altere el nombre, limitado a 24 caracteres. Configuración Estándar de Fábrica Descripción Posibilidades Área de Diagnóstico (%Q) %Q Initial Address Size Dirección inicial de los diagnósticos de la UCP (%Q) Ubicado automáticamente en la creación del proyecto. Tamaño del área de diagnóstico en bytes NX3004: 558 NX3005: 558 NX3010: 558 NX3020: 693 NX3030: 693 NX3004: 0 NX3005: 0 NX3010: 0 NX3020: 0 NX3030: 0 a 32210 a 32210 a 32210 a 64843 a 97611 No es posible alterar el tamaño del área de diagnóstico de la UCP Área Retentiva (%Q) %Q Initial Address Size NX3004: 4096 NX3005: 4096 NX3010: 4096 NX3020: 4096 NX3030: 4096 Dirección inicial de la memoria de datos retentivos (%Q) Tamaño de la memoria de datos retentivos en bytes NX3004: 7680 NX3005: 7680 NX3010: 32768 NX3020: 65536 NX3030: 98304 NX3004: 0 a 32767 menos el Tamaño de la memoria de datos retentivos NX3005: 0 a 32767 menos el Tamaño de la memoria de datos retentivos NX3010: 0 a 32767 menos el Tamaño de la memoria de datos retentivos NX3020: 0 a 65535 menos el Tamaño de la memoria de datos retentivos NX3030: 0 a 98303 -Tamaño de la memoria de datos retentivos NX3004: 0 NX3005: 0 NX3010: 0 NX3020: 0 NX3030: 0 a 7680 a 7680 a 32768 a 65536 a 98304 Área Persistente (%Q) %Q Initial Address Dirección inicial de la memoria de datos persistentes (%Q) NX3004: 12288 NX3005: 12288 NX3010: 12288 NX3020: 20480 NX3030: 20480 36 NX3004: 0 a 32767 menos el Tamaño de la memoria de datos retentivos NX3005: 0 a 32767 menos el Tamaño de la memoria de datos retentivos NX3010: 0 a 32766 menos el Tamaño de la memoria de 4. Configuración Configuración Estándar de Fábrica Descripción Posibilidades datos retentivos NX3020: 0 a 65534 menos el Tamaño de la memoria de datos persistentes NX3030: 0 a 98302 menos el Tamaño de la memoria de datos persistentes Size Tamaño de la memoria de datos persistentes en bytes NX3004: 7680 NX3005: 7680 NX3010: 32768 NX3020: 65536 NX3030: 98304 NX3004: 0 NX3005: 0 NX3010: 0 NX3020: 0 NX3030: 0 a 7680 a 7680 a 32768 a 65536 a 98304 Parámetros de la UCP Start User Application After a Watchdog Reset Hot Swap Mode Cuando habilitado, inicia la aplicación del usuario tras el reset del watchdog, de hardware o por la reinicialización del Runtime, sin embargo mantiene la indicación del diagnóstico vía LED WD y variables. Modo cambio en caliente de los módulos. Deshabilitado Habilitado Deshabilitado Habilitada, sin consistencia en la partida. - Deshabilitada, apenas para módulos declarados - Deshabilitada - Habilitada, con consistencia en la partida solamente para módulos declarados: - Habilitada, con consistencia el na partida - Habilitada, sin consistencia en la partida. Parámetros TCP/IP Indica cuanto tiempo, después de la primera transmisión de un mensaje, se debe retransmitirlo, asumiendo que no ha sido recibido por el destinatario. A cada retransmisión el time-out es doble. 2 1 a 75 ACK Delay (x10 ms) Tiempo de espera para envío de un comando de confirmación. 10 0 a 100 Consist retain and persistent area in %Q Configuración para consistir las memorias persistentes y retentivas direccionables. Initial Time-out (x100 ms) Parámetros del Proyecto Desmarcado - Marcado: Consiste las memorias persistentes y retentivas direccionables - Desmarcado: No consiste las memorias persistentes y retentivas direccionables Enable I/O update per task Configuración para actualizar las entradas y salidas en las tareas en que estas son usadas Desmarcado - Marcado: Las entradas y salidas son actualizadas por las tareas en que están siendo usadas. - Desmarcado: Las entradas y salidas son actualizadas apenas en la MainTask. Enable retain and persistent variables in Function Blocks Configuración para permitir el uso de las variables retentivas y Desmarcado - Marcado: permite el uso de variables retentivas y persistentes en los Bloques Funcionales. 37 4. Configuración Configuración Estándar de Fábrica Descripción persistentes en Bloques Funcionales Posibilidades - Desmarcado: Si esto se hace con esta opción desactivada, puede producirse un error de excepción en el arranque. Tabla 4-1. Configuraciones de la UCP Notas: Generate error on tasks watchdog consistency: Este parámetro fue descontinuado a partir de la versión 1.32 del software MasterTool IEC XE. Enable I/O update per task: Este parámetro fue adicionado a partir de la versión 2.01 del software MasterTool IEC XE. ATENCIÓN: Cuando la dirección inicial o el tamaño de la memoria de datos retentivos o persistentes se alteran en la aplicación del usuario, la memoria se reubica totalmente, haciendo con que el área de variables retentivas y persistentes se limpie. Entonces, el usuario deberá tener precaución para no perder los datos guardados en la memoria. ATENCIÓN: En situaciones en las que el área de memoria simbólica persistente es cambiada, se presenta el mensaje por el programador MasterTool IEC XE para que sea elegido un comportamiento para esta área después de la carga del programa cambiado. La elección de este comportamiento no afecta el área persistente de la representación directa, que es siempre limpiada. ATENCIÓN: La opción Habilita actualización de E/S por tarea no es compatible con módulos maestos de red de campo como el NX5001. Esta función se aplica únicamente a los módulos de entrada y salida del bus local del controlador (rack principal y racks de expansión). ATENCIÓN: Aun que un punto de E/S se utilice y actualice en otras tareas, con la opción Enable I/O Update per Task marcada, seguirá siendo actualizado también en la MainTask; excepto cuando todos los puntos de E/S del módulo se utilizan y actualizan en otra tarea, en este caso ya no será actualizado por la MainTask. Cambio en Caliente Las UCPs de la serie Nexto presentan la posibilidad de cambio de los módulos de E/S del bus sin la necesidad de desconectarse el sistema y sin pérdida de informaciones. Esta característica se conoce como cambio en caliente. CUIDADO: Las UCPs de la Serie Nexto no garantizan la retentividad de las variables persistentes y retentivas en caso de que la fuente de alimentación, o la propia UCP, se remueva del bastidor energizado. 38 4. Configuración En el cambio a caliente, el comportamiento del sistema relacionado se cambia según la configuración definida por el usuario, que tiene las siguientes opciones, tal como se describe a continuación: Disabled, for declared modules only (Deshabilitado, sólo para los módulos declarados) Disabled (Deshabilitado) Enabled, with startup consistency for declared modules only (Habilitado, con consistencia en la partida, sólo para los módulos declarados) Enabled, with startup consistency (Habilitado, con consistencia en la partida) Enabled, without startup consistency (Habilitado, sin consistencia en la partida) De esta forma, el usuario puede elegir el comportamiento que el sistema deberá presentar en situaciones anormales de bus y cuando la UCP esté en Modo Run. La Tabla 4-2 presenta las posibles situaciones anormales de bus. Situación Posibles Causas Configuración Incompatible - Algún módulo presente en el bus es diferente del que está declarado en la configuración. Módulo Ausente El módulo fue retirado del bus. Algún módulo no está respondiendo a la UCP por estar con defecto. Alguna posición del bastidor está con defecto. Tabla 4-2. Situaciones Anormales de Bus Para más informaciones sobre los diagnósticos correspondientes a las situaciones descritas arriba, consultar capítulo Mantenimiento– Diagnósticos vía Variables. Si un módulo está presente en una posición del bastidor en la cual no debería existir módulo según la configuración, este módulo se considera como no declarado. Las opciones de cambio a caliente Disabled, for declared modules only y Enabled, with startup consistency for declared modules only no toman en cuenta los módulos que están en esta condición. Cambio en Caliente Deshabilitado, Solamente para Módulos Declarados En esta configuración, la UCP entra inmediatamente en Modo Stop cuando ocurre una situación anormal de bus (según la Tabla 4-2), el LED DG comienza a parpadear 4x (según la Tabla 4-3). Para que, en estos casos, la UCP vuelva al estado normal Run, además de deshacer lo que causó la situación anormal es necesario ejecutar un Reset de cualquier tipo (esto se puede hacer por el MasterTool IEC XE en el menú Comunicación). Si se realiza un Reset Origen, será necesario realizar el download para que la UCP pueda volver a estado normal Run. Los comandos Reset Warm, Reset Cold y Reset Origin pueden hacerse vía MasterTool IEC XE, en el menú Online. La UCP permanece en el estado normal Run, incluso si encuentra un módulo no declarado en el bus. Cambio en Caliente Deshabilitado Esta configuración no permite cualquier situación anormal de bus Tabla 4-2) incluso módulos no declarados e presentes en el bus. La UCP entra en Modo Stop, y el LED DG parpadea 4x (Tabla 4-3. ). En estos casos, para la UCP volver al estado normal Run, además de deshacer lo que causó la situación anormal, es necesario realizar una Reset Warm o un Reset Cold. En el caso de que se realice un Reset Origin, será necesario hacer el download para que la UCP pueda volver al estado normal Run. Los comandos Reset Warm, Reset Cold y Reset Origin pueden hacerse vía MasterTool IEC XE, en el menú Online. Cambio en Caliente Habilitado con Consistencia en la Partida, Solamente para Módulos Declarados Se considera “partida” el intervalo entre la energización de la UCP (o comando de reset o download de aplicación) hasta la primera vez en que esta entra en modo Run. Esta configuración verifica si sucedió alguna situación anormal de Bus (según la Tabla 4-2) durante la partida; en caso positivo, la UCP entra en Modo Stop y el LED DG comienza a parpadear 4 veces (según la Tabla 4-3). Posteriormente, para que la UCP pueda colocarse en modo Run, además de corregir lo que ocasionó la situación anormal, es necesario ejecutar un comando de Reset de cualquier tipo, que se puede 39 4. Configuración hacer por el MasterTool IEC XE (menú Comunicación). ). Si se realiza un Reset Origen, será necesario realizar el download para que la UCP pueda volver a estado normal Run. Los comandos Reset Warm, Reset Cold y Reset Origin pueden hacerse vía MasterTool IEC XE, en el menú Online. Tras la partida, si algún módulo presenta alguna de las situaciones planteadas en la tabla anterior, el sistema continuará trabajando normalmente y señalizará el problema por diagnóstico. Si no ocurre otra situación anormal para los módulos declarados, la UCP irá hacia el estado normal Run aun que encuentre un módulo no declarado en el bus. ATENCIÓN: En esta configuración, cuando ocurre falta de alimentación (aunque temporaria), comando Reset en Caliente, comando Reset en Frío o se ejecutó el download de una nueva aplicación, y algún módulo está en una situación anormal de bus, la UCP entrará en Modo Stop y el LED DG comienza a parpadear 4 veces (según la Tabla 4-3), pues esta se considera una situación de partida. Esta es la opción que más se recomienda, pues garantiza la integridad del sistema en su inicialización y permite el cambio de módulos con el sistema en marcha. Cambio en Caliente Habilitado, con Consistencia en la Partida Esta configuración comprueba si ha habido cualquier situación anormal de bus (Tabla 4-2) durante la partida, aunque hay módulos no declarado y presentes en el bus. Si es así, la UCP entra en el modo Stop y el LED DG parpadea 4x (conforme a Tabla 4-3). Posteriormente, para que la UCP se pueda poner en modo Run, más allá de corregir lo que ha ocasionado la situación anormal, es necesario que se ejecute un comando de Reset Warm o Reset Cold. En el caso de que se realice un Reset Origin, será necesario hacer el download para que la UCP pueda volver al estado normal Run. Los comandos Reset Warm, Reset Cold y Reset Origin pueden hacerse vía MasterTool IEC XE, en el menú Online. Cambio en Caliente Habilitado sin Consistencia en la Partida Permite que el sistema siga marchando aun cuando algún módulo esté en una situación anormal de bus (según Tabla 4-2). Las situaciones anormales se relatan por diagnóstico, tanto durante, como después de la partida. ATENCIÓN: Esta opción se recomienda para la fase de implantación del sistema, pues permite que cargas de nuevas aplicaciones y la desconexión de la alimentación se hagan sin la presencia de todos los módulos configurados. Como Realizar el Cambio en Caliente CUIDADO: Antes de proceder al cambio en caliente, es importante descargar eventuales potenciales estáticos acumulados en el cuerpo. Para eso, toque (con las manos desnudas) una superficie metálica puesta a tierra antes de manejar los módulos. Dicho procedimiento garantiza que los niveles de electricidad estática soportados por el módulo no sobrepasarán. ATENCIÓN: Se recomienda el monitoreo de los diagnósticos de cambio a caliente en la aplicación de control desarrollada por el usuario, con el fin de garantizar que el valor retornado por el módulo se valide antes de la utilización. El procedimiento para el cambio de módulos en caliente se describe a continuación: Destrabe el módulo junto al bastidor, a través de la traba de seguridad. Retire el módulo, tirándolo firmemente. Inserte el nuevo módulo al bastidor. Fíjese de que la traba que prende el módulo al bastidor esté totalmente conectada; caso sea necesario, empuje el módulo hacia al bastidor con más fuerza. 40 4. Configuración En el caso de módulos de salida, es conveniente que los puntos estén desconectados al hacer el cambio, a fin de reducir la generación de arcos en el conector del módulo. Eso se puede hacer por la desconexión de la fuente de campo o por el forzamiento de los puntos por herramientas de software. Si la carga es pequeña, no hay la necesidad de desconectar los puntos. Es importante resaltar que, en los casos en que la UCP entra en Modo Stop y el LED DG comienza a parpadear 4 veces (según la Tabla 4-3), debido a alguna situación anormal de bus (según la Tabla 4-2); los módulos de salida colocan sus puntos según lo que se ha configurado en los Parámetros del Módulo cuando la UCP sale del Modo Run y entra en Modo Stop. En caso de inicialización de la aplicación, cuando la UCP entra en Modo Stop sin ter pasado a Modo Run, los módulos de salida colocan sus puntos en modo seguro de falla, es decir, desconectan el punto (0 Vdc). En el caso de los módulos de entrada, en caso de que este se remueva del bus energizado, el estado lógico de los puntos permanecerá en el último valor. Caso el(los) conector(es) se remuevan, el estado lógico de los puntos se colocarán en estado seguro, es decir, cero o alta impedancia. ATENCIÓN: Ejecute la sustitución de un módulo por vez siempre, para que la UCP actualice los estados de los módulos. A continuación, la Tabla 4-3. relaciona las condiciones de bus y el estado de operación y del LED DG de la UCP Nexto. Para más informaciones sobre los estados de los LEDs de diagnóstico, consulte el capítulo Mantenimiento – Diagnósticos vía LED. Condición Habilitado, con consistencia en la partida Habilitado, con consistencia en la partida, sólo para los módulos declarados Módulo no declarado LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 2x Aplicación: Run Módulo no declarado (condición partida) LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 2x Aplicación: Run Módulo ausente LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop Módulo ausente (condición partida) LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop Configuración incompatible LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 2x Aplicación: Run LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop Habilitado, sin consistencia en la partida Deshabilitado Deshabilitado, sólo para los módulos declarados Configuración incompatible (condición partida) LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 2x Aplicación: Run o LED DG: Parpadea 4x Aplicación: Stop Dirección de slot duplicada LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop Módulo inactivo LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop LED DG: Parpadea 4x Aplicación: Stop Tabla 4-3. Relación Entre Condiciones y Cambio en Caliente Nota: Habilitado, sin consistencia en la partida: Cuando este modo de cambio a caliente está configurado, en situaciones normales al existir un módulo incompatible en la partida del sistema la 41 4. Configuración aplicación pasará de Stop a Run. Sin embargo, si el módulo es un NX5000 o NX5001, y si hay otro módulo en posición, la aplicación se quedará en Stop Áreas de Memoria Retentiva y Persistente La UCP Nexto permite la utilización de variables simbólicas y de variables de salida de representación directa como variables retentivas o persistentes. Las variables de salida de representación directa que serán retentivas o persistentes se deben declarar en los Parámetros Generales de la UCP, según lo descrito en Configuración - Configuración de la UCP - Parámetros Generales. También se pueden atribuir nombres simbólicos a estas variables de salida de representación directa utilizando la directiva AT y la palabra clave RETAIN en su declaración, o la palabra clave PERSISTENT. Por ejemplo, al estar %QB4096 y %QB20480, dentro de las áreas de memoria retentiva y persistente, respectivamente: PROGRAM MainPrg VAR RETAIN byVariavelRetentiva_01 AT %QB4096 : BYTE; END_VAR VAR PERSISTENT byVariavelPersistente_01 AT %QB20480 : BYTE; END_VAR Caso las variables simbólicas declaradas con la directiva AT no sean declaradas dentro de las áreas respectivas de las memorias retentivas y/o persistentes, errores durante la generación de código en el MasterTool se puedem presentan(según lo descrito en Configuración - Configuración de la UCP Parámetros Generales, configuración Consist retain and persistent area in %Q), informando que existen variables no- retentivas o no-persistentes definidas en espacios de memoria retentiva o persistente. En relación a las variables simbólicas que serán retentivas o persistentes, sólo las variables retentivas podrán ser locales o globales, siendo que variables simbólicas persistentes deberán siempre ser globales. Para la declaración de variables simbólicas retentivas, se debe utilizar la palabra clave RETAIN. Por ejemplo, para variables locales: PROGRAM MainPrg VAR RETAIN wVariableSimbolicaRetentivaLocal_01 : WORD; END_VAR O, para variables globales, declaradas dentro de una lista de variables globales: VAR_GLOBAL RETAIN wVariableSimbolicaRetentivaGlobal_01 : WORD; END_VAR Ya las variables simbólicas persistentes se deberán declarar dentro de un objeto Variables Persistentes, añadido a la aplicación. Estas variables serán globales y estarán declaradas de la siguiente forma dentro del objeto: VAR_GLOBAL PERSISTENT RETAIN wVariableSimbolicaPersistenteGlobal_01 : WORD; END_VAR Desde la versión 1.5.0.22 para NX3004 y 1.5.1.1 para NX3010, NX3020 y NX3030, las UCPs Nexto permiten flexibilidad en el uso de memorias retentivas y persistentes. Esto significa que el usuario podrá optar por el tamaño que utilizará en cada tipo de memoria, desde que la suma del tamaño de las memorias retentivas y persistentes no sobrepase el límite total disponible para cada modelo de UCP. El total de memoria retentiva y persistente disponible se describe en la Tabla 2-5 en Características Específicas. 42 4. Configuración En el caso de que la suma de memoria simbólica retentiva, simbólica persistente, retentiva en %Q y persistente en %Q sobrepase el total disponible, MasterTool presentará error durante la generación de código Si, por ejemplo, se utiliza una UCP NX3004 que posee 7680 Bytes de memoria retentiva y persistente y configurado 1000 Bytes retentivos y 1000 Bytes persistentes de salida de representación directa (%Q), y aun, declarado las variables del código abajo, el total de memoria retentiva y persistente utilizada será de 2004 Bytes, quedando 5676 Bytes para que se utilice de la forma que desee. VAR_GLOBAL PERSISTENT RETAIN wVariavelSimbolicaPersistenteGlobal_01 : WORD; END_VAR VAR_GLOBAL RETAIN wVariavelSimbolicaRetentivaGlobal_01 : WORD; END_VAR ATENCIÓN: Para utilizar las memorias retentivas y persistentes de manera flexible, es necesario utilizar el MasterTool IEC X 2.03 o superior. Configuraciones TCP Algunas de las configuraciones avanzadas afectan los protocolos soportados por las UCPs de la Serie Nexto, pues se refieren a la capa de red TCP. Son: Time-out Inicial Retraso de envío de ACK La UCP Nexto, antes de tratar y responder requerimientos y así como cualquier otro equipo Ethernet que utiliza la capa de transporte TCP, exige la abertura de un puerta de comunicación, es decir, del establecimiento de una conexión. La cantidad de conexiones de la interfaz es limitada y, cuando alcanza su límite, la interfaz simplemente no establece ninguna conexión más. Esto puede ser un problema para las conexiones establecidas en el modo servidor, pues el cierre de las conexiones depende del otro equipo, el cliente. La capa de transporte TCP, responsable por la entrega de los mensajes del origen para el destino, posee ciertos parámetros que involucran time-outs, muy comunes en los protocolos de comunicación en general. Dichos parámetros buscan la recuperación de la comunicación tras determinadas fallas. El usuario debe estar atento a la configuración de los time-outs, pues puede haber conflicto con los valores configurados dentro de la capa de aplicación, es decir, de los protocolos. Como la configuración TCP es referencia para todas las instancias configuradas, será el tiempo válido caso sea menor que el parametrizado dentro de un protocolo: Time-out Inicial: indica cuanto tiempo, después de la primera transmisión de un mensaje, este se debe retransmitir y asumir que no fue recibido por el destinatario. A cada retransmisión el timeout es doble. El número de reintentos de transmisión está aferrado al time-out de la comunicación configurado dentro del protocolo, es decir, será el tiempo máximo antes de desistir de la entrega del mensaje, y así se concreta, entonces, la falla de transmisión. Además es importante resaltar que existe un límite máximo de reintentos fijo para las UCPs de la Serie Nexto. Este número es fijo en 5 reintentos máximos antes de la conexión establecida y 3 reintentos tras la conexión establecida. Toda la vez que es alcanzado el número máximo de reintentos, el proceso de tentativa de comunicación es reiniciado. Ver sección Configuración de Protocolos para más detalles sobre la utilización de esos parámetros de time-out, pues, como se ha descrito anteriormente, puede ser diferente dentro de cada instancia. Es importante resaltar que este parámetro se utiliza solamente en el establecimiento de la conexión, después se utilizan estadísticas de las últimas comunicaciones para calcular el nuevo time-out. 43 4. Configuración Ejemplo de funcionamiento de los parámetros de time-out inicial y time-out de la comunicación dentro de la instancia MODBUS TCP Server al considerar el no recibimiento de respuesta de confirmación, para los siguientes valores: 300 para time-out inicial (= 300 ms) y 3000 para time-out de la comunicación (= 3000 ms): Figura 4-1. Time-out Inicial y Time-out de la Comunicación Leyenda: 8. 9. 10. 11. 12. Instante de la transmisión del mensaje. Primer reintento de transmisión del mensaje, tras el time-out inicial. Segundo reintento de transmisión del mensaje, tras dos veces el time-out inicial. Tercer reintento de transmisión del mensaje, tras dos veces el time-out anterior. Renuncia de transmisión del mensaje e indicación de falla, tras exceder el time-out de la comunicación (tiempo total hasta la renuncia: 300 + 600 + 1200 + 900 = 3000 ms). 13. Sería el cuarto reintento de transmisión del mensaje, tras dos veces el time-out anterior, sin embargo se excedió el time-out de la comunicación configurado dentro del protocolo y la falla se indicó. Retraso de envío de ACK: define el tiempo máximo aguardado por la interfaz para la transmisión de ACK del TCP. Este ACK es responsable por la confirmación del recibimiento de un mensaje por el destinatario. El ajuste de este campo busca disminuir la cantidad de mensajes que circulan por la red. A seguir, se plantea como funciona este mecanismo: o Todos los mensajes del tipo requerimiento, enviados de un cliente hacia un servidor necesitan que se confirmen por el servidor a través de la transmisión de un mensaje de ACK para el cliente. o Todos los mensajes del tipo respuesta, enviados de un servidor hacia un cliente, necesitan que se confirmen por el cliente a través de la transmisión de un mensaje de ACK para el servidor. o El no recibimiento del mensaje de ACK por una de las partes, dentro del tiempo hábil definido por el parámetro de time-out del TCP, irá ocasionar el reintento de transmisión del mensaje por parte de la dirección origen (ver parámetro de número de reintentos del TCP). o El mensaje de ACK no necesita ser exclusivo, es decir, el ACK que el servidor debe enviar hacia el cliente, en el momento en que reciba un requerimiento, puede estar incluido en el mismo mensaje que contiene la respuesta, y el ACK que el cliente debe enviar hacia el servidor, en el momento en que reciba un requerimiento, puede estar incluido en el mismo mensaje que contiene el próximo requerimiento. Las figuras a continuación presentan la diferencia entre el envío de un ACK inmediato y un ACK calibrado: ATENCIÓN: Las UCPs NX3004 y NX3005 posee un comportamiento un poco diferente, no considera el valor configurado en el parámetro Time out inicial, considera solo el Time out de la comunicación. Aun así, el valor configurado para Time out de la comunicación se utiliza al ser inferior a 3 segundos y nunca dobla en los reintentos. Al ser el parámetro Time out de la comunicación superior a 3 segundos, el valor se desconsidera y pasa a consistir el valor inicial de 3 segundos y dobla a cada reintento. 44 4. Configuración Cliente Servidor Mensaje con requerimiento 1 Mensaje con ACK de requerimiento 1 tiempo de tratamiento de requerimiento 1 Mensaje con respuesta 1 Mensaje con ACK de la respuesta 1 Mensaje con requerimiento 2 Mensaje con ACK de requerimiento 2 tiempo de tratamiento de requerimiento 2 Mensagem con respuesta 2 Mensaje con ACK de la respuesta 2 Mensaje con requerimiento 3 ... tiempo Figura 4-2. Ejemplo de Funcionamiento para Envío de ACK Inmediato (=0) Cliente Servidor Mensaje con requerimiento 1 tiempo de tratamiento de requerimiento 1 Mensaje con ACK de requerimiento 1 + respuesta 1 Mensaje con ACK de la respuesta 1 + requerimiento 2 tiempo de tratamiento del requerimiento 2 Mensaje con ACK de requerimiento 2 + respuesta 2 Mensaje con ACK de la respuesta 2 + requerimiento 3 ... tiempo Figura 4-3. Ejemplo de Funcionamiento para Envío de ACK Calibrado ATENCIÓN: Todos los sistemas operacionales con soporte a interfaces de red con protocolo TCP/IP, poseen parámetros equivalentes a los discutidos en este capítulo para la interfaz Ethernet de las UCPs de la Serie Nexto. En el sistema operacional Windows, estos parámetros se definen en los registros del sistema, bajo las más distintas identificaciones, y se deben modificar sólo por administradores de red, pues afectan todos los programas y aplicativos instalados bajo el sistema operacional. ATENCIÓN: El parámetro de retraso en el envío del ACK se aplica solamente a la comunicación entre la UCP y el software MasterTool IEC XE. Para la comunicación con otros dispositivos y/o otros protocolos (MODBUS, por ejemplo) el estándar utilizado será sin retraso. Parámetros del Proyecto Los parámetros del proyecto de la UCP están relacionados a configuraciones para actualización de las entradas y salidas en las tareas en que están en uso, consistencia del área retentiva y persistente en 45 4. Configuración %Q y en el caso de las UCPs NX3010, NX3020 y NX3030, opciones de grabación y lectura de la tarjeta de memoria. Descripción Estándar de Fábrica Consist retain and persistent area in %Q Realiza la consistencia de las áreas retentivas y persistentes en %Q Marcado - Marcado - Desmarcado Enable I/O update per task Actualiza las entradas y salidas en las tareas en que son usadas Desmarcado - Marcado - Desmarcado Enable retain and persistente variables in Function Blocks Configuración para permitir el uso de las variables retentivas y persistentes en los bloques de funciones Desmarcado - Marcado - Desmarcado Configuración Posibilidades Tarjeta de Memoria Copia el proyecto de la memoria interna de la UCP para la tarjeta de memoria Habilitado - Habilitado: Configuración habilitada - Deshabilitado: Configuración deshabilitada Password to Copy Project from CPU to Memory Card Contraseña para copiar el proyecto de la memoria interna de la UCP para la tarjeta de memoria - Contraseña de 6 dígitos (0 a 999999) Copy Project from Memory Card to CPU Copia el proyecto de la tarjeta de memoria para la memoria interna de la UCP Deshabilitado - Habilitado: Configuración habilitada - Deshabilitado: Configuración deshabilitada Password to Copy Project from Memory Card to CPU Contraseña para copiar el proyecto de la tarjeta de memoria para la memoria interna de la UCP - Contraseña de 6 dígitos (0 a 999999) Copy Project from CPU to Memory Card Tabla 4-4. Parámetros del Proyecto de la UCP ATENCIÓN: Tras configurar las posibilidades de copia del proyecto y de haber creado la aplicación de inicialización, se debe ubicar el archivo “Application.crc” para que las configuraciones referentes a la tarjeta de memoria tengan efecto. La ubicación se puede realizar en Seleccionar el Application.crc a través del botón “Ubicar Archivo...”, como se puede ver en la Figura 4-66. Configuración de Evento Externo El evento externo es una característica disponible en la UCP que permite que una entrada digital, configurada por el usuario, cuando accionada, dispare la ejecución de una tarea específica con código definido por el usuario. De esta manera, es posible que a través de esta entrada, cuando accionada, se interrumpa la ejecución de la aplicación principal y ejecute la aplicación definida en la tarea ExternInterruptTask00, que posee mayor prioridad que las demás tareas de aplicación. Es importante también observar que, para evitar la generación de varios eventos en un espacio muy corto de tiempo fue limitado el tratamiento de este tipo de evento a cada 10 ms, o sea, si ocurren dos o más eventos durante 10 ms después del primer evento, el segundo y demás eventos serán descartados. Esta limitación fue impuesta para evitar que un evento externo, que sea generado de forma descontrolada, no bloquee la UCP, una vez que su tarea posee mayor prioridad frente a las demás. Para configurar un evento externo es necesario insertar un módulo de entrada digital y realizar las configuraciones descritas en seguida, en la UCP, a través del software de programación MT8500. 46 4. Configuración Figura 4-4. Pantalla de Configuración de Evento Externo en la UCP En la pestaña de configuración de evento externo, dentro de las configuraciones de la UCP, es necesario seleccionar cual módulo será la fuente de interrupción en el campo Dirección de Módulo: Nombre. En seguida debe ser seleccionado cuál entrada de este módulo será responsable por generar el evento (IO_EVT_0), en esta selección es posible elegir por las opciones descritas en la Figura 4-5. Figura 4-5. Opciones de Origen del Evento Externo en el Módulo NX1001 Además de la configuración de la UCP es necesario configurar la tarea responsable por ejecutar las acciones definidas por el usuario. En este caso el usuario debe utilizar un perfil de proyecto que soporte eventos externos. Para más informaciones consulte el capítulo Perfiles de Proyecto. En la pantalla de configuración de la tarea ExternInterruptTask00, en la Figura 4-6, es necesario 47 4. Configuración seleccionar el origen del evento, en el campo Evento. En este caso debe ser seleccionado IO_EVT_0, pues las demás fuentes de origen IO_EVT_1 a IO_EVT_7 no están disponibles. En seguida debe ser verificado si la POU seleccionada en el campo POUs es correcta, pues la misma será utilizada por el usuario para definir las acciones que serán ejecutadas cuando un evento externo ocurrir. Figura 4-6. Pantalla de Configuración de la Tarea ExternInterruptTask00 Configuración del SOE El SOE (Sequence of Events) es responsable de la generación de una secuencia de eventos digitales. A través de este, es posible analizar el histórico comportamental de las variables del sistema mapeadas en su área de monitoreo. El SOE es un servicio exclusivo disponible en los modelos NX3020 y NX3030. Una vez habilitado el servicio SOE, la UCP pasa a portarse como un servidor DNP3, de esta forma es necesario soporte al protocolo DNP3 por parte del cliente para utilización de este recurso. Los tipos de objetos soportados bien como los códigos de función y los calificadores se pueden encontrar en el Anexo A. El servicio SOE hace la utilización de direcciones %Q para constituir su base de datos estáticos. Para esto, se debe configurar un área continua de memoria %Q en la cual el usuario informará su inicio y tamaño dividido por dos. Para proyectos redundantes el área de %Q también debe ser redundante, para que, en el momento del switchover, la base de datos del servidor DNP3 se mantenga. La dirección inicial del DNP3 siempre será 0, correspondiendo al %QBxxxx.0 y la última dirección será: ((Tamaño del área de %Q * 8) *2) - 1. De esta forma, definida la base de datos estática, el usuario debe copiar cada punto digital que debe generar eventos para dentro del área continua de %Q. El número máximo de puntos que se pueden copiar es 8000. Para la configuración de los eventos, es necesario informar sólo el tamaño de la fila de eventos. Esta fila es persistente y redundante, de este modo, no se perderán eventos en el momento del switchover, o en el momento de una falla en la alimentación. En caso de que ocurra un overflow en la fila de eventos, los eventos más antiguos se sobrescribirán. En caso de que en un único ciclo se generen más eventos de lo que soporta la fila, su generación se interrumpe y lo diagnóstico de overflow se conecta 48 4. Configuración (SOE[x].bOverflowStatus). Por ejemplo, si 100+n bits tienen variación en una configuración de 100 eventos, ocurre un descarte de n eventos. El SOE rodará en el contexto de la tarea MainTask, inclusive en el primer ciclo de la tarea. El SOE será ejecutado al final de cada ciclo de la tarea y comparará los bits mapeados para detectar transiciones ocurridas durante el ciclo. De esta forma, a cada ciclo en que eventos se generen, ocurrirá un incremento de tiempo en este ciclo de la MainTask. Para el peor caso (1000 eventos, siendo que se generarán sólo 1000 y el resto se desechará), esta influencia será de alrededor de 5 ms. Por lo tanto, para una aplicación con el SOE habilitado, el usuario deberá tener en consideración este tiempo al configurar los parámetros de tiempo de watchdog e intervalo de la tarea MainTask. Para la utilización de este, el usuario deberá configurar los siguientes parámetros en la pestaña Configuración del SOE: Figura 4-7. Configuración de la Secuencia de Eventos 49 4. Configuración Configuración Descripción Estándar de Fábrica Posibilidades Configuraciones Generales Deshabilitado Habilitado Deshabilitado SOE Service Activa el SOE. Ethernet Interface Selecciona la interfaz utilizada. NET1 NET1 NET2 Keep Alive Interval (ms) Intervalo de las mensajes de keep alive (ms). 10000 0 a 4294967295 Events Queue Size Tamaño de la fila de eventos. 1000 100 a 1000 Puntos de Comunicación Offset of %Q Start Address Dirección inicial para datos estáticos. 20480 Se puede utilizar cualquier dirección de la área de %Q. Size of Area %Q Tamaño de la memoria a ser utilizada por datos estáticos (%Q). 1000 1 a 1000 Configuración de los Clientes Configuración Descripción Estándar de Fábrica Posibilidades 2 1, 2 Number of Clients Define el número de clientes. TCP Port for Client 1 Selecciona la puerta de comunicación para el primer cliente. 20000 1 a 65535 TCP Port for Client 2 Selecciona la puerta de comunicación para el segundo cliente. 20001 1 a 65535 Tabla 4-5. Configuración del SOE Notas: Tamaño del Memoria de Datos: El tamaño del área de memoria reservada utilizarse por los datos estáticos será siempre el doble del valor configurado, pues la segunda mitad del área de memoria se utiliza para almacenar los valores anteriores de las variables de la primera mitad. Keep Alive: Mientras esté conectado a un cliente, se enviarán mensajes de keep alive en intervalos, según lo configurado. En caso de que el cliente no responda a estos mensajes, la conexión se cierra. Es decir, una conexión entre cliente y servidor podrá llevar un tiempo igual al intervalo configurado para que se cierre en caso de error. En las opciones avanzadas (botón Avanzado...) es posible configurar las direcciones de comunicación referentes al protocolo DNP3. Configuración Descripción Estándar de Fábrica Posibilidades DNP3 Source Address Dirección de origen (CP) 4 0 – 65519 DNP3 Destination Address of Client 1 Dirección del primer cliente 3 0 – 65519 DNP3 Destination Address of Client 2 Dirección del segundo cliente 3 0 – 65519 Tabla 4-6. Configuraciones Avanzadas del SOE 50 4. Configuración Nota: DNP3 Address: Las direcciones DNP3 de la franja de 65520 a 65535 no se pueden configurar en el origen o en un destino, pues estos se utilizan para mensajes en broadcast. ATENCIÓN: Los mensajes de Data Link del DNP3 no se utilizan por las UCPs de la serie Nexto, pues la norma no recomienda que se utilicen al comunicar por TCP/IP. Sincronización de Tiempo Para la sincronización de tiempo, las UCPs de la serie Nexto usan el protocolo SNTP (Simple Network Time Protocol). Para eso, se portará como un cliente SNTP, es decir, enviará solicitudes de sincronización de tiempo para un servidor SNTP/NTP, que puede estar en la red local o en internet. El cliente SNTP trabaja con resolución de 1 ms, con 100 ms de precisión, o sea, cuando una sincronización se efectúa, el horario actualizado en el cliente puede estar hasta 100 ms adelantado o retrasado en relación al servidor. La UCP envía las solicitudes de sincronización cíclicas, según el tiempo configurado en el campo Período de Sincronización del SNTP. En el primer intento de sincronización, enseguida de la inicialización del servicio, la solicitud es para el primer servidor, configurado en Dirección de IP del 1° Servidor. En caso de que este no conteste, las solicitudes se direccionan al segundo servidor configurado en Dirección de IP del 2º Servidor, lo que suministra una redundancia de servidores SNTP. En caso de que el segundo servidor tampoco responda, el mismo proceso de intento de sincronización se ejecuta nuevamente, pero sólo después del Período de Sincronización haber pasado. O sea, a cada período de sincronización, la UCP intenta conectarse una vez en cada servidor, intenta el segundo en caso de que el primero no conteste. El tiempo de espera por una respuesta del servidor SNTP se define por estándar en 5 segundos y no puede ser alterar. En caso de que, tras una solicitud de sincronización, la diferencia entre el horario actual de la UCP y el recibido por el servidor sea mayor que el valor configurado en el parámetro Error Mínimo Antes de la Actualización del Reloj, el horario de la UCP se actualiza. Como el SNTP usa el horario en el formato UTC (Universal Time Coordinated), el parámetro de Fuso Horario se debe configurar correctamente, para que el horario leído por el SNTP se convierta correctamente la hora local. El proceso de ejecución del cliente SNTP se puede ejemplificar con los siguientes pasos: 1. Intento de sincronización a través del primer servidor. En caso de que la sincronización ocurra con éxito, la UCP aguarda el tiempo para la nueva sincronización (Período de Sincronización) e intentará sincronizarse nuevamente con este servidor, utilizando, entonces, este como servidor primario. En caso de falla (el servidor no contesta en menos de 5 s) el paso 2 se ejecuta. 2. Intento de sincronización a través del do segundo servidor. En caso de que la sincronización ocurra con éxito, la UCP aguarda el tiempo para la nueva sincronización (Período de Sincronización) e intentará sincronizarse nuevamente con este servidor, utilizando, entonces, este como servidor primario. En caso de falla (el servidor no contesta en menos de 5 s) se aguarda el tiempo referente al Período de Sincronización y se ejecuta nuevamente el paso 1. Como el tiempo de espera por la respuesta del servidor SNTP es de 5 s, se debe estar atento al configurar valores menores que 10 s para el Período de Sincronización. En caso de que el servidor primario no conteste, el tiempo para la sincronización será de, en lo mínimo, 5 s (espera de la respuesta del servidor primario e intento de sincronización con el servidor secundario). En caso de que ni el servidor primario y tampoco el secundario contesten, el tiempo para la sincronización será de, en lo mínimo, 10 s (espera de la respuesta de los dos servidores y nuevo intento de conexión con el 1° servidor). Cuando es utilizado las UCPs NX3020 y NX3030, dependiendo de la subred del servidor SNTP, el cliente utilizará la interfaz Ethernet que esté en la subred correspondiente para hacer las solicitudes de sincronismo. Si no hay una interface configurada en la misma subred del servidor, la solicitud se 51 4. Configuración podrá hacer por cualquiera de las dos interfaces que pueda encontrar un camino hacia el servidor, siendo eso también valido para los modelos de NX3004, NX3005 y NX3010. Para la utilización del cliente SNTP, el usuario debe configurar los siguientes parámetros en la pestaña Configuración de SNTP, la cual se accede a través de la UCP, en el árbol de dispositivos: Figura 4-8. Configuración de SNTP Configuración SNTP Service Descripción Activa el servicio SNTP Estándar de Fábrica Posibilidades Deshabilitado Deshabilitado Habilitado Period for SNTP Synchronization (x1 sec) Intervalo de tiempo de las solicitudes de sincronización (segundos) 60 1 a 255 Minimum Error Before Clock Update (x1 ms) Valor de offset aceptable entre el horario del servidor y del cliente (milisegundos) 100 100 a 65519 -3:00 -12:59 a +13:59 Time zone (hh:mm) Huso horario de su localidad. Se puede insertar la hora y el minuto IP Address of the First SNTP Server Dirección IP del servidor SNTP primario 192.168.15.10 1.0.0.1 a 223.255.255.255 IP Address of the 2º Second SNTP Server Dirección IP del servidor SNTP secundario 192.168.15.11 1.0.0.1 a 223.255.255.255 Tabla 4-7. Configuraciones SNTP Notas: Servidor SNTP: Es posible definir una dirección preferencial y otra secundaria para acceder a un servidor SNTP y, así, obtener sincronismo de tiempo. Si ambos los campos están vacíos, el servicio SNTP permanecerá deshabilitado. Estándar de Fábrica: Desde la versión MasterTool 1.40 y superiores del MasterTool IEC XE el valor predeterminado de fábrica para las direcciones IP de los Servidores SNTP han cambiado. ATENCIÓN: El Servicio SNTP depende de la aplicación del usuario sólo para su configuración. Por lo tanto, este servicio se va a ejecutar aun cuando la UCP esté en los modos STOP o BREAKPOINT, desde que exista una aplicación en la UCP con el cliente SNTP habilitado y correctamente configurado. 52 4. Configuración CUIDADO: Sumamente importante es la configuración de, en lo mínimo, un servidor SNTP. Lo recomendable es configurar dos servidores SNTP (primario y secundario). El sincronismo SNTP es necesario para generar eventos con estampa de tiempo coherente entre los CPA y CPB y con la hora mundial. Otra utilidad es evitar discontinuidades durante un switchover en aplicaciones que referencian fecha y hora, teniendo en cuenta que no existe sincronismo de fecha y hora entre los CPs a través de los canales de sincronismo NETA y NETB. Horario de Verano La configuración del horario de verano se debe hacer indirectamente, a través de la función NextoSetTimeZone, que altera el huso horario aplicado al RTC. En el inicio del horario de verano, se debe usar la función para aumentar en una hora el huso horario. Al final del horario de verano, se usa la función nuevamente para disminuirlo en una hora. Para más informaciones, consultar la subsección Reloj RTC de este manual. Configuración de las Interfaces Seriales COM 1 (NX3010/NX3020/NX3030) La interfaz de comunicación COM 1, presente en las UCPs NX3010, NX3020 y NX3030, es compuesta por un conector tipo DB9 hembra para el estándar RS-232C. Permite la comunicación punto a punto (o en red utilizando conversor) en los protocolos abiertos, MODBUS RTU esclavo o MODBUS RTU maestro. A continuación, siguen los parámetros que se deben configurar para el buen funcionamiento de la aplicación. Al utilizar el protocolo MODBUS Maestro/Esclavo, algunos de estos parámetros (como Modo Serial, Bits de Dato, Threshold RX y Eventos Seriales) se ajustan automáticamente por la herramienta MasterTool para el correcto funcionamiento de este protocolo. Configuración Estándar de Fábrica Descripción Serial Type Configuración del tipo del canal serial RS-232C Baud Rate Velocidad de la puerta de comunicación serial 115200 Parity Configura la paridad de la puerta serial Sin Paridad Posibilidades RS-232C 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps Impar Par Paridad Siempre Un Paridad Siempre Cero Sin Paridad Data Bits Configura el número de bits de datos en cada carácter de la comunicación serial. 8 5, 6, 7 e 8 Stop Bits Configura los bits de parada de la puerta serial 1 1, 1.5 e 2 Serial Mode Configura el modo de operación de la puerta serial Modo Normal Modo Extendido: Modo extendido de operación de la comunicación serial, en el cual se suministran informaciones sobre el frame de datos recibido. Modo Normal: Modo normal de operación de la comunicación serial. Tabla 4-8. Configuraciones de la Interfaz Serial Estándar RS-232 53 4. Configuración Notas: Modo Extendido: En este modo de operación de la comunicación serial se suministran informaciones sobre el frame de datos recibido. Las informaciones disponibles son las siguientes: Un byte para el dato recibido (RX_CHAR : BYTE): Almacena los cinco, seis, siete u ocho bits de los datos recibidos, lo que depende de la configuración de la serial. Un byte para los errores en la señal (RX_ERROR : BYTE): Tiene el siguiente formato: Bit 0: 0 - el carácter en los bits 0 a 7 es válido. el carácter en los bits 0 a 7 no es válido (o puede no ser válido), debido a los problemas indicados en los bits 10 a 15. Bit 1: No utilizado. Bit 2: No utilizado. Bit 3: Error de interrupción en la UART. La entrada serial permaneció en la lógica 0 (paridad siempre cero) por un tiempo mayor que un carácter (bit de partida + bit de datos + bit de paridad + bit de parada). Bit 4: Error en el frame UART. La lógica 0 (paridad siempre cero) se leyó cuando el primer bit de parada se esperaba, siendo que debería ser lógica 1 (paridad siempre un). Bit 5: Error de paridad UART. El bit de paridad leído no está según el bit de paridad calculado. Bit 6: Error de overrun UART. Datos se perdieron durante la lectura del FIFO UART, porque nuevos caracteres fueron recibidos antes que los antiguos se removieran. Ese error solamente se indicará en el primer carácter leído tras la indicación del error de overrun. Eso significa que algunos datos antiguos se perdieron. Bit 7: Error de overrun en la fila RX: Ese carácter fue escrito cuando la fila RX se completó, sobrescribiendo caracteres no leídos. Dos bytes para la señal de timestamping (RX_TIMESTAMP : WORD): Indica el tiempo de silencio, en el intervalo de 0 a 65535, usa como base de tiempo 10 us. Colma en 655,35 ms, caso el tiempo de silencio sea mayor que 65535 unidades. El RX_TIMESTAMP de un carácter mide el tiempo desde una referencia que puede ser una de las tres opciones a continuación: En la mayoría de los casos, el fin del carácter anterior. Configuración de la puerta serial. El fin de la transmisión serial al usar el SERIAL_TX FB, es decir, cuando el último carácter se envía en la línea. Además de medir el tiempo de silencio antes de cada carácter, el RX_TIMESTAMP también es importante, pues mide el tiempo de silencio del último carácter de la fila RX. La medición del silencio es importante para implementar correctamente algunos protocolos, como MODBUS RTU. Ese protocolo especifica un interframe mayor que 3,5 caracteres y un interbyte menor que 1,5 caracteres. Bits de Dato: La configuración Bits de Dato de las interfaces seriales limita los campos Bits de Parada y Paridad de la comunicación, es decir, el número de bits de parada y el método de paridad cambiarán según el número de bits de dato. A continuación la Tabla 4-9 muestra las configuraciones permitidas para la interfaces COM 1 de las UCPs NX3010, NX3020 y NX3030. Bits de Datos Bits de Parada Paridad 5 1,1.5 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 6 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 7 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 8 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO Tabla 4-9. Configuraciones Específicas 54 4. Configuración Configuraciones Avanzadas Las configuraciones avanzadas se relacionan a las señales de control de la comunicación serial, es decir, cuando se hace necesaria la utilización de un control más apurado de la transmisión y recepción de los datos. Configuración Estándar de Fábrica Descripción Posibilidades Parámetros de Puerta Avanzados Handshake Realiza el control de requerimiento para transmisión de un comando, a través de la interfaz RS-232. RTS Siempre Desligado UART RX Threshold Cantidad de bytes que se deben recibir para generar una nueva interrupción en UART. Valores bajos hacen el TIMESTAMP más preciso cuando el MODO EXTENDIDO se utiliza y minimiza los errores de overrun. Sin embargo, valores bajos pueden causar muchas interrupciones que pueden retardar la UCP. 8 RX on TX Cuando verdadero, todos los bytes recibidos durante la transmisión se descartarán en vez de irse a la fila de RX. Se utiliza para deshabilitar la operación full-duplex en la interfaz RS-232. RX DCD Event Cuando verdadero, genera un evento externo debido al cambio de la señal DCD. RX CTS Event Cuando verdadero, genera un evento externo debido al cambio de la señal CTS. - RTS: Se habilita en el inicio de la transmisión y reinicia, lo más rápido posible, tras el fin de la transmisión. Ej.: Control de un conversor RS232/RS485 externo. - RTS siempre deshabilitado. - RTS siempre habilitado. - RTS/CTS: Caso el CTS esté deshabilitado, el RTS se habilita. Entonces, se aguarda que el CTS se habilite para que comience la transmisión y el RTS se reinicie, lo más rápido posible, en el fin de la transmisión. Ej.: Control de radio módems con la misma señal de modem. - Manual RTS: El usuario es responsable por controlar todas las señales de control. 1, 4, 8 y 14 Eventos Seriales Deshabilitado - Habilitado: Configuración habilitada - Deshabilitado: Configuración deshabilitada Habilitado - Habilitado: Configuración habilitada - Deshabilitado: Configuración deshabilitada Habilitado - Habilitado: Configuración habilitada - Deshabilitado: Configuración deshabilitada Tabla 4-10. Configuraciones Avanzadas de la Interfaz Estándar RS-232 Notas: RX en TX: Este parámetro avanzado es válido para configuraciones RS-232C y RS-422. 55 4. Configuración Evento RX DCD: Los eventos externos, como la señal de DCD de CON 1 de las UCPs NX3010, NX3020 y NX3030, solo se pueden asociar a las tareas del perfil de proyecto personalizado, descrito con detalles en el Manual de Manual del Usuario MasterTool IEC XE– MU299800. Evento RX CTS: Los eventos externos, como la señal de CTS de COM 1 de las UCPs NX3010, NX3020 y NX3030, solo se pueden asociar a las tareas del perfil de proyecto personalizado, descrito con detalles en el Manual de Manual del Usuario MasterTool IEC XE – MU299800. COM 1 (NX3004/NX3005) y COM 2 (NX3010/NX3020/NX3030) Las interfaces de comunicación COM1 (NX3004 y NX3005) y COM 2 (NX3010, NX3020 y NX3030) son compuestas por un conector tipo DB9 hembra para los estándares RS-422C y RS-485. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS RTU esclavo o MODBUS RTU maestro. Cuando usado el protocolo MODBUS Maestro/Esclavo, algunos de estos parámetros (como Modo Serial, Bits de dato Threshold RX y Eventos Seriales) se ajustan automáticamente por el software MasterTool para el correcto funcionamiento de este protocolo. A continuación, siguen los parámetros que se deben configurar para el buen funcionamiento de la aplicación: Configuración Descripción Serial Type Configuración del tipo del canal serial Baud Rate Velocidad de la puerta de comunicación serial Estándar de Fábrica Posibilidades RS-485 RS-422 y RS-485 115200 200, 300, 600, 1200, 1800, 2400, 4800, 9600, 19200, 38400, 57600, 115200 bps Parity Configura la paridad de la puerta serial 0 Impar Par Paridad Siempre Un Paridad Siempre Cero Sin Paridad Data Bits Configura el número de bits de datos en cada carácter de la comunicación serial 8 5, 6, 7 e 8 Stop Bits Configura los bits de parada de la puerta serial 1 1, 1.5 y 2 Serial Mode Configura el modo de operación de la puerta serial Modo Normal - Modo Extendido: Modo extendido de operación de la comunicación serial, en el cual se suministran informaciones sobre el frame de datos recibido. (Vea nota sección COM 1). - Modo Normal: Modo normal de operación de la comunicación serial. Tabla 4-11. Configuración de la Interfaz Serial Estándar RS-485/422C La configuración Bits de Dato de las interfaces seriales limita los campos Bits de Parada y Paridad de la comunicación, es decir, el número de bits de parada y el método de paridad cambiarán según el número de data bits. A continuación, la tabla muestra las configuraciones permitidas para la interfaz COM 1 (NX3004 and NX3005) y COM 2 (NX3010, NX3020 y NX3030). Bits de Datos Bits de Parada Paridad 5 1, 1.5 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 6 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 56 4. Configuración 7 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO 8 1, 2 SIN PARIDAD, IMPAR, PAR, PARIDAD SIEMPRE UN, PARIDAD SIEMPRE CERO Tabla 4-12. Configuraciones Específicas Configuraciones Avanzadas Las configuraciones avanzadas se refieren a las señales de control de la comunicación serial, es decir, cuando se hace necesaria la utilización de un control más apurado de la transmisión y recepción de los datos. Configuración Descripción UART RX Threshold Cantidad de bytes que se deben recibir para generar una nueva interrupción en UART. Valores bajos hacen el TIMESTAMP más preciso cuando el MODO EXTENDIDO se utiliza y minimiza los errores de overrun. Sin embargo, valores bajos pueden causar muchas interrupciones que pueden retardar la UCP. Estándar de Fábrica Posibilidades 8 1, 4, 8 y 14 Tabla 4-13. Configuraciones Avanzadas de la Interfaz Estándar RS-485/422C Configuración de las Interfaces Ethernet Las UCPs Nexto pueden dejar disponibles hasta dos interfaces Ethernet locales, NET 1 y NET 2. Las UCPs NX3004, NX3005 y NX3010 tienen sólo la interfaz NET 1 y las UCPs NX3020 y NX3030 poseen NET 1 y NET 2. Además de las interfaces Ethernet locales, la Serie Nexto ofrece también interfaces Ethernet remotas a través de la inclusión del módulo NX5000. Los módulos NX5000 poseen sólo la interfaz NET 1. Interfaces Ethernet Locales NET 1 La interfaz NET 1 está compuesta por un conector tipo RJ45 de comunicación en el estándar 10/100Base-TX. Permite la comunicación punto a punto o en red en los protocolos abiertos, como por ejemplo, MODBUS TCP Cliente, MODBUS RTU por TCP Cliente, MODBUS TCP Servidor y MODBUS RTU por TCP Servidor. A continuación, siguen los parámetros que se deben configurar para el buen funcionamiento de la aplicación. Descripción Estándar de Fábrica Posibilidades Dirección IP del controlador en el bus Ethernet. 192.168.15.1 1.0.0.1 a 223.255.255.254 Sub network Mask Máscara de subred del Controlador en el bus Ethernet. 255.255.255.0 128.0.0.0 a 255.255.255.252 Gateway Address Dirección del Gateway del Controlador en el bus Ethernet. 192.168.15.253 1.0.0.1 a 223.255.255.254 Configuración IP Address Tabla 4-14. Configuraciones NET 1 57 4. Configuración NET 2 La interfaz NET 2 está compuesta por un conector tipo RJ45 de comunicación en el estándar 10/100Base-TX. Permite la comunicación punto a punto o en red en los protocolos abiertos, como por ejemplo, MODBUS TCP Cliente, MODBUS RTU por TCP Cliente, MODBUS TCP Servidor y MODBUS RTU por TCP Servidor. A continuación, siguen los parámetros que se deben configurar para el buen funcionamiento de la aplicación. Descripción Estándar de Fábrica Posibilidades Dirección IP del controlador en el bus Ethernet. 192.168.16.1 1.0.0.1 a 223.255.255.254 Sub network Mask Máscara de subred del Controlador en el bus Ethernet. 255.255.255.0 128.0.0.1 a 255.255.255.252 Gateway Address Dirección del Gateway del Controlador en el bus Ethernet. 192.168.16.253 1.0.0.1 a 223.255.255.254 Configuración IP Address Tabla 4-15. Configuraciones NET 2 ATENCIÓN: No es posible configurar las dos interfaces Ethernet de una UCP en la misma subred, este tipo de configuración está bloqueada por la herramienta MasterTool. De esta manera, cada interfaz Ethernet debe configurarse en una subred independiente. Interfaces Ethernet Remotas NET 1 La interfaz NET 1 está compuesta por un conector tipo RJ45 de comunicación en el estándar 10/100Base-TX. Permite la comunicación punto a punto o en red en los protocolos abiertos, MODBUS TCP Cliente, MODBUS RTU por TCP Cliente, MODBUS TCP Servidor y MODBUS RTU por TCP Servidor. A continuación, siguen los parámetros que se deben configurar para el buen funcionamiento de la aplicación. Descripción Estándar de Fábrica Posibilidades IP Address Dirección IP del Controlador en el bus Ethernet 192.168.xx.68 1.0.0.1 a 223.255.255.254 Sub network Mask Máscara de subred del Controlador en el bus Ethernet 255.255.255.0 128.0.0.0 a 255.255.255.252 Gateway Address Dirección del Gateway del Controlador en el bus Ethernet 192.168.xx.253 1.0.0.1 a 223.255.255.254 Configuración Tabla 4-16. Configuraciones NET 1 Remota Puertas TCP Reservadas Las puertas TCP de las interfaces Ethernet, a continuación, tanto locales como remotas, se utilizan por servicios de la UCP y, por lo tanto, se reservan y no se deben utilizar por el usuario: 80, 8080, 1217, 1740, 1741, 1742,1743 y 11740. Configuración del Módulo NX5000 Los módulos NX5000 se pueden insertar en el proyecto para aumentar la cantidad de interfaces Ethernet en caso de que las interfaces locales de la UCP no sean suficientes. Sólo las UCPs NX3005, NX3020 y NX3030 tienen soporte al módulo NX5000. 58 4. Configuración Los canales Ethernet de los módulos NX5000 se pueden usar de forma individual, u organizados en pares NIC Teaming. Pares NIC Teaming se utilizan para proveer canales Ethernet redundantes. Una aplicación típica para el módulo NX5000 puede ser construir una HSDN (High Speed Deterministic Network), redundante, para comunicación entre diversos CPs. A través de esta red, diversos CPs pueden intercambiar mensajes en una red totalmente aislada, para garantizar determinismo y una comunicación rápida. Además, al configurar esta red como redundante con pares NIC Teaming, se puede obtener excelente disponibilidad. Para construir una HSDN redundante, se debe insertar dos módulos NX5000. La Figura 4-9 muestra un ejemplo de HSDN redundante, al utilizar dos módulos NX5000. La Figura 4-9 también muestra un ejemplo con un módulo NX5000 usado de forma aislada (sin redundancia NIC Teaming), insertado a la derecha de los demás módulos. MasterTool SCADAs Ethernet não-redundante N X 8 0 0 0 N X 3 0 3 0 N X 5 0 0 0 N X 5 0 0 0 N X 5 0 0 0 Ethernet não-redundante Ethernet HSDN A Ethernet HSDN B Outros CPs na HSDN (normalmente redundantes) Figura 4-9. Redes Ethernet Simples y Redundante Utilizando NX5000 Los dos primeros NX5000 del bastidor forman un par redundante NIC Teaming, interconectados en dos switches diferentes (Ethernet HSDN A y Ethernet HSDN B). En algún punto, estos dos switches se deben interconectar, para que exista conexión entre las dos puertas NIC Teaming y disponibilidad aun mayor (contra doble fallas). Dichas arquitecturas Ethernet brindan excelente disponibilidad, contra falla en las puertas Ethernet, en cables y en switches. Un conjunto de dos puertas Ethernet, al formar un par NIC Teaming posee una única dirección de IP, vinculada al par de puertas. De esta forma, un cliente como un SCADA o MasterTool, conectado a un servidor en el CP, no necesita preocuparse en cambiar la dirección IP en caso de que haya falla en algunas de las puertas del par NIC Teaming. Diagnósticos apuntan fallas que eventualmente surjan en cualquiera de las puertas de un par NIC Teaming. 59 4. Configuración ATENCIÓN: Ambas las UCPs NX3020 y NX3030 tienen soporte al módulo NX5000 e pueden agrupar dos módulos NX5000 como un par NIC Teaming. Al utilizar la UCP NX3020 se pueden insertar en el proyecto hasta dos módulos NX5000, y al utilizar la UCP NX3030 se pueden insertar hasta seis. Si utilizada una UCP NX3020 o NX3030 se puede configurar pares NIC Teaming, con hasta el máximo número de módulos soportados por cada UCP, como por ejemplo en la arquitectura mostrada en la Figura 4-9, en la cual tenemos un par NIC Teaming y una interfaz Ethernet independiente más, usando tres módulos. Para agrupar dos módulos NX5000 como un par redundante, estos dos módulos deben necesariamente ocupar posiciones vecinas en el bastidor, y el checkbox “Redundancia de Comunicación” del módulo a la izquierda se debe marcar, como muestra la Figura 4-10. Al hacer esto, el módulo a la derecha tiene la edición de sus parámetros bloqueada. Los parámetros editados en el módulo a la izquierda pasan a ser comunes para los dos módulos. Por otro lado, al desmarcar el checkbox “Redundancia de Comunicación” del módulo a la izquierda, se provoca la separación de los módulos, que vuelven a portarse como módulos individuales sin redundancia NIC Teaming. Figura 4-10. Parámetro de Redundancia NX5000 Configuración de Protocolos Independientemente de los protocolos utilizados en cada aplicación, la UCPs de la Serie Nexto posee algunos límites máximos para cada modelo de la UCP. Básicamente hay dos tipos de protocolos de comunicación - los que usan mapeos simbólicos y los que utilizan mapeos por representación directa. La cantidad máxima de protocolos (instancias) se define en la Tabla 4-17. 60 4. Configuración NX3004 NX3005 NX3010 NX3020 NX3030 Puntos mapeados 20480 20480 20480 20480 20480 Mapeos para MODBUS simbólico 5120 5120 5120 5120 5120 Mapeos/solicitudes MODBUS (representación directa/simbólico respectivamente) 512 512 512 512 512 NETs – Instancias Cliente o Servidor 4 4 4 8 16 COM (n) – Instancias Maestro o Esclavo 1 1 1 1 1 Tabla 4-17. Límites de los Protocolos por UCP Notas: Puntos mapeados: Cada variable o ítem de un tipo de dato se considerará un punto. Lo mismo se considera para cada posición del tipo ARRAY. Eso significa que la cantidad de puntos mapeados se incrementa en una unidad cuando hay una variable de tipo simple siendo declarada, y en el caso de una variable del tipo ARRAY, se incrementará según el tamaño del ARRAY declarado. Esto es independiente del tamaño del tipo de dato, entonces mapear una variable del tipo INT (16 bits) en un Holding Register de los drivers MODBUS simbólicos o una variable del tipo LINT (64 bits) en cuatro Holding Registers de los drivers MODBUS simbólicos se cuenta como solamente un punto mapeado Mapeos para MODBUS simbólico: Un mapeo es una relación entre una variable interna de aplicación y un objeto del protocolo de aplicación. El valor límite para mapeos del proyecto corresponde a la suma de todos los mapeos llevados a cabo en las instancias de protocolos de comunicación y sus respectivos dispositivos. Mapeos/solicitudes MODBUS (representación directa/simbólico respectivamente): Límite de mapeos (líneas) para el MODBUS por representación directa y de solicitudes para el MODBUS por mapeo simbólico. ATENCIÓN: En los casos en que los dos tipos de protocolos se usen en conjunto, a la medida en que un tipo se utiliza, la capacidad máxima del otro tipo disminuye. Por ejemplo, si se utilizan 10240 mapeos simbólicos sólo será posible utilizar 256 mapeos por representación directa. La proporción entre los dos tipos de mapeos es de 40 mapeos simbólicos para cada mapeo por representación directa. NETs: Instancias Cliente o Servidor: El valor máximo definido arriba se distribuye entre todas las interfaces Ethernet del sistema, es decir, incluye los módulos de expansión, cuando estos se aplican. Ejemplos para ese tipo de tarea son las instancias del Protocolo MODBUS. COM (n): Instancias Maestro o Esclavo: La "n" representa el número de la interfaz serial, es decir, aun con módulos de expansión, el valor de la tabla será el máximo por interfaz. Ejemplos para ese tipo de tarea son las instancias del Protocolo MODBUS. El número máximo de instancias compiten entre sí, es decir, entre el MODBUS RTU Maestro y Esclavo solamente una instancia se puede configurar por interfaz en cualquier modelo de UCP. Entre MODBUS Ethernet Cliente y Servidor solamente cuatro (NX3010), ocho (NX3020) o dieciséis (NX3030) instancias se pueden configurar por interfaz. Las limitaciones del Protocolo MODBUS por Representación Directa y por mapos simbólicos para las UCPs se pueden visualizar en Tabla 4-18 y Tabla 4-19, respectivamente. 61 4. Configuración MODBUS RTU Maestro MODBUS RTU Esclavo MODBUS Ethernet Cliente MODBUS Ethernet Servidor Mapeos por instancia 128 32 128 32 Dispositivos por instancia 64 1 (1) 64 Mapeos por dispositivos 32 32 32 32 Solicitudes simultáneas por instancia - - 128 64 Solicitudes simultáneas por dispositivo - - 8 64 Limitaciones (2) 64 Tabla 4-18. Limitaciones del Protocolo MODBUS por Representación Directa Notas: Dispositivos por instancia: Protocolos Maestro o Cliente: cantidad de dispositivos esclavos o servidores soportados por cada instancia de protocolo Maestro o Cliente. Protocolo MODBUS RTU Esclavo: el límite(1) informado tiene relación con a las interfaces seriales, que no permiten que un Esclavo pueda establecer comunicación, simultáneamente, a través de la misma interfaz serial, con más de un dispositivo Maestro. No es necesario, y tampoco posible, declarar ni configurar el dispositivo Maestro bajo la instancia del protocolo MODBUS RTU Esclavo. El dispositivo Maestro tendrá acceso a todos los mapeos hechos directamente en la instancia del protocolo MODBUS RTU Esclavo. Protocolo MODBUS Servidor: el límite(2) informado tiene relación con a las interfaces Ethernet, que limitan la cantidad de conexiones que se pueden establecer con otros dispositivos a través de una misma interfaz Ethernet. No es necesario, y tampoco posible, declarar ni configurar los dispositivos Clientes bajo la instancia del protocolo MODBUS Servidor. Todos los dispositivos Clientes tendrán acceso a todos los mapeos hechos directamente en la instancia del protocolo MODBUS Servidor. Mapeos por dispositivos: El número máximo de mapeos por dispositivo a pesar de estar relacionado arriba, también se limita por el número máximo de mapeos del protocolo. También se debe considerar el límite máximo de mapeos de la UCP conforme descrito en la Tabla 4-17. Solicitudes simultáneas por instancia: Cantidad de solicitudes que se pueden transmitir simultáneamente por cada instancia de protocolo Cliente, o que se pueden recibir simultáneamente por cada instancia de protocolo Servidor. Instancias de protocolo MODBUS RTU, Maestro o Esclavo, no soportan solicitudes simultáneas. Solicitudes simultáneas por dispositivo: Cantidad de solicitudes que se pueden transmitir simultáneamente para cada dispositivo MODBUS Servidor, o que se pueden recibir simultáneamente de cada dispositivo MODBUS Cliente. Dispositivos MODBUS RTU, Maestro o Esclavo, no soportan solicitudes simultáneas. 62 4. Configuración Limitaciones MODBUS RTU Maestro MODBUS RTU Esclavo MODBUS Ethernet Cliente MODBUS Ethernet Servidor Dispositivos por instancia 64 1 (1) 64 64 Solicitudes por dispositivo 32 - 32 - Solicitudes simultáneas por instancia - - 128 64 Solicitudes simultáneas por dispositivo - - 8 64 (2) Tabla 4-19. Limitaciones del Protocolo MODBUS por Mapeos Simbólicos Notas: Dispositivos por instancia: Protocolos Maestro o Cliente: cantidad de dispositivos esclavos o servidores soportados por cada instancia de protocolo Maestro o Cliente. Protocolo MODBUS RTU Esclavo: el límite(1) informado tiene relación con a las interfaces seriales, que no permiten que un Esclavo pueda establecer comunicación, simultáneamente, a través de la misma interfaz serial, con más de un dispositivo Maestro. No es necesario, y tampoco posible, declarar ni configurar el dispositivo Maestro bajo la instancia del protocolo MODBUS RTU Esclavo. El dispositivo Maestro tendrá acceso a todos los mapeos hechos directamente en la instancia del protocolo MODBUS RTU Esclavo. Protocolo MODBUS Servidor: el límite(2) informado tiene relación con las interfaces Ethernet, que limitan la cantidad de conexiones que se pueden establecer con otros dispositivos a través de una misma interfaz Ethernet. No es necesario, y tampoco posible, declarar ni configurar los dispositivos Clientes bajo la instancia del protocolo MODBUS Servidor. Todos los dispositivos Clientes tendrán acceso a todos los mapeos hechos directamente en la instancia del protocolo MODBUS Servidor. Solicitudes por dispositivo: Cantidad de solicitudes, como por ejemplo de lectura o escritura de holding registers, que se pueden configurar para cada uno de los dispositivos (esclavos o servidores) de instancias de protocolos Maestro o Cliente. Este parámetro no se aplica a las instancias de protocolos Esclavo o Servidor. Solicitudes simultáneas por instancia: Cantidad de solicitudes que se pueden transmitir simultáneamente por cada instancia de protocolo Cliente, o que se pueden recibir simultáneamente por cada instancia de protocolo Servidor. Instancias de protocolo MODBUS RTU, Maestro o Esclavo, no soportan solicitudes simultáneas. Solicitudes simultáneas por dispositivo: Cantidad de solicitudes que se pueden transmitir simultáneamente para cada dispositivo MODBUS Servidor, o que se pueden recibir simultáneamente de cada dispositivo MODBUS Cliente. Dispositivos MODBUS RTU, Maestro o Esclavo no soportan solicitudes simultáneas. ATENCIÓN: Los drivers de comunicación por Mapeos simbólicos sólo están disponibles desde la versión 1.3.0.20 de las UCPs de la Serie Nexto. Igualmente para utilizar esta función es necesario la versión 1.40 o superior del MasterTool IEC XE. Comportamiento de los Protocolos x Estados de la UCP La Tabla 4-20 muestra en detalle cada comportamiento asumido para cada protocolo de comunicación configurable en las UCPs de la serie Nexto, en todos sus estados de funcionamiento. 63 4. Configuración Estado operacional de la UCP STOP Protocolo Tipo RUN Después del download, antes de que la aplicación se inicie Después de la aplicación, ir a STOP (PAUSE) Después de una excepción No redundante o Activo Redundante en Reserva Después de un breakpoint en la MainPrg Slave/Server Master/Client SOE (DNP3) Outstation EtherCAT Master NA OPC Server SNTP Client HTTP Server SNMP Agent MODBUS Tabla 4-20. Comportamiento de los Protocolos x Estados de la UCP Notas: Símbolo : El protocolo permanece activo y operando normalmente. Símbolo : El protocolo está deshabilitado. EtherCAT: Los testeos se ejecutaron usando la MainTask como Bus Cycle Task. En el caso de que otra tarea se utilice, el protocolo permanecerá activo al ocurrir un breakpoint en la MainPrg. El protocolo EtherCAT no está disponible para los modelos NX3004, NX3005 y NX3010 y tampoco para la configuración de redundancia de cluster. SOE: El protocolo de registro de eventos (SOE) no está disponible para los modelos NX3004, NX3005 y NX3010. MODBUS RTU MAESTRO Este protocolo está disponible para las UCPs de la Serie Nexto en sus canales seriales. Al seleccionar esta opción en el MasterTool IEC XE, la UCP pasa a ser maestro de la comunicación MODBUS, lo que posibilita el acceso a otros dispositivos con el mismo protocolo, cuando esta está en modo de ejecución (Modo Run). Hay dos formas de instalación de este protocolo. Uno de ellos hace uso de representación directa (% Q), en lo cual las variables se definen por su dirección. El otro, llamado Mapeo Simbólico, tiene las variables definidas por su nombre. Independiente del modo de configuración, los pasos para insertar una instancia del protocolo y configurar la interfaz serial son iguales. El procedimiento para insertar una instancia del Protocolo se encuentra en detalle en el Manual del Usuario de MasterTool IEC XE-MU299800 o en el capítulo Insertando una Instancia de Protocolo. A continuación se describen los pasos restantes de configuración para cada modo. Añadir la instancia del protocolo MODBUS RTU Maestro al canal serial COM 1 o COM 2 (o ambos, en caso de dos redes de comunicación). Para realizar dicho procedimiento, consultar el capítulo Insertando una Instancia de Protocolo. Configurar la interfaz serial, elegir la tasa de comunicación, el comportamiento de las señales de modem RTS/CTS, la paridad, los bits de parada del canal e demás configuraciones a través de un doble clic sobre el canal serial COM 1 o COM 2. Consultar el capítulo Configuración – Configuración de las Interfaces Seriales. Configuración del Protocolo MODBUS Maestro por Mapeo Simbólico Para configurar el protocolo utilizando Mapeo Simbólico, los siguientes pasos deben ser ejecutados: 64 4. Configuración Configurar los parámetros generales del protocolo MODBUS Maestro, como: tempos de retraso de envío e interframe mínimo como en la Figura 4-11. Añadir y configurar dispositivos, a través de la pestaña Parámetros Generales, definiendo la dirección del esclavo, time-out de comunicación y número de reintentos de comunicación como en la Figura 4-12. Agregar y configurar los mapeos de MODBUS en la pestaña de Mapeos como en la Figura 4-13, especificando el nombre de la variable, el tipo de datos y su dirección inicial, el tamaño del dato y el rango en lo cual se rellenan automáticamente. Agregar y configurar las solicitudes MODBUS como presentado en la Figura 4-14, especificando la función, el tiempo de escaneo de la solicitud, la dirección inicial (lectura/escritura), el tamaño de los datos (Lectura/Escritura) y generar las variables de diagnosis y desactivación de las solicitudes a través de los botones en la parte inferior de la ventana. Parámetros Generales del Protocolo MODBUS Maestro – Configuración por Mapeo Simbólico Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS (Figura 4-11), se definen como: Figura 4-11. Pantalla de Configuración Parámetros Generales MODBUS RTU Maestro Configuración Descripción Estándar de Fábrica Posibilidades Send Delay (ms) Tiempo de retraso para envío de la respuesta. 0 0 a 65535 Minimum Interframe (chars) Tiempo mínimo de silencio entre diferentes frames. 3.5 3.5 a 100.0 Tabla 4-21. Configuraciones Generales MODBUS RTU Maestro Notas: Send Delay: La respuesta a un requerimiento MODBUS puede causar problemas, como, por ejemplo, en la interfaz RS-485 u otra half-duplex. A veces existe un retraso entre el tiempo de respuesta del esclavo y el silencio en la línea física (retraso en el esclavo para colocar RTS a cero y colocar el transmisor RS-485 en alta impedancia). Para resolver el problema, el maestro puede esperar el tiempo determinado en ese campo antes de enviar el nuevo requerimiento. En caso contrario, los primeros bytes transmitidos por el maestro, durante el requerimiento, se pueden perder. Minimum Interframe: La norma MODBUS define este tiempo como 3,5 caracteres, sin embargo este parámetro es configurable para atender a los dispositivos que no están según el estándar. Los diagnósticos y comandos del protocolo MODBUS Maestro configurado, sea por mapeo simbólico o por representación directa, se almacenan en variables del tipo T_DIAG_MODBUS_RTU_MASTER_1 y para el mapeo por representación directa están en 4 bytes y 8 words, los cuales se describen en la Tabla 4-22 (n es el valor configurado en el campo Dirección Inicial de Diagnósticos en %Q): Variable de Representación Directa Variable de Diagnóstico del tipo T_DIAG_MODBUS_RTU_MASTER_1.* Tamaño Descripción Bits de diagnóstico: %QX(n).0 tDiag.* bRunning BIT 65 El maestro está en ejecución. 4. Configuración Variable de Representación Directa %QX(n).1 Variable de Diagnóstico del tipo T_DIAG_MODBUS_RTU_MASTER_1.* bNotRunning Tamaño Descripción BIT El maestro no está en ejecución (ver bit: bInterruptedByCommand). %QX(n).2 bInterruptedByCommand BIT El bit bNotRunning ha sido habilitado porque el maestro fue interrumpido por el usuario a través de bits de comando. %QX(n).3 bConfigFailure BIT Diagnóstico descontinuado. %QX(n).4 bRXFailure BIT Diagnóstico descontinuado. %QX(n).5 bTXFailure BIT Diagnóstico descontinuado. %QX(n).6 bModuleFailure BIT Indica si hay una falla en el módulo o el no está presente. %QX(n).7 bDiag_7_reserved BIT Reservado Códigos de error: %QB(n+1) SERIAL_STATUS (BYTE) eErrorCode 66 0: no hay errores 1: puerta serial no válida 2 : modo de la puerta serial no válido 3: baud rate no válido 4: data bits no válido 5: paridad no válida 6: stop bits no válido 7: parámetro de señal de modem no válido 8: parámetro de Threshold de RX da UART no válido 9: parámetro de time-out no válido 10: puerta serial ocupada 11: error de hardware en la UART 12: error de hardware remoto 20: tamaño del buffer de transmisión no válido 21: método de señal de modem no válido 22: time-out de CTS = verdadero 23: time-out de CTS = falso 24: error de time-out en la transmisión. 30: tamaño del buffer de recepción no válido 31: error de time-out en la recepción 32: control de flujo configurado diferente del manual 33: control de flujo no válido para puerta serial configurada 34: recepción de datos no permitida en el modo normal. 35: recepción de datos no está permitida en el modo extendido 36: interrupción DCD no permitida 37: interrupción CTS no permitida 38: interrupción DSR no permitida 39: puerta serial no configurada 50: error interno en la puerta 4. Configuración Variable de Representación Directa Variable de Diagnóstico del tipo T_DIAG_MODBUS_RTU_MASTER_1.* Tamaño Descripción serial Bits de comando, reiniciados automáticamente: %QX(n+2).0 bStop BIT Parar el maestro %QX(n+2).1 bRestart BIT Reiniciar el maestro %QX(n+2).2 bResetCounter BIT Reiniciar las estadísticas de los diagnósticos (contadores) bDiag_19_reserved BIT Reservado %QX(n+2).4 bDiag_20_reserved BIT Reservado %QX(n+2).5 bDiag_21_reserved BIT Reservado %QX(n+2).6 bDiag_22_reserved BIT Reservado BIT Reservado BYTE Reservado %QX(n+2).3 tCommand.* %QX(n+2).7 %QB(n+3) bDiag_23_reserved byDiag_03_reserved Estadísticas de comunicación: Contador de solicitudes transmitidas por el maestro (0 a 65535) %QW(n+4) wTXRequests WORD %QW(n+6) wRXNormalResponses WORD Contador de respuestas normales recibidas por el maestro (0 a 65535) %QW(n+8) wRXExceptionResponses WORD Contador de respuestas con códigos de excepción recibidas por el maestro (0 a 65535) wRXIllegalResponses WORD Contador de Respuestas ilegales recibidas por el maestro – Sintaxis no válida, número insuficiente de bytes recibidos, CRC no válido – (0 a 65535) wRXOverrunErrors WORD Contador de errores de overrun durante la recepción – UART FIFO o fila RX – (0 a 65535) %QW(n+10) tStat.* %QW(n+12) %QW(n+14) wRXIncompleteFrames WORD Contador de respuestas con error de construcción, paridad o falla durante la recepción (0 a 65535) %QW(n+16) wCTSTimeOutErrors WORD Contador de errores de time-out en el CTS, con handshake RTS/CTS, durante la transmisión (0 a 65535) WORD Reservado %QW(n+18) Tabla 4-22. Diagnósticos MODBUS RTU Maestro Nota: Contadores: Todos los contadores de los diagnósticos del MODBUS RTU Maestro vuelven a cero cuando el valor límite 65535 sobrepasa. Configuración de los Dispositivos – Configuración por Mapeo Simbólico La configuración de los dispositivos esclavos, vista en la Figura 4-12, siguen los siguientes parámetros: 67 4. Configuración Figura 4-12. Pantalla de Configuraciones de los Parámetros Generales del Dispositivo Configuración Descripción Slave Address Dirección del esclavo MODBUS Communication Time-out (ms) Establece el time-out de lo nivel de la aplicación Maximum Number of Retries Establece el número de reintentos antes de informar sobre un error de comunicación Estándar de Fábrica Posibilidades 1 0 a 255 3000 10 a 65535 2 0a9 Tabla 4-23. Configuraciones del Dispositivo Notas: Slave Address: Según el estándar MODBUS, el rango de dirección válido para esclavos es de 0 a 247, siendo las direcciones 248 a 255 reservadas. Cuando el maestro envía un comando de escritura con la dirección configurada a cero, está llevando a cabo las solicitudes de broadcast en la red. Communication Time-out: El tiempo de espera de comunicación es el tiempo que el maestro espera una respuesta del esclavo a la solicitud. Para un dispositivo MODBUS RTU maestro debe tenerse en cuenta al menos las siguientes variables: el tiempo que el esclavo lleva a transmitir el frame (según la tasa de transmisión), el tiempo que el esclavo tarda en procesar la solicitud y el retraso del envío de la respuesta si se configura en el esclavo. Se recomienda que el tiempo de espera sea igual o superior que el tiempo para transmitir el frame agregado al retraso del envío de la respuesta y a dos veces el tiempo de procesamiento de la solicitud. Para obtener más información, consulte el capítulo Desempeño de Comunicación. Maximum number of retries: Establece el número de reintentos antes de informar sobre un error de comunicación. Por ejemplo, si el esclavo no responde a un pedido y el maestro está configurado para enviar tres reintentos, el número del contador de errores se incrementará por 1 unidad al fin de la ejecución de estos tres reintentos. Tras el incremento del error, el proceso de intento de comunicación se reinicia y en el caso de que el número de reintentos se alcance nuevamente, nuevo error se incrementará en el contador. Configuración de los Mapeos – Configuración por Mapeo Simbólico La configuración de los mapeos MODBUS, vista en la Figura 4-13, sigue los parámetros de Tabla 4-24: 68 4. Configuración Figura 4-13. Pantalla de Mapeos de Datos MODBUS Configuración Estándar de Fábrica Descripción Value Variable Nombre de la variable simbólica Posibilidades - Nombre de una variable declarada en programa o GVL Data Type Tipo de dato MODBUS - Coil Escritura(1 bit) Coil Lectura (1 bit) Holding Register Escritura (16 bits) Holding Register Lectura (16 bits) Holding Register – Máscara AND (16 bits) Holding Register – Máscara OR (16 bits) Input Register (16 bits) Input Status (1 bit) Data Initial Address Dirección inicial de los datos MODBUS - 1 a 65536 Data Size Tamaño del dato MODBUS - 1 a 65536 Data Range Franja de direcciones del dato configurado - - Tabla 4-24. Configuración de los Mapeos MODBUS Notas: Value Variable: Ese campo especifica una variable simbólica en la relación MODBUS. Data type: Ese campo especifica el tipo de dato utilizado en la relación MODBUS. Tipo de Dato Writing Coil Tamaño [bits] Descripción 1 Salida digital de escritura Reading Coil 1 Salida digital de lectura Writing Holding Register 16 Salida analógica de escritura Reading Holding Register 16 Salida analógica de lectura Holding Register with AND mask 16 Salida analógica que se puede leer o escribir con máscara AND Holding Register with OR mask 16 Salida analógica que se puede leer o escribir con máscara OR 69 4. Configuración Input Register 16 Entrada analógica que se puede solamente leer Input Status 1 Entrada digital que se puede solamente leer Tabla 4-25. Tipos de Datos Soportados en MODBUS RTU Maestro Data Initial Address: Dirección inicial del dato de un mapeo MODBUS. Data Size: El Tamaño especifica la cantidad máxima de datos que una relación MODBUS puede acceder, desde la dirección inicial. Por lo tanto, para leer una gama continua de direcciones, es necesario que todas las direcciones se declaren en una sola relación. Ese campo varía con el tipo de datos MODBUS configurado. Data Range: Ese campo muestra al usuario la franja de direcciones de memoria utilizada por la relación MODBUS. Configuración de las Solicitudes – Configuración por Mapeo Simbólico La configuración de las solicitudes MODBUS, vista en la Figura 4-14, sigue los parámetros descritos en la Tabla 4-26: Figura 4-14. Pantalla de Solicitudes de Datos MODBUS Maestro Configuración Descripción Estándar de Fábrica Posibilidades 01 – Lectura de Coils 02 – Lectura de Input Status 03 – Lectura de Holding Registers 04 – Lectura de Input Registers 05 – Escritura de un Coil 06 – Escritura de un Register 15 – Escritura de Múltiple Coils 16 – Escritura de Múltiple Registers 22 – Escritura Mascarada de Register 23 – Lectura/Escritura de Múltiple Register Function Code Tipo de función MODBUS - Scan (ms) Período de comunicación (ms) 100 Initial Address of the Read Data Dirección inicial de los datos de lectura MODBUS - 70 0 a 3600000 1 a 65536 4. Configuración Read Data Size Tamaño de los dados de lectura MODBUS - Depende de la función utilizada Read Data Range Franja de dirección de los datos de lectura MODBUS - 0 a 2147483646 Initial Address of the Write Data Dirección inicial de los datos de escritura MODBUS - 1 a 65536 Write Data Size Tamaño de los dados de escritura MODBUS - Depende de la función utilizada Write Data Range Franja de dirección de los datos de escritura MODBUS - 0 a 2147483647 Diagnostic Variable Nombre de la variable de diagnóstico - Nombre de una variable declarada en programa o GVL - Campo destinado a variable simbólica utilizada para deshabilitar, individualmente, las solicitudes MODBUS configuradas. Esta variable debe ser del tipo BOOL. La variable puede ser simple o elemento de array y puede estar en estructuras. Disabling Variable Variable utilizada para deshabilitar la relación MODBUS Tabla 4-26. Configuración de las Relaciones MODBUS Maestro Notas: Setting: El número de configuraciones, estándar de fábrica y los valores de la columna posibilidades, pueden variar según el tipo de dato y función MODBUS (FC). Function Code: Las funciones MODBUS (FC) disponibles son: Tipo de Función Access to Variables Código Descripción DEC HEX 1 0x01 Read coils (FC 01) 2 0x02 Read input status (FC 02) 3 0x03 Read holding registers (FC 03) 4 0x04 Read input registers (FC 04) 5 0x05 Write coil (FC 05) 6 0x06 Write holding register (FC 06) 15 0x0F Write multiple coils (FC 15) 16 0x10 Write holding registers (FC 16) 22 0x16 Register write mask (FC 22) 23 0x17 Read/Write holding registers (FC 23) Tabla 4-27. Funciones MODBUS Soportadas por UCPs Nexto Scan: Este parámetro indica la frecuencia de la comunicación establecida por esta solicitud. Cuando se finaliza la comunicación se aguarda un tiempo igual al configurado en este campo y e, después, se ejecutada una nueva comunicación. Initial Address of the Read Data: Campo destinado a dirección inicial de los datos de lectura MODBUS. Read Data Size: El valor mínimo para el tamaño de los datos de lectura es 1 y el valor máximo depende de la función MODBUS (FC) utilizada, conforme abajo: Read Coils (FC 1): 2000 Read Input Status (FC 2): 2000 Read Holding Registers (FC 3): 125 Read Input Registers (FC 4): 125 Read/Write Holding Registers (FC 23): 121 71 4. Configuración Read Data Range: Ese campo muestra la franja de datos de lectura MODBUS configurada para cada solicitud. La dirección inicial de lectura, sumado al tamaño del dato de lectura resultará en la franja de datos de lectura de cada una de las solicitudes. Initial Address of the Write Data: Campo destinado a dirección inicial de los datos de escritura MODBUS. Write Data Size: El valor mínimo para el tamaño de los dados de escritura es 1 y el valor máximo depende de la función MODBUS (FC) utilizada, conforme abajo: Write Single Coil (FC 5): 1 Write Single Holding Registers (FC 6): 1 Write Multiple Coils (FC 15): 1968 Write Holding Registers (FC 16): 123 Register Write Mask (FC 22): 1 Read/Write Holding Registers (FC 23): 121 Write Data Range: Ese campo muestra la franja de datos de escritura MODBUS configurada para cada solicitud. La dirección inicial de escritura, sumado al tamaño del dato de escritura resultará en la franja de datos de lectura de cada una de las solicitudes. Diagnostic Variable: Los diagnósticos de la solicitud MODBUS configurada, sea por mapeo simbólico o por representación directa, se almacenan en variables del tipo T_DIAG_MODBUS_RTU_MAPPING_1 y para el mapeo por representación directa están en 4 bytes e 2 words, los cuales se describen en la Tabla 4-28 (n es el valor configurado en el campo Dirección Inicial de Diagnósticos en %Q). Variable de Representación Directa Variable de diagnóstico tipo T_DIAG_MODBUS_RTU_MAPPING_1.* Tamaño Descripción Bits de estado de la comunicación: %QX(n).0 bCommIdle BIT Comunicación inactiva (a la espera de ser constada) %QX(n).1 bCommExecuting BIT Comunicación activa bCommPostponed BIT Comunicación postergada, porque el número máximo de solicitudes simultáneas se alcanzó. Las comunicaciones postergadas se ejecutarán en el mismo orden en el que fueron solicitados para evitar la indeterminación. El tiempo de permanencia en este estado no se cuenta para efectos de time-out. Los bits bCommIdle y bCommExecuting son falsos cuando el bit bCommPostponed es verdadero. bCommDisabled BIT Comunicación desactivada. El bit bCommIdle es reiniciado en esta condición. bCommOk BIT Comunicación completada previamente se ha realizado con suceso. bCommError BIT Falla en la comunicación completada previamente. Verificar código de error. bCommAborted BIT No utilizado en el MODBUS Maestro RTU. bDiag_7_reserved BIT Reservado %QX(n).2 byStatus.* %QX(n).3 %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 Último código de error (habilitado cuando bCommError = verdadero): %QB(n+1) MASTER_ERROR_CODE (BYTE) eLastErrorCode 72 Informa a la posible causa del último error producido en la interfaz MODBUS. Ver la Tabla 4-29 para los detalles de las posibilidades. 4. Configuración Último código de excepción recibido por el maestro: %QB(n+2) eLastExceptionCode %QB(n+3) byDiag_3_reserved MODBUS_EXCEPTION (BYTE) NO_EXCEPTION (0) FUNCTION_NOT_SUPPORTED (1) MAPPING_NOT_FOUND (2) ILLEGAL_VALUE (3) ACCESS_DENIED (128)* MAPPING_DISABLED (129)* IGNORE_FRAME (255)* Estadísticas de comunicación: BYTE Reservado %QW(n+4) wCommCounter WORD Contador de comunicaciones completadas, con o sin errores. El usuario puede testear cuando la comunicación se ha completado testeando la variación de ese contador. Cuando el valor 65535 se completa, el contador vuelve a cero. %QW(n+6) wCommErrorCounter WORD Contador de comunicaciones completadas con errores. Cuando el valor 65535 se completa, el contador vuelve a cero. Tabla 4-28. Diagnósticos de las relaciones MODBUS Exception Codes: Los códigos de excepción presentados en este campo son los valores retornados por el esclavo. Las definiciones de los códigos de excepción 128, 129 y 255, presentadas en esa tabla, son válidas solo en la utilización de esclavos Altus. Para esclavos de otros fabricantes, esos códigos de excepción pueden tener significados diferentes. Disabling Variable: Campo destinado a la variable de tipo booleana utilizada para desactivar individualmente las solicitudes MODBUS configuradas en la pestaña Solicitudes a través del botón en la parte inferior de la ventana. La solicitud se desactiva cuando la variable, correspondiente a la solicitud, es igual a 1, de lo contrario, la solicitud está habilitada. Last Error Code: Los códigos de las posibles situaciones que conllevan a error en la comunicación MODBUS se pueden consultar a continuación: Código Enumerable Descripción Respuesta reportada en un código de excepción (ver eLastExceptionCode = Código de Excepción). 1 ERR_EXCEPTION 2 ERR_CRC 3 ERR_ADDRESS Dirección MODBUS no encontrada. La dirección que respondió a la solicitud ha sido diferente a lo esperado. 4 ERR_FUNCTION Código inválido de la función. La función recibida en la respuesta ha sido diferente a la esperada por la solicitud. 5 ERR_FRAME_DATA_COUNT Respuesta con CRC inválido. La cantidad de datos de la respuesta ha sido diferente a lo esperado. 7 ERR_NOT_ECHO 8 ERR_REFERENCE_NUMBER Respuesta no es eco de la pregunta (FC 5 y 6). Número de referencia inválido (FC 15 y 16). 9 ERR_INVALID_FRAME_SIZE Respuesta menor que la esperada. 21 ERR_SEND Error durante la fase de transmisión. 22 ERR_RECEIVE 41 ERR_SEND_TIMEOUT Erro durante la fase de recepción. 42 ERR_RECEIVE_TIMEOUT Time-out en el nivel de aplicación mientras aguarda respuesta. 43 ERR_CTS_OFF_TIMEOUT Time-out mientras aguarda CTS = falso en la transmisión. 44 ERR_CTS_ON_TIMEOUT Time-out mientras aguarda CTS = verdadero en la transmisión. 128 NO_ERROR Time-out en el nivel de aplicación durante la transmisión. Sin error desde la inicialización. Tabla 4-29. Diagnósticos de las relaciones MODBUS 73 4. Configuración ATENCIÓN: A diferencia de otras tareas de una aplicación, cuando se alcance una marca de depuración en la MainTask, la tarea de una instancia MODBUS RTU Maestro, y cualquier otra tarea MODBUS, dejará de ejecutarse en el momento en que intente llevar a cabo una escritura en un área de memoria. Esto ocurre con el fin de mantener la consistencia de los datos de las áreas de memoria mientras que no se esté ejecutando MainTask. Configuración del Protocolo MODBUS Maestro por Representación Directa (%Q) Para configurar este protocolo mediante uso de representación directa (%Q), es necesario ejecutar los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS Maestro, tales como: tiempos de comunicación y variables de representación directa (%Q) para recibir los diagnósticos. Las descripciones de cada configuración están relacionadas a continuación en este capítulo. Añadir y configurar dispositivos, estableciendo dirección, variables de representación directa (%Q) para desactivar las relaciones, time-outs y número de reintentos de comunicación. Añadir y configurar relaciones MODBUS, especificando el tipo de dato e función MODBUS, time-outs, variables de representación directa (%Q) para recibir los diagnósticos de la relación y otras para recibir/escribir los datos, cuantidad de datos a comunicar y polling de la relación. Las descripciones de cada configuración están relacionadas a continuación en este capítulo. Parámetros Generales del Protocolo MODBUS Maestro – Configuración por Representación Directa (%Q) Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS (Figura 4-15), se definen como: Figura 4-15. Pantalla de Configuración MODBUS RTU Maestro Variables de representación directa (%Q) para los diagnósticos del protocolo: 74 4. Configuración Descripción Estándar de Fábrica Posibilidades Initial Address of Diagnostics in %Q Dirección inicial de las variables de diagnóstico - 0 a 2147483628 Size Tamaño de la área de diagnósticos 20 Deshabilitado para edición Configuración Tabla 4-30. Configuraciones Notas: Initial Address of Diagnostics in %Q: Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede establecer para el campo Dirección Inicial de Diagnósticos en %Q, pues la creación de una instancia del protocolo se puede realizar en cualquier momento en el desarrollo de la aplicación, haciendo con que el propio software MasterTool IEC XE ubique un valor, de la franja de variables de salida de representación directa (%Q), aún no utilizado. Los diagnósticos y comandos del protocolo MODBUS y se describen en la Tabla 4-22. Los tiempos de comunicación del protocolo MODBUS Maestro, encontrados en el botón “Avanzado...” de la pantalla de configuración, se dividen en Retraso de Envío e Interframe Mínimo. Más detalles se describen en la sección Parámetros Generales del Protocolo MODBUS Maestro – Configuración por Mapeo Simbólico. Configuración de los Dispositivos – Configuración por Representación Directa (%Q) La configuración de los dispositivos esclavos, vistos en la Figura 4-16, siguen los parámetros a continuación: Figura 4-16. Configuraciones del Dispositivo Configuración Descripción Estándar de Fábrica Posibilidades MODBUS_Device Identificador, según la IEC 61131-3 Name Nombre de la instancia Slave Address Dirección del esclavo MODBUS 1 0 a 255 Communication Time-out (ms) Define el time-out del nivel de aplicación 1000 10 a 65535 75 4. Configuración Maximum Number of Retries Define el número de intentos antes de reportar un error de comunicación 2 0a9 Mapping Disabling Dirección inicial utilizada para deshabilitar las relaciones MODBUS - 0 a 2147483644 Tabla 4-31. Configuraciones Notas: Instance Name: Ese campo es el identificador del dispositivo, el cual se verifica según la IEC 61131-3, es decir, no permite espacios, caracteres especiales e iniciar con carácter numeral. Es limitado en 24 caracteres. Mapping Disabling: Compuesto por 32 bits, utilizados para deshabilitar, individualmente, las 32 relaciones MODBUS configuradas en el campo Mapeo del Dispositivo. La relación se deshabilita cuando el bit, correspondiente a la relación, es igual a 1, en caso contrario, el mapeo está habilitado. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica - Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede definir para el campo Deshabilitación de los Mapeos, pues la creación de una instancia del protocolo se puede realizar a cualquier momento en el desarrollo del aplicativo, lo que hace con que el propio software MasterTool IEC XE determine un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. Más detalles de los parámetros Dirección del Esclavo, Time-out de Comunicación y Número máximo de reintentos se pueden encontrar en la sección Configuración de los Dispositivos – Configuración por Mapeo Simbólico. Configuración de los Mapeos – Configuración por Representación Directa (%Q) La configuración de las relaciones MODBUS, vistas en la Figura 4-17 y Figura 4-18, siguen los parámetros descritos en la Tabla 4-33: Figura 4-17. Tipo de Dato MODBUS 76 4. Configuración Figura 4-18. Función MODBUS En la Tabla 4-32, el número de configuraciones, estándar de fábrica y los valores de la columna posibilidades, pueden variar de acuerdo con el tipo de dato y función MODBUS (FC). Configuración Descripción Estándar de Fábrica Posibilidades Function Tipo de función MODBUS Leer Leer Escribir Leer/Escribir Máscara de Escritura Polling (ms) Periodo de comunicación (ms) 100 0 a 3600000 Mapping Diagnostics Area Dirección inicial de los diagnósticos de la relación MODBUS (%Q) - 0 a 2147483640 Read Data Start Address Dirección inicial de los datos de lectura MODBUS 1 1 a 65536 Read Data Size Número de datos de lectura MODBUS - 0 a 2147483646 Read IEC Variable Dirección inicial de las variables de lectura (%I) - 1 a 65536 Write Data Start Address Dirección inicial de los datos de escritura MODBUS 1 0 a 2147483646 Write Data Size Número de datos de escritura MODBUS - Depende de la función utilizada Write IEC Variable Dirección inicial de las variables de escritura (%Q) - 0 a 2147483647 Write Mask of IEC Variables Dirección inicial de las variables para la máscara de escritura (%Q) - 0 a 2147483644 Tabla 4-32. Mapeos del Dispositivo Notas: Function: Los tipos de datos están detallados en la Tabla 4-25. Las funciones MODBUS (FC) están disponibles en la Tabla 4-27. Polling: Este parámetro indica con qué frecuencia la comunicación definida por esta relación se debe ejecutar. Al finalizar una comunicación se aguardará un tiempo igual al polling configurado y, enseguida, se ejecutará una nueva comunicación lo más rápido posible. Mapping Diagnostics Area: Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción 77 4. Configuración Técnica – Características Específicas. Los diagnósticos de la relación MODBUS configurada están descritos na Tabla 4-28. Read/Write Data Size: Detalles del tamaño de los dados soportados por cada función se describe en las notas de la sección Configuración de las Solicitudes – Configuración por Mapeo Simbólico. Read IEC Variable: sea Coil o Input Status (bit), la dirección inicial de las variables IEC de lectura tendrá el formato %IX.X. Sin embargo, si el tipo de dato MODBUS es Holding Register o Input Register (16 bits), la dirección inicial de las variables IEC de lectura tendrá el formato %IW. Ese campo se limita por el tamaño de la memoria de variables de entrada direccionables (%I) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Write Mask : Caso el tipo de dato MODBUS sea Coil, la dirección inicial de las variables IEC de escritura tendrá el formato, por ejemplo, %QX10.1. Sin embargo, si el tipo de dato MODBUS es Holding Register (16 bits la dirección inicial de las variables IEC de escritura tendrá el formato %QW. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Default Value: La función Máscara de Escritura (FC 22), a través de una lógica entre el valor ya escrito y las 2 words configuradas en este campo, siendo %QW(0) para la máscara AND y %QW(2) para la máscara OR; permite al usuario manejar la word. Este campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede definir para los campos Área de Diagnósticos del Mapeo, Variables IEC de Lectura, Variable IEC de Escritura y Máscara de Escritura de las Variables IEC, pues la creación de una relación se puede realizar en cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE ubique un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. El estándar de fábrica no se puede definir para los campos Tamaño de Datos de Lectura y Tamaño de Datos de Escritura, pues variarán según el tipo de dato MODBUS seleccionado. ATENCIÓN: Diferentemente de otras tareas de una aplicación, al alcanzar una marca de depuración en MainTask, la tarea de una instancia MODBUS RTU Maestro, y cualquier otra tarea MODBUS, parará de ejecutarse en el momento en que intente efectuar una escritura en un área de memoria. Esto ocurre para mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté en ejecución. MODBUS RTU ESCLAVO Este protocolo está disponible para las UCPs de la Serie Nexto en sus canales seriales. Al seleccionar esta opción en el MasterTool IEC XE, la UCP pasa a ser esclavo de la comunicación MODBUS, lo que permite la conexión con dispositivos maestro MODBUS RTU. Este protocolo solamente está disponible cuando la UCP está en modo de ejecución (Modo Run). Hay dos formas de configuración para este protocolo. Uno de ellos hace uso de representación directa (% Q), en la cual las variables se definen por su dirección. El otro, llamado Mapeo Simbólico, tiene las variables definidas por su nombre. Independiente del modo de configuración, los pasos para insertar una instancia del protocolo y configurar la interfaz serial son iguales. El procedimiento para insertar una instancia del Protocolo se encuentra en detalle en Manual de Usuario MasterTool IEC XE – MU299800 o en el capítulo Insertando una Instancia de Protocolo. Los demás pasos de configuración se describen a continuación para cada modalidad. Añadir la instancia del protocolo MODBUS RTU Esclavo al canal serial COM 1 o COM 2 (o ambos, en caso de dos redes de comunicación). Para realizar dicho procedimiento, consultar el capítulo Insertando una Instancia de Protocolo 78 4. Configuración Configurar la interfaz serial, elegir la velocidad de comunicación, el comportamiento de las señales RTS/CTS, la paridad, los bits de parada del canal, entre otros. Consultar el capítulo Configuración – Configuración de las Interfaces Seriales. Configuración del Protocolo MODBUS Esclavo por Mapeo Simbólico Para configurar este protocolo usando Mapeo Simbólico, es necesario ejecutar los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS esclavo, tales como: dirección del esclavo y tiempos de comunicación (disponible en el botón configuración avanzada del esclavo). Agregar y configurar las relaciones de MODBUS, especificando el nombre de la variable, tipo de dato MODBUS, la dirección inicial del dato. Automáticamente el tamaño del dato y el rango según el tipo de la variable declarada se rellenan. Parámetros Generales del Protocolo MODBUS Slave – Configuración por Mapeo Simbólico Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS se muestran como en la Figura 4-19. Figura 4-19. Configuración del Esclavo Configuración Slave Address Descripción Dirección del esclavo MODBUS Estándar de Fábrica Posibilidades 1 1 a 255 Tabla 4-33. Configuraciones del Esclavo Los tiempos de comunicación del Protocolo MODBUS esclavo, encontrados en el botón "Avanzado...", de la pantalla de configuración, se dividen en: Ciclo da Tarea, Retraso del Envío e Interframe Mínimo como se puede ver visto en la Figura 4-20 y en la Tabla 4-34. Figura 4-20. Configuraciones Avanzadas Modbus del Esclavo Configuración Task Cycle (ms) Descripción Estándar de Fábrica Posibilidades Tiempo para ejecución de la instancia dentro del ciclo, sin considerar el tiempo de ejecución de la misma 50 20 a 100 79 4. Configuración Send Delay (ms) Tiempo de retraso para envío de la respuesta Minimum Interframe (chars) Tiempo mínimo de silencio entre diferentes frames 0 0 a 65535 3.5 3.5 a 100.0 Tabla 4-34. Configuraciones Avanzadas Modbus Esclavo Notas: Task Cycle: El usuario debe tener cuidado al cambiar este parámetro, porque interfiere directamente en el tiempo de respuesta, volumen de datos por escaneo y, principalmente, en el equilibrio de los recursos de la UCP entre comunicación y otras tareas. Send Delay: La respuesta a una solicitud MODBUS puede causar problemas en ciertos momentos, como, por ejemplo en la interfaz RS-485 u otra half-duplex. A veces hay un retraso entre el momento de la solicitud del maestro y el silencio en la línea física (retardo en el maestro para poner RTS en cero y poner el transmisor RS-485 en alta impedancia). Para resolver el problema, el esclavo puede esperar los plazos establecidos en el campo antes de enviar la respuesta. De lo contrario, los primeros bytes transmitidos por el esclavo durante la respuesta, pueden perderse. Minimum Interframe: El estándar MODBUS establece este tiempo como 3,5 caracteres, pero este parámetro es configurable para cumplir con los dispositivos que no estén según la norma. Los diagnósticos y los comandos del protocolo MODBUS Esclavo configurado, sea por mapeo simbólico o por representación directa, se almacenan en variables de tipo T_DIAG_MODBUS_RTU_SLAVE_1 y para el mapeo por representación directa es 4 bytes y 8 words, que se describen en la Tabla 4-35 (n es el valor configurado en el campo Dirección de inicial de Diagnósticos en % Q): Variable de Representación Directa Variable de diagnósticos del tipo T_DIAG_MODBUS_RTU_SLAVE_1 *. Tamaño Descripción Bits de Diagnóstico: %QX(n).0 bRunning BIT El esclavo se está ejecutando %QX(n).1 bNotRunning BIT El esclavo no se está ejecutando (vea bit: bInterruptedByCommand). %QX(n).2 bInterruptedByCommand BIT El bit bNotRunning se ha habilitado, pues el esclavo fue detenido por el usuario a través de los bits de comando. bConfigFailure BIT Diagnóstico descontinuado %QX(n).4 bRXFailure BIT Diagnóstico descontinuado %QX(n).5 bTXFailure BIT Diagnóstico descontinuado %QX(n).6 bModuleFailure BIT Diagnóstico descontinuado %QX(n).7 bDiag_7_reserved BIT Reservado %QX(n).3 tDiag.* Códigos de Error: %QB(n+1) SERIAL_STATUS (BYTE) eErrorCode 80 0: no hay errores. 1: puerta serial no válida. 2 :modo de la puerta serial no válido 3: baud rate no válido. 4: data bits no válido. 5: paridad no válida. 6: stop bits no válido. 7: parámetro de señal de modem no válido. 8: parámetro de Threshold de RX da UART no válido. 4. Configuración Variable de Representación Directa Variable de diagnósticos del tipo T_DIAG_MODBUS_RTU_SLAVE_1 *. Tamaño Descripción 9: parámetro de time-out no válido. 10: puerta serial ocupada. 11: error de hardware en la UART. 12: error de hardware remoto. 20: tamaño de buffer de transmisión no válido. 21: método de señal de modem no válido. 22: time-out de CTS = verdadero. 23: time-out de CTS = falso. 24: error de time-out en la transmisión. 30: tamaño del buffer de recepción no válido. 31: error de time-out en la recepción. 32: control de flujo configurado diferente de manual. 33: controle de flujo inválido para a porta serial configurada. 34: recepción de datos no permitida en modo normal. 35: recepción de datos no permitida en modo extendido. 36: interrupción DCD no permitida. 37: interrupción CTS no permitida. 38: interrupción DSR no permitida. 39: puerta serial no configurada. 50: error interno en la puerta serial Bits de comando, reiniciados automáticamente: %QX(n+2).0 bStop BIT Parar el esclavo %QX(n+2).1 bRestart BIT Reiniciar el esclavo bResetCounter BIT Reiniciar las estadísticas de los diagnósticos (contadores) bDiag_19_reserved BIT Reservado %QX(n+2).4 bDiag_20_reserved BIT Reservado %QX(n+2).5 bDiag_21_reserved BIT Reservado %QX(n+2).6 bDiag_22_reserved BIT Reservado %QX(n+2).7 bDiag_23_reserved BIT Reservado BYTE Reservado %QX(n+2).2 %QX(n+2).3 %QB(n+3) tCommand.* byDiag_03_reserved Estadísticas de Comunicación: %QW(n+4) wRXRequests WORD Contador de solicitudes normales recibidas por el esclavo y respondidas normalmente. En el caso de un comando broadcast, este contador se incrementa, pero no transmite la respuesta (0 a 65535). WORD Contador de solicitudes normales recibidas por el esclavo y respondidas con códigos de excepción En el caso de un comando broadcast, este contador se incrementa, pero no transmite la respuesta (0 a 65535). Códigos de excepción: 1: el código de la función (FC) es legal, pero no es soportado. 2: relación no encontrada en estos datos MODBUS. tStat.* %QW(n+6) wTXExceptionResponses 81 4. Configuración Variable de Representación Directa Variable de diagnósticos del tipo T_DIAG_MODBUS_RTU_SLAVE_1 *. Tamaño Descripción 3: valor ilegal para la dirección. 128: el maestro/cliente no tiene derecho de escritura o lectura. 129: la relación MODBUS está desactivada. %QW(n+8) %QW(n+10) wRXFrames wRXIllegalRequests WORD Contador de frames recibidos por el esclavo. Se considera frame algo que se procesa y sigue por un período de silencio interframes (interframe mínimo), es decir, un mensaje ilegal también se computa (0 a 65535). WORD Contador de solicitudes ilegales. Estos son frames que inician con la dirección 0 (broadcast) o con la dirección MODBUS del esclavo, pero no son solicitudes legales sintaxis no válida, frames menores, CRC no válido – (0 a 65535). %QW(n+12) wRXOverrunErrors WORD Contador de frames con errores de overrun durante la recepción– UART FIFO o fila RX – (0 a 65535). %QW(n+14) wRXIncompleteFrames WORD Contador de frames con errores de construcción, paridad o falla durante la recepción (0 a 65535). %QW(n+16) wCTSTimeOutErrors WORD Contador de errores de time-out en el CTS, utilizando el handshake RTS/CTS, durante la transmisión (0 a 65535). %QW(n+18) wDiag_18_reserved WORD Reservado Tabla 4-35. Diagnósticos MODBUS RTU Esclavo Nota: Contadores: Todos los contadores de los diagnósticos de MODBUS RTU esclavo vuelven a cero cuando el valor límite 65535 sobrepasa. Configuración dos Mapeos – Configuración por Mapeo Simbólico La configuración de los mapeos MODBUS, visualizadas sigue os parámetros descritos en la Tabla 4-36: Figura 4-21. Pantalla de Mapeos de Datos MODBUS Configuración Value Variable Data Type Descripción Nombre de la variable simbólica Tipo de dato MODBUS 82 Estándar de Fábrica Posibilidades - Nombre de una variable declarada en un programa o GVL - Coil (1 bit) Input Status (1 bit) Holding Register (16 bits) Input Register (16 bits) 4. Configuración Data Start Address Dirección inicial de los datos MODBUS - 1 a 65536 Data Size Tamaño del dato MODBUS - 1 a 65536 Franja de direcciones del dato configurado - - Data Range Tabla 4-36. Configuración de los Mapeos MODBUS Notas: Variable Value: Ese campo se utiliza para especificar una variable simbólica en la relación MODBUS. Data Type: Ese campo se utiliza para especificar el tipo de utilizado en la relación MODBUS. Tipo de Dato Coil Tamaño [bits] Descripción 1 Salida digital que se puede leer o escribir. Input Status 1 Entrada digital que solamente se puede leer. Holding Register 16 Salida analógica que se puede leer o escribir. Input Register 16 Entrada analógica que solamente se puede leer. Tabla 4-37. Tipos de Datos Soportados por el MODBUS RTU Esclavo Data Start Address: Dirección inicial del dato de una relación MODBUS. Data Size: El valor de tamaño especifica la cantidad máxima de datos que una relación MODBUS puede acceder, desde la dirección inicial. Por lo tanto, para leer un rango de direcciones continua, es necesario que todas las direcciones estén declaradas en una sola relación. Ese campo varía con el tipo de datos MODBUS configurado. Data Range: Ese campo muestra al usuario el rango de direcciones de memoria utilizado por la relación MODBUS. ATENCIÓN: A diferencia de otras tareas de una aplicación, cuando se alcance una marca de depuración en la MainTask, la tarea de una instancia MODBUS RTU esclavo y cualquier otra tarea MODBUS, dejará de ejecutarse en el momento en que intente llevar a cabo una escritura en un área de memoria. Esto ocurre con el fin de mantener la consistencia de los datos de las áreas de memoria mientras que no se esté ejecutando MainTask. Configuración del Protocolo MODBUS Esclavo por Representación Directa (%Q) Para configurar este protocolo usando Representación Directa (%Q), es necesario ejecutar los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS esclavo, tales como: tiempos de comunicación, dirección y variables de representación directa (% Q) para recibir los diagnósticos y controlar las relaciones. Agregar y configurar relaciones MODBUS, especificando el tipo de datos MODBUS, variables de representación directa (% Q) para recibir y escribir los datos y la cantidad de datos a comunicar. Las descripciones de cada configuración se relacionan a seguir, en este capítulo. Parámetros Generales del Protocolo MODBUS Esclavo – Configuración por Representación Directa (%Q) Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo (Figura 4-22), se definen como: 83 4. Configuración Figura 4-22. Pantalla de Configuración MODBUS RTU Esclavo Dirección, Variables de representación directa (%Q) para controlar las relaciones y los diagnósticos: Configuración Descripción Estándar de Fábrica Posibilidades %Q Start Address of diagnosticsArea Dirección inicial de las variables de diagnóstico - 0 a 2147483628 Size Tamaño de la área de diagnósticos - Deshabilitado para edición Slave Address Dirección del esclavo MODBUS 1 1 a 255 Mapping Disabling Dirección inicial utilizada para deshabilitar las relaciones MODBUS - 0 a 2147483644 Tabla 4-38. Configuraciones Notas: %Q Start Address of DiagnosticsArea: Ese campo está limitado por el tamaño de memoria de variables de salidas direccionables (% Q) de cada UCP, la cual se puede encontrar en el capítulo Descripción Técnica – Características Específicas. Slave Address: Es importante destacar que el esclavo acepta solicitudes broadcast, cuando el maestro envía un comando con la dirección configurada a cero. Además, de acuerdo con el estándar MODBUS, el rango de direcciones válidas para esclavos es 1 a 247, siendo las direcciones 248 a 255 reservadas. Mapping Disabling: Compuesto por 32 bits, utilizados para desactivar, individualmente, las 32 relaciones MODBUS configuradas en el espacio Mapeos del Esclavo. La relación se desactiva cuando el bit, correspondiente a relación, es igual a 1, de lo contrario, el mapeo está habilitado. Ese campo está limitado por el tamaño de memoria de variables de salidas direccionables (% Q) de cada UCP, la cual se puede encontrar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede establecer para los campos Dirección Inicial de Diagnóstico en % Q y Desactivación de los Mapeos, pues la creación una instancia del protocolo podrá realizarse a cualquier momento en el desarrollo del aplicativo, haciendo el propio software MasterTool IEC XE asigne un valor del rango de variables de salida de representación directa (% Q), aún sin usar. 84 4. Configuración Los diagnósticos y comandos de protocolo MODBUS y se describen en la Tabla 4-35. Los tiempos de comunicación del protocolo MODBUS Esclavo, encontrados en el botón “Avanzado...” de la pantalla de configuración, se describen en la Tabla 4-34. Configuración de los Mapeos – Configuración por Representación Directa (%Q) La configuración de las relaciones MODBUS visualizada en las Figura 4-23 y Figura 4-24, sigue los parámetros descritos em Tabla 4-39: Figura 4-23. Añadir Relaciones MODBUS Figura 4-24. Configuración de la Relación MODBUS Configuración Descripción Estándar de Fábrica Posibilidades Data Type Tipo de dato MODBUS Coil Coil (1 bit) Holding Register (16 bits) Input Status (1 bit) Input Register (16 bits) Data Start Address Dirección inicial de los datos MODBUS 1 1 a 65536 Data Size Número de datos MODBUS - 1 a 65536 IEC Variable Dirección inicial de las variables (%Q) - 0 a 2147483647 Read Only Solamente permite la lectura Deshabilitada Habilitada o Deshabilitada Tabla 4-39. Mapeos del Esclavo 85 4. Configuración Notas: Posibilidades: Los valores descritos en la columna Posibilidades pueden variar según el tipo de dato MODBUS configurado. Data Size: El valor de tamaño del dato define la cantidad máxima de datos que una relación MODBUS podrá acceder, a partir de la dirección inicial. De esta forma, para leer una franja de direcciones continua, es necesario que todas las direcciones estén declaradas en una única relación. Ese campo cambia según el tipo de dato MODBUS configurado, es decir, cuando seleccionado tipo Coil o Input Status, el campo Tamaño del Dato debe ser un número múltiple de ocho. También se debe tener en cuenta que el valor máximo no sea superior al tamaño de la memoria de salidas direccionables y que no se atribuyan los mismos valores ya utilizados durante la aplicación. IEC Variable: En caso de que el tipo de dato MODBUS sea Coil o Input Status (bit), la dirección inicial de las variables IEC tendrá el formato, por ejemplo %QX10.1. Sin embargo, si el tipo de dato MODBUS es Holding Register o Input Register (16 bits), la dirección inicial de las variables IEC tendrá el formato %QW. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Read-only: Cuando habilitada, solamente permite que el maestro de la comunicación lea los datos de las variables, no permite la escritura. Opción válida solamente para las funciones de escritura. Estándar de Fábrica: El estándar de fábrica no se puede definir para el campo Variable IEC, pues la creación de una instancia del protocolo se puede realizar en cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE determine un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. El estándar de fábrica no se puede definir para el campo Tamaño del Dato, pues variará según el tipo de dato MODBUS seleccionado. En las relaciones definidas anteriormente, el tamaño máximo de datos MODBUS puede ser 65535 (máximo valor configurado en el campo Tamaño del Dato). Sin embargo, la pregunta que llega en el MODBUS RTU Esclavo deberá direccionar un subconjunto de ese mapeo y ese grupo debe tener, en lo máximo, el tamaño de datos que depende del código de la función, los cuales están definidos a continuación: Read coils (FC 1): 2000 Read input status (FC 2): 2000 Read holding registers (FC 3): 125 Read input registers (FC 4): 125 Write single coil (FC 5): 1 Write single holding register (FC 6): 1 Force multiple coils (FC 15): 1968 Write holding registers (FC 16): 123 Write register mask (FC 22): 1 Read/ Write holding registers (FC 23): o Read: 121 o Write: 121 ATENCIÓN: Diferentemente de otras tareas de una aplicación, al alcanzar una marca de depuración en MainTask, la tarea de una instancia MODBUS RTU Esclavo, y cualquier otra tarea MODBUS, parará de ejecutarse en el momento en que intente efectuar una escritura en un área de memoria. Esto ocurre para mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté en ejecución. 86 4. Configuración MODBUS Ethernet La red de comunicación multimaestro permite que las UCPs Nexto lean o escriban variables MODBUS en otros controladores o IHMs compatibles con los protocolos MODBUS TCP o MODBUS RTU por TCP. La UCP Nexto puede, simultáneamente, ser cliente y servidor en una misma red de comunicación, o hasta mismo tener más instancias asociadas a la interfaz Ethernet, indiferente si son MODBUS TCP o MODBUS RTU por TCP, según describe la Tabla 4-17. La Figura 4-25 representa algunas de las posibilidades de comunicación al utilizar el protocolo MODBUS TCP simultáneamente con el protocolo MODBUS RTU por TCP. Figura 4-25. Red de Comunicación MODBUS TCP La asociación de variables MODBUS con variables simbólicas de la UCP se realiza por el usuario a través de la definición de relaciones por configurador MasterTool IEC XE. Se pueden definir hasta 32 relaciones para el modo servidor y hasta 128 relaciones para el modo cliente. Una relación, en modo servidor, puede definir una gran área de datos MODBUS y volverla disponible para varios clientes. Las relaciones en modo cliente, por otro lado, deben respetar el tamaño máximo de datos de una función MODBUS: 125 registradores (input registers o holding registers) o 2000 bits (coils o input status). Estas informaciones se plantean con detalles en la descripción de cada protocolo. Todas las relaciones, en modo cliente o servidor, se pueden deshabilitar a través de variables de representación directa (%Q) identificadas como Deshabilitación de los Mapeos por el MasterTool IEC XE. La deshabilitación puede ocurrir a través de bits generales, los cuales afectan todas las relaciones de un modo de operación, o a través de bits específicos, lo que afecta relaciones específicas. Para las relaciones en modo servidor se pueden definir conjuntos de direcciones IPs con permiso de escritura y lectura, llamados filtros. Esto se hace a través de la definición de una dirección de red IP y de una máscara de subred, lo que resulta en un grupo de IPs clientes que pueden escribir y leer en las variables de la relación. Funciones de lectura/escritura no se filtran, es decir, se pueden requerir por 87 4. Configuración cualquier cliente, independiente de la dirección IP. Estas informaciones se plantean con detalles en la descripción del protocolo MODBUS Ethernet Servidor. Cuando el protocolo MODBUS TCP se utiliza, en el modo cliente, se puede disfrutar de la característica de múltiples requerimientos, al utilizar la misma conexión TCP para acelerar la comunicación con los servidores. Cuando no se desea esta característica o no se soporta por el servidor, se puede deshabilitarla (acción en nivel de relación). Es importante resaltar que el número máximo de conexiones TCP entre cliente y servidor es 63, siendo que si algunos parámetros se alteran, comunicaciones inactivas se pueden cerrar, lo que posibilita la apertura de nuevas conexiones. La Tabla 4-40 y la Tabla 4-41 traen, respectivamente, la lista completa de los tipos de datos y funciones MODBUS soportadas por las UCPs Nexto. Tipo de Dato Tamaño [bits] Coil Descripción 1 Salida digital que puede ser leída o escritura. Input Status 1 Entrada digital que puede ser sólo leída. Holding Register 16 Salida analógica que puede ser leída o escritura. Input Register 16 Entrada analógica que puede ser sólo leída. Tabla 4-40. Tipos de Datos MODBUS Soportados por las UCPs Nexto Tipo de Función Variables Access Código Descripción DEC HEX 1 0x01 Coils reading (FC 1) 2 0x02 Input status reading (FC 2) 3 0x03 Holding registers reading (FC 3) 4 0x04 Input registers reading (FC 4) 5 0x05 Coil writing (FC 5) 6 0x06 Holding register writing (FC 6) 15 0x0F Multiple coils writing (FC 15) 16 0x10 Multiples holding registers writing (FC 16) 22 0x16 Writing mask of a holding register (FC 22) 23 0x17 Multiples holding registers reading/writing (FC 23) Tabla 4-41. Funciones MODBUS Soportadas por las UCPs Nexto Independiente del modo de configuración, los pasos para insertar una instancia del protocolo y configurar la interfaz Ethernet son iguales. Los demás pasos de configuración se describen a continuación para cada modalidad. Agregar una o más instancias del protocolo MODBUS Ethernet cliente o servidor para Ethernet al canal NET 1 o NET 2 (o ambas cosas, en el caso de más de una red de comunicación). Para realizar este procedimiento, consulte el capítulo Insertando una Instancia de Protocolo Configurar la interfaz Ethernet. Para realizar este procedimiento, consulte el capítulo Configuración de las Interfaces Ethernet. MODBUS Ethernet Cliente Este protocolo está disponible para las UCPs de la Serie Nexto en los sus canales Ethernet. Al seleccionar esta opción en el MasterTool IEC XE, la UCP pasa a ser cliente de la comunicación MODBUS, lo que posibilita el acceso a otros dispositivos con el mismo protocolo, cuando ésta esté en modo de ejecución (Modo Run). Hay dos formas de configuración para este protocolo. Uno de ellos hace uso de Representación Directa (% Q), en la cual las variables se definen por su dirección. El otro, llamado Mapeo Simbólico, tiene las variables definidas por su nombre 88 4. Configuración El procedimiento para insertar una instancia de protocolo se encuentra en detalles en el de Manual del Usuario Tool IEC XE – MU299800 o en el capítulo Insertando una Instancia de Protocolo Configuración del Protocolo MODBUS Ethernet Cliente por Mapeo Simbólico Para configurar este protocolo usando Mapeo Simbólico, es necesario ejecutar los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS Cliente, con el protocolo TCP o RTU vía TCP. Agregar y configurar los dispositivos, especificando dirección IP, puerta, dirección del esclavo y time-out de comunicación (disponible en el botón de configuraciones avanzadas del Dispositivo). Agregar y configurar los mapeos MODBUS, especificando el nombre de la variable, tipo de datos, dirección inicial del dato, tamaño del dato y variable que recibirá los datos de cualidad. Adicionar e configurar las solicitudes MODBUS, especificando la función que se desea, el tiempo de escaneo de la solicitud, la dirección inicial (Lectura/Escritura), el tamaño de los datos (Lectura/Escritura), la variable recibirá los datos de cualidad, y la variable responsable por deshabilitar la solicitud. Parámetros Generales del Protocolo MODBUS Cliente – Configuración por Mapeo Simbólico Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS (Figura 4-26), se definen como: Figura 4-26. Pantalla de Configuración Parámetros Generales MODBUS Cliente Configuración Connection Mode Descripción Estándar de Fábrica Posibilidades Selección del protocolo TCP RTU vía TCP TCP Tabla 4-42. Configuraciones Generales MODBUS Cliente Los diagnósticos y los comandos del protocolo MODBUS Cliente configurado, sea por mapeo simbólica o por representación directa, se almacenan en variables de tipo T_DIAG_MODBUS_ETH_CLIENT_1 y para el mapeo por representación directa están 4 bytes y 8 word, las cuales se describen en la (n é o valor configurado en el campo Dirección Inicial de Diagnósticos en %Q): Variable de Representación Directa Variable de diagnóstico del tipo T_DIAG_MODBUS_ETH_CLIENT_1.* Tamaño Descripción Bits de Diagnóstico: %QX(n).0 bRunning BIT El cliente se está ejecutando bNotRunning BIT El cliente no se está ejecutando (vea bit bInterruptedByCommand). bInterruptedByCommand BIT El bit de bNotRunning se ha habilitado porque el cliente fue interrumpido por el usuario a través de los bits de comando. %QX(n).3 bConfigFailure BIT Diagnóstico descontinuado %QX(n).4 bRXFailure BIT Diagnóstico descontinuado %QX(n).1 %QX(n).2 tDiag.* 89 4. Configuración Variable de Representación Directa Variable de diagnóstico del tipo T_DIAG_MODBUS_ETH_CLIENT_1.* %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) Tamaño Descripción bTXFailure BIT Diagnóstico descontinuado bModuleFailure BIT Indica se hay falla en el módulo o el módulo no está presente bDiag_7_reserved BIT Reservado BYTE Reservado byDiag_1_reserved Bits de comando, reiniciados automáticamente: %QX(n+2).0 bStop BIT Parar el cliente %QX(n+2).1 bRestart BIT Reiniciar el cliente bResetCounter BIT Reiniciar las estadísticas de los diagnósticos (contadores). bDiag_19_reserved BIT Reservado %QX(n+2).4 bDiag_20_reserved BIT Reservado %QX(n+2).5 bDiag_21_reserved BIT Reservado %QX(n+2).6 bDiag_22_reserved BIT Reservado BIT Reservado BYTE Reservado %QX(n+2).2 %QX(n+2).3 tCommand.* %QX(n+2).7 bDiag_23_reserved %QB(n+3) byDiag_03_reserved Estadísticas de Comunicación: %QW(n+4) wTXRequests WORD Contador de solicitudes transmitidas por el cliente (0 a 65535). %QW(n+6) wRXNormalResponses WORD Contador de respuestas normales recibidas por cliente (0 a 65535). %QW(n+8) wRXExceptionResponses WORD Contador de respuestas con códigos de excepción (0 a 65535). wRXIllegalResponses WORD Contador de respuestas ilegales recibidas por el cliente - sintaxis no válida o número insuficiente de bytes recibidos (0 a 65535). %QW(n+12) wDiag_12_reserved WORD Reservado %QW(n+14) wDiag_14_reserved WORD Reservado %QW(n+16) wDiag_16_reserved WORD Reservado %QW(n+18) wDiag_18_reserved WORD Reservado %QW(n+10) tStat.* Tabla 4-43. Diagnósticos MODBUS Cliente Notas: Contadores: Todos los contadores de los diagnósticos MODBUS TCP cliente vuelven a cero cuando el valor límite 65535 sobrepasa. Configuración de los Dispositivos – Configuración por Mapeo Simbólico La configuración de los dispositivos esclavos, visualizados en la Tabla 4-44, siguen los siguientes parámetros: 90 4. Configuración Figura 4-27. Pantalla de Configuraciones de los Parámetros Generales del Dispositivo Configuración Descripción Estándar de Fábrica Posibilidades IP Address Dirección IP del servidor 0. 0. 0. 0 1.0.0.1 a 223.255.255.254 TCP Port Puerta TCP 502 2 a 65534 Slave Address Dirección del Esclavo MODBUS 1 0 a 255 Tabla 4-44. Configuraciones Generales MODBUS Cliente Notas: IP Address: Dirección IP del dispositivo servidor Modbus. TCP Port: Si hay varias instancias añadidas del protocolo en una sola interfaz Ethernet, diferentes puertas TCP deben seleccionarse para cada instancia. Algunas puertas TCP, entre las posibilidades mencionadas, están reservados y por tanto no se pueden utilizar. Son: 80, 8080, 1217, 1740, 1741, 1742.1743 y 11740. Slave address: Según el estándar MODBUS, el rango de direcciones válido para esclavos es de 0 a 247, siendo las direcciones 248 a 255 reservadas. Cuando el maestro envía un comando de escritura con la dirección configurada a cero, está llevando a cabo las solicitudes de difusión (broadcast) en la red. Los parámetros de la configuración avanzada del dispositivo MODBUS Cliente, encontrados en el botón “Avanzado...” en la pestaña de Parámetros Generales están divididos en: número máximo de solicitudes simultáneas, Time-out de comunicación, modo de tiempo de time-out de conexión y tiempo de inactividad. Configuración Descripción Estándar de Fábrica Posibilidades Maximum Simultaneous Request Número de solicitudes simultáneas que el cliente puede pedir al servidor 1 1a8 Communication Timeout (ms) Time-out de nivel de la aplicación en ms 3000 10 a 65535 Mode Define cuándo el cliente termina la conexión con el servidor La conexión se cierra después de un tiempo de inactividad de (s): 10 a 3600. Connection is closed after a timeout. Connection is closed at the end of each communication. Connection is closed after an inactive time of (s):(10 to 3600) Inactive Time (s) Tiempo de inactividad 10 3600 Tabla 4-45. Configuraciones Avanzadas MODBUS Cliente 91 4. Configuración Notas: Maximum Simultaneous Requests : Se utiliza en los servidores con un alto ciclo de escaneo. Este parámetro se establece en 1 (no editable), cuando el protocolo configurado es MODBUS RTU por TCP. Communication Time-out : Es el tiempo de que el cliente espera una respuesta del servidor a la solicitud. Para un dispositivo MODBUS cliente, dos variables del sistema se deben considerar: el tiempo que tarda el servidor para procesar la solicitud y el retardo de envío de la respuesta si se ha configurado en el servidor. Se recomienda que el time-out es igual o mayor que el doble de la suma de estos parámetros. Para más informaciones, vea el capitulo Desempeño de Comunicación. Mode: Define cuándo se cierra la conexión al servidor por el cliente. Opciones: Connection is closed after an time-out or Connection is never closed in normal situations: Estas opciones presentan el mismo comportamiento del Cliente al cerrar la conexión debido al hecho de que el Servidor no haya respondido a una solicitud antes del Time-out de Comunicación haberse agotado. Connection is closed at the end of each communication: La conexión es cerrada por el Cliente tras concluir cada solicitud. Connection is closed after Inactive Time: La conexión se cerrará por el Cliente en el caso de que quede por un tiempo igual al Tiempo de Inactividad sin que realice solicitud para el Servidor. Inactive Time: Tiempo de inactividad de la conexión. Configuración de los Mapeos – Configuración por Mapeo Simbólico La configuración de los mapeos MODBUS Cliente, visualizadas en la Figura 4-28, sigue los parámetros descritos en la Tabla 4-46. Figura 4-28. Pantalla de Mapeos de Datos MODBUS Cliente Configuración Descripción Estándar de Fábrica Posibilidades Value Variable Nombre de la variable simbólica - Nombre de una variable declarada en un programa o GVL - Coil Escritura(1 bit) Coil Lectura (1 bit) Holding Register Escritura (16 bits) Holding Register Lectura (16 bits) Holding Register – Máscara AND (16 bits) Data Type Tipo de dato MODBUS 92 4. Configuración Holding Register – Máscara OR (16 bits) Input Register (16 bits) Input Status (1 bit) Data Start Address Dirección inicial dos de los datos MODBUS - 1 a 65536 Data Size Tamaño del dato MODBUS - 1 a 65536 Franja de direcciones del dato configurado - - Data Range Tabla 4-46. Configuración de los Mapeos MODBUS Cliente Notas: Value Variable: Ese campo se utiliza para especificar una variable simbólica en la relación MODBUS. Data Type: Ese campo se utiliza para especificar el tipo de dato utilizado en la relación MODBUS. Tipo de Dato Tamaño [bits] Coil Write 1 Write digital output Descripción Coil Read 1 Read digital output Holding Register Write 16 Write analog output Holding Register Read 16 Read analog output Holding Register- AND Mask 16 AND mask used in “write analog output” Holding Register- OR Mask 16 OR mask used in “write analog output” Input Register 16 Analog input that can only be read Input Status 1 Digital input which can only be read Tabla 4-47. Tipos de Datos soportados en el MODBUS Cliente Data Start Address: Dirección inicial del dato de un mapeo MODBUS. Data Size: El valor de tamaño especifica la cantidad máxima de datos que una relación MODBUS puede acceder, desde la dirección inicial. Por lo tanto, para leer un rango de direcciones continua, es necesario que todas las direcciones estén declaradas en una sola relación. Este campo varía con el tipo de datos MODBUS configurado. Data Range: Ese campo muestra al usuario el rango de direcciones de memoria utilizado por la relación MODBUS. Configuración de las Solicitudes – Configuración por Mapeo Simbólico La configuración de las solicitudes MODBUS, visualizadas en la Figura 4-29, sigue los parámetros descritos en la Tabla 4-48. 93 4. Configuración Figura 4-29. Pantalla de Solicitudes de Datos MODBUS Configuración Estándar de Fábrica Descripción Function Code Tipo de función MODBUS - Polling (ms) Período de comunicación (ms) 100 Posibilidades 01– Read Coils 02– Read Input Status 03– Read Holding Registers 04– Read Input Registers 05– Write Coil 06– Write Register 15– Write multiple Coils 16 – Write Multiple Registers 22– Masked Writing of Register 23 –Read/Write Multiple Register 0 a 3600000 Read Data Start Address Dirección inicial de los datos de lectura MODBUS - 1 a 65536 Read Data Size Tamaño de los dados de lectura MODBUS - Depende de la función utilizada Franja de los datos de lectura MODBUS - 0 a 2147483646 Write Data Start Address Dirección inicial de los datos de escritura MODBUS - 1 a 65536 Write Data Size Tamaño de los de escritura MODBUS - Depende de la función utilizada Write Data Range Franja de dirección de los datos de escritura MODBUS - 0 a 2147483647 Nombre de la variable de diagnóstico - Nombre de una variable declarada en programa o GVL - Campo destinado a la variable simbólica utilizada para desactivar individualmente las solicitudes MODBUS configuradas. Esta variable debe ser del tipo BOOL. La variable puede ser simple o elemento de array y puede ser en estructuras. Read Data Range Diagnostic Variable Disabling Variable Variable utilizada para desactivar la relación MODBUS Tabla 4-48. Configuración de las Relaciones MODBUS Cliente 94 4. Configuración Notas: MODBUS Relation Settings: El número de configuraciones, estándar de fábrica y los valores de la columna para las posibilidades, pueden variar según el tipo de dato y la función MODBUS (FC). Function Code: Las funciones MODBUS (FC) disponibles se describen a continuación: Tipo de Función Access to Variables Código Descripción DEC HEX 1 0x01 Read coils (FC 01) 2 0x02 Read input status (FC 02) 3 0x03 Read holding registers (FC 03) 4 0x04 Read input registers (FC 04) 5 0x05 Write a coil (05 FC) 6 0x06 Write a holding register (FC 06) 15 0x0F Write multiple coils (FC 15) 16 0x10 Write holding registers (FC 16) 22 0x16 Register write mask (FC 22) 23 0x17 Read/Write holding registers (FC 23) Tabla 4-49. Funciones MODBUS Cliente Polling: Este parámetro indica con qué frecuencia la comunicación establecida por esta solicitud se debe realizar. Para finalizar una comunicación se esperará un tiempo igual al configurado en el campo escaneo y después, se ejecutará una nueva comunicación. Read Data Start Address: Campo destinado a la dirección inicial de los datos de lectura MODBUS Read Data Size: El valor mínimo para el tamaño de los datos de lectura es 1 y el valor máximo depende de la función MODBUS (CF) utilizada, como se puede ver a continuación: Read Coils (HR 1): 2000 Read Input Status (FC 2): 2000 Read Holding Registers (HR 3): 125 Read Input Registers (HR 4): 125 Read/Write Holding Registers (FC 23): 121 Read Data Range: Ese campo muestra la franja de datos de lectura MODBUS configurada para cada solicitud. La dirección inicial de la lectura, junto con el tamaño de los datos de lectura resultará en el rango de datos de lectura de cada una de las solicitudes. Write Data Start Address: Campo destinado a la dirección inicial de los datos de escritura MODBUS Write Data Size: El valor mínimo para el tamaño de los datos de escritura es 1 y el valor máximo depende de la función MODBUS (CF) utilizada, como está a continuación: Write Coil (HR 5): 1 Write Holding Registers (FC 6): 1 Write Multiple Coils (FC 15): 1968 Write Holding Registers (FC 16): 123 Register write mask (FC 22): Read/Write Holding Registers (FC 23): 121 Write Data Range: Ese campo muestra el rango de datos de escritura MODBUS configurado para cada solicitud. La dirección inicial de la escritura, junto con el tamaño de los datos de la escritura resultará en el rango de datos de escritura de cada una de las solicitudes. Diagnostic Variable: Los diagnósticos de la solicitud MODBUS configurada, sea por mapeo simbólico o por representación directa, se almacenan en variables del tipo T_DIAG_MODBUS_ETH_CLIENT_1 y para el mapeo por representación directa están en 4 bytes e 95 4. Configuración 2 words, la cual se describe en la Tabla 4-50 (n es el valor configurado en campo Dirección Inicial de Diagnósticos en %Q). Variable de Representación Directa Variable de diagnóstico del tipo T_DIAG_MODBUS_ETH_MAPPING_1.* Tamaño Descripción Bits de estado de la comunicación: %QX(n).0 bCommIdle BIT Comunicación inactiva (a la espera de ser constada) %QX(n).1 bCommExecuting BIT Comunicación activa bCommPostponed BIT Comunicación postergada, porque se alcanzó el número máximo de solicitudes simultáneas. Las comunicaciones postergadas se llevarán a cabo en la misma secuencia en la que fueron solicitadas para evitar la indeterminación. El tiempo utilizado en este estado no se cuenta para efectos de time-out. Los bits de bCommIdle y bCommExecuting son falsos cuando el bit bCommPostponed es verdadero. %QX(n).3 bCommDisabled BIT Comunicación desactivada. Se reinicia el bit bCommIdle en esta condición. %QX(n).4 bCommOk BIT Comunicación terminada previamente ha sido exitosa. %QX(n).5 bCommError BIT Comunicación terminada previamente tuvo un error. Verifique el código de error. %QX(n).6 bCommAborted BIT Comunicación terminada previamente fue interrumpida debido a una falla de conexión. %QX(n).7 bDiag_7_reserved BIT Reservado %QX(n).2 byStatus.* Último código de error (habilitado cuando bCommError = verdadero): %QB(n+1) MASTER_ERROR_CODE (BYTE) eLastErrorCode Informa la posible causa del último error ocurrido en la relación MODBUS. Consulte la Tabla 4-51 para detalles de las posibilidades. Último código de excepción recibido por el maestro: %QB(n+2) MODBUS_EXCEPTION (BYTE) eLastExceptionCode NO_EXCEPTION (0) FUNCTION_NOT_SUPPORTED (1) MAPPING_NOT_FOUND (2) ILLEGAL_VALUE (3) ACCESS_DENIED (128)* MAPPING_DISABLED (129)* IGNORE_FRAME (255)* Estadísticas de comunicación: %QB(n+3) %QW(n+4) %QW(n+6) byDiag_3_reserved BYTE wCommCounter wCommErrorCounter Reservado. WORD Contador de comunicaciones terminadas, con o sin errores. El usuario puede probar cuando la comunicación haya sido terminada, probando la variación de este contador. WORD Cuando se alcanza el valor 65535, el contador vuelve a cero. Contador de comunicaciones terminadas con errores. Cuando se alcanza el valor 65535, el contador vuelve a cero. Tabla 4-50. Diagnósticos de las Relaciones MODBUS Cliente 96 4. Configuración Exception Codes: El códigos de excepción presentados en eso campo son los valores retornados por el servidor. Las definiciones de los códigos de excepción, 128, 129 y 255 son válidas únicamente en el uso de esclavos Altus. Para los esclavos de otros fabricantes estos códigos de excepción pueden tener distintos significados. Disabling Variable: Campo destinado a la variable utilizada para desactivar individualmente las solicitudes MODBUS configuradas. La solicitud se desactiva cuando la variable, correspondiente a la solicitud, es igual a 1, de lo contrario, la solicitud está activada. Last Error Code: Los códigos de las posibles situaciones que causan error en la comunicación MODBUS se pueden encontrar a continuación: Código Enumerable Descripción Respuesta reportada en un código de excepción (ver eLastExceptionCode = Código de Excepción). 1 ERR_EXCEPTION 2 ERR_CRC 3 ERR_ADDRESS Dirección MODBUS no encontrada. La dirección que respondió a la solicitud ha sido diferente a lo esperado. 4 ERR_FUNCTION Código de función no válido. La función recibida en la respuesta ha sido diferente a la esperada por la solicitud. 5 ERR_FRAME_DATA_COUNT 6 ERR_INVALID_PROTOCOL_ID 7 ERR_NOT_ECHO 8 ERR_REFERENCE_NUMBER Número de referencia no válido (FC 15 y 16). 9 ERR_INVALID_FRAME_SIZE Respuesta menor que la esperada. 20 ERR_CONNECTION 21 ERR_SEND 22 ERR_RECEIVE 40 ERR_CONNECTION_TIMEOUT 41 ERR_SEND_TIMEOUT 42 ERR_RECEIVE_TIMEOUT 128 NO_ERROR Respuesta con CRC inválido. La cantidad de datos de la respuesta ha sido diferente a lo esperado. Protocolo no identificado. El protocolo de la respuesta es diferente de lo esperado. Respuesta no es eco de la pregunta (FC 5 y 6). Error en la fase de conexión. Error en la fase de transmisión. Error en la fase de recepción. Time-out en lo nivel de la aplicación durante la conexión. Time-out en lo nivel de la aplicación durante la transmisión. Time-out en el nivel de aplicación mientras aguarda respuesta. Sin error desde la inicialización. Tabla 4-51. Códigos de Error de las relaciones MODBUS Cliente ATENCIÓN: A diferencia de otras tareas de una aplicación, cuando se alcanza una marca en la depuración de MainTask, la tarea de una instancia MODBUS Ethernet Cliente y cualquier otra tarea MODBUS, dejará de ejecutarse en el momento en que intente ejecutar una escritura en un área de memoria. Esto ocurre con el fin de mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté funcionando. Configuración do Protocolo MODBUS Ethernet Cliente por Representación Directa (%Q) Para configurar este protocolo mediante Representación Directa (% Q), se debe llevar a cabo los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS cliente, tales como: protocolo y variables de representación directa (%Q) para recibir los diagnósticos. Las descripciones de cada configuración se enumeran a continuación, en este capítulo. Agregar e configurar dispositivos, definiendo dirección, variables de representación directa (%Q) para deshabilitar las relaciones y puerta de comunicación. Agregar y configurar las relaciones MODBUS, especificando el tipo de dato y función MODBUS, time-outs, variables de representación directa (%Q) para recibir los diagnósticos de la relación y otras para recibir/escribir los datos, cuantidad de datos a comunicar y polling de la relación. 97 4. Configuración Las descripciones de cada configuración se enumeran a continuación, en este capítulo. Parámetros Generales del Protocolo MODBUS Cliente– Configuración por Representación Directa (%Q) Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS (Figura 4-30), se definen como: Figura 4-30. Pantalla de Configuración MODBUS Cliente Selección del protocolo y variables de representación directa (%Q) para los diagnósticos: Configuración Descripción Estándar de Fábrica Posibilidades %Q Start Address of Diagnostics Area Dirección inicial de las variables de diagnósticos - 0 a 2147483628 Size Tamaño de la área de diagnósticos 20 Deshabilitada para edición Protocol Selección del protocolo TCP RTU vía TCP TCP Tabla 4-52. Configuraciones Generales del Protocolo MODBUS Cliente Notas: %Q Start Address of Diagnostics Area: Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede definir para el campo Dirección Inicial de Diagnósticos en %Q, pues la creación de una instancia del protocolo se puede realizar a cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE determine un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. Los diagnósticos y comandos del protocolo MODBUS se describen en la Tabla 4-43. 98 4. Configuración Configuración de los Dispositivos– configuración por Representación Directa (%Q) La configuración de los dispositivos esclavos, vistos en la Figura 4-31, siguen los siguientes parámetros: Figura 4-31. Configurar el Cliente MODBUS Configuración Descripción Estándar de Fábrica Posibilidades Name Nombre de la instancia MODBUS_Device Identificador, según la IEC 61131-3 Destination IP Dirección IP del servidor 0. 0. 0.1 0.0.0.1 a 255.255.255.254 502 2 a 65534 - 0 a 2147483644 TCP Port Puerta TCP Mapping Disabling Dirección inicial utilizada para deshabilitar las relaciones MODBUS Tabla 4-53. Configuraciones Notas: Name: Ese campo es el identificador del dispositivo, el cual se verifica según la IEC 61131-3, es decir, no permite espacios, caracteres especiales e iniciar con carácter numeral. Se limita en 24 caracteres. TCP Port: En caso de que se añadan varias instancias del protocolo en una única interfaz Ethernet, diferentes puertas TCP se deben seleccionar para cada instancia. Algunas puertas TCP, entre las posibilidades mencionadas antes, se reservan y, por lo tanto, no se pueden utilizar. Son: 80, 8080, 1217, 1740, 1741, 1742,1743 y 11740. Mapping Disabling: Compuesto por 32 bits, utilizados para deshabilitar, individualmente, las 32 relaciones MODBUS configuradas en el espacio Mapeos del Dispositivo. La relación se deshabilita cuando el bit, correspondiente a la relación, sea igual a 1, en caso contrario, el mapeo está habilitado. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede definir para el campo Deshabilitación de los Mapeos, pues la creación de una relación se puede realizar en cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE ubique un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. 99 4. Configuración Communication Time-out: Las configuraciones presentes en el botón “Avanzado...” se refieren a la conexión TCP y se describen en las notas de la sección Configuración de los Dispositivos – Configuración por Mapeo Simbólico. Configuración de los Mapeos – Configuración por Representación Directa (%Q) La configuración de las relaciones MODBUS, vistas en las Figura 4-32 y Figura 4-33, sigue los parámetros que se describen en la Tabla 4-54: Figura 4-32. Tipo de Dato MODBUS Figura 4-33. Función MODBUS Estándar de Fábrica Posibilidades Tipo de función MODBUS Leer Leer Escribir Leer/Escribir Máscara de Escritura Slave Address Dirección del esclavo MODBUS 1 0 a 255 Polling (ms) Período de comunicación (ms) 100 0 a 3600000 Dirección inicial de los diagnósticos de la relación MODBUS - 0 a 2147483640 Dirección inicial de los datos de lectura MODBUS 1 1 a 65536 Número de datos de lectura MODBUS - Depende de la función utilizada Dirección inicial de las variables de lectura (%I) - 0 a 2147483647 Dirección inicial de los datos de 1 1 a 65536 Configuración Function Mapping Diagnostics Area Read Read Data Size Read IEC Variable Write Data Start Descripción 100 4. Configuración Address escritura MODBUS Número de datos de escritura MODBUS - Depende de la función utilizada Write IEC Variable Dirección inicial de las variables de escritura (%Q) - 0 a 2147483647 Write Mask of IEC Variables Dirección inicial de las variables para la máscara de escritura (%Q) - 0 a 2147483644 Write Data Size Tabla 4-54. Mapeos del Dispositivo Notas: Device Mappings Table: El número de configuraciones y los valores descritos en la columna Posibilidades pueden cambiar según el tipo de dato y función MODBUS. Slave Address: Normalmente, la dirección 0 se utiliza cuando el servidor es un Gateway MODBUS TCP o MODBUS RTU a través de TCP, y este transmite la solicitud a todos los dispositivos de la red. Cuando la dirección 0 se utiliza, el cliente no espera por una respuesta, su uso sirve solamente para comandos de escritura. Además, según la Norma MODBUS, la franja de direcciones válidas para esclavos es de 0 a 247, siendo las direcciones 248 a 255 reservadas. Polling: Este parámetro indica con qué frecuencia la comunicación definida por esta relación se debe ejecutar. Al finalizar una comunicación se aguardará un tiempo igual al polling configurado y, enseguida, se ejecutará una nueva comunicación lo más rápido posible. Mapping Diagnostic Area: Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Los diagnósticos de la relación MODBUS configurada, se almacenan en 4 bytes y 2 words, las cuales están descritas a continuación (“n” es el valor configurado en el campo Área de Diagnósticos del Mapeo): Size of the Read and Write Data: Detalles do tamaño dos dados suportados por cada función se describen en las notas dela sección Configuración de las Solicitudes – Configuración por Mapeo Simbólico. Read IEC Variable: Caso el tipo de dato MODBUS sea Coil o Input Status (bit), la dirección inicial de las variables IEC de lectura tendrá el formato por ejemplo %IX10.1. Sin embargo, si el tipo de dato MODBUS es Holding Register o Input Register (16 bits), la dirección inicial de las variables IEC de lectura tendrá el formato %IW. Ese campo se limita por el tamaño de la memoria de variables de entrada direccionables (%I) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Write IEC Variable: Caso el tipo de dato MODBUS sea MODBUS sea Coil (bit), la dirección inicial de las variables IEC de escritura tendrá el formato por ejemplo %QX10.1. Sin embargo, si el tipo de dato MODBUS es Holding Register (16 bits), la dirección inicial de las variables IEC de escritura tendrá el formato %QW. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Write Mask of IEC Variables: La función Máscara de Escritura del Register (FC 22), a través de una lógica entre el valor ya escrito y las 2 words configuradas en este campo, siendo la word %QW(0) para la máscara AND y la word %QW(2) para la máscara OR; permite al usuario manejar la word. Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Estándar de Fábrica: El estándar de fábrica no se puede definir para los campos Área de Diagnósticos del Mapeo, Variable IEC de Lectura, Variable IEC de Escritura y Máscara de Escritura de las Variables IEC, pues la creación de una relación se puede realizar a cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE determine un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. El estándar 101 4. Configuración de fábrica no se puede definir para los campos Tamaño de Datos de Lectura y Tamaño de Datos de Escritura, pues variarán según el tipo de dato MODBUS seleccionado. ATENCIÓN: Diferentemente de otras tareas de una aplicación, cuando se alcance una marca de depuración en MainTask, la tarea de una instancia MODBUS Ethernet Cliente, y cualquier otra tarea MODBUS, parará de ejecutarse en el momento en que intente efectuar una escritura en un área de memoria. Esto ocurre para mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté en ejecución. MODBUS Ethernet SERVIDOR Este protocolo está disponible para las UCPs de la Serie Nexto en sus canales Ethernet. Al seleccionar esta opción en MasterTool IEC XE, la UCP se convierte en el servidor de la comunicación MODBUS, lo que permite la conexión con dispositivos cliente MODBUS. Este protocolo está disponible sólo cuando la UCP está en modo de ejecución (Run Mode). Hay dos maneras de configuración para este protocolo. Uno hace uso de Representación Directa (% Q), en lo cual las variables se definen por su dirección. El otro, llamado Mapeo Simbólico definido las variables por su nombre. El procedimiento para insertar una instancia del protocolo se encuentra en detallada en el Manual del Usuario MasterTool IEC XE - MU299800 o en el capítulo Insertando una Instancia de Protocolo. Configuración del Protocolo MODBUS Ethernet Servidor por Mapeo Simbólico Para configurar este protocolo mediante Mapeo Simbólico, es necesario llevar a cabo los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS servidor, como: puerta TCP, selección de protocolo, filtros de IP para Escritura y Lectura (disponible en el botón de configuración de filtros) y tiempos de comunicación (disponible en el botón de configuraciones avanzadas del Servidor). Agregar y configurar los mapeos MODBUS, especificando el nombre de la variable, tipo de datos, dirección inicial del dato y tamaño del dato. Las descripciones de cada configuración se relacionan a continuación, en este capítulo. Parámetros Generales del Protocolo MODBUS Servidor – Configuración por Mapeo Simbólico Los parámetros generales, encontrado en la pantalla inicial de configuración do protocolo MODBUS (Figura 4-34), se definen como: Figura 4-34 Pantalla de Configuración Parámetros Generales MODBUS Servidor Configuración TCP Port Connection Mode Descripción Porta TCP Selección del protocolo Estándar de Fábrica Posibilidades 502 2 a 65534 TCP RTU vía TCP TCP Tabla 4-55. Configuraciones Gerais MODBUS Servidor 102 4. Configuración Notas: TCP Port: Si hay varias instancias añadidas del protocolo en una sola interfaz Ethernet, diferentes puertas TCP deben seleccionarse para cada instancia. Algunas puertas TCP, entre las posibilidades mencionadas, están reservados y por lo tanto no se pueden utilizar. Son: 80, 8080, 1217, 1740, 1741, 1742.1743 y 11740. Las configuraciones presentes en el botón “Filtros...”, se describen en la Tabla 4-56, y están relacionadas a filtros de comunicación TCP: Configuración Descripción Estándar de Fábrica Posibilidades Write Filter IP Address Especifica un intervalo de IPs con acceso de escritura en las variables declaradas en la relación MODBUS 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Write Filter Mask Especifica la máscara de subred junto con el parámetro Filtro de IP para Escritura 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Read Filter IP Address Especifica un rango de IPs con acceso de lectura en las variables declaradas en la relación MODBUS 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Read Filter Mask Especifica la máscara de subred junto con el parámetro Filtro de IP para Lectura 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Tabla 4-56. Filtros de IP Nota: Filters: Los filtros se utilizan para establecer un intervalo de direcciones IP que tienen acceso de escritura o lectura en las relaciones MODBUS, configuradas individualmente. El criterio de permiso se logra a través de una operación lógica AND entre el Filtro de Máscara para Escritura y la dirección IP del cliente. Si el resultado es el mismo que el del filtro de IP para Escritura, el cliente tiene derecho a escritura. Por ejemplo, si el filtro de IP para escritura = 192.168.15.0 y el filtro de la Máscara para Escritura = 255.255.255.0, entonces sólo los clientes con dirección IP = 192.168.15. x tendrán derecho de escritura. El mismo procedimiento se aplica en los parámetros de filtro de lectura para definir los derechos de lectura. Los tempos de comunicación del protocolo MODBUS Servidor que se encuentran en el botón “Avanzado...” de la pantalla de configuración se dividen en: Ciclo de Tarea y Time-out de la Inactividad de la Conexión. Configuración Descripción Estándar de Fábrica Posibilidades Task Cycle (ms) Tiempo para ejecutar la instancia dentro del ciclo, sin tener en cuenta el tiempo de ejecución de la misma 50 5 a 100 Connection Inactivity Time-out (s) Tiempo máximo de inactividad entre el cliente y el servidor antes de que la conexión se cierre por el servidor 10 10 a 3600 Tabla 4-57. Configuraciones Avanzadas Notas: Task Cycle: El usuario debe tener cuidado cambiar este parámetro, ya que interfiere directamente en el tiempo de respuesta, volumen de datos por ciclo y sobre todo en el equilibrio de los recursos de la UCP entre comunicaciones y otras tareas. Connection Inactivity Time-out: Este parámetro está diseñado para evitar que el número máximo de conexiones TCP se alcance, en el supuesto de que las conexiones inactivas están abiertas por muchos problemas diferentes. Indica cuanto tempo la conexión (cliente o servidora) puede 103 4. Configuración permanecer abierta sin uso, es decir, sin cambiar mensajes de comunicación. Si el tiempo especificado se alcanza, la comunicación es cerrada, libertando una entrada en la tabla de conexiones. Diagnósticos MODBUS Servidor – Configuración por Mapeo Simbólico Los diagnósticos y comandos del protocolo MODBUS Servidor configurado, sea por mapeo simbólico o por representación directa, se almacenan en variables del tipo T_DIAG_MODBUS_ETH_SERVER_1 y para el mapeo por representación directa están en 4 bytes e 8 words, las cuales se describen en la Tabla 4-58 (n es el valor configurado en el campo Dirección Inicial de Diagnósticos en %Q): Variable de Representación Directa Variable de diagnósticos do tipo T_DIAG_MODBUS_ETH_SERVER_1 *. Tamaño Descripción Bits de Diagnóstico: %QX(n).0 bRunning BIT El servidor se está ejecutando bNotRunning BIT El servidor no se está ejecutando (vea bit bInterruptedByCommand). bInterruptedByCommand BIT El bit bNotRunning fue habilitado, porque el servidor fue interrumpido por el usuario a través de bits de comando. bConfigFailure BIT Diagnóstico descontinuado bRXFailure BIT Diagnóstico descontinuado bTXFailure BIT Diagnóstico descontinuado bModuleFailure BIT Diagnóstico descontinuado bDiag_7_reserved BIT Reservado BYTE Reservado %QX(n).1 %QX(n).2 %QX(n).3 tDiag.* %QX(n).4 %QX(n).5 %QX(n).6 %QX(n).7 %QB(n+1) byDiag_1_reserved Bits de comando, reiniciados automáticamente: %QX(n+2).0 bStop BIT Parar el servidor %QX(n+2).1 bRestart BIT Reiniciar o servidor %QX(n+2).2 bResetCounter BIT Reiniciar la estadística de los diagnósticos (contadores). bDiag_19_reserved BIT Reservado %QX(n+2).4 bDiag_20_reserved BIT Reservado %QX(n+2).5 bDiag_21_reserved BIT Reservado %QX(n+2).6 bDiag_22_reserved BIT Reservado BIT Reservado BYTE Reservado %QX(n+2).3 tCommand.* %QX(n+2).7 %QB(n+3) bDiag_23_reserved byDiag_03_reserved Estadísticas de Comunicación: %QW(n+4) %QW(n+6) %QW(n+8) WORD Número de conexiones establecidas entre cliente y servidor (0 a 64). wTimeoutClosedConnections WORD Contador de conexiones, entre cliente y servidor, interrumpidas después de un período de inactividad – time-out (0 a 65535). wClientClosedConnections WORD Contador de conexiones interrumpidas por la solicitud del cliente (0 a 65535). wActiveConnections tStat.* %QW(n+10) wRXFrames WORD Contador de frames Ethernet recibidos por el servidor; un frame Ethernet puede contener más de una solicitud (0 a 65535). %QW(n+12) wRXRequests WORD Contador de solicitudes recibidas por el servidor y 104 4. Configuración Variable de Representación Directa Variable de diagnósticos do tipo T_DIAG_MODBUS_ETH_SERVER_1 *. Tamaño Descripción respondidas normalmente (0 a 65535). %QW(n+14) wTXExceptionResponses WORD Contador de solicitudes recibidas por el servidor y respondidas con códigos de excepción (0 a 65535). Los códigos de excepción se relacionan a continuación: 1: código da función (FC) es legal, pero no es soportado. 2: la relación no encontrada en eses datos MODBUS. 3: valor ilegal para la dirección. 128: maestro/cliente no tiene derecho de escritura o lectura. 129: la relación MODBUS se deshabilita. %QW(n+16) wRXIllegalRequests WORD Contador de solicitudes ilegais. (0 a 65535). %QW(n+18) wDiag_18_reserved WORD Reservado Tabla 4-58. Diagnósticos MODBUS Servidor Nota: Contadores: Todos los contadores de los diagnósticos MODBUS Ethernet Servidor vuelven a cero cuando el valor límite 65535 sobrepasa. Configuración dos Mapeos – Configuración por Mapeo Simbólico La configuración de los mapeos MODBUS Servidor, visualizadas en la Figura 4-35, sigue los parámetros descritos en la Tabla 4-59. Figura 4-35. Pantalla de Mapeos de Datos MODBUS Servidor Configuración Descripción Value Variable Nombre de la variable simbólica Estándar de Fábrica Posibilidades - Nombre de una variable declarada en programa o GVL Data Type Tipo de dato MODBUS - Coil Input Status Holding Register Input Register Data Start Address Dirección inicial de los dados MODBUS - 1 a 65536 Absolute Data Start Address Dirección inicial absoluta de los datos MODBUS según su tipo. - - 105 4. Configuración Data Size Data Range Tamaño del dato MODBUS - 1 a 65536 Franja de direcciones del dato configurado - - Tabla 4-59. Configuración de los Mapeos MODBUS Ethernet Notas: Value Variable: Ese campo se utiliza para especificar una variable simbólica en la relación MODBUS. Data Type: Ese campo se utiliza para especificar el tipo de dato utilizado en la relación MODBUS. Data Start Address: Dirección inicial del dato de un mapeo MODBUS. Absolut Data Start Address : Dirección absoluta de los datos MODBUS según su tipo. Por ejemplo, la dirección absoluta del Holding Register con dirección 5 es 400005. Este campo es solo para lectura y está disponible para auxiliar en la configuración del Client/Master MODBUS que se comunicará con este dispositivo. Los valores dependen de la dirección base (offset) de cada tipo de dato MODBUS y de la dirección permitida a cada tipo de dato. Data Size: El valor de Tamaño especifica la cuantidad máxima de datos que una relación MODBUS podrá accesar, desde la dirección inicial. Para leer una franja de direcciones continua, es necesario que todos las direcciones se declaren en una única relación. Ese campo varía según el tipo de dato MODBUS configurado. Data Range: Es un campo de lectura y muestra el rango de direcciones que se usa en ese mapeo. Es formada por la suma de los campos “Dirección Inicial” y “Tamaño”. No puede haber sobreposición de franja con otros mapeos del mismo “Tipo de Dato”. ATENCIÓN: Diferentemente de otras tareas de una aplicación, cuando se alcance una marca de depuración en MainTask, la tarea de una instancia MODBUS Ethernet Servidor, y cualquier otra tarea MODBUS, parará de ejecutarse en el momento en que intente efectuar una escritura en un área de memoria. Esto ocurre para mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté en ejecución. Configuración do Protocolo MODBUS Ethernet Servidor por Representación Directa (%Q) Para configurar este protocolo mediante Representación Directa (% Q), se debe llevar a cabo los siguientes pasos: Configurar los parámetros generales del protocolo MODBUS servidor, tales como: tiempos de comunicación, direcciones y variables de representación directa (%Q) para recibir los diagnósticos y controlar las relaciones. Agregar y configurar las relaciones MODBUS, especificando el tipo de dato MODBUS, variables de representación directa (%Q) para recibir/escribir los datos y la cuantidad de datos a comunicar. Las descripciones de cada configuración se enumeran a continuación, en este capítulo. Parámetros Generales del Protocolo MODBUS Servidor – Configuración por Representación Directa (%Q) Los parámetros generales, encontrados en la pantalla inicial de configuración del protocolo MODBUS (Figura 4-36), se definen como: 106 4. Configuración Figura 4-36. Pantalla de Configuración MODBUS Servidor Puerta TCP, Protocolo, Variables de representación directa (%Q) para controlar las relaciones y diagnósticos: Configuración %Q Start Address of Diagnostics Area Size TCP Port Descripción Estándar de Fábrica Posibilidades - 0 a 2147483628 20 Deshabilitada para edición Dirección inicial de las variables de diagnóstico Tamaño de la área de diagnósticos Puerta TCP 502 2 a 65534 Mapping Disabling Dirección inicial utilizada para deshabilitar las relaciones MODBUS - 0 a 2147483644 Protocol Selección del protocolo TCP RTU vía TCP TCP Tabla 4-60. Configuraciones Notas: %Q Start Address of Diagnostics Area: Ese campo se limita por el tamaño de la memoria de variables de salidas direccionables (%Q) de cada UCP, la cual se puede ser consultar en el capítulo Descripción Técnica – Características Específicas. TCP Port: Si hay varias instancias añadidas del protocolo en una sola interfaz Ethernet, diferentes puertas TCP deben seleccionarse para cada instancia. Algunas puertas TCP, entre las posibilidades mencionadas, están reservadas y por tanto no se pueden utilizar. Son: 80, 8080, 1217, 1740, 1741, 1742,1743 y 11740. Mapping Disabling: Compuesto por 32 bits, utilizados para deshabilitar, individualmente, las 32 relaciones MODBUS configuradas en el espacio Mapeos del Servidor. La relación se deshabilita cuando el bit, correspondiente a la relación, sea igual a 1, en caso contrario, el mapeo está habilitado. Estándar de Fábrica: El estándar de fábrica no se puede definir para los campos Dirección Inicial de Diagnósticos en %Q y Deshabilitación de los Mapeos, pues la creación de una instancia del protocolo se puede realizar en cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE ubique un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. 107 4. Configuración Los tempos de comunicación del protocolo MODBUS Servidor que se encuentran en el botón “Avanzado...” de la pantalla de configuración se dividen en: Ciclo de Tarea (ms) y Time-out de la Inactividad de la Conexión. Más detalles se describen en la sección Parámetros Generales del Protocolo MODBUS Servidor – Configuración por Mapeo Simbólico. Los diagnósticos y comandos del protocolo MODBUS se describen en la Tabla 4-58. Configuración de los Mapeos – Configuración por Representación Directa (%Q) La configuración de las relaciones MODBUS, visualizada en las Figura 4-37 y Figura 4-38, siguen los parámetros que se describen en la Tabla 4-61: Figura 4-37. Tipo de Dato MODBUS Figura 4-38. Función MODBUS Configuración Estándar de Fábrica Posibilidades Coil Coil (1 bit) Holding Register (16 bits) Input Status (1 bit) Input Register (16 bits) 1 1 a 65536 Número de datos MODBUS 8 1 a 65536 (Holding Register e Input Register) 8 a 65536 (Coil e Input Status) Dirección inicial de las - 0 a 2147473647 Descripción Data Type Tipo de dato MODBUS Data Start Address Dirección inicial de los dados MODBUS Data Size IEC Variable 108 4. Configuración variables (%Q) Read-only Solamente permite la lectura Deshabilitada Habilitada o Deshabilitada Tabla 4-61. Mapeos del Servidor Notas: Options: Los valores descritos en la columna Posibilidades pueden variar según el tipo de dato MODBUS configurado. Data Size: El valor de tamaño del dato define la cantidad máxima de datos que una relación MODBUS podrá acceder, a partir de la dirección inicial. De esta forma, para leer una franja de direcciones continua, es necesario que todas las direcciones estén declaradas en una única relación. Ese campo cambia según el tipo de dato MODBUS configurado, es decir, cuando seleccionado tipo Coil o Input Status, el campo Tamaño del Dato debe ser un número múltiple de ocho. También se debe tener en cuenta que el valor máximo no sea superior al tamaño de la memoria de salidas direccionables y que no se atribuyan los mismos valores ya utilizados durante la aplicación. IEC Variable: Caso el tipo de dato MODBUS sea Coil o Input Status (bit), la dirección inicial de las variables IEC de lectura tendrá el formato por ejemplo %QX10.1. Sin embargo, si el tipo de dato MODBUS es Holding Register o Input Register (16 bits), la dirección inicial de las variables IEC de lectura tendrá el formato %QW. Ese campo se limita por el tamaño de la memoria de variables de entrada direccionables (%Q) de cada UCP, la cual se puede consultar en el capítulo Descripción Técnica – Características Específicas. Read-only: Cuando habilitada, solamente permite que el maestro de la comunicación lea los datos de las variables, no permite la escritura. Opción válida solamente para las funciones de escritura. Estándar de Fábrica: El estándar de fábrica no se puede definir para el campo Variable IEC, pues la creación de una instancia del protocolo se puede realizar en cualquier momento en el desarrollo del aplicativo, haciendo con que el propio software MasterTool IEC XE ubique un valor, de la franja de variables de salida de representación directa (%Q), aun no utilizado. El estándar de fábrica no se puede definir para el campo Tamaño del Dato, pues variará según el tipo de dato MODBUS seleccionado. Las configuraciones presentes en el botón “Filtros...”, se describen en la Tabla 4-62, y están relacionadas a filtros de comunicación TCP: Configuración Descripción Estándar de Fábrica Posibilidades Write Filter IP Address Especifica un intervalo de IPs con acceso de escritura en las variables declaradas en la relación MODBUS 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Write Filter Mask Especifica la máscara de subred junto con el parámetro Filtro de IP para Escritura 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Read Filter IP Address Especifica un rango de IPs con acceso de lectura en las variables declaradas en la relación MODBUS 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Read Filter Mask Especifica la máscara de subred junto con el parámetro Filtro de IP para Lectura 0. 0. 0. 0 0.0.0.0 a 255.255.255.255 Tabla 4-62. Filtros Nota: Filters: Los filtros se utilizan para establecer un intervalo de direcciones IP que tienen acceso de escritura o lectura en las relaciones MODBUS, configuradas individualmente. El criterio de permiso se logra a través de una operación lógica AND entre el Filtro de Máscara para Escritura y la dirección 109 4. Configuración IP del cliente. Si el resultado es el mismo que el del filtro de IP para Escritura, el cliente tiene derecho a escritura. Por ejemplo, si el filtro de IP para escritura = 192.168.15.0 y el filtro de la Máscara para Escritura = 255.255.255.0, entonces sólo los clientes con dirección IP = 192.168.15. x tendrán derecho de escritura. El mismo procedimiento se aplica en los parámetros de filtro de lectura para definir los derechos de lectura. En las relaciones definidas anteriormente, el tamaño máximo de datos MODBUS puede ser 65535 (máximo valor configurado en el campo Tamaño del Dato). Sin embargo, la pregunta que llega en el MODBUS Ethernet Servidor deberá direccionar un subconjunto de ese mapeo y ese grupo debe tener, en lo máximo, el tamaño de datos que depende del código de la función, los cuales están definidos a continuación: Read coils (FC 1): 2000 Read input status (FC 2): 2000 Read holding registers (FC 3): 125 Read input registers (FC 4): 125 Write single coil (FC 5): 1 Write single holding register (FC 6): 1 Force multiple coils (FC 15): 1968 Write holding registers (FC 16): 123 Mask Write (FC 22): 1 Read/ Write holding registers (FC 23): o Read: 121 o Write: 121 ATENCIÓN: Diferentemente de otras tareas de una aplicación, cuando se alcance una marca de depuración en MainTask, la tarea de una instancia MODBUS Ethernet Servidor, y cualquier otra tarea MODBUS, parará de ejecutarse en el momento en que intente efectuar una escritura en un área de memoria. Esto ocurre para mantener la consistencia de los datos de las áreas de memoria mientras MainTask no esté en ejecución OPC DA Para comunicarse con las UCPs de la Serie Nexto, es posible utilizar la tecnología OPC DA (Open Platform Communications Data Access). Esta plataforma de comunicación abierta ha sido desarrollada para ser el estándar utilizado en las comunicaciones industriales. Basada en la arquitectura cliente/servidor, ofrece innúmeras ventajas en el desarrollo de proyecto y facilidades en la comunicación con los sistemas de automación. Una analogía muy común, utilizada para describir la tecnología OPC, es la de una impresora. Al estar correctamente conectada, la computadora necesita un driver para tener la interfaz con el equipo. Muy similar, el OPC auxilia en la interfaz entre el sistema de supervisión con los datos de campo en el CP. Al tratarse del desarrollo de proyectos, configurar la comunicación e intercambiar informaciones entre los sistemas es extremamente simple al utilizar tecnología OPC. Al utilizar otros drivers, basados en direcciones, es necesario crear tablas para relacionar las tags del sistema de supervisión y las variables del controlador programable. Al alterar las áreas de datos, en el transcurrir del desarrollo del proyecto, es necesario rehacer los mapeos y hacer nuevas tablas con las relaciones entre las informaciones del CP con el sistema de Supervisión Control y Adquisición de Datos (SCADA). 110 4. Configuración Figura 4-39. Arquitectura OPC La Figura 4-39. Arquitectura OPC presenta una arquitectura para comunicación de sistema SCADA y CPs en proyecto de automación. Todos los papeles presentes en la comunicación están explícitos en esta figura independiente del lugar donde estén ejecutando, pueden estar en un mismo equipo o en equipos diferentes. Cada uno de los papeles de esta arquitectura se describe en la Tabla 4-63. Papel Descripción Programmable Controllers and Field Devices Level Los dispositivos de campo y el CPs son los dispositivos en los cuales las informaciones del estado de operaciones y control de la planta se almacenan. Los sistemas SCADA acceden a las informaciones en estos dispositivos y almacenan en los servidores SCADA para consulta por los Clientes SCADA durante la operación de la planta. Acquisition Network La red de adquisición es la red en la cual trafican los mensajes para solicitar los datos que se recolectan de los dispositivos de campo. PLC Communication Gateway Para la comunicación entre el Servidor OPC y los CPs de la Serie Nexto se utiliza un gateway que permite esta comunicación. Siempre es necesario existir un gateway en la misma subred del CP como lo descrito en el capítulo Configuraciones de Comunicación, en el Manual del Usuario MasterTool IEC XE - MU299800. OPC Server Modules El Servidor OPC es un Módulo responsable por recibir las solicitudes OPC DA y traducirlas para la comunicación con los dispositivos de campo. OPC Client Device Module El módulo Dispositivo del Cliente OPC es responsable por hacer solicitudes al Servidores OPC utilizando el protocolo OPC DA. Los datos recolectados por se almacenan en la base de datos del Servidor SCADA 111 4. Configuración SCADA Server Level El Servidor SCADA es responsable de conectarse a los diversos dispositivos de comunicación y almacenar los datos recolectados de estos dispositivos en una base de datos para que se pueda consultar por los Clientes SCADA. Supervision Network La red de supervisión es la red por la cual los Clientes SCADA están conectados a los Servidores SCADA. En una topología en la cual no se usan diversos Clientes o que el servidor y el Cliente estén instalados en un mismo equipo, no existe este tipo de red. SCADA Client Level Los clientes SCADA son responsables de solicitar a los servidores SCADA los datos necesarios para exhibir en una pantalla donde se ejecuta la operación de una planta. A través de eso es posible ejecutar lecturas y escrituras en datos almacenados en la base de datos del Servidor SCADA. Tabla 4-63. Descripción de los Papeles en una Arquitectura con Servidor OPC La relación entre las tags de los sistemas de supervisión y los datos del proceso en las variables del controlador es totalmente transparente. Eso significa que si las áreas de datos se alteran en el transcurrir del desarrollo del proyecto, no hay la necesidad de rehacer relaciones entre las informaciones del CP con el SCADA. Basta utilizar la nueva variable brindada por el CP en los sistemas que solicitan este dato. El uso del OPC ofrece más productividad y conectividad con los sistemas SCADA. Contribuye en la reducción del tiempo de desarrollo de aplicaciones y en los costos con mantenimiento. Hace factible, aun, inserción de nuevos datos en la comunicación de forma simplificada con más flexibilidad e interoperabilidad entre los sistemas de automación por ser un estándar abierto. El Servidor OPC se instala juntamente con la instalación del MasterTool IEC XE y su configuración se realiza dentro de la herramienta. Vale resaltar que el OPC está disponible solamente en las interfaces Ethernet locales de las UCPs Nexto. Los módulos de expansión Ethernet no soportan esta funcionalidad. Creando un Proyecto para Comunicación OPC Diferente de las comunicaciones con drivers como MODBUS y PROFIBUS DP, para configurar la comunicación OPC basta configurar el nodo correctamente e indicar cuáles son variables que se utilizarán en la comunicación. Hay dos formas de indicar cuáles son las variables de proyecto que estarán disponibles en el Servidor OPC. En ambos casos, es necesario añadir el objeto Symbol Configuration a la aplicación, en el caso de que este no esté presente. Para añadirlo basta pulsar con el botón derecho del mouse sobre el objeto Application y seleccionar la opción. ATENCIÓN: Las variables exhibidas en el objeto IoConfig_Globals, IoConfig_Application_Mappings e IoConfig_Global_Mappings se utilizan internamente para control de E/S y no deben se deben utilizar por el usuario. ATENCIÓN: Más allá de las variables declaradas en las POUs en lenguaje SFC se muestran algunas variables creadas implícitamente. Para cada paso creado, se crea una variable del tipo IecSfc.SFCStepType donde se pueden monitorear los status del paso, o sea, si este está activo o no, y el tiempo que está activo según define la norma IEC61131-3. Para cada transición se crea una variable del tipo BOOL que define si la transición es verdadera o falsa. Dichas variables se muestran en el objeto Symbol Configuration y pueden quedar disponibles para acceso por el Cliente OPC. 112 4. Configuración Figura 4-40. Objeto Symbol Configuration La Tabla 4-64 presenta una descripción de los campos en la pantalla de configuraciones de los símbolos en el objeto Symbol Configuration. Campo Descripción Symbols Identificador de la variable que estará disponible para el servidor OPC. Access Rights Indica cual es el nivel de acceso en el símbolo declarado. Al no utilizar esta columna, esta se vuelve vacía y el nivel de acceso es máximo. En caso contrario el nivel de acceso se puede modificar al pulsar sobre el campo. Las opciones posibles son las siguientes: Solamente lectura Solamente escritura Lectura y escritura Maximal Indica el nivel máximo de acceso que se puede asignar a la variable. Los símbolos que representan tienen el mismo significado del campo Access Right. No es posible alterar y se indica por la presencia o no de {attribute 'symbol'}. Attribute Indica si se está utilizando {attribute 'symbol'} cuando declarada la variable. Al no utilizar esta columna, esta se vuelve vacía. Para los casos en que utiliza el atributo, el comportamiento es el siguiente: {attribute 'symbol' := 'read'} la columna muestra {attribute 'symbol' := 'write'} la columna muestra {attribute 'symbol' := 'readwrite'} la columna muestra Type Tipo de dato de la variable declarada. Members Cuando el tipo de datos es una Struct, se habilita un botón en esta columna. Al pulsar el botón es posible seleccionar cuales elementos de la estructura estarán disponibles para el Servidor OPC. Comment Comentario de la variable insertada en el POU o GVL donde se declara. Para aparecer como comentario de la variable, el comentario debe ser insertado una línea antes de la declaración de la variable, en el editor cuando en modo texto o en la columna comentario, cuando en modo tabular. Tabla 4-64. Descripción de los Campos de la Pantalla del Objeto Symbol Configuration 113 4. Configuración Al ejecutar una alteración en las configuraciones del proyecto, como añadir o remover variables, se hace necesario ejecutar el comando Build para actualizar la lista de variables. Este comando se debe ejecutar hasta que el mensaje presente en la Figura 4-40 desaparezca. Después de eso, todas las variables disponibles en el proyecto, sean declaradas en POUs, GVLs y diagnósticos, se mostrarán y se podrán seleccionar. Las variables seleccionadas estarán disponibles en el Servidor OPC para acceso por los Clientes. Figura 4-41. Seleccionando Variables en Symbol Configuration Tras este procedimiento el proyecto se puede cargar en un CP y las variables seleccionadas estarán disponibles para comunicación con el Servidor OPC. Si la pantalla del Objeto Symbol Configuration está abierta y alguna de las variables, POUs o GVLs seleccionadas se altera, los nombres de estos objetos aparecerán en rojo. Las situaciones en las cuales eso sucede son en el caso de que la variable se apague o que el valor del atributo haya sido alterado. También es posible configurar cuáles variables estarán disponibles en el Servidor OPC a través de un atributo insertado directamente en las POUs o GVLs donde las variables se declaran. Al estar el atributo {attribute 'symbol'} presente en la declaración de las variables, pudiendo estar antes de la definición del nombre de la POU o GVL, o para cada variable individualmente, estas se envían directamente al objeto Symbol Configuration, las cuales se presentan con un símbolo en la columna Attribute. Antes de cargar el proyecto, en este caso, es necesario ejecutar el comando Build dentro del objeto Symbol Configuration. Las sintaxis válidas para el uso del atributo son: {attribute 'symbol' := 'none'} – cuando el valor del atributo es igual a 'none' las variables no estarán disponibles para el Servidor OPC y no se mostrarán en la pantalla del objeto Symbol Configuration. {attribute 'symbol' := 'read'} - cuando el valor del atributo es igual a 'read' las variables estarán disponibles para el Servidor OPC con derecho de acceso solamente para lectura. {attribute 'symbol' := 'write'} - cuando el valor del atributo es igual a 'write' las variables estarán disponibles para el Servidor OPC con derecho de acceso solamente para escritura. {attribute 'symbol' := 'readwrite'} – cuando el valor del atributo es igual a 'readwrite' las variables estarán disponibles para el Servidor OPC con derecho de acceso para lectura y escritura. En el ejemplo a continuación de declaración de variables, la configuración de las variables A y B permite que un Servidor OPC acceda a estas con derecho de acceso para lectura y escritura. En contrapunto, la variable C no se puede acceder, mientras la variable D se acceda con derecho de acceso solo para lectura 114 4. Configuración {attribute 'symbol' := 'readwrite'} PROGRAM MainPrg VAR A: INT; B: INT; {attribute 'symbol' := 'none'} C: INT; {attribute 'symbol' := 'read'} D :INT; END_VAR Cuando una variable diferente de los tipos básicos se define, el uso del atributo se debe hacer dentro de la declaración de esta DUT y no solamente en el contexto en el cual la variable se declara. Por ejemplo, en el caso de una instancia DUT declarada dentro de una POU o GVL que poseen un atributo, este no impactará en el comportamiento de los elementos de la instancia de esta DUT. Será necesario aplicar el mismo nivel de acceso en la declaración de la DUT. ATENCIÓN: Las configuraciones de los símbolos que estarán disponibles al Servidor OPC se almacenan dentro del proyecto del CP. Al modificar dichas configuraciones, es necesario cargar la aplicación en el CP para que sea posible acceder a estas variables. ATENCIÓN: Al excluir una variable del proyecto y cargarla en el CP, y así desmarcarla del objeto Symbol Configuration, la variable no puede más ser leída con el Cliente OPC. Si la variable se añade al proyecto nuevamente, con el mismo nombre y el mismo contexto, y se la inserta al objeto Symbol Configuration, será necesario reinicializar el Cliente OPC para actualizar la referencia de la dirección de la variable, que pasa a crearse en otra área de memoria en el CP. Configurando un CP en el Servidor OPC La configuración de un CP se ejecuta dentro del MasterTool IEC XE a través de la opción disponible en el menú Comunicación. Es necesario que MasterTool IEC XE se ejecute como administrador. 115 4. Configuración Figura 4-42. Configuración del OPC Server La Gateway Configuration es la misma configurada en el Gateway utilizado para comunicación entre el MasterTool IEC XE e el CP (descrita en Configuraciones de Comunicación, en el Manual del Usuario MasterTool IEC XE - MU299800. Si la configuración utilizada es localhost, la Gateway Address se debe llenar con 127.0.0.1. Esta configuración es necesaria, pues el Servidor OPC utiliza el mismo gateway de comunicación y el mismo protocolo utilizados en la comunicación entre CP y MasterTool IEC XE. Existe la opción Using the Gateway Embedded in PLC que se puede seleccionar si se desea utilizar el Gateway que está en el propio CP. Esta opción se puede emplear para optimizar la comunicación, pues evita el exceso de tráfico a través de una determinada estación, cuando más de una estación, con Cliente OPC, está conectada al mismo CP. Para la configuración del CP, son posibles dos tipos de configuración, según la selección del checkbox Use TCP/IP Blockdriver. Al no estar la opción seleccionada el nombre del CP se debe colocar en el campo Device Name. Este es el nombre mostrado por el CP seleccionado como activo en la pantalla de Communication Settings. La otra opción es utilizar la Dirección IP de las Interfaces Ethernet. La misma dirección configurada en las pantallas de configuración se debe colocar en este campo. Además, al utilizar este método se debe colocar el número de la puerta 11740. La confirmación salvará las configuraciones del Servidor OPC. Configuración del Dispositivo Descripción Estándar de Fábrica Posibilidades Name Descripción del PLC dentro del archivo de configuración del Servidor OPC. Este campo puede tener cualquier nombre, pero para organizarse se ‘PLC1’ El campo es una STRING y se pueden colocar caracteres alfanuméricos (letras y números) y el carácter “_”.No es permitido comenzar la STRING con números 116 4. Configuración recomienda utilizar el nombre del proyecto cargado en el CP. o "_". Permite hasta 49 caracteres. Gateway Address Dirección IP de la computadora en la cual está instalado el Servidor OPC para los casos en los cuales todos los CPs estén en la misma subred. En el caso de que exista algún CP en otra subred se debe especificar el Gateway utilizado en esta subred. 127.0.0.1 0.0.0.0 a 255.255.255.255 Gateway Port Puerta TCP para la conexión con el Gateway. 1217 2 a 65534 Device Name Es el nombre del CP que aparece en la pestaña Configuración de comunicación del Device. El nombre es la STRING antes del valor hexadecimal entre [ ]. Activado sólo cuando el checkbox Use TCP/IP Blockdriver no está seleccionado. ‘0000’ El campo es una STRING y se pueden colocar cualesquier caracteres así como se hace en la configuración del nombre del CP en la pestaña Configuraciones de comunicación del Device. Permite hasta 49 caracteres. IP Address Active Dirección IP del CP. Activado sólo cuando el checkbox Usar Driver de Bloqueante TCP está seleccionado. Sólo se utiliza cuando la configuración no es redundante. 192.168.15.1 0.0.0.0 a 255.255.255.255 IP Address PLC A Dirección IP del CP A. Sólo se activa cuando la configuración es redundante. Es la dirección del CP primario con que el servidor se comunicará si no hay falla. 192.168.15.69 0.0.0.0 a 255.255.255.255 IP Address PLC B Dirección IP del CP B. Sólo se activa cuando la configuración es redundante. Es la dirección del CP secundario con que el servidor se comunicará en caso de falla. 192.168.15.70 0.0.0.0 a 255.255.255.255 Device Port Puerta TCP. Activado sólo cuando el checkbox Use TCP/IP Blockdriver está seleccionado. 11740 11740 o 11739 Tabla 4-65. Parámetros de Configuración de Cada CP para el Servidor OPC Al necesitar configurar un nuevo CP en el Servidor OPC basta presionar el botón New Device y la configuración se creará. Siempre que la pantalla de configuración se acceda se mostrará una lista con 117 4. Configuración todos los CPs ya configurados en el Servidor OPC. Las configuraciones existentes se pueden editar al seleccionar el CP en la lista Devices y editar los parámetros. Las configuraciones de CPs que no se utilizan más se pueden excluir. La cantidad máxima de CPs que se configura en un servidor OPC es 16. En el caso de que la arquitectura de automación utilizada prevea que el servidor OPC se debe ejecutar en una computadora en la cual no se ejecuta la comunicación con el CP por MasterTool IEC XE, la herramienta se debe instalar en esta computadora para permitir la configuración del Servidor OPC de la misma manera como se hace en las demás situaciones. ATENCIÓN: Para almacenar la configuración del Servidor OPC, el MasterTool IEC XE necesita ser ejecutado con derechos de administrador en el Sistema Operacional. Dependiendo de la versión del sistema Operacional este derecho se debe autorizar al ejecutar el programa. Para esta operación, pulse el botón derecho sobre el ejecutable del MasterTool IEC XE y elija la opción Ejecutar como administrador. ATENCIÓN: Las configuraciones de un CP en el Servidor OPC no se almacenan en el proyecto creado en el MasterTool IEC XE. Por dicha razón se pueden realizar con un proyecto abierto o cerrado. Las configuraciones se almacenan en un archivo de configuración en el cual el Servidor OPC está instalado. Cuando se alteren las configuraciones no es necesaria carga de aplicación en el CP, pero dependiendo del Cliente OPC es posible que sea necesario conectar nuevamente al Servidor o cargar las configuraciones para que los datos se actualicen correctamente. Importación de una Configuración de Proyecto Al utilizar el botón Read Project Configuration, según la Figura 4-42, es posible atribuir la configuración del proyecto abierto a la configuración del CP que está en edición. Para que esta opción tenga buen resultado debe haber un proyecto abierto y se debe definir un Camino Activo según lo descrito en Configuraciones de Comunicación, presente en el Manual del Usuario MasterTool IEC XE - MU299800. En el caso de que alguna de estas condiciones no se atienda se mostrará un mensaje de error y ningún dato se alterará. Cuando las condiciones anteriores son válidas, las configuraciones del CP reciben los parámetros del proyecto abierto. Las informaciones de Dirección IP y Puerta del Gateway son las configuradas según lo descrito Configuraciones de Comunicación de acuerdo con el Camino Activo. Las configuraciones de Dirección de IP son leídas de las configuraciones de la interfaz Ethernet NET1. La puerta para conexión con el CP siempre se atribuye en este caso como 11740. Configuración con CP en el Servidor OPC con Redundancia de Conexión Es posible configurar el Servidor OPC para que este opere con redundancia de conexión. De esta forma, el Servidor OPC se comunicará preferencialmente con un CP, pero cuando, por alguna razón, no consigue establecer una comunicación con este CP, un segundo CP también configurado se accederá. Esta configuración es especialmente importante para la comunicación de sistemas SCADA con los CPs de la Serie Nexto que utilizan redundancia de Half-Cluster, en el cual existe un CP en estado activo ejecutando el proceso y otro CP en estado reserva apto a asumir el control del proceso al ocurrir algún tipo de falla. La configuración del proyecto en estos casos es semejante a la descrita en Creando un Proyecto para Comunicación OPC. Sin embargo, cuando un Proyecto se crea con Redundancia de Half-Cluster y la comunicación con el sistema de supervisión se hará a través del Servidor OPC, es necesario seleccionar la opción de la Redundancy Configuration como habilitada durante el Wizard de creación de proyecto del MasterTool IEC XE. Al habilitar esta opción el proyecto creado tendrá el código necesario para funcionamiento de la comunicación con redundancia de conexión OPC. 118 4. Configuración En el caso redundante, una variable se declara dentro de la POU llamada NonSkippedPrg. Esta POU se ejecuta en ambos CPs, independiente del estado de redundancia. Dentro de esta POU se declara una variable del tipo BOOL, que se utiliza para el control de la conexión con el Servidor OPC llamado OPCRedundancyActive. Esta variable se puede acceder de cualquier punto de la aplicación, a través de todo el contexto, es decir, Application.NonSkippedPrg. OPCRedundancyActive. Se declara dentro del objeto Symbol Configuration con derecho solo de lectura por parte del SCADA. Cuando el valor de la variable es igual a TRUE los datos se leen a través de la conexión con este CP. De esta forma, toda vez que ocurre un cambio de estado entre los CPs la variable tiene su estado alterado, permaneciendo en el estado TRUE en el CP que está en el estado activo de redundancia. El código del programa NonSkippedPrg es el siguiente, en lenguaje ST: PROGRAM NonSkippedPrg VAR {attribute 'symbol' := 'read'} OPCRedundancyActive : BOOL; END_VAR IF fbRedundancyManagement.m_fbDiagnosticsLocal.eRedState = REDUNDANCY_STATE.ACTIVE THEN OPCRedundancyActive := TRUE; ELSE OPCRedundancyActive := FALSE; END_IF El código del programa NonSkippedPrg se puede editar teniéndose el cuidado de mantener el código arriba sin alteraciones. Este código testea el estado de la redundancia y llena una variable del tipo BOOL llamada OPCRedundancyActive, en función de este estado. En el caso de que el CP sea el Activo, el valor de la variable será TRUE, en caso contrario será FALSE. Esta variable recibe el attribute ‘symbol’ := ‘read’ para permitir que el Servidor OPC acceda a su contenido y defina de dónde se deberá leer la información. En el caso de que se decida añadir comunicación OPC después de que un proyecto haya sido creado, es posible configurar el OPC al añadir el código anterior en el programa NonSkippedPrg y añadir el objeto Symbol Configuration al proyecto. Para la configuración del CP redundante en el Servidor OPC es necesario seleccionar la opción Configuración Redundante en la pantalla de configuración según lo mostrado en la Figura 4-42. Al seleccionar esta opción, se utilizará siempre la opción Use TCP-/IP Blockdriver. Además, se habilitarán los campos IP Address PLC A y IP Address PLC B según lo descrito en la Tabla 4-65. Estas Direcciones de IP son las mismas configuradas en las interfaces Ethernet dentro del proyecto del CP con redundancia de Half-Cluster. Para facilitar la configuración al estar abierto un proyecto redundante, el botón Read Project Configuration se puede utilizar. ATENCIÓN: La redundancia de conexión del Servidor OPC se lleva a cabo por un Servidor solo. En los casos en que se desee más disponibilidad de los datos para los sistemas de supervisión se debe usar una arquitectura con Servidores SCADA redundantes. En estos casos, no es necesaria ninguna configuración en el Servidor OPC. Consulte las documentaciones del sistema SCADA para verificar cuáles son las configuraciones necesarias para el funcionamiento de la arquitectura redundante. Variables de Status y Calidad de la Comunicación OPC Para cada uno de los CPs creados en el Servidor OPC se generan variables de status llamadas _CommState y _CommStateOK. La variable _CommState indica el estado de la comunicación del Servidor OPC con CP. Este estado se puede interpretar por el Cliente OPC según la Tabla 4-66. 119 4. Configuración Estado Valor Descripción STATE_TERMINATE -1 Se la comunicación del Servidor OPC con el Cliente OPC se termina, este valor retornará. Al haber más de un Cliente OPC conectado al mismo tiempo, el retorno ocurrirá en la desconexión del último Cliente conectado. Este status a pesar de estar en la variable no se puede visualizar, pues solo se altera al no existir más conexión con un cliente. STATE_PLC_NOT_CONNECTED 0 El CP configurado en el Servidor OPC no está conectado. Puede suceder en el caso de que la configuración esté incorrecta (Dirección de IP del CP y/ o Gateway errados) o que el CP no esté disponible en aquel momento. STATE_PLC_CONNECTED 1 El CP configurado en el Servidor OPC no está conectado. Este es un estado transitorio durante la conexión. STATE_NO_SYMBOLS 2 No existen símbolos (variables) disponibles en el CP configurado en el OPC Server. Puede suceder cuando no existen símbolos o aun cuando no hay un proyecto cargado en el CP. STATE_SYMBOLS_LOADED 3 Finalizado el proceso de lectura de los símbolos (variables) del CP configurado en el Servidor OPC. Este es un estado transitorio durante la conexión. STATE_RUNNING 4 Tras la lectura de los símbolos (variables), el Servidor OPC ejecuta la actualización periódica de los valores de los símbolos disponibles en cada CP configurado. STATE_DISCONNECT 5 Ocurrió desconexión con el CP configurado en el servidor OPC. STATE_NO_CONFIGURATION 6 Cuando la configuración del OPC (almacenada en un archivo OPCServer.ini) posee una sintaxis errada, este será el status de la variable. De manera general, este comportamiento no se observa pues el MasterTool IEC XE mantiene esta configuración íntegra. Tabla 4-66. Descripción de los estados de la comunicación del Servidor OPC con el CP La variable _CommStateOK es una variable del tipo BOOL que indica si la comunicación entre el Servidor OPC y el CP está funcionando. Cuando el valor es TRUE, esto indica que la comunicación está funcionando correctamente. Si el valor es FALSE, no es posible por alguna razón comunicar con el CP. Más allá de monitorear el estado de la comunicación, el Cliente OPC puede acceder a informaciones sobre la calidad de comunicación. Los bits de calidad forman un byte y están distribuidos en tres grupos de bits: Calidad, Substatus y Límite. Los bits están distribuidos de la siguiente forma QQSSLL, en la cual QQ representa los bits de Calidad, SS los bits de Substatus y LL los bits de Límite. En este caso, los bits QQ son los más significativos en el byte, mientras que los bits LL son los menos significativos. QQ Valor de los Bits Definición Descripción 0 00SSSSLL Bad El valor leído no se puede usar porque hay algún problema en la conexión. Es posible monitorear el valor de _CommState diagnosticar el problema. 1 01SSSSLL Uncertain La calidad no se puede definir y se puede presentar en el campo Substatus. 2 10SSSSLL NA Este valor está reservado y no se utiliza por el estándar OPC. 3 11SSSSLL Good La calidad es buena y el valor leído se puede usar. Tabla 4-67. Descripción del valor de la Calidad OPC La Tabla 4-67 los valores posibles de la calidad. El Servidor OPC retorna solo valores con Calidad Good y Bad. Un Cliente OPC puede mantener la calidad como Uncertain en el caso de alguna falla 120 4. Configuración en la cual no consiga una conexión con el Servidor. En el caso de monitoreo de los 8 bits de calidad directamente del Servidor OPC los campos Substatus y Límite serán nulos y la Calidad Good se representará con el valor 192 y la calidad Bad con el valor 0. Límites de la Comunicación con Servidor OPC Para comunicación con el Servidor OPC existen algunas limitaciones que se deben respetar para el correcto funcionamiento de la aplicación. No se deben configurar para estar disponibles en el Servidor OPC más de 20.000 variables en cada CP. Por lo tanto, 20.000 variables es el límite máximo a comunicarse con un único CP. Además, al configurar las variables que estarán disponibles en el Servidor OPC, la cantidad de variables declarada en cada POU o GVL no debe sobrepasar el límite de 5.000. La Tabla 4-68 presenta los límites de la configuración del servidor OPC. Número máximo de variables en comunicación con un solo CP 20.000 Número máximo de variables declaradas en una única POU o GVL 5.000 Número máximo de CPs en un servidor OPC 16 Número máximo de conexiones simultáneas del servidor OPC en un mismo PC 8 Tabla 4-68. Límites de la Comunicación con el Servidor OPC ATENCIÓN: El número máximo de conexiones simultáneas de Servidor OPC en un mismo CP se comparte con las conexiones llevadas a cabo con el MasterTool IEC XE. O sea, la suma de conexiones con Servidor OPC y MasterTool IEC XE no debe sobrepasar el número máximo definido en la Tabla 4-68. La comunicación entre el Servidor OPC y el CP utiliza el mismo protocolo que se utiliza para la comunicación del MasterTool IEC XE con el CP. Este protocolo solo está disponible para las interfaces Ethernet de las UCPs de la Serie Nexto, no es posible establecer este tipo de comunicación con módulos de expansión Ethernet. Al establecerse una comunicación entre el Servidor OPC y el CP, estos dos elementos inician una serie de transacciones que buscan resolver la dirección de cada variable declarada, y optimizan la comunicación en régimen de lectura de datos. Además, en esta fase, también se resuelven las clasificaciones de los grupos de comunicación usados por algunos Clientes con el objetivo de optimizar la comunicación. Este proceso inicial requiere algún tiempo y depende de la cantidad de variables mapeadas. El tiempo aproximado de esta fase inicial con 5.000 variables es alrededor de 2 min. En los casos en que más variables se utilizan, este tiempo puede ser de hasta 4 min, dependiendo del tipo de dato y de las configuraciones de la red. Acceso a Datos a través de un Cliente OPC Tras la configuración del Servidor OPC, los datos disponibles en todos los CPs se pueden acceder por un Cliente OPC. En la configuración del Cliente OPC se debe seleccionar el nombre del Servidor OPC correcto. En este caso el nombre es CoDeSys.OPC.DA. La Figura 4-43 exhibe la selección del servidor en el driver cliente del software SCADA BluePlant. 121 4. Configuración ATENCIÓN: De la misma forma que el MasterTool IEC XE, algunas herramientas se necesitan ejecutar con derechos de administrador en el Sistema Operacional para el correcto funcionamiento del Cliente OPC. Dependiendo de la versión del sistema Operacional este derecho se debe autorizar al ejecutar el programa. Para dicha operación, pulse el botón derecho sobre el ejecutable de la herramienta y elija la opción Ejecutar como administrador. Figura 4-43. Servidor OPC Seleccionado en la Configuración del Cliente En los casos en que el servidor se encuentra remoto, puede que sea necesario añadir el camino de la red o la dirección de IP de la computadora donde se encuentra el servidor instalado. En estos casos hay dos opciones de configuración. Lo primero es configurar directamente, para eso, es necesario liberar los Servicios de COM/DCOM del Windows. Sin embargo, una forma más simple es utilizar una herramienta de tunneller que abstrae las configuraciones de COM/DCOM, más allá de hacer factible una comunicación más segura entre el Cliente y el Servidor. Para más informaciones sobre este tipo de herramienta consulte a NAP151 - Utilização do Tunneller OPC. Una vez que el Cliente se conecta en el Servidor, se pueden usar comandos de importación de TAGs. Estos comandos consultan informaciones declaradas en el CP, retornan una lista con todos los símbolos brindados por este. 122 4. Configuración Figura 4-44. Lista de Símbolos Consultados por el Cliente OPC La lista de variables seleccionadas se incluirá en la lista de comunicaciones del Cliente y se pueden utilizar, por ejemplo, en pantallas de un sistema SCADA. ATENCIÓN: El modo de simulación del software MasterTool IEC XE se puede utilizar para testeos de la comunicación OPC. Las informaciones sobre cómo configurarlo están presentes en la sección Testeo de la Comunicación OPC con el Uso del Simulador, del Manual del Usuario MasterTool IEC XE MU299800. EtherCAT EtherCAT es un protocolo con arquitectura maestro-esclavo de alto desempeño, para Ethernet determinística, que permite desempeño en tiempo real, pues actualiza 1000 E/S distribuidas en 30 µS o 100 ejes de servomotores a cada 100 µS usando par trenzado o cables de fibra óptica. Además, tiene topología flexible, que permite las conexiones en línea, árbol o estrella. Un frame Ethernet se puede procesar en tiempo real en vez de ser recibido, interpretado y copiado como datos del proceso en cada conexión. El FMMU (Fieldbus Memory Management Unit) en cada nodo Esclavo lee los datos que le son enviados al mismo tiempo en que el telegrama se encamina al próximo dispositivo. De una manera similar, los datos de entrada se insertan mientras el telegrama se pasa. Debido a eso, los frames se retrasan solo por algunos nanosegundos. Accesos a los terminales de Ethernet se pueden hacer en cualquier orden, porque la secuencia de datos es independiente del orden físico. Es posible ejecutar comunicación Broadcast, Multicast y comunicación entre los Esclavos. El protocolo EtherCAT permite una sincronización con precisión, que es necesaria, por ejemplo, en aplicaciones en las cuales varios ejes realizan movimientos coordinados simultáneamente, esto se puede realizar a través de un ajuste exacto del Distributed Clock. Hay también la posibilidad de configuración de dispositivos que, en contraste con la comunicación síncrona, tiene un elevado grado de tolerancia dentro del sistema de comunicación. La configuración de módulos EtherCAT inicialmente se determina por los Archivos de Descripción de Dispositivo de los dispositivos Maestro y Esclavo utilizados y puede ser alterado por el usuario en las cajas de diálogo del Editor de Configuración. Sin embargo, para aplicaciones convencionales y con el objetivo de tener un manejo tan fácil como posible, la configuración en larga escala se puede automatizar, al elegir el modo Autoconfig en Parámetros del Maestro. 123 4. Configuración Observe la posibilidad de alteración de los parámetros de configuración del Maestro y Esclavo también en el modo operacional, a través de las instancias de Maestro y Esclavo, según la disponibilidad del dispositivo en cuestión. Instalando e Insertando Dispositivos EtherCAT Con el fin de ser posible insertar y configurar dispositivos EtherCAT como objetos en el árbol de dispositivos, los dispositivos Esclavos se deben instalar. El dispositivo Maestro se instala automáticamente por la instalación estándar del MasterTool IEC XE. El Maestro EtherCAT define cuáles Esclavos se pueden insertar. Para instalar los dispositivos Esclavos se debe abrir el diálogo Device Repository, utilizar el filtro EtherCAT XML Device description Configuration File (*.xml) y seleccionar los archivos de descripción de dispositivo (EtherCAT XML Device Description / ESI EtherCAT Slave Information), suministrado con el hardware. Las descripciones para los Esclavos están disponibles como archivos XML (tipo de archivo: *.xml). Un Maestro EtherCAT puede ser añadido al Device Tree a través del comando Add Device, a través del menú de contexto de los conectores NET de la UCP. Abajo de un maestro, uno o más esclavos se pueden insertar, al seleccionar un Maestro EtherCAT y ejecutar el comando Add Device (menú de contexto del Maestro EtherCAT) o ejecutar el comando Buscar Dispositivos. Más allá de las topologías de línea y de árbol, el MasterTool IEC XE también soporta la topología en estrella de EtherCAT. Para la configuración de una topología en estrella EtherCAT, juntas especiales EtherCAT son necesarias (en el ejemplo: Beckhoff EK1122). Una estrella EtherCAT modular se puede ser realizar al utilizar varias juntas. Dispositivos individuales o una sección de línea EtherCAT completa se pueden conectar en las puertas de junta. Una junta EtherCAT está marcada con el ícono . El ejemplo de Árbol de Dispositivos en la Figura 4-45 muestra diferentes posibilidades. Figura 4-45. Ejemplo de Configuración EtherCAT ATENCIÓN: - Permitido solamente una instancia de Maestro EtherCAT por proyecto. - Permitido solamente en CPs modelos NX3020 y NX3030. - Permitido solamente en conectores NET de las CPs. - No se puede usar cuando las NETs están configuradas como redundantes. 124 4. Configuración - No se puede usar cuando el proyecto tiene redundancia de cluster. - No se pueden instanciar otros drivers en la misma puerta NET que el Maestro EtherCAT. - Permitido un máximo de 128 esclavos EtherCAT por proyecto. Buscar Dispositivos El comando Scan for Devices, disponible en el menú de contexto del Maestro EtherCAT, ejecuta una búsqueda por los dispositivos Esclavos instalados físicamente en la red EtherCAT del CP actualmente conectado. Eso significa que con este comando es posible detectar y visualizar los componentes de hardware en la ventana presentada en la figura a continuación, lo que permite que el usuario pueda mapearlos directamente en el Device Tree del proyecto Es importante resaltar que, cuando el comando Scan for Devices se selecciona, una conexión con el CP se establece automáticamente antes que inicie la búsqueda y termina cuando la búsqueda termina. Así, para que este comando se ejecute por la primera vez, la conexión del Gateway se debe configurar y se debe hacer un download del proyecto con un Maestro EtherCAT configurado en el CP. En el caso de que hayan futuros incrementos de dispositivos Esclavos, para ejecutar este comando es necesario que la red EtherCAT esté parada, para eso, poner en TRUE el bit bStopBus presente en las variables de Diagnóstico del Maestro EtherCAT. Cuando el comando se ejecuta, el campo Scanned Devices contendrá una lista de todos los dispositivos y módulos encontrados durante la última verificación. Para añadirlos al proyecto, basta pulsar el botón Copy All Devices To Project. Es posible, también, ejecutar una comparación entre los dispositivos encontrados en la búsqueda y los presentes en el proyecto, al seleccionar la caja Show differences to project. Al añadir un módulo Maestro EtherCAT al proyecto y utilizar el comando Buscar Dispositivos, usted tendrá una lista con todos los Esclavos EtherCAT disponibles. Aparecerán entradas escritas en negrita, en el caso de que haya más de un dispositivo con la misma descripción. Al pulsar dos veces sobre esta entrada, una lista se abrirá y el dispositivo deseado se puede seleccionar. Tras concluir las modificaciones en la configuración de la red EtherCAT, es necesario que se ejecute un nuevo download del proyecto, para que las modificaciones se apliquen. 125 4. Configuración Figura 4-46. Diálogo Buscar Dispositivos para EtherCAT Diagnóstico de Variables A través de la inserción de un Maestro EtherCAT y Esclavo se añade una variable de diagnóstico para el dispositivo en la GVL Diagnostics. Esta variable proporciona información sobre el estado del dispositivo. Hay dos tipos de variables: una para el Maestro EtherCAT y otra para los esclavos EtherCAT. Cada variable tiene información específica sobre el dispositivo. Los diagnósticos y comandos suministrados están descritos en las tablas a continuación. Variable DG_EtherCAT_Master.* tDiag.bRunning Tipo BOOL tDiag.bError BOOL tDiag. eLastErrorCode ETC_LASTERROR tDiag.bDistributedClock InSync BOOL Valores Posibles Descripción FALSE o TRUE Si esta variable es TRUE, la transferencia de todos los parámetros de configuración se finalizó con éxito, sin errores encontrados y el bus no ha sido parado por el comando de usuario. La comunicación está funcionando. FALSE o TRUE Esta variable será TRUE si un error se detecta durante la inicialización de la pila EtherCAT o si durante la operación, la comunicación con los esclavos se interrumpe si ningún mensaje más se puede recibir (por ejemplo, debido a una falla en el cable). La causa del error se puede descubrir con el auxilio de la lista de logs por STRING de error. Las informaciones con respecto a los valores posibles para este diagnóstico, bien como su descripción se encuentran en la Tabla 4-70. FALSE o TRUE 126 Si DC se usa, el CLP se sincronizará con el primer esclavo EtherCAT cuya configuración DC está activa. Esta variable es TRUE enseguida de que esta sincronización termine con éxito. Esta señal, por ejemplo, se puede usar para iniciar bloques funcionales de SoftMotion en el caso de compatibilidad con el dispositivo después que el CLP está en modo sincronizado, en caso contrario 4. Configuración saltos en la posición pueden ocurrir. En la inicialización del CLP, la variable es FALSE y cambiará para TRUE después de algunos segundos. Si la sincronización se pierde debido a cualquier falla, la variable irá a FALSE tDiag.bReserved_00 BOOL - Espacio reservado. tDiag.bReserved_01 BOOL - Espacio reservado. byReserved_00 BYTE - Espacio reservado. tCommand.bRestart BOOL FALSE o TRUE En el borde de subida, el maestro reiniciará por completo. Todos los parámetros de configuración se recargarán. FALSE o TRUE Cuando esta variable es TRUE, se detiene la comunicación. Paquetes EtherCAT no ser enviarán más. En la mayoría de los dispositivos, una reinicialización es necesaria, porque están en estado de error. tCommand.bStopBus BOOL tCommand. wDCInSyncWindow BOOL 0..65535 Ventana de tiempo para bDistributedClockInSync. El jitter tiene que estar dentro de esta ventana para que la variable bDistributedClockInSync permanezca en TRUE. Valor estándar: 50 microsegundos. tCommand. bySlaveUpdatedbyCycl e BOOL 0..128 Este valor define el número de esclavos que se leen por ciclo para llenar las variables de diagnósticos de los esclavos. Valor 0 significa que ningún diagnóstico de esclavo se actualizará. tCommand. bReserved_00 BOOL - tCommand. bReserved_01 BOOL - byReserved_01 BYTE - Espacio reservado. Espacio reservado. Espacio reservado. Tabla 4-69. Diagnósticos y Comandos del Maestro EtherCAT Código Enumerable 00 NO_ERROR Sin error, en funcionamiento. Descripción 01 NO_COMM Sin comunicación. Más de 100 paquetes no fueron recibidos. Posible falla en el cable del maestro. 02 WRONG_WORKING_COUNTER 03 DC_TIME_ZERO Working counter para processdata está con error. Uno o más esclavos no están operacionales o faltando y el working counter esperado no se encuentra. El tiempo DC del esclavo es siempre cero -> quizás conectores IN y OUT estén errados y ningún tiempo se puede leer de la referencia de tiempo. 04 OPEN_FIRSTADAPTER_FAILED 05 OPEN_SECONDADAPTER_FAILED No se puede abrir el primer adaptador de red. 06 ADAPTER_MISMATCH Segundo adaptador de red utiliza el MAC-ID como la primera interfaz. 07 NO_SLAVES_FOUND Error en inicialización de los esclavos: posiblemente hay esclavos que faltan o no hay comunicación. 08 VENDOR_ID_WRONG VendorID no es igual. 09 PRODUCT_ID_WRONG ProductID no es igual. 10 NUMBER_DEVICE_MISMATCH 11 SDO_WRITE_ERROR Error en la escritura SDO en el inicio del proceso. 12 SDO_TIMEOUT Timeout del SDO en la inicialización del proceso. 13 EMERGENCY_RECEIVED 14 IDN_WRITE_ERROR 15 IDN_TIMEOUT No se puede abrir el segundo adaptador de red. Lectura de ProductID o VendorID sin éxito, más esclavos en la configuración que en la arquitectura real. Emergencia recibida del dispositivo. Error en la escritura IDN en la inicialización del proceso. Timeout del IDN en la inicialización del proceso. Tabla 4-70. Códigos de Error del Maestro EtherCAT 127 4. Configuración Variable DG_Escravo.* tDiag.wState Tipo Valores Posibles ETC_SLAVE_STA TE ETC_SLAVE_BOOT=3 ETC_SLAVE_INIT=1 ETC_SLAVE_PREOPERATIO NAL=2 ETC_SLAVE_SAVEOPERATI ONAL=4 ETC_SLAVE_OPERATIONAL =8 BOOL Franja DWORD tDiag. dwVendorID tDiag. dwProductID ETC_LASTERROR tDiag. dwRevisionID BOOL Descripción Estado actual del esclavo. Después de la inicialización de la pila EtherCAT, esta variable retorna el vendorID leído del esclavo. Franja DWORD Después de la inicialización de la pila EtherCAT, esta variable retorna el productID leído del esclavo. Franja DWORD Después de la inicialización de la pila EtherCAT, esta variable retorna el revisionID leído del esclavo. Si un mensaje se recibe, entonces esta información se almacena dentro del esclavo y se podrá leer en la aplicación por esta variable. En añadidura también un mensaje de log se añade. Más informaciones sobre este diagnóstico se encuentran en la Tabla 4-72. tDiag. tLastEmergency . ETC_CO_Emergen cy tDiag.bReserved _01 BOOL - byReserved_00 BYTE - Espacio reservado. Espacio reservado. Tabla 4-71. Diagnósticos del Esclavo EtherCAT Variable DG_Escravo.tDiag.t LastEmergency.* wErrorCode Tipo WORD Código en Hexa Descripción 00XX Error de Reset o Sin error. 10XX Error genérico. 20XX Corriente. 21XX Corriente, interior del dispositivo. 22XX Corriente dentro del dispositivo. 23XX Corriente, fuera del dispositivo. 30XX Tensión. 31XX Tensiones principales. 32XX Tensión en el dispositivo. 33XX Tensión de salida. 40XX Temperatura. 41XX Temperatura de Ambiente. 42XX Temperatura del dispositivo. 50XX Hardware del dispositivo. 60XX Software del dispositivo. 61XX Software Interno. 62XX Software de usuario. 63XX Conjunto de datos. 70XX Módulos Adicionales. 80XX Monitoreo. 81XX Comunicación. 82XX Error de protocolo. 8210 PDO no se procesa debido a un error de tamaño. 8220 Tamaño del PDO excedido. 128 4. Configuración byErrorRegister BYTE tDiag.tLastEmergen cy.abyErrorField ARRAY[0..5] OF BYTE 90XX Error externo. A000 Transición de PRE-OPERATIONAL para SAFEOPERATIONAL sin éxito. A001 Transición de SAFE-OPERATIONAL para OPERATIONAL sin éxito. F0XX Funciones adicionales. FFXX Dispositivo específico. Franja BYTE Registrador de error. 0000-9FFF Campo de error específico para Fabricante. A000-EFFF Datos de diagnóstico. F000-FFFF Campo de error específico para Fabricante. Tabla 4-72. Contenido de ETC_CO_Emergency Configuración del Maestro EtherCAT A continuación se listan las opciones para la ejecución de la configuración de un Maestro EtherCAT, tal como se define en el Device Description File. Parámetros del Maestro A continuación se presentan los parámetros generales que se encuentran en la pantalla inicial de configuración del Maestro EtherCAT, Figura 4-47. Figura 4-47. Diálogo de Configuración del Maestro EtherCAT Configuración del Dispositivo Descripción Estándar de Fábrica Posibilidades Autoconfig Master/Slaves Habilita la configuración automática del Maestro y de los Esclavos. Marcado Marcado Desmarcado Cycletime [µs] Configura el período de tiempo en el cual debe enviarse un nuevo telegrama al bus. 100000 2000 a 1000000 Sync Offset [%] Ajusta el desplazamiento de la interrupción de sincronización del Esclavo EtherCAT para 20 -50 a 50 129 4. Configuración el ciclo del CP. Sync Window Monitoring Si activada, esta opción permite controlar la sincronización de los Esclavos. Desmarcado Marcado Desmarcado Synch Window [µs] Tiempo para la Ventana de Monitoreo de Sincronización. 1 1 a 32768 Use LRW instead of LWR/LRD Habilitar los comandos combinados de lectura y escritura. Desmarcado Marcado Desmarcado Enable Messages per Task Si activada, los comandos lectura y escritura, que están manejando con mensajes de entrada y salida se podrán hacer en diferentes tareas. Desmarcado Marcado Desmarcado Auto Restart Slaves Reinicia los esclavos cuando se interrumpe la comunicación. Marcado Marcado Desmarcado Number of Devices Read per Cycle Define el número de Esclavos que son leídos por ciclo para llenar las variables de diagnóstico. El valor '0' significa que ningún diagnóstico de Esclavo se actualizará. 128 0 a 128 Image In Address Primera dirección del primer Esclavo para los datos de entrada 16#1000000 16#1 a 16#1F000000 Image Out Address Primera dirección lógica del primer Esclavo para los datos de salida. 16#2000000 16#1 a 16#1F000000 Tabla 4-73. Configuraciones del Maestro EtherCAT Notas: Autoconfig Master/Slaves: Si esta opción está activa, la mayor parte de la configuración del Maestro y Esclavo se hará automáticamente, basándose en los archivos de descripción y cálculos implícitos. En este caso, el diálogo de configuraciones FMMU / Sync no estarán disponibles. Si esta no está activa, las opciones Dirección Imagen In y Dirección Imagen Out estarán disponibles para el usuario. ATENCIÓN: El modo Autoconfiguración se activa por estándar y, generalmente, suficiente y fuertemente recomendado para aplicaciones estándar. Si la opción no está activa, todas las definiciones de configuración para el Maestro y el Esclavo(s) tendrán que hacerse manualmente y un conocimiento especializado es necesario. Para la configuración de una comunicación Esclavo hacia Esclavo, la opción Autoconfiguración tiene que ser desactivada. Cycletime: Periodo de tiempo tras el cual, un nuevo telegrama de datos se debe enviar al bus. Si la funcionalidad Distributed Clock está activada, el valor de este parámetro se transferirá a los clocks de los Esclavos. Así, una sincronización precisa de intercambio de datos se puede alcanzar, lo que particularmente es importante en los casos en que los procesos distribuidos especialmente exigen acciones simultáneas. Entonces, una base de tiempo muy precisa para toda la red, con un jitter significativamente menor que un microsegundo, se puede alcanzar. Sync Offset: Este valor permite ajustar el desplazamiento de la interrupción de sincronización del Esclavo EtherCAT para el ciclo del CP. Normalmente, el ciclo de tarea del CP comienza 20% más tarde que la sincronización de interrupción de los Esclavos. Esto significa que la tarea del CP se puede retrasar por el 80% del tiempo de ciclo y ningún mensaje se perderá. 130 4. Configuración Sync Window: Si la sincronización de todos los Esclavos está dentro de esta ventana del tiempo, el diagnóstico del Maestro EtherCAT bDistributedClockInSync se establece como TRUE. Si lo contrario, como FALSE. Cuando Distributed Clock se utiliza, es altamente recomendado usar una tarea dedicada con alta prioridad como Bus Cycle Task del maestro EtherCAT. De esta manera, es necesario que se utilice Perfiles de Proyecto que hagan factible la creación de nuevas tareas, crear una tarea cíclica con prioridad 0 (tarea de tiempo real), y atribuir la Tarea Cíclica de Bus del maestro a esta nueva tarea en la pestaña EtherCAT I/O Mapping del Maestro EtherCAT. V wDCInSyncWindow, al configurar cuál el jitter máximo permitido en la sincronización entre maestro y esclavos. Use LRW instead of LWR/LRD: La activación de esta opción habilita la comunicación Esclavo hacia Esclavo, pues, al contrario de comandos separados de lectura (LRD) y escritura (LWR), comandos combinados lectura/escritura (LRW) se utilizarán. Auto Restart Slaves: Al habilitar esta opción, el Maestro reiniciará los Esclavos en cuanto la comunicación se termine, por lo tanto, la variable bError en los diagnósticos del Maestro EtherCAT en la GVL Diagnostics no irá a TRUE. Image In Address and Image Out Address: Estas definiciones solo se podrán editar si el modo Autoconfig está desactivado, en caso contrario esto se hará automáticamente y estos parámetros estarán invisibles. Diagnostics Message: Muestra algunas informaciones o mensajes de error de la pila. Los mensajes también se registran en la guía de Log del CP, accedida por el ícono Device, en el Device Tree. Esta opción sólo está visible cuando el Maestro EtherCAT está en modo Online. Bus Load: Este valor muestra la carga del bus en el adaptador de red, esta opción solo se vuelve visible cuando el Maestro EtherCAT está en modo Online. Mapeo de E/S Esta guía del editor de configuración del Maestro EtherCAT ofrece la posibilidad de atribuir las variables de proyecto a las respectivas entradas y salidas del EtherCAT. Así, las variables del Maestro EtherCAT se pueden controlar por la aplicación de usuario. Además, podemos elegir la opción de Bus Cycle Task a través de la lista de selección, en la cual podemos alterar la tarea que se desea utilizar. Todas las tareas añadidas al proyecto estarán presentes en esta lista. Esa tarea sirve para efectuar las operaciones del Maestro EtherCAT. La MainTask es la opción estándar de este campo. 131 4. Configuración Figura 4-48. Diálogo I/O Mapping Guías Status e Información La guía Status do editor del editor de configuración del Maestro EtherCAT brinda informaciones de estado (por ejemplo, 'Ejecutando', 'Parado') y mensajes de diagnóstico específicos del dispositivo y del sistema de bus interno. El diálogo Information, presente en el editor de configuración del Maestro EtherCAT, muestra, en el caso de que estén disponibles, las siguientes informaciones generales para el módulo: Nombre, Proveedor, Tipo, Número de Versión, Categorías, Número de Orden, Descripción, Imagen. Configuración del Esclavo EtherCAT A continuación, se listan las principales opciones de configuración para un Esclavo EtherCAT, tal como está definido en el Device Description File. Parámetros del Esclavo A continuación se presentan los parámetros generales que se encuentran en la pantalla inicial de configuración del Esclavo EtherCAT. Estos campos estarán disponibles solamente si el modo Autoconfig (Maestro) no está activado. 132 4. Configuración Figura 4-49. Diálogo de Configuración del Esclavo EtherCAT Configuración del Dispositivo Descripción Estándar de Fábrica Posibilidades AutoInc Address Dirección Autoincremental (16 bits), definida por la posición del Esclavo en la red. - -65535 a 0 EtherCAT Address Dirección final del Esclavo, asignado por el Maestro durante la inicialización. Esta dirección es independiente de la posición en la red. - 1 a 65535 Enable Expert Settings Habilita las opciones de configuración avanzadas del Esclavo. Desmarcado Marcado Desmarcado Optional Declara el Esclavo como Opcional. Desmarcado Marcado Desmarcado Select DC Presenta todas las configuraciones, para 133 4. Configuración Configuración del Dispositivo Descripción Estándar de Fábrica Posibilidades Distributed Clocks, brindadas por el Device Description File. Enable Distributed Clock Habilita las opciones de configuración de Distributed Clock. Desmarcado Marcado Desmarcado Sync Unit Cycle [µs] Presenta el Tiempo de Ciclo configurado en el Maestro. 100000 2000 a 1000000 Enable Sync 0 Habilita las configuraciones de la unidad de sincronización Sync 0. Desmarcado Marcado Desmarcado Sync Unit Cycle (Sync 0) Al seleccionar esta opción, el factor elegido se multiplicará por el valor en Sinc.Unidad de Ciclo. Desmarcado Marcado Desmarcado User Defined (Sync 0) Si está marcada, el tiempo deseado en microsegundos puede introducirse en el campo Tiempo de Ciclo (μs). Desmarcado Marcado Desmarcado Cycle Time [µs] (Sync 0) Muestra el tiempo de ciclo actualmente ajustado. 100000 1 a 2147483647 Shift Time [µs] (Sync 0) Tiempo entre eventos de sincronización y Output Valid o Input Latch. 0 -2147483648 a 2147483647 Enable Sync 1 Habilita las configuraciones de la unidad de sincronización Sync 0. Desmarcado Marcado Desmarcado Sync Unit Cycle (Sync 1) Al seleccionar esta opción, el factor elegido se multiplicará por el valor en Tiempo de Ciclo (µs).Sync 0. Desmarcado Marcado Desmarcado User Defined (Sync 1) Si está marcada, el tiempo deseado en microsegundos puede introducirse en el campo Tiempo de Ciclo (μs). Desmarcado Marcado Desmarcado Cycle Time [µs] (Sync 1) Muestra el tiempo de ciclo actualmente ajustado. 100000 1 a 2147483647 Shift Time [µs] (Sync 1) Tiempo entre eventos de sincronización y Output Valid o Input Latch. 0 -2147483648 a 2147483647 Check Vendor ID Si desmarcado, deshabilita la Verificación del ID del Proveedor. Marcado Marcado Desmarcado Check Product ID Si desmarcado, deshabilita la Verificación del ID del Producto. Marcado Marcado Desmarcado SDO Access Configura una referencia para la verificación del Tiempo de Acceso SDO - 0 a 100000 I -> P (Timeouts) Configura una referencia para la verificación del tiempo entre el cambio del estado Init para Preoperacional - 0 a 100000 P -> S/S -> O Configura una referencia para la verificación del tiempo entre el cambio del estado - 0 a 100000 134 4. Configuración Configuración del Dispositivo Descripción Estándar de Fábrica Posibilidades Preoperacional para Seguridad Operacional y de Seguridad Operacional para Operacional. Cycle Units Asigna la Unidad de Ciclo al microprocesador local. Desmarcado Marcado Desmarcado Latch Unit 0 Asigna la Latch Unit 0 al microprocesador local. Desmarcado Marcado Desmarcado Latch Unit 1 Asigna la Latch Unit 1 al microprocesador local. Desmarcado Marcado Desmarcado Tabla 4-74. Configuraciones del Esclavo EtherCAT Notas: AutoInc Address: Esta dirección se usa solo durante la inicialización, cuando el Maestro le está atribuyendo las direcciones EtherCAT a los Esclavos. Cuando, para este propósito, el primer telegrama recorre los Esclavos, cada Esclavo de lectura rápida aumenta su Dirección AutoInc por 1. El Esclavo con la dirección 0, finalmente, recibirá los datos. Optional: Si un Esclavo se declara como Optional ningún mensaje de error se creará en el caso de que el dispositivo no exista en el sistema de bus. Si esa opción es activada, una dirección de estación se debe almacenar en el dispositivo Esclavo. Así, una dirección Station alias se debe definir y grabar en la EEPROM. Esta opción solo está disponible si la opción Autoconfig Master/Slaves está activada en las configuraciones del Maestro EtherCAT, y si esta función es soportada por el Esclavo EtherCAT. Enable Distributed Clock: Si la funcionalidad Distributed Clock se activa, el tiempo de ciclo de cambio de datos, mostrado en el campo Sync Unit Cycle (µs) se determinará por el Master Cycle Time. Así, el clock Maestro puede sincronizar el cambio de datos dentro de la red. Las definiciones para manejar la(s) unidad(es) de sincronización dependen del Esclavo. Enable Sync 0: Si esa opción se activa, la unidad de sincronización Sync0 se utiliza. Una unidad de sincronización describe un conjunto de datos del proceso que son intercambiados de forma síncrona. Sync Unit Cycle (Sync 0): Si esta opción está activa, el Master Cycle Time, multiplicado por el factor elegido se utilizará como tiempo de ciclo de sincronización para el Esclavo. El campo Cycle Time (µs) muestra el tiempo de ciclo actualmente definido. Shift Time (µs): El Tiempo de desplazamiento describe el tiempo entre los eventos de sincronización (Sync0, Sync1) y las Outputs Valid o Input Latch. Valor grabable, si el esclavo soporta transferencia de Outputs Valid o Input Latch. Enable Sync 1: Si esa opción se activa, la unidad de sincronización Sync1 se utiliza. Una unidad de sincronización describe un conjunto de datos del proceso que se intercambian de forma síncrona. Sync Unit Cycle (Sync1): Si esta opción está activa, el Cycle Time del grupo Sync0, multiplicado por el factor elegido se utilizará como tiempo de ciclo de sincronización para el Esclavo. El campo Cycle Time (µs)muestra el tiempo de ciclo actualmente definido. Current State: Se muestra el estado actual del Esclavo. Valores posibles: Init, Pre-Operational, Safe-Operational, Operational. Si el Estado es Operacional, la configuración del Esclavo se cerró correctamente. Check VendorID and ProductID: Por estándar, en la inicialización del sistema el ID del Proveedor y/o el ID del Producto se verificarán contra las configuraciones actuales. Si se detecta alguna diferencia, el bus se interrumpirá y ninguna acción adicional se ejecutará. Eso sirve para evitar el download de una configuración errada. Estas opciones tienen la finalidad de desactivar esta verificación. 135 4. Configuración SDO Access: Por estándar, no hay tiempo límite definido para la acción de envío de una lista SDO al iniciar el sistema. Sin embargo, si hay la necesidad de verificar si esta acción sobrepasa cierto tiempo, esto se debe especificar en este campo. I -> P: Por estándar, no hay tiempo límite definido para la acción de cambio del modo Init para PreOperational. Sin embargo, si hay la necesidad de verificar si esta acción sobrepasa cierto tiempo, esto se debe especificar en este campo. P -> S / S-> O: Por estándar, no hay tiempo límite definido para la acción de cambio del modo PreOperational para Safe-Operational y respectivamente de Safe-Operational para Operational. Sin embargo, si hay la necesidad de verificar si esta acción sobrepasa cierto tiempo, esto se debe especificar en este campo. DC cycle unit control: Elija la(s) opción(es) deseada(s), relativa a las funciones de Distributed Clock, con el fin de definir lo que se debe atribuir al microprocesador local. El control se realiza en el registro 0x980 del Esclavo EtherCAT. Las configuraciones posibles son: Cyclic Unit, Latch Unit 0, Latch Unit 1. Station Alias: Esta definición solo se vuelve visible si la opción Opcional está activada o si el dispositivo Esclavo soporta direcciones de alias (definido en el Device Description File). Enable: Si la definición de Optional no está activa, esa configuración se puede activar si es soportada por la descripción del dispositivo Esclavo, pues permite la atribución directa de una dirección de alias, con el fin de obtener la dirección de los Esclavos independiente de su posición dentro del bus. Si la opción Optional está activada, esta caja de selección estará desactivada. Write to EEPROM: Este comando sólo es visible en modo online. Eso permite escribir la dirección definida en la EEPROM del Esclavo. Si no es soportado por el Esclavo, este comando no tendrá ningún efecto y el dispositivo no funcionará como Optional Slave. Actual Address: Este campo, visible sólo en modo online, muestra la dirección real del Esclavo. Se puede utilizarlo para verificar el éxito del comando Write to EEPROM. FMMU/Sync Este diálogo solo se suministrará en una guía de un editor de configuración Esclavo EtherCAT, si el Autoconfig Mode en el Maestro está desactivado. Eso muestra los FMMUs y Gerentes de sincronización.del Esclavo, según lo definido por el Device Description File. Estas configuraciones se pueden retrabajar, por ejemplo, para configurar una comunicación Esclavo hacia Esclavo. ATENCIÓN: Estas son las Configuraciones Avanzadas, que generalmente no son necesarias para aplicaciones estándar. 136 4. Configuración Figura 4-50. Diálogo FMMU/Sync FMMU Esta tabla muestra las Unidades del Gerenciador de Memoria Fieldbus (FMMUs - Fieldbus Memory Management Unit) del Esclavo que se utilizan para el tratamiento de los datos del proceso. Cada mapeo de la dirección lógica GlobStartAddr en una dirección física Ph. StartBit es definida. Es posible ejecutar un mapeo bit a bit. Nuevas unidades se pueden añadir y las ya existentes se pueden editar por el diálogo Editar FMMU, que se puede abrir a través de los botones Add… y Edit.... Gerenciador Sync Esta tabla muestra el Gerenciador de Sincronización del Esclavo. Para cada Tipo de Gerenciador disponible (Caja de Entrada, Caja de Salida, Entradas, Salidas) una Dirección Inicial física, el tipo de Acceso, el Buffer y la Dirección Física, donde las Interrupciones se tienen que enviar, se definen. Nuevos Gerenciadores de Sincronización se pueden añadir y los existentes se pueden abrir a través de los botones Add… y Edit.... Datos de Proceso y Datos de Proceso Avanzados La guía Datos del Proceso del editor de configuración del Esclavo EtherCAT muestra los datos del proceso de entrada y de salida del Esclavo, cada uno definido por nombre, tipo e índice del Device Description File, como se puede ver en la Figura 4-51. Las entradas seleccionadas (por leer) y salidas (por escribir) del dispositivo estarán disponibles en el diálogo I/O Mapping de como salidas y entradas para el CP, en el cual las variables del proyecto se pueden mapear. Con el fin de modificar la selección actual, pulse primero con el mouse sobre la caja de selección de los datos seleccionados en el momento, para cancelar la selección. Después de eso, es posible seleccionar otro. 137 4. Configuración Figura 4-51. Diálogo Process Data El diálogo Expert Process Data solo estará visible en el editor de configuración del Esclavo EtherCAT si la opción Enable Expert Settings del Esclavo está activada. Eso brinda una visión más detallada de los datos del proceso, más allá de que se presenta en la pestaña Process Data. Además, en esta pestaña, es posible habilitar el download de la Atribución PDO y la Configuración PDO. ATENCIÓN: Si el Esclavo no acepta la configuración del PDO, quedará en modo Pre-Operational y ningún cambio de datos en tiempo real será posible. 138 4. Configuración Figura 4-52. Diálogo Expert Process Data Esta guía está dividida en cuatro secciones y dos opciones: Sync Manager: Lista de SM (Sync Manager) con el tamaño de los datos y el tipo de PDO. PDO Assignment: Lista de PDO asignados al Sync Manager seleccionado. La caja de selección activa, el PDO y canales E/S se crean. Se parece a las ventanas de configuración de PDO simple. Aquí solo PDOs se pueden activar o desactivar. PDO List: Lista de todos los PDOs definidos en el Device Description File. PDOs individuales se pueden apagar, editar o añadir por medio de la ejecución del respectivo comando en el menú de contexto. PDO Content: Muestra el contenido del PDO seleccionado en la sección arriba. Las inscripciones se pueden apagar, editar o añadir por medio de la ejecución del respectivo comando a partir del menú de contexto. PDO Assignment: Si se activa un comando de escritura CoE se añadirá al índice 0x1CXX para escribir la configuración PDO 0x16XX o 0x1A00. PDO Configuration: Si se activan varios comandos de la grabación CoE se añadirán al escribir el mapeo PDO en el Esclavo. ATENCIÓN: Si el Esclavo no soporta la configuración PDO, el download de esta puede resultar en un error de Esclavo. Esta función debe ser utilizada sólo por expertos. 139 4. Configuración Edición de la Lista PDO Figura 4-53. Diálogo Editar Lista PDO Este diálogo se abre a través del menú de contexto del área Lista PDO, presentada en la Figura 4-52. Siguen algunas explicaciones de las opciones de configuración presentes en este diálogo. Name: Nombre de la entrada PDO. Index: Índice del PDO en edición. TxPDO (Input): Si activo, el PDO se transferirá del Maestro al Esclavo. RxPDO (Output): Si activo, el PDO se transferirá del Esclavo al Maestro. Mandatory: El PDO es necesario y no se puede desmarcar en el área PDO Assignment. Fixed Content: El contenido del PDO es fijo y no se puede cambiar. No se puede agregar entradas en el Panel PDO Content. Virtual PDO: Reservado para uso futuro. Exclude PDOs: Es posible definir PDOs que se pueden, o no, seleccionar juntos al PDO en edición en el área PDO Assignment, o en la guía Datos del Proceso. Si un PDO se marca en esta lista, este no se podrá seleccionar, volviéndose gris, en el ambiente PDO Assignment cuando el PDO en edición se seleccione. SyncUnit: ID del Gerenciador Sync del PDO para el cual se debe atribuir. Definición del Contenido del PDO Este diálogo se accede a través del menú de contexto del área PDO Content y su contenido, más allá de la posibilidad de acceso de esta ventana, tiene variación según el Esclavo EtherCAT utilizado. 140 4. Configuración Figura 4-54. Diálogo Seleccionar Ítem del Directorio del Objeto Parámetros de Inicialización En la guía Startup Parameters, se pueden definir parámetros para el dispositivo, que se repasarán por los SDOs (Service Data Objects) o IDN en la inicialización del sistema. Las opciones presentes en este ambiente, más allá de la posibilidad de acceso, tienen variación según el Esclavo EtherCAT utilizado y están presentes en su Device Description File. Online El diálogo Online solo será visible en el editor de configuración Esclavo EtherCAT, si la opción Enable Expert Config del Esclavo está habilitado y la Application está conectada al dispositivo. Provee una visión con informaciones de status de los Esclavos y funciones para transferir archivos a los Esclavos sobre EtherCAT (FoE). 141 4. Configuración Figura 4-55. Diálogo Online Esta guía se divide en los siguientes grupos funcionales: State Machine: Los botones Inicio (Init), Pre-Op (Preoperacional), Op (Operacional) y Safe-Op (Seguridad Operacional) se pueden utilizar para el objetivo de debugging, dichos botones hacen que el Esclavo vaya a los respectivos estados. File access over EtherCAT: Para transferir archivos de firmware al Esclavo o a partir de él, pulse el botón Bootstrap para cambiar el Esclavo al Modo Bootstrap. El Download y Upload de archivos del firmware se pueden hacer con los botones correspondientes. Una caja de diálogo para guardar o abrir el archivo de firmware se abrirá. En esta caja se solicitarán usuario y contraseña para ejecutar la transferencia de archivos. Esta información la provee el dispositivo Esclavo y la documenta en el datasheet del mismo. E2PROM access: La configuración Esclavo se puede leer de la E2PROM o escribir en la E2PROM. Aquí, tal cual la transferencia de firmware, una caja de diálogo, para abrir o guardar archivos, se abrirá. El comando escribir E2PROM XML se puede usar para escribir la configuración del Esclavo directamente del archivo XML hacia el dispositivo. Este comando solo se habilitará si existen datos de configuración en el archivo XML (sección <ConfigData>). Mapeo de E/S Esta guía del editor de configuración del Esclavo EtherCAT ofrece la posibilidad de atribuir las variables de proyecto a las respectivas entradas y salidas del EtherCAT. Así, las variables del Esclavo EtherCAT se pueden controlar por la aplicación de usuario. 142 4. Configuración Figura 4-56. Diálogo I/O Mapping Guías Status e Información La guía Status del editor de configuración del Esclavo EtherCAT brinda informaciones de estado (por ejemplo, 'Ejecutando', 'Parado') y mensajes de diagnóstico específicas del dispositivo y del sistema de bus interno. El diálogo Information, presente en el editor de configuración del Esclavo EtherCAT, muestra, si disponible, las siguientes informaciones generales para el módulo: Nombre, Proveedor, Tipo, Número de Versión, Categorías, Número de Orden, Descripción, Imagen. Desempeño de Comunicación Tasa de Comunicación de un Dispositivo Servidor MODBUS Los dispositivos MODBUS configurables en la UCP Nexto ejecutan en segundo plano, con una prioridad inferior a la aplicación de usuario y de forma cíclica. De esta forma, su desempeño variará según el tiempo que queda, teniendo en consideración la diferencia entre el intervalo y el tiempo que la aplicación lleva para ejecutarse. Por ejemplo, un dispositivo MODBUS en una aplicación que se ejecuta a cada 100 ms, con un tiempo de ejecución de 50 ms, tendrá un desempeño menor que con una aplicación de 50 ms ejecutando a cada 200 ms de intervalo. Esto ocurre porque, en el segundo caso, la UCP tendrá un tiempo mayor entre cada ciclo de MainTask para ejecutar las tareas con prioridad inferiores. También se debe tener en cuenta el número de ciclos que el dispositivo, esclavo o servidor, lleva para responder a una solicitud. Para procesar y transmitir una respuesta, un MODBUS RTU Esclavo se llevará dos ciclos (tiempo del ciclo de la tarea MODBUS), mientras que un MODBUS Ethernet Servidor llevará un ciclo sólo. Sin embargo, ese es el tiempo mínimo entre la recepción de una solicitud y el envío de la respuesta. En el caso de que la solicitud se envíe tras la ejecución de un 143 4. Configuración ciclo de la tarea MODBUS, el tiempo podrá ser equivalente a 2 o 3 veces el tiempo de ciclo para el MODBUS Esclavo, y de 1 a 2 veces el tiempo de ciclo para el MODBUS Servidor. En este caso: Tiempo de Respuesta Máximo = 3 * (tiempo del ciclo) + (tiempo de ejecución de las tareas) + (tiempo interframe chars) + (retardo de envío). Por ejemplo, para una tarea MODBUS Ethernet Servidor con un ciclo de 50 ms, en una aplicación ejecutada por 60 ms a cada 100 ms, el servidor conseguirá ejecutar sólo un ciclo entre cada ciclo de la aplicación. Por otro lado, con la misma aplicación, ejecutándose por 60 ms, pero con un intervalo de 500 ms, el MODBUS tendrá un desempeño mejor, pues mientras la aplicación no está en ejecución, este se estará ejecutando a cada 50 ms y sólo a cada ciclo de MainTask demorará más para ejecutarse. Para estos casos, el peor desempeño será la suma del tiempo de ejecución de la aplicación del usuario con el tiempo del ciclo de la tarea MODBUS. Para los dispositivos maestro y cliente el principio de funcionamiento es exactamente igual, pero hay que tener en consideración el tiempo de polling de la relación MODBUS y no el tiempo del ciclo de la tarea MODBUS. Para estos casos, el peor desempeño de una relación será ejecutarse después de su tiempo de polling, sumado al tiempo de ejecución de la aplicación de usuario. Es importante resaltar que el número de dispositivos MODBUS en ejecución también alterará su desempeño. En una aplicación de usuario con tiempo de ejecución de 60 ms e intervalo de 100 ms, quedará 40 ms para que la UCP ejecute todas las tareas de menor prioridad. Por lo tanto, una UCP con sólo un MODBUS Ethernet Servidor tendrá un desempeño mayor que una UCP que utiliza cuatro de estos dispositivos. Interfaces Locales de la UCP Para un dispositivo MODBUS Ethernet Servidor, podemos decir que él es capaz de responder a un número x de solicitudes por segundo, o sea, es capaz de transferir n bytes por segundo dependiendo del tamaño de cada solicitud. Cuanto menor sea el ciclo de la tarea del Servidor MODBUS, mayor será el impacto del número de conexiones activas en su frecuencia de respuesta. Sin embargo, para los tiempos de ciclo más corto que 20 ms, este impacto no es lineal y se debe consultar la Tabla 4-75 para obtener más informaciones. La Tabla 4-75 muestra el número de solicitudes respondidas por un Servidor MODBUS insertado en una interfaz local de la UCP, dependiendo del tiempo de ciclo configurado para la tarea e del número de conexiones activas efectuando solicitudes. Número de Conexiones Solicitudes respondidas por segundo con el tiempo de ciclo de la tarea MODBUS de 5 ms Solicitudes respondidas por segundo con el tiempo de ciclo de la tarea MODBUS de 20 ms 47 1 Conexión 160 2 Conexiones 300 95 3 Conexiones 395 142 4 Conexiones 470 190 5 Conexiones 515 237 6 Conexiones 570 285 7 Conexiones 605 332 8 Conexiones 640 380 9 Conexiones 665 427 10 Conexiones 690 475 Tabla 4-75. Tasa de Comunicación de un Servidor MODBUS en una Interfaz Local ATENCIÓN: Los desempeños de comunicación mencionados en este capítulo son ejemplos utilizando una UCP con solamente un Servidor MODBUS TCP, sin ningún tipo de lógica en la aplicación que puedan retrasar la comunicación. Por lo tanto, estos desempeños deben ser tomados como máximos. 144 4. Configuración Para los tiempos de ciclo igual o mayor que 20 ms lo crecimiento de la taja de respuesta es linear y se puede calcular usando la fórmula: N =- C x (Z – (Z / (T x 1000))) Z=1/T Donde N es el número medio de respuestas por segundo, C es el número de conexiones y T es igual a el tiempo de ciclo de la tarea MODBUS (en segundos). Utilizando como ejemplo un Servidor MODBUS con una conexión activa e un tiempo de ciclo de 50 ms tenemos que: C = 1; T = 0,05 s; Z = 1 / 0,05 = 20; N = 1 x (20 – (20 / (0,05 x 1000))) = 1 x (20 – ( 20 / 50)) = 1 x (20 – 0,4) = 1 x 19,6 N = 19,6 Entonces, con esta configuración el Servidor MODBUS será capaz de responder, en promedio, 19 solicitudes por segundo. Si el valor obtenido sea multiplicado por el número de bytes en cada solicitud, será obtenida una velocidad de trasferencia de n bytes por segundo. Interfaces Remotas El desempeño de un dispositivo MODBUS Servidor en una interfaz Ethernet remota es similar a su desempeño en las interfaces locales de la UCP. Sin embargo, debido al tiempo de comunicación entre la UCP y los módulos, el máximo desempeño es limitado. Por sólo una conexión abierta, el número de respuestas se limita a un máximo de 18 respuestas por segundo. Con más conexiones abiertas, el número de respuestas se incrementará linearmente exactamente como para la interfaz local, sino que se limita a un número máximo de 90 respuestas por segundo. Por lo tanto, para una interfaz Ethernet remota tenemos las siguientes formas para calcular su desempeño: Para T ≤ 55 ms se utiliza: N = C x (18,18 – (18,18 / (0,055 x 1000))) Y para T ≥ 55 ms se utiliza: N = C x (Z – (Z / (T x 1000))) Donde N es el número medio de respuestas por segundo, C es el número de conexiones y T es igual a el tiempo de ciclo de la tarea MODBUS (en segundos). Es necesario prestar atención al hecho de que el máximo desempeño de un dispositivo MODBUS Servidor en un interfaz Ethernet remota será de 90 respuestas a solicitudes por segundo. Tasa de Comunicación de un Dispositivo con Servidor OPC Para los testeos de desempeño de la comunicación con Servidor OPC se crearon proyectos para el CP declarando variables del tipo INT y separándolas en POUs con 1.000 variables cada uno. En todos los escenarios se utilizaron proyectos con perfiles Single y el Intervalo de la MainTask configurado en 100 ms. Para llevar a cabo la comunicación, se utilizó el atributo {attribute 'symbol' := 'readwrite'}, con el fin de dejar disponibles los datos en el Servidor OPC. También es importante resaltar que las mediciones se hicieron con el software MasterTool desconectado de la UCP y con la duración de la MainTask ajustada para consumir 5%, 50% y 80% del Intervalo configurado, como lo presentado en la Tabla 4-76. En la perspectiva del cliente OPC, se utilizó un driver en un sistema SCADA. El tiempo de actualización configurado fue de 50 ms. Los resultados del desempeño en estas condiciones están descritos en la Tabla 4-76. 145 4. Configuración Tiempo de actualización de las variables en el cliente OPC Número Total de variables en el proyecto del CP 5% de la UCP Ocupada 50% de la UCP Ocupada 80% de la UCP Ocupada 1.000 600 ms 800 ms 1400 ms 2.000 800 ms 900 ms 2800 ms 5.000 1000 ms 2000 ms 6500 ms 10.000 2000 ms 4000 ms 13700 ms 15.000 3200 ms 6400 ms 20000 ms 20.000 4000 ms 8100 ms 25000 ms Tabla 4-76. Taja de Comunicación de Servidor OPC Disparo de Relaciones MODBUS Cliente de Forma Acíclica Para disparar relaciones MODBUS Cliente de forma acíclica, se sugiere el siguiente método, que se puede implementar de forma simple en el programa aplicativo del usuario: Definir tiempo máximo de polling para las relaciones Mantener la relación normalmente deshabilitada Habilitar la relación en el momento en que se desea ejecutarla Esperar por la confirmación de término de la ejecución de la relación, y en este momento deshabilitarla nuevamente Desempeño del Sistema En casos en los cuales la aplicación posee sólo una tarea de usuario MainTask, responsable de la ejecución de una única unidad de programación del tipo Programa denominada MainPrg (como en el perfil Simple), el CP consume un determinado tiempo para que la tarea se procese. A este tiempo le damos el nombre de Tiempo de Ejecución. En una aplicación, podemos conocer el Tiempo de Ejecución promedio de la aplicación al usar el MasterTool IEC XE, en el Árbol de Dispositivos, en el ítem Device, en el siguiente camino: PLC Logic-> Application-> Task Configuration en la pestaña Monitor, en la columna Tiempo de Ciclo Promedio. Se debe estar atento al Tiempo de Ejecución para que no sobrepase a 80% del intervalo configurado en la tarea de usuario MainTask. Por ejemplo, en una aplicación en la cual el intervalo es de 100 ms, un Tiempo de Ejecución adecuado es de hasta 80 ms. Esto se debe al hecho de que la UCP necesita un tiempo para la ejecución de otras tareas como el procesamiento de la comunicación, tratamiento del visor y tarjeta de memoria, y estas tareas también ocurren dentro del intervalo (los 20% restantes del Tiempo de Ejecución). ATENCIÓN: Para tiempos de ciclo muy altos (típicamente tiempos mayores que 300 ms), mismo que el porcentual de 80% se respete, puede haber una disminución en el tiempo de respuesta del visor y de la tecla de diagnósticos. En caso de que el porcentual de 80% no se respete y el tiempo de ejecución de la tarea de usuario se acerque o exceda el intervalo configurado de MainTask, el visor y la tecla de diagnósticos pueden no contestar, una vez que su prioridad en la ejecución del sistema es menor que las tareas de usuario. En caso de que una aplicación con errores se cargue en la UCP, puede ser necesario reinicializarla sin cargar esta aplicación, como lo descrito en la sección No Cargar la Aplicación en la Inicialización. 146 4. Configuración ATENCIÓN: Los logs de sistema de las UCPs de la serie Nexto, a partir de la versión de firmware 1.4.0.33 se recargan en el caso de una reinicialización de la UCP o por una reinicialización del Runtime System, es decir, será posible visualizar los logs más antiguos cuando una de esas condiciones ocurra. Escaneo de E/S Para un proyecto que utiliza módulos de E/S digitales y están estos insertados en el bus y declarados en el proyecto, el tiempo de MainTask aumentará según el número de módulos. La Tabla 4-77 ejemplifica el tiempo promedio que se añade a la MainTask: Módulos Declarados en el Bus Alza de Tiempo en el Ciclo de MainTask (µs) 5 300 10 700 20 1000 Tabla 4-77. Tiempo de Escaneo de E/S En proyectos que utilizan E/S remotas, como, por ejemplo, que utilizan el módulo Maestro Profibus DP NX5001, el manual del respectivo módulo se debe consultar para informaciones sobre desempeño e influencias del módulo en la ejecución de las tareas de usuario. Tarjeta de Memoria La transferencia de datos que involucran la tarjeta de memoria se realiza en segundo plano por la UCP, pues esta le da prioridad para la ejecución de la aplicación de usuario y procesamiento de la comunicación. De esta forma, la transferencia de archivos para la tarjeta podrá sufrir un alza de tiempo significativo, dependiendo del tiempo de ejecución de la aplicación del usuario. El tiempo necesario para leer/escribir archivos en la tarjeta se afectará directamente por el tiempo de ejecución de la aplicación de usuario, una vez que esa aplicación tiene prioridad en la ejecución. Para más informaciones sobre la utilización de la tarjeta de memoria, ver capítulo Configuración Tarjeta de Memoria. Reloj RTC Las UCPs de la Serie Nexto poseen un reloj interno que se puede utilizar a través de la biblioteca NextoStandard.lib. Esta biblioteca se carga automáticamente durante la creación de un nuevo proyecto (para realizar el procedimiento de inserción de una biblioteca, consultar –Bibliotecas). La Figura 4-57 muestra como incluir los bloques en el proyecto: 147 4. Configuración Figura 4-57. Bloques de Escritura y Lectura del Reloj ATENCIÓN: Bloques funcionales para Lectura y Escritura del RTC, disponibles en versiones anteriores a 2.00 del MasterTool IEC XE se volvieron obsoletos de la versión 2.00 en adelante, los bloques a los que les ocurrió eso son: NextoGetDateAndTime, NextoGetDateAndTimeMs e NextoGetTimeZone, NextoSetDateAndTime, NextoSetDateAndTimeMs y NextoSetTimeZone. Bloques Funcionales para Lectura y Escritura del RTC Entre otros bloques funcionales, existen seis muy importantes que se utilizan para la lectura del reloj (NextoGetDateAndTime, NextoGetDateAndTimeMs y NextoGetTimeZone) y para configurar nuevos valores de fecha y hora (NextoSetDateAndTime, NextoSetDateAndTimeMs y NextoSetTimeZone). A continuación, se describen los procedimientos utilizados para configurar los bloques. ATENCIÓN: Los bloques de función para lectura y escritura de RTC no se pueden utilizar en el área de datos redundantes en proyectos redundantes. Los bloques funcionales se pueden utilizar sólo en POUs no redundantes como la POU NonSkippedPrg. Para más detalles acerca el funcionamiento de la POU NonSkippedPrg se pueden encontrar en Programa NonSkippedPrg. Bloques Funcionales de Lectura del RTC La lectura del reloj se puede hacer a través de los bloques funcionales a seguir: GetDateAndTime Figura 4-58. Lectura de Fecha y Hora 148 4. Configuración Parámetros de entrada y salida Tipo DATEANDTIME EXTENDED_DAT E_AND_TIME Descripción Esta variable devuelve el valor de la fecha y hora del RTC en el formato presentado en Tabla 4-87. Tabla 4-78. Parámetros de Entrada y Salida GetDateAndTime Parámetros de salida GETDATEANDTIME Tipo Descripción RTC_STATUS Devuelve el estado de error de la función, ver Tabla 4-89 . Tabla 4-79. Parámetros de Salida GetDateAndTime Ejemplo de uso en Lenguaje ST: PROGRAM MainPrg VAR Result : RTC_STATUS; DATEANDTIME : EXTENDED_DATE_AND_TIME; xEnable : BOOL; END_VAR -------------------------------------------------------------------------IF xEnable = TRUE THEN Result := GetDateAndTime(DATEANDTIME); xEnable := FALSE; END_IF GetTimeZone La función a continuación hace la lectura de las configuraciones de huso horario, esta función está directamente relacionada al tiempo de huso horario configurado en el servicio de sincronismo del SNTP: Figura 4-59. Lectura de las Configuraciones de Huso Horario Parámetros de entrada y salida Tipo TimeZone TIMEZONESETTINGS Descripción Esta variable presenta la lectura de las configuraciones de huso horario. Tabla 4-80. Parámetros de Entrada y Salida GetTimeZone Parámetros de salida Tipo GetTimeZone RTC_STATUS Descripción Retorna el estado de error de la función, ver . Tabla 4-81. Parámetros de Salida GetTimeZone Ejemplo de uso en Lenguaje ST: PROGRAM MainPrg VAR GetTimeZone_Status TimeZone xEnable : BOOL; : RTC_STATUS; : TIMEZONESETTINGS; 149 4. Configuración END_VAR -------------------------------------------------------------------------IF xEnable = TRUE THEN GetTimeZone_Status := GetTimeZone(TimeZone); xEnable := FALSE; END_IF GetDayOfWeek La función se utiliza para hacer la lectura del día de la semana. Figura 4-60. Lectura del Día de la Semana Parámetros de salida Tipo Descripción GetDayOfWeek DAYS_OF_WEEK Retorna el día de la semana. Ver sección Estructuras de Datos del RTCDAYS_OF_WEEK Tabla 4-82. Parámetros de Salida GetDayOfWeek Al llamarla, la función leerá el día de la semana y llenará la estructura DAYS_OF_WEEK. Ejemplo de uso en Lenguaje ST: PROGRAM MainPrg VAR DayOfWeek : DAYS_OF_WEEK; END_VAR -------------------------------------------------------------------------DayOfWeek := GetDayOfWeek(); Bloques Funcionales y Funciones de Escritura y Configuración del RTC Las configuraciones del reloj se hacen a través de las funciones y bloques funcionales a continuación: SetDateAndTime El Bloque Funcional SetDateAndTime se utiliza para realizar la configuración del reloj: Figura 4-61. Configuración de Fecha y Hora con Milisegundos Parámetros de entrada Tipo Descripción Esta variable, al recibir un borde de subida, habilita la escritura del reloj. REQUEST BOOL DATEANDTIME EXTENDED_DATE_A ND_TIME Obtiene los valores de fecha y hora con milisegundos. Consulte la sección. Estructuras de Datos del RTC EXTENDED_DATE_AND_TIME Tabla 4-83. Parámetros de Entrada SetDateAndTime 150 4. Configuración Parámetros de salida Tipo Descripción DONE BOOL Esta variable, cuando es verdadera, indica que la acción se completó con éxito. EXEC BOOL Esta variable, al ser verdadera, indica que la función está procesando los valores. ERROR BOOL Esta variable, al ser verdadera, indica que ocurrió un error durante la Escritura. STATUS RTC_STATUS Retornará el error ocurrido durante la configuración. Ver sección Estructuras de Datos del RTC - RTC_STATUS Tabla 4-84. Parámetros de Salida SetDateAndTime Al ocurrir un borde de subida en la entrada REQUEST, el bloque funcional escribirá el nuevo valor DATEANDTIME en el reloj. En el caso de que la escritura se realice con éxito, la salida DONE será igual a TRUE. En caso contrario, la salida ERROR será igual a TRUE y el error se presentará en la variable STATUS. Ejemplo de uso en Lenguaje ST: PROGRAM MainPrg VAR SetDateAndTime : SetDateAndTime; xRequest : BOOL; DateAndTime : EXTENDED_DATE_AND_TIME; xDone : BOOL; xExec : BOOL; xError : BOOL; Status : RTC_STATUS; xWrite : BOOL; END_VAR -------------------------------------------------------------------------IF (xWrite = TRUE) THEN SetDateAndTime( request := xRequest, done => xDone, exec => xExec, error => xError, status => status, DateAndTime := DateAndTime); xWrite := FALSE; END_IF ATENCIÓN: Si el usuario intenta escribir valores de hora fuera del intervalo del RTC, los valores se convertirán en valores válidos, desde que no sobrepase la franja válida de 01/01/2000 hasta 31/12/2035. Por ejemplo, si el usuario intenta escribir el valor 2000 ms, este se convertirá en 2 segundos, si escribe el valor 100 segundos, se convertirá en 1 min y 40 segundos. Si escribe el valor de 30 horas, se convertirá en 1 día y 6 horas, y así por delante. SetTimeZone La función SetTimeZone hace la escritura de las configuraciones de huso horario: Figura 4-62. Configuración de Huso Horario 151 4. Configuración Parámetros de entrada Tipo Descripción TIMEZONE TIMEZONESETTINGS Estructura con el valor de huso horario a ser configurado. Ver sección Estructuras de Datos del RTC - TIMEZONESETTINGS. Tabla 4-85. Parámetros de Entrada SetTimeZone Parámetros de salida Tipo Descripción SetTimeZone RTC_STATUS Retorna el error ocurrido durante la configuración. Ver sección Estructuras de Datos del RTC - RTC_STATUS Tabla 4-86. Parámetros de Salida SetTimeZone Al ser llamada, la función, configurará el valor de TIMEZONE como la nueva configuración de huso horario del sistema. El resultado de la configuración lo retorna por la función. Ejemplo de uso en Lenguaje ST: PROGRAM MainPrg VAR Status : RTC_STATUS; TimeZone : TIMEZONESETTINGS; xWrite : BOOL; END_VAR -------------------------------------------------------------------------//FB SetTimeZone IF (xWrite = TRUE) THEN Status := SetTimeZone(TimeZone); xWrite := FALSE; END_IF ATENCIÓN: Para configurar el reloj, se deben utilizar valores de hora y fechas dentro de la siguiente franja válida: 00:00:00 horas de 01/01/2000 hasta 23:59:59 horas de 31/12/2035, en caso contrario, se reportará un error a través del parámetro de salida STATUS. Para más detalles sobre el parámetro de salida STATUS, consulte la sección RTC_STATUS. Estructuras de Datos del RTC Los bloques funcionales de lectura y configuración del RTC de las UCPs de la Serie Nexto utilizan las siguientes estructuras de datos en su configuración: EXTENDED_DATE_AND_TIME Esta estructura se utiliza para almacenar la fecha del RTC cuando se utilicen los bloques funcionales para lectura/configuración de la fecha con precisión de milisegundos y se describe en la Tabla 4-87: Estructura Tipo Descripción byDayOfMonth Almacena el día del mes de la fecha configurada. BYTE ByMonth Almacena el mes de la fecha configurada. wYear Almacena el año de la fecha configurada. BYTE byHours Almacena la hora de la fecha configurada. BYTE byMinutes Almacena los minutos de la fecha configurada. BYTE bySeconds Almacena los segundos de la fecha configurada. WORD EXTENDED_DATE_ AND_TIME Variable BYTE 152 4. Configuración WORD wMiliseconds Almacena los milisegundos de la fecha configurada. Tabla 4-87. EXTENDED_DATE_AND_TIME DAYS_OF_WEEK Esta estructura se utiliza para almacenar el día de la semana al utilizar la función para lectura del día de la semana: Enumerador Valor DAYS_OF_WEEK Descripción 0 INVALID_DAY 1 SUNDAY 2 MONDAY 3 TUESDAY 4 WEDNESDAY 5 THURSDAY 6 FRIDAY 7 SATURDAY Tabla 4-88. Estructura DAYS_OF_WEEK RTC_STATUS Este enumerador se utiliza para retornar el tipo de error en la configuración o lectura del RTC y se describe en la Tabla 4-89: Enumerador RTC_STATUS Valor Descripción NO_ERROR (0) No hay error UNKNOWN_COMMAND (1) Comando desconocido DEVICE_BUSY (2) Dispositivo está ocupado DEVICE_ERROR (3) Dispositivo con error ERROR_READING_OSF (4) Error en la lectura del señalizador de fecha y hora válidas ERROR_READING_RTC (5) Error en la lectura de la fecha y hora ERROR_WRITING_RTC (6) Error en la escritura de la fecha y hora ERROR_UPDATING_ SYSTEM_TIME (7) Error en la actualización de fecha y hora del sistema INTERNAL_ERROR (8) Error interno INVALID_TIME (9) Fecha y hora inválidas INPUT_OUT_OF_RANGE (10) Fuera del límite de Fecha y hora válidas para el sistema SNTP_NOT_ENABLE (11) Error generado cuando el servicio SNTP no está habilitado y se hace un intento de modificar el huso horario Tabla 4-89. RTC_STATUS 153 4. Configuración TIMEZONESETTINGS Esta estructura se utiliza para almacenar el valor del huso horario en las solicitudes de lectura/configuración de los bloques funcionales del RTC y se describe en la : Estructura TIMEZONE SETTINGS Tipo Variable Descripción INT iHour Hora del huso horario configurado INT iMinutes Minuto del huso horario configurado Tabla 4-90. TIMEZONESETTINGS Nota: Bloques Funcionales de Escritura y Lectura de Fecha y Hora: Bibliotecas diferentes de la NextoStandard, que tengan bloques funcionales o funciones que puedan hacer acceso de lectura y escritura de la fecha y hora en el sistema, no se indican. La biblioteca NextoStandard posee las interfaces adecuadas para escribir y leer la fecha y hora del sistema de forma correcta e informar los diagnósticos correctos. Memoria de Archivos de Usuario Las UCPs de la Serie Nexto poseen un área de memoria destinada al almacenaje de datos de uso general, es decir, el usuario podrá grabar diversos archivos de cualquier formato en la memoria de la UCP. Esta área de memoria puede variar según el modelo de UCP que se utiliza (consultar capítulo Descripción Técnica - Características Generales - Características Específicas). Para usar esta área, el usuario deberá acceder a un proyecto en el software MasterTool IEC XE y hacer clic en el Árbol de Dispositivos, ubicado a la izquierda del programa. Deberá hacer doble clic sobre el ítem Device y, tras seleccionar la UCP en la pestaña Configuraciones de Comunicación que se abrirá, seleccionar la pestaña Archivos y hacer clic en Actualizar, tanto en la columna de archivos del computador (izquierda), como en la columna de archivos de la UCP seleccionada (derecha), según muestran las indicaciones de la Figura 4-63. Figura 4-63. Acceso a los Archivos de Usuario Tras actualizar la columna de archivos de la UCP, se exhibirá el directorio raíz de archivos almacenados en la UCP y se podrá seleccionar la carpeta para donde los archivos se transferirán. La 154 4. Configuración carpeta “InternalMemory” es una carpeta estándar, que se utiliza para almacenar archivos en la memoria interna de la UCP, una vez que no es posible transferir archivos para el directorio raíz. En caso de que sea necesario, se pueden crear otras carpetas en el directorio raíz o subcarpetas dentro de la carpeta “InternalMemory”. Ya la carpeta “MemoryCard” es el directorio en el cual la tarjeta de memoria estará armada, en caso de que este esté insertado en la UCP. Archivos transferidos para la carpeta “MemoryCard” se transferirán directamente hacia dentro de la tarjeta de memoria. A medida que se añaden nuevas características al producto, algunas carpetas pueden aparecer y cuáles deben ser ignorados por el usuario. ATENCIÓN: En el caso en que la tarjeta de memoria se inserte tras la inicialización de la UCP, se solicitará un usuario y contraseña para realizar el acceso y/o transferencias de archivos del MasterTool IEC XE hacia la tarjeta de memoria o viceversa. El usuario estándar con privilegios para acceso a la UCP es “Owner” y la contraseña estándar de este usuario es “Owner”. Para transferir algún archivo de la microcomputadora a la UCP, basta seleccionar el archivo que se desee en la columna de la izquierda y presionar el botón “>>”, ubicado en el centro de la pantalla, según Figura 4-64. El tiempo de transferencia variará según el tamaño del archivo y con el tiempo de ciclo (ejecución) de la aplicación actual de la UCP, lo que puede llevar varios minutos. El usuario no necesita estar en Modo Run o conectado a la UCP para hacer la transferencia, pues esta posee la capacidad de conectarse automáticamente cuando el usuario lo hace. Figura 4-64. Transfiriendo Archivos ATENCIÓN: Los archivos contenidos dentro de la carpeta de un proyecto creado por la herramienta MasterTool IEC XE poseen nombres especiales reservados por el sistema, de esta forma, no se pueden transferir a través de la pestaña Archivos. En el caso de que el usuario desee transferir un proyecto a la memoria de usuario, será necesario que se compacte la carpeta y entonces se transfiera el archivo compactado (*.zip por ejemplo). En caso de que sea necesario transferir documentos de la UCP a la microcomputadora en la cual está instalado el software MasterTool IEC XE el usuario debe realizar un procedimiento muy semejante al anterior, es decir, debe seleccionar el archivo en la columna de la derecha y presionar el botón “<<”, ubicado en el centro de la pantalla. 155 4. Configuración Además, el usuario posee algunas opciones de operación del área de almacenaje de archivos, son: Nuevo directorio Excluir ítem : permite la creación de una nueva carpeta en el área de memoria de usuario. : permite la exclusión de archivos en los directorios del área de memoria de usuario. Actualizar : permite actualizar, en la pantalla del MasterTool IEC XE, los archivos presentes en la memoria de usuario y en la microcomputadora. Figura 4-65. Opciones de Utilización ATENCIÓN: Para una UCP en Modo Stop o sin ninguna aplicación, la tasa de transferencia para la memoria interna es de alrededor de150kB /s. Tarjeta de Memoria Entre otras memorias, las UCPs de la Serie Nexto le dan la posibilidad al usuario de utilizar una tarjeta de memoria, definida según las características del capítulo Descripción Técnica – Interfaz de la Tarjeta de Memoria. Cuando se inserte la tarjeta en la UCP y esté con sistema de archivos diferente de FAT32, automáticamente se identifica y le pregunta al usuario si desea formatear. En caso negativo, el usuario no podrá utilizar la tarjeta (la tarjeta no se armará, aparecerá un mensaje diciendo que el formato no ha sido reconocido, y el visor no indicará la presencia de la tarjeta). En caso de que se seleccione la opción de formatación, la UCP llevará algunos minutos, dependiendo del tiempo de ciclo (ejecución) de la aplicación que rueda en la UCP, para ejecutar la operación. Una vez que se instale la tarjeta de memoria, la UCP leerá informaciones generales, dejando el acceso a la tarjeta de memoria más lento en los primeros minutos. Este procedimiento sucede solamente cuando se inserta la tarjeta o se reinicia la UCP. ATENCIÓN: Se recomienda realizar el procedimiento de formatación de la tarjeta de memoria directamente en la UCP Nexto para evitar posibles problemas de utilización, aumento del tiempo de armado o hasta funcionamiento incorrecto. No se recomienda remover la tarjeta de memoria o desernegizar la UCP durante la formatación o durante la transferencia de archivos, pues se puede causar la pérdida de datos bien como daños irreversibles a la tarjeta. 156 4. Configuración Durante la configuración del proyecto, dentro del software MasterTool IEC XE, el usuario habilita la opción de copia del proyecto de la UCP para la tarjeta de memoria o la copia del proyecto que está en la tarjeta para la UCP. En esta misma pantalla el usuario podrá configurar contraseñas de acceso y controlar el uso de estas informaciones. Informaciones sobre la tabla, consultar el capítulo Configuración – Parámetros del Proyecto. Figura 4-66. Configuraciones de la Tarjeta de Memoria Cuando una contraseña se configura para la tarjeta de memoria en el MasterTool, es necesario que se ejecuten los pasos a continuación para que, al enviar el proyecto, el archivo criptografiado que lo genera el MasterTool tenga la contraseña incluida en su contenido y también se envíe. Primeramente configurar la(s) contraseña(s) y hacer clic en el botón “OK”. En este momento las contraseñas se registraron y el próximo paso es ejecutar en el menú Comunicación el comando “Crear Aplicación de Inicialización”, recordando que no se puede estar logueado en la UCP para realizar este procedimiento. Tras ejecutar este comando, dos archivos se crearán. Uno con la extensión “app” y otro con la extensión “crc”. Para concluir la operación de configuración de la(s) contraseña(s) es necesario hacer clic nuevamente en el botón “Tarjeta de Memoria”, que está en la configuración de los Parámetros Generales de la UCP y entonces ubicar el archivo con extensión “crc” generado en el paso anterior, utilizando el botón “Ubicar Archivo...”. Ejecutados estos pasos, el MasterTool IEC XE enviará todos los archivos necesarios para realizar las operaciones de envío y recibimiento de proyectos por tarjeta de memoria. En caso de que la tarjeta esté armada, la contraseña se grabará en ella. En caso contrario, la contraseña configurada en el MasterTool se solicitará si el usuario intenta transferir el proyecto de la UCP a la tarjeta. Para realizar el envío de la UCP para la tarjeta de memoria o viceversa, el usuario, además de habilitar en el software MasterTool IEC XE y colocar la contraseña, tendrá que acceder el Menú “Tarjeta de Memoria” en la UCP, utilizando la tecla de diagnósticos, y seleccionar la opción de transferencia deseada. Enseguida, se solicitará la contraseña, en caso de que el usuario haya configurado durante la configuración de la aplicación. Entonces, al presionar de forma corta en la tecla de diagnósticos los dígitos se incrementarán y con un presión larga se confirmarán. En el sexto dígito confirmado, la UCP aceptará la contraseña e iniciará el proceso. Cuando las contraseñas, tanto de la aplicación que está en la UCP como de la aplicación que está en la tarjeta de memoria, son iguales, no se solicita la inserción de las contraseñas en el menú de la UCP para realizar las transferencias de las aplicaciones. Más informaciones sobre la utilización de la tecla de diagnósticos, consultar capítulo Mantenimiento – Diagnósticos One Touch. 157 4. Configuración Para remover la tarjeta de memoria, basta presionar la tecla MS con una presión larga, y aguardar hasta que el ícono de la tarjeta desaparezca de la pantalla de status del visor gráfico. ATENCIÓN: Si hay algún archivo en la raíz de la tarjeta de memoria llamado "NextoMemCard" o "Backup", el archivo será eliminado para crear las carpetas con el mismo nombre, utilizadas por la UCP para almacenar la aplicación y el archivo del proyecto. Las carpetas con estos nombres no será sobreescritos. Acceso en el MasterTool El acceso a la memoria de la tarjeta está vinculado a la misma pantalla de memoria de usuario en el software MasterTool IEC XE, siendo que se arma en la carpeta “MemoryCard”. Los directorios “NextoMemCard” y “Backup" se crean dentro de la tarjeta de memoria toda vez que se inserta en la UCP. En caso de que ya existan, el sistema reconocerá y no sobrescribirá las carpetas. Figura 4-67. Directorio Raíz con Tarjeta de Memoria Insertado La transferencia de archivos ocurre de forma semejante a la utilización de la memoria de usuario (Memoria de Archivos de Usuario), basta acceder al directorio “MemoryCard” y enviar los archivos, según muestra la Figura 4-68. 158 4. Configuración Figura 4-68. Archivos Grabados en la Tarjeta de Memoria Dentro del directorio de la tarjeta de memoria, además de los archivos que están almacenados en la tarjeta, estarán las carpetas “NextoMemCard” y “Backup”. En estas carpetas estarán grabados el aplicativo y el proyecto actual en caso de que el usuario elija transferirlos o hacerles un backup a través del menú de la UCP. ATENCIÓN: El tiempo de transferencia de archivos depende de la diferencia del tiempo de intervalo menos el tiempo de ejecución promedio de la(s) tarea(s) en ejecución (tiempo disponible hasta el próximo ciclo de la tarea), es decir, cuanto mayor es esta diferencia para cada tarea en una aplicación, más rápida será la transferencia de un dato a partir de la tarjeta de memoria para la UCP/MasterTool IEC XE o viceversa. La transferencia de archivos hacia la tarjeta de memoria será más lenta que la transferencia hacia la memoria interna de la UCP. Para una UCP en Modo Stop o sin ninguna aplicación, la tasa de transferencia se acerca a 100kB/s. Menú Informativo y de Configuración de la UCP El acceso al Menú Informativo y de Configuración de las UCPs Nexto, así como el acceso detallado a los diagnósticos, están disponibles a través de niveles, siendo que para acceder a las informaciones del menú, cambiar de nivel y modificar alguna configuración, basta presionar largamente la tecla de diagnósticos y, para navegar por los ítems de mismo nivel, basta hacer un presionamiento corto en la tecla de diagnósticos. Consultar el capítulo Mantenimiento – Diagnósticos One Touch para verificar el funcionamiento y la diferencia entre tipos de presionamiento en la tecla de diagnósticos. La Tabla 4-91 muestra los niveles del menú y el tipo de cada pantalla disponible en la UCP, es decir, si es de carácter informativo, configurable o si retorna un nivel. Nivel 1 HARDWARE IDIOMAS Nivel 2 Nivel 3 Tipo TEMPERATURA - Informativo CONTRASTE NIVEL CONTRASTE Configurable FECHA E HORA - Informativo VOLVER - Retorna Nivel INGLÉS >INGLÉS Configurable PORTUGUÉS >PORTUGUÉS Configurable ESPAÑOL >ESPAÑOL Configurable VOLTAR - Retorna Nivel 159 4. Configuración RED REDUNDANCIA SOFTWARE DIR. IP NET 1 Informativo MÁSCARA NET 1 Informativo DIR. IP NET 2 - Informativo VOLVER Retorna Nivel IDENT. CP Informativo ESTADO REM. - SINCR. PROYE. VOLVER Informativo Informativo VOLVER Retorna Nivel FIRMWARE Informativo BOOTLOADER - PROC. AUX. VOLTAR TARJETA DE MEM. Informativo MÁSCARA NET 2 Informativo Informativo Retorna Nivel TARJETA > UCP CONTRASEÑA UCP Configurable UCP > TARJETA CONTRASEÑA CM Configurable FORMATEAR CONFIRMA ? Configurable VOLVER - Retorna Nivel - - Retorna Nivel Tabla 4-91. Nivel del Menú de la UCP Notas: Tarjeta de Memoria: La tarjeta de memoria solamente estará disponible en el menú en caso de que este esté conectado en la UCP Nexto. Contraseña: La contraseña para acceso a los datos de la tarjeta de memoria solamente será necesaria en caso de que se la configure en el software MasterTool IEC XE. No es posible editar la contraseña por el menú. Red: Los ítems correspondientes a la interface NET 2 solamente están disponibles en las UCPs NX3020 y NX3030. Redundancia: El menú “Redundancia” solamente estará disponible en caso de que la UCP NX3030 esté identificada como Redundante. Según ya se ha mostrado en la Tabla 4-91, entre las opciones disponibles para visualización y alteración, se encuentran los principales datos necesarios al usuario, como: Informaciones sobre los recursos de hardware: o TEMPERATURA – Temperatura interna de la UCP (Ej.: 36 C 97 F) o CONTRASTE – Ajuste del contraste del visor delantero de la UCP o DATA E HORA – Fecha y hora configuradas en la UCP (Ej.: 2001.01.31 00:00) Alteración del idioma del menú de la UCP: o PORTUGUÉS – Altera el idioma para Portugués o INGLÉS – Altera el idioma para Inglés o ESPAÑOL – Altera el idioma para Español Visualización de informaciones sobre la red configurada en el dispositivo: o o o o END. IP NET 1 – Dirección IP (Ej.: 192.168.0.1) MASCARA NET 1 – Máscara de subred (Ej.: 255.255.255.0) END. IP NET 2 – Dirección IP (Ej.: 192.168.0.2) MASCARA NET 2 – Máscara de subred (Ej.: 255.255.255.0) Informaciones sobre las versiones de software: o FIRMWARE – Versión de software de la UCP (Ej.: 1.0.0.0) o BOOTLOADER – Versión del bootloader de la UCP (Ej.: 1.0.0.0) o PROC. AUX. – Versión del procesador auxiliar de la UCP (Ej.: 1.0.0.0) 160 4. Configuración Acceso a las informaciones de redundancia del CP: o IDENT. CLP – Informa la identificación del CP en la redundancia. Posibles informaciones: ESTADO REM. – Informa el estado del CP redundante remoto. Posibles estados: o o o o o o ACTIVO INACTIVO RESERVA NO CONFIG. INICIANDO INDISPON. SINCR. PROY. – Informa si la sincronización de proyectos está habilitada o o o o o CPA CPB CONECTADO NO CONEC. DESHABILITADO SINC. INI. SINCRONIZADO Acceso a los datos de la tarjeta de Memoria: o CARTAO>UCP – Transferencia del proyecto de la tarjeta de memoria a la UCP o UCP>CARTAO – Transferencia del proyecto de la UCP para la tarjeta de memoria o FORMATEAR – Formatea la tarjeta para el sistema de archivos FAT32 La Figura 4-69 describe un ejemplo de cómo operar el menú de las UCPs Nexto, a través del procedimiento de ajuste del contraste a partir de la pantalla de Status. Además de facilitar la configuración, es posible identificar todos los niveles de pantalla y el tipo de presionamiento para navegar entre estas, siendo que para modificar los otros parámetros, como Idioma e insertar la(s) contraseña(s) en la tarjeta de Memoria, basta seguir la misma lógica de acceso. El presionamiento corto muestra que el contraste se está incrementado (más claro), siendo que en el próximo presionamiento después de su valor máximo, vuelve al valor mínimo (menos claro). El presionamiento largo muestra la confirmación del contraste que se desea y el retorno al nivel anterior. 161 4. Configuración Figura 4-69. Ajuste del Contraste Además de cerrarse el menú de las UCPs Nexto a través de un presionamiento largo en la tecla de diagnósticos en la pantalla VOLVER del nivel 1, también existen otras condiciones de salida, las cuales se describen a continuación: Tiempo de inactividad, en cualquier nivel, superior a 5s. Bloques Funcionales y Funciones Bloques Funcionales Especiales para Comunicación Serial Los bloques funcionales especiales para comunicación serial posibilitan el acceso local (COM 1 y COM 2) y también a la puertas seriales remotas (módulos de expansión). De esta forma, el usuario podrá crear sus propios protocolos y manejar las puertas seriales como quiera, siguiendo los lenguajes de la IEC 61131-3 disponibles en el software MasterTool IEC XE. Los bloques están disponibles dentro de la biblioteca Serial, la cual se debe añadir al proyecto para que sea posible utilizarlos (para realizar el procedimiento de inserción de una biblioteca, consultar el Manual de Programación IEC 61131 - MP399800, capítulo Bibliotecas). Los bloques funcionales especiales para serial pueden llevar varios ciclos (consecutivas llamadas) para completar la ejecución de la tarea. A veces, un bloque puede completar en un único ciclo, pero, en general, necesita varios ciclos. La ejecución de la tarea asociada a un bloque puede comprender varios pasos, siendo que algunos dependen de eventos externos, los cuales pueden tener retrasos significantes para el sistema. El bloque no puede implementar rutinas para ocupar el tiempo, mientras aguarda por dichos eventos, pues de esta forma, iría a monopolizar la UCP. La solución podría ser la creación de bloques funcionales bloqueadores, pero eso no se aconseja porque complicaría la aplicación del usuario, pues normalmente no se tiene disponible la programación multitarea. Entonces, cuando un evento externo se espera, los bloques funcionales de la serial se finalizan y el control se devuelve al programa de llamada. El tratamiento de la tarea sigue en el próximo ciclo, es decir, en la próxima vez que el bloque sea llamado. Antes de describir los bloques funcionales especiales para control de las interfaces seriales, es importante conocer un poco sobre los Datatypes, es decir, los tipos de datos utilizados por los bloques: 162 4. Configuración Datatype Opción Descripción BAUD200 BAUD300 BAUD600 BAUD1200 BAUD1800 SERIAL_BAUDRATE BAUD2400 BAUD4800 Lista todas las posibilidades de tasa de transmisión (bits por segundo) BAUD9600 BAUD19200 BAUD38400 BAUD57600 BAUD115200 DATABITS_5 SERIAL_DATABITS DATABITS_6 DATABITS_7 Lista todas las posibilidades de bits de dato. DATABITS_8 Define todas las posibilidades de las señales de modem para las configuraciones: RS232_RTS Controla la puerta RS-232 de la UCP Nexto. El RTS se habilita en el inicio de la transmisión y se reinicia luego que posible tras el final de la transmisión. Por ejemplo, se puede utilizar para controlar un conversor RS-232/RS485 externo. RS232_RTS_OFF Controla la puerta RS-232 de la UCP Nexto. La señal RTS está siempre desconectada. RS232_RTS_ON Controla la puerta RS-232 de la UCP Nexto. La señal RTS está siempre conectada. RS232_RTS_CTS Controla la puerta RS-232 de la UCP Nexto. Caso el CTS esté deshabilitado, el RTS se habilita. Entonces, se aguarda que el CTS se habilite para que empiece la transmisión y el RTS se reinicie, lo más rápido posible, en el fin de la transmisión. Ex: Control de radio modems con la misma señal de modem. RS232_MANUAL Controla la puerta RS-232 de la UCP Nexto. El usuario es responsable por controlar todas las señales (RTS, DTR, CTS, DSR, DCD). NORMAL_MODE Modo normal de operación de la comunicación serial. SERIAL_HANDSHAKE SERIAL_MODE EXTENDED_MODE Modo extendido de operación de la comunicación serial, en el cual se brindan informaciones sobre el frame de datos recibido. Define todos los parámetros de configuración de la puerta serial: BAUDRATE Definido en SERIAL_BAUDRATE. DATABITS Definido en SERIAL_DATABITS. STOPBITS Definido en SERIAL_STOPBITS. PARITY SERIAL_PARAMETERS HANDSHAKE UART_RX_THRESHOLD 163 Definido en SERIAL_PARITY. Definido en SERIAL_HANDSHAKE. Cantidad de bytes que se deben recibir para generar una nueva interrupción en la UART. Valores bajos hacen el TIMESTAMP más preciso cuando el MODO EXTENDIDO se utiliza y minimiza 4. Configuración Datatype Opción Descripción los errores de overrun. Sin embargo, valores bajos pueden causar muchas interrupciones que pueden retardar la UCP. MODE Definido en SERIAL_MODE ENABLE_RX_ON_TX Cuando verdadero, todos los bytes recibidos durante la transmisión se desecharán en vez de ir la fila de RX. Utilizado para deshabilitar la operación full-duplex en la interfaz RS-422. ENABLE_DCD_EVENT Cuando verdadero, genera un evento externo cuando el DCD se altera ENABLE_CTS_EVENT Cuando verdadero, genera un evento externo cuando el CTS se altera. PARITY_NONE PARITY_ODD SERIAL_PARITY PARITY_EVEN Lista todas las posibilidades de paridad. PARITY_MARK PARITY_SPACE COM 1 SERIAL_PORT COM 2 Lista todas las puertas seriales disponibles (COM 10, COM 11, COM 12, COM 13, COM 14, COM 15, COM 16, COM 17, COM 18, COM 19 – módulos de expansión). Define un carácter de la fila RX modo extendido. RX_CHAR RX_ERROR SERIAL_RX_CHAR_EXTENDED RX_TIMESTAMP Byte de datos. Código de error. Silencio debido al carácter anterior o debido a otro evento que haya ocurrido antes de ese carácter (configuración de la puerta serial, fin de la transmisión). Contiene algunos campos que disponen informaciones de status/error sobre la fila RX, utilizados cuando se utiliza el formato normal (sin error e informaciones de timestamping): RX_FRAMING_ERRORS Contador de errores de frame, es decir, formación incorrecta del carácter – falta de bit, de parada, tasa de transmisión incorrecta, entre otros – desde la configuración de la puerta serial. Vuelve a cero en caso de que alcance el valor máximo (65535). RX_PARITY_ERRORS Contador de errores de paridad desde la configuración de la puerta serial. Vuelve a cero en caso de que alcance el valor máximo (65535). RX_BREAK_ERRORS Contador de errores de interrupción desde la configuración de la puerta serial, es decir, línea activa mayor que el tiempo de un carácter. Vuelve a cero en caso de que alcance el valor máximo (65535). RX_FIFO_OVERRUN_ERRORS Contador de errores de overrun en FIFO RX desde la configuración de la puerta serial, es decir, error en el threshold configurado para FIFO RX. Vuelve a cero en caso de que alcance el valor máximo (65535). RX_QUEUE_OVERRUN_ERRORS Contador de errores de overrun en la fila RX desde la configuración de la puerta serial, es decir, el valor máximo de caracteres (1024) sobre pasó y los datos están siendo SERIAL_RX_QUEUE_STATUS 164 4. Configuración Datatype Opción Descripción sobrescritos. Vuelve a cero en caso de que alcance el valor máximo (65535). RX_ANY_ERRORS Suma de los 5 últimos contadores de errores (frame, paridad, interrupción, overrun RX FIFO, overrun fila RX). RX_REMAINING Número de caracteres remanentes en la fila RX. Lista los códigos de error críticos que se pueden devolver por los bloques funcionales de la serial. Cada bloque devuelve errores específicos, los cuales se mencionarán durante la descripción de los mismos: NO_ERROR ILLEGAL_* No existen errores. Devuelve los parámetros con valores no válidos o fuera de la franja: SERIAL_PORT SERIAL_MODE BAUDRATE DATA_BITS PARITY STOP_BITS HANDSHAKE UART_RX_THRESHOLD TIMEOUT TX_BUFF_LENGTH HANDSHAKE_METHOD RX_BUFF_LENGTH PORT_BUSY Indica que la puerta serial se está utilizando por otra instancia. HW_ERROR_UART Error de hardware detectado en la UART. HW_ERROR_REMOTE Error de hardware al comunicarse con la puerta serial remota. CTS_TIMEOUT_ON Time-out espera que CTS se habilite, en la señal de modem RS232 RTS/CTS, en el bloque SERIAL_TX. CTS_TIMEOUT_OFF Time-out espera que CTS se deshabilitado, en la señal de modem RS-232C RTS/CTS, en el bloque SERIAL_TX. SERIAL_STATUS TX_TIMEOUT_ERROR Time-out espera por el fin de la transmisión en el bloque SERIAL_TX. RX_TIMEOUT_ERROR Time-out espera a todos los caracteres en el bloque SERIAL_RX o SERIAL_RX_EXTENDED. FB_SET_CTRL_NOT_ALLOWED El bloque SET_CTRL no se puede utilizar en caso de que la señal de modem sea diferente de RS232_MANUAL. FB_GET_CTRL_NOT_ALLOWED El bloque GET_CTRL no se puede utilizar en caso de que la señal de modem sea diferente de R232_MANUAL. FB_SERIAL_RX_NOT_ALLOWED El bloque SERIAL_RX no está disponible para la fila RX, modo extendido. FB_SERIAL_RX_EXTENDED_NOT_ALLOWED El bloque SERIAL_RX_EXTENDED no está disponible para la fila RX, modo normal. DCD_INTERRUPT_NOT_ALLOWED La interrupción por la señal DCD no se puede habilitar en caso de que la puerta serial no posea el 165 4. Configuración Datatype Opción Descripción respectivo pin. CTS_INTERRUPT_NOT_ALLOWED La interrupción por la señal CTS no se puede habilitar en caso de que la señal de modem sea diferente de R232_MANUAL o en caso de que la puerta serial no posea el respectivo pin. DSR_INTERRUPT_NOT_ALLOWED La interrupción por la señal DSR no se puede habilitar en caso de que la puerta serial no posea el respectivo pin (las UCPs Nexto no poseen esta señal en las puertas locales). NOT_CONFIGURED El bloque funcional no se puede utilizar antes de que la puerta serial se configure. INTERNAL_ERROR Indica que algún problema interno ha ocurrido en la puerta serial. STOPBITS_1 SERIAL_STOPBITS Lista todas las posibilidades de bits de parada. STOPBITS_2 STOPBITS_1_5 Tabla 4-92. Datatypes Bloques Funcionales Seriales SERIAL_CFG Ese bloque funcional se utiliza para configurar e iniciar la puerta serial que se desee. Tras la llamada del bloque, todas las filas RX y TX asociadas a la puerta serial y los FIFOs RX y TX, se reinician. Figura 4-70. Bloque de Configuración de la Serial Parámetros de Entrada Tipo Descripción REQUEST BOOL PORT SERIAL_PORT PARAMETERS SERIAL_PARAMETERS Esa variable, cuando verdadera, habilita el uso del bloque funcional. Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Esa estructura define los parámetros de configuración de la puerta serial, según lo descrito en el datatype SERIAL_PARAMETERS. Tabla 4-93. Parámetros de Entrada Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se está ejecutando, en caso contrario, es falsa. ERROR BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. STATUS SERIAL_STATUS 166 En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los estados, ya descritos en el datatype 4. Configuración SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - ILLEGAL_SERIAL_MODE, - ILLEGAL_BAUDRATE, - ILLEGAL_DATA_BITS, - ILLEGAL_PARITY, - ILLEGAL_STOP_BITS, - ILLEGAL_HANDSHAKE, - ILLEGAL_UART_RX_THRESHOLD, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - DCD_INTERRUPT_NOT_ALLOWED, - CTS_INTERRUPT_NOT_ALLOWED, - DSR_INTERRUPT_NOT_ALLOWED, Tabla 4-94. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que se inserte la biblioteca Nexto Serial al proyecto: PROGRAM MainPrg VAR Config: SERIAL_CFG; Port: SERIAL_PORT := COM1; Parameters: SERIAL_PARAMETERS := (BAUDRATE := BAUD9600, DATABITS := DATABITS_8, STOPBITS := STOPBITS_1, PARITY := PARITY_NONE, HANDSHAKE := RS232_RTS, UART_RX_THRESHOLD := 8, MODE :=NORMAL_MODE, ENABLE_RX_ON_TX := FALSE, ENABLE_DCD_EVENT := FALSE, ENABLE_CTS_EVENT := FALSE); Status: SERIAL_STATUS; END_VAR //ENTRADAS: Config.REQUEST := TRUE; Config.PORT := Port; Config.PARAMETERS := Parameters; //FUNCIÓN: Config(); //SALIDAS: Config.DONE; Config.EXEC; Config.ERROR; Status := Config.STATUS; // En caso de que sea necesario tratar el error. SERIAL_GET_CFG Ese bloque funcional se utiliza para capturar las configuraciones de la puerta serial que se desea. Figura 4-71. Bloque para Capturar la Configuración de la Serial 167 4. Configuración Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Tabla 4-95. Parámetros de Entrada Parámetros de Salida Tipo DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se está ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. STATUS SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los estados, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - NOT_CONFIGURED. PARAMETERS SERIAL_PARAME TERS Esa estructura recibe los parámetros de configuración de la puerta serial que se desea, según lo descrito en el datatype SERIAL_PARAMETERS. ERROR Descripción Tabla 4-96. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto: PROGRAM MainPrg VAR GetConfig: SERIAL_GET_CFG; Port: SERIAL_PORT := COM1; Parameters: SERIAL_PARAMETERS; Status: SERIAL_STATUS; END_VAR //ENTRADAS: GetConfig.REQUEST := TRUE; GetConfig.PORT := Port; //FUNCIÓN: GetConfig(); //SALIDAS: GetConfig.DONE; GetConfig.EXEC; GetConfig.ERROR; Status := GetConfig.STATUS; // En caso de que sea necesario tratar el error. Parameters := GetConfig.PARAMETERS; // Recibe los parámetros de la puerta serial que se desea. 168 4. Configuración SERIAL_GET_CTRL Ese bloque funcional se utiliza para leer las señales de control CTS, DSR y DCD, en caso de que estén disponibles en la puerta serial. Se devolverá un valor falso cuando las señales de control no existan. Figura 4-72. Bloque para Visualizar las Señales de Control Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Tabla 4-97. Parámetros de Entrada Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. STATUS SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - FB_GET_CTRL_NOT_ALLOWED, - NOT_CONFIGURED. CTS_VALUE BOOL Valor leído en la señal de control CTS. DSR_VALUE BOOL Valor leído en la señal de control DSR. DCD_VALUE BOOL Valor leído en la señal de control DCD. ERROR Tabla 4-98. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Get_Control: SERIAL_GET_CTRL; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //ENTRADAS: 169 4. Configuración Get_Control.REQUEST := TRUE; Get_Control.PORT := Port; //FUNCIÓN: Get_Control(); //SALIDAS: Get_Control.DONE; Get_Control.EXEC; Get_Control.ERROR; Status := Get_Control.STATUS; tratar el error. Get_Control.CTS_VALUE; Get_Control.DSR_VALUE; Get_Control.DCD_VALUE; // En caso de que sea necesario SERIAL_GET_RX_QUEUE_STATUS Ese bloque funcional se utiliza para leer algunas informaciones de status sobre la fila RX, siendo especialmente desarrollado para el modo normal, pero también se puede utilizar en el modo extendido. Figura 4-73. Bloque para Visualizar el Status de la Fila RX Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Tabla 4-99. Parámetros de Entrada Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. STATUS SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - NOT_CONFIGURED. RXQ_STATUS SERIAL_RX_QUE UE_STATUS Devuelve status/errores de la fila RX, según lo descrito en el datatype. SERIAL_RX_QUEUE_STATUS. ERROR Tabla 4-100. Parámetros de Salida 170 4. Configuración Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurado: PROGRAM MainPrg VAR Get_Status: SERIAL_GET_RX_QUEUE_STATUS; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; Status_RX: SERIAL_RX_QUEUE_STATUS; END_VAR //ENTRADAS: Get_Status.REQUEST := TRUE; Get_Status.PORT := Port; //FUNCIÓN: Get_Status(); //SALIDAS: Get_Status.DONE; Get_Status.EXEC; Get_Status.ERROR; Status := Get_Status.STATUS; // En caso de que sea necesario tratar el error. Status_RX := Get_Status.RXQ_STATUS; // En caso de que sea necesario tratar el error de la fila RX. SERIAL_PURGE_RX_QUEUE Ese bloque funcional se utiliza para limpiar la fila RX, local y remota, de la puerta serial. La UART RX FIFOs también se reinicia. Figura 4-74. Bloque para Limpiar la Fila RX Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Tabla 4-101. Parámetros de Entrada Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, ERROR STATUS 171 4. Configuración - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - NOT_CONFIGURED. Tabla 4-102. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Purge_Queue: SERIAL_PURGE_RX_QUEUE; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //ENTRADAS: Purge_Queue.REQUEST := TRUE; Purge_Queue.PORT := Port; //FUNCIÓN: Purge_Queue(); //SALIDAS: Purge_Queue.DONE; Purge_Queue.EXEC; Purge_Queue.ERROR; Status := Purge_Queue.STATUS; // En caso de que sea necesario tratar el error. SERIAL_RX Ese bloque funcional se utiliza para recibir un buffer de la puerta serial utilizando el modo normal de la fila RX. En este modo, cada carácter en la fila RX ocupa un único byte que contiene el dato recibido, es decir, almacena 5, 6, 7 o 8 bits, según la configuración de la interfaz serial. Figura 4-75. Bloque para Leer Valores del Buffer de Recepción Parámetros de Entrada Tipo REQUEST BOOL PORT SERIAL_PORT RX_BUFFER_POINTER POINTER TO BYTE RX_BUFFER_LENGTH RX_TIMEOUT Descripción Esa variable, cuando verdadera, habilita el uso del bloque funcional. Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. Puntero de un array de bytes para recibir los valores del buffer. UINT Especifica el número de caracteres esperados en el array de bytes. En caso de que estén disponibles más bytes que lo esperado, solamente la cantidad esperada se va a leer en el array de bytes, siendo que los demás se dejarán en la fila RX (tamaño máximo igual a 1024 caracteres). UINT Especifica el time-out para recibir la cantidad de caracteres esperados. En caso de que sea menor que la cantidad de bytes a recibir, se indicará RX_TIMEOUT_ERROR en el parámetro de salida STATUS. Cuando el valor especificado, en ms, sea igual a cero, la función irá a devolver los datos presentes en el buffer. Tabla 4-103. Parámetros de Entrada 172 4. Configuración Parámetros de Salida Tipo DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. ERROR BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - ILLEGAL_RX_BUFF_LENGTH, - RX_TIMEOUT_ERROR, - FB_SERIAL_RX_NOT_ALLOWED, - NOT_CONFIGURED. RX_RECEIVED UINT Devuelve el número de caracteres recibidos. Ese número puede estar entre cero y el valor configurado en RX_BUFFER_LENGTH. En caso de que sea menor, un error se indicará por el bloque funcional. RX_REMAINING UINT Devuelve el número de caracteres que aun están en la fila RX después que el bloque funcional se ejecutó. STATUS Descripción Tabla 4-104. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Receive: SERIAL_RX; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..1023] OF BYTE; // Tamaño máximo. Status: SERIAL_STATUS; END_VAR //ENTRADAS: Receive.REQUEST := TRUE; Receive.PORT := Port; Receive.RX_BUFFER_POINTER := ADR(Buffer_Pointer); Receive.RX_BUFFER_LENGTH := 1024; // Tamaño máximo. Receive.RX_TIMEOUT := 10000; //FUNCIÓN: Receive(); //SALIDAS: Receive.DONE; Receive.EXEC; Receive.ERROR; Status := Receive.STATUS; // En caso de que sea necesario tratar el error. Receive.RX_RECEIVED; Receive.RX_REMAINING; SERIAL_RX_EXTENDED Ese bloque funcional se utiliza para recibir un buffer de la puerta serial utilizando el modo extendido de la fila RX, según lo detallado en el capítulo Configuración de las Interfaces Seriales. 173 4. Configuración Figura 4-76. Bloque para Lectura del Buffer de Recepción Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. RX_BUFFER_POINTER POINTER TO SERIAL_RX_CH AR_EXTENDED Puntero de un array de SERIAL_RX_CHAR_EXTENDED para recibir los valores del buffer. RX_BUFFER_LENGTH RX_TIMEOUT UINT Especifica el número de caracteres esperados en el array de SERIAL_RX_CHAR_EXTENDED. En caso de que estén disponibles más bytes que lo esperado, solamente la cantidad esperada se va a leer en el array, siendo que los demás se dejarán en la fila RX (tamaño máximo igual a 1024 caracteres). UINT Especifica el time-out para recibir la cantidad de caracteres esperados. En caso de que sea menor que la cantidad de bytes a recibir, se indicará RX_TIMEOUT_ERROR en el parámetro de salida STATUS. Cuando el valor especificado, en ms, sea igual a cero, la función le devolverá los datos presentes en el buffer. Tabla 4-105. Parámetros de Entrada Parámetros de Salida Tipo DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibido tras la conclusión del bloque. ERROR Descripción SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - ILLEGAL_RX_BUFF_LENGTH, - RX_TIMEOUT_ERROR, - FB_SERIAL_RX_EXTENDED_NOT_ALLOWED, - NOT_CONFIGURED. RX_RECEIVED UINT Devuelve el número de caracteres recibidos. Ese número puede estar entre cero y el valor configurado en RX_BUFFER_LENGTH. En caso de que sea menor, un error se indicará por el bloque funcional. RX_REMAINING UINT Devuelve el número de caracteres que aún están en la fila RX después que el bloque funcional se ejecute. RX_SILENCE UINT Devuelve el tiempo de silencio en la línea RX, medido desde el fin del último carácter recibido. La unidad de tiempo es 10 µs. Ese tipo de parámetro STATUS 174 4. Configuración de salida es importante para detectar el tiempo de silencio en protocolos como MODBUS RTU. Puede no ser el tiempo de silencio después del último carácter recibido por ese bloque funcional, pues solamente es verdad si RX_REMANING = 0. Tabla 4-106. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Receive_Ex: SERIAL_RX_EXTENDED; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..1023] OF SERIAL_RX_CHAR_EXTENDED; Status: SERIAL_STATUS; END_VAR //ENTRADAS: Receive_Ex.REQUEST := TRUE; Receive_Ex.PORT := Port; Receive_Ex.RX_BUFFER_POINTER := ADR(Buffer_Pointer); Receive_Ex.RX_BUFFER_LENGTH := 1024; //Tamaño máximo. Receive_Ex.RX_TIMEOUT := 10000; //FUNCIÓN: Receive_Ex(); //SALIDAS: Receive_Ex.DONE; Receive_Ex.EXEC; Receive_Ex.ERROR; Status := Receive_Ex.STATUS; // En caso de que sea necesario tratar el error. Receive_Ex.RX_RECEIVED; Receive_Ex.RX_REMAINING; Receive_Ex.RX_SILENCE; SERIAL_SET_CTRL Ese bloque funcional se utiliza para escribir en las señales de control (RTS y DTR), cuando éstas están disponibles en la puerta serial. También puede determinar una condición de ocupado para la transmisión, a través del parámetro BREAK, siendo que solamente se puede utilizar si la señal de modem está configurada para RS232_MANUAL. Figura 4-77. Bloque para Escribir en las Señales de Control Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_PORT Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. RTS_VALUE BOOL Valor a ser escrito en la señal RTS. RTS_EN BOOL Habilita la escritura del parámetro RTS_VALUE. 175 4. Configuración DTR_VALUE BOOL Valor a ser escrito en la señal DTR. DTR_EN BOOL Habilita la escritura del parámetro DTR_VALUE. BREAK BOOL En caso de que sea verdadero, habilita lógica 0 (ocupado) en la línea de transmisión. Tabla 4-107. Parámetros de Entrada Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - FB_SET_CTRL_NOT_ALLOWED, - NOT_CONFIGURED. ERROR STATUS Tabla 4-108. Parámetros de Salida Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Set_Control: SERIAL_SET_CTRL; Port: SERIAL_PORT := COM1; Status: SERIAL_STATUS; END_VAR //ENTRADAS: Set_Control.REQUEST := TRUE; Set_Control.PORT := Port; Set_Control.RTS_VALUE := FALSE; Set_Control.RTS_EN := FALSE; Set_Control.DTR_VALUE := FALSE; Set_Control.DTR_EN := FALSE; Set_Control.BREAK := FALSE; //FUNCIÓN: Set_Control(); //SALIDAS: Set_Control.DONE; Set_Control.EXEC; Set_Control.ERROR; Status := Set_Control.STATUS; tratar el error. // En caso de que sea necesario SERIAL_TX Ese bloque funcional se utiliza para transmitir un buffer de datos por la puerta serial, siendo que éste solamente se finaliza después que todos los bytes se transmiten o tras el time-out (genera algunos errores). 176 4. Configuración Figura 4-78. Bloque para Transmitir Valores por la Serial Parámetros de Entrada Tipo Descripción REQUEST BOOL Esa variable, cuando verdadera, habilita el uso del bloque funcional. PORT SERIAL_POR T Selecciona la puerta serial, según lo descrito en el datatype SERIAL_PORT. TX_BUFFER_POINTER POINTER TO BYTE Puntero de un array de bytes para transmitir los valores del buffer. TX_BUFFER_LENGTH UINT Especifica el número de caracteres a transmitirse por el array de bytes (el tamaño máximo de la fila TX es igual a 1024 caracteres). TX_TIMEOUT UINT Especifica el time-out para completar la transmisión, lo que incluye la fase de handshake. El valor especificado, en ms, debe ser positivo y diferente de cero. DELAY_BEFORE_TX UINT Especifica el retraso, en ms, entre la llamada del bloque funcional y el inicio de la transmisión. Esa variable se puede utilizar en comunicaciones con algunos modems. CLEAR_RX_BEFORE_TX BOOL Cuando verdadero, la fila RX y la UART FIFO RX están limpias antes de iniciar la transmisión. Ese comportamiento es típico de protocolos maestro/esclavo half-duplex. Tabla 4-109. Parámetros de Entrada SERIAL_TX Parámetros de Salida Tipo Descripción DONE BOOL Esa variable es verdadera cuando el bloque se ejecute por completo, en caso contrario, es falsa. EXEC BOOL Esa variable es verdadera mientras el bloque se esté ejecutando, en caso contrario, es falsa. ERROR BOOL Esa variable es verdadera cuando el bloque concluye su ejecución con algún error, en caso contrario, es falsa. Está vinculada a la variable DONE, pues su estado se exhibe tras la conclusión del bloque. STATUS SERIAL_STATUS En caso de que la variable ERROR sea verdadera, la estructura STATUS exhibirá el error encontrado en la ejecución del bloque. Los status, ya descritos en el datatype SERIAL_STATUS, posibles son: - NO_ERROR, - ILLEGAL_SERIAL_PORT, - PORT_BUSY, - HW_ERROR_UART, - HW_ERROR_REMOTE, - ILLEGAL_TX_BUFF_LENGTH, - ILLEGAL_TIMEOUT - CTS_TIMEOUT_ON, - CTS_TIMEOUT_OFF, - TX_TIMEOUT_ERROR, - NOT_CONFIGURED. TX_TRANSMITTED UINT Devuelve el número de bytes transmitidos, el cual debe ser igual al TX_BUFFER_LENGTH, pero puede ser menor en caso de que ocurra algún error durante la transmisión. Tabla 4-110. Parámetros de Salida SERIAL_TX 177 4. Configuración Ejemplo de utilización en Lenguaje ST, después que la biblioteca se inserte al proyecto y la puerta serial sea configurada: PROGRAM MainPrg VAR Transmit: SERIAL_TX; Port: SERIAL_PORT := COM1; Buffer_Pointer: ARRAY [0..9] OF BYTE := [0,1,2,3,4,5,6,7,8,9]; Status: SERIAL_STATUS; END_VAR //ENTRADAS: Transmit.REQUEST := TRUE; Transmit.PORT := Port; Transmit.TX_BUFFER_POINTER := ADR(Buffer_Pointer); Transmit.TX_BUFFER_LENGTH := 10; Transmit.TX_TIMEOUT := 10000; Transmit.DELAY_BEFORE_TX := 1000; Transmit.CLEAR_RX_BEFORE_TX := TRUE; //FUNCIÓN: Transmit(); //SALIDAS: Transmit.DONE; Transmit.EXEC; Transmit.ERROR; Status := Transmit.STATUS; //Caso sea necesario tratar el error. Transmit.TX_TRANSMITTED; Actualización de Entradas y Salidas Funcionalidad utilizada para actualizar entradas y salidas en el transcurso del aplicativo, no siendo necesario aguardar hasta que se complete un ciclo. Cuando los bloques funcionales para actualizar las entradas y salidas no se utilizan, la actualización se realiza a cada ciclo de MainTask. ATENCIÓN: En la inicialización de una UCP de la serie Nexto, las entradas y salidas solamente estarán actualizadas para lectura y preparadas para escritura cuando MainTask se ejecute. Todas las demás tareas del sistema que se ejecuten antes de MainTask estarán con las entradas y las salidas inválidas. REFRESH_INPUT Ese bloque funcional se utiliza para actualizar las entradas del módulo especificado, sin aguardar que se complete el ciclo. Es importante resaltar que los filtros, configurados en el MasterTool IEC XE, y el tiempo de actualización de las entradas del módulo, se deberán considerar en el tiempo efectivo de actualización de las entradas en el aplicativo desarrollado por el usuario. ATENCIÓN: La función REFRESH_INPUT debe utilizarse sólo en la tarea MainTask. Para ejecutar la actualización de entradas en otras tareas, la opción Enable I/O Update per Task se debe seleccionar, más informaciones con respecto a esta opción se pueden obtener en la Tabla 4-1. . ATENCIÓN: La función REFRESH_INPUT no soporta la actualización de entradas que hayan sido mapeadas para variables simbólicas. Para el correcto funcionamiento, es necesario que la entrada esté mapeada para una variable dentro de la memoria de variables de entrada de representación directa (%I). 178 4. Configuración Figura 4-79. Función para Actualizar las Entradas Parámetros de Entrada Tipo byRackNumber BYTE Número del bastidor. Descripción bySlotNumber BYTE Número de la posición, en la cual se encuentra el módulo. Tabla 4-111. Parámetros de Entrada REFRESH_INPUT Posibles ERRORCODE: NoError: Ejecución con éxito; IOModuleAbsent: El módulo se configuró, sin embargo está ausente; IOModuleNotConfigured: El módulo no se ha configurado; ParameterMismatch: Ese error se devuelve en caso de que la opción Siempre actualizar variables no esté marcada o en caso de que la función REFRESH_INPUT se llame para un módulo que posea solamente salidas; InputReadFail: Falla crítica interna en el módulo (el frame transmitido por la función no se devolvió dentro del time-out estipulado); FrameTransmitError: Falla crítica interna en el módulo (error en la transmisión del frame de la función); BusBusy: Falla crítica interna en el módulo (el bus no está habilitado para transmitir el frame de la función). Ejemplo de utilización en Lenguaje ST: PROGRAM MainPrg VAR Info: ERRORCODE; byRackNumber: BYTE; bySlotNumber: BYTE; END_VAR //ENTRADAS: byRackNumber := 0; bySlotNumber := 10; //FUNCIÓN: Info := REFRESH_INPUT (byRackNumber, bySlotNumber); // Llamada de la función. // Variable ‘Info’ recibe posibles errores de la función. REFRESH_OUTPUT Ese bloque funcional se utiliza para actualizar las salidas del módulo especificado, sin aguardar que se complete el ciclo. Es importante resaltar que el tiempo de actualización de las salidas del módulo, se deberán considerar en el tiempo efectivo de actualización de las salidas en el aplicativo desarrollado por el usuario. ATENCIÓN: La función REFRESH_OUTPUT se debe utilizar solo e la tarea MainTask. Para ejecutar la actualización de salidas en otras tareas, la opción Enable I/O Update per Task se debe seleccionar, más informaciones con respecto a esta opción se pueden obtener en la Tabla 4-1. . 179 4. Configuración ATENCIÓN: La función REFRESH_OUTPUT no soporta la actualización de salidas que hayan sido mapeadas para variables simbólicas. Para el correcto funcionamiento, es necesario que la salida esté mapeada para una variable dentro de la memoria de variables de salida de representación directa (%Q). Figura 4-80. Función para Actualizar las Salidas Parámetros de Entrada Tipo byRackNumber BYTE Número del bastidor. Descripción bySlotNumber BYTE Número de la posición, en la cual se encuentra el módulo. Tabla 4-112. Parámetros de Entrada REFRESH_OUTPUT Posibles ERRORCODE: NoError: Ejecución con éxito; IOModuleAbsent: El módulo se configuró, sin embargo está ausente; IOModuleNotConfigured: El módulo no se ha configurado; ParameterMismatch: Ese error se devuelve en caso de que la opción Siempre actualizar variables no esté marcada o en caso de que la función REFRESH_OUTPUT se llame para un módulo que posea solamente entradas; OutputWriteFail: Falla crítica interna en el módulo (el frame transmitido por la función no se devolvió dentro del time-out estipulado); FrameTransmitError: Falla crítica interna en el módulo (error en la transmisión del frame de la función); BusBusy: Falla crítica interna en el módulo (el Bus no está habilitado para transmitir el frame de la función). Ejemplo de utilización en Lenguaje ST: PROGRAM MainPrg VAR Info: ERRORCODE; byRackNumber: BYTE; bySlotNumber: BYTE; END_VAR //ENTRADAS: byRackNumber := 0; bySlotNumber := 10; //FUNCIÓN: // Llamada de la función. Info := REFRESH_OUTPUT (byRackNumber, bySlotNumber); // Variable ‘Info’ recibe posibles errores de la función. Bloque funcional PID El bloque funcional PID se utiliza para controlar un proceso real. El bloque está presente en la biblioteca NextoPID, la cual se debe añadir al proyecto (para realizar el procedimiento de inserción de una biblioteca, consultar el Manual de Programación IEC 61131 - MP399800, capítulo Bibliotecas). 180 4. Configuración Figura 4-81. Bloque funcional PID Parámetros de Entrada Tipo Descripción SP REAL Setpoint. La unidad y el intervalo deben ser los mismos que el PV, pues las dos variables se pueden comparar. PV REAL Variable de proceso. La unidad y el intervalo deben ser los mismos que el SP, pues las dos variables se pueden comparar. Gp REAL Ganancia proporcional utilizada para calcular la acción proporcional del bloque PID. Td REAL Tiempo Derivativo, en segundos, se utiliza para calcular la acción derivativa del bloque PID. Ti REAL Tiempo Integral, en segundos, se utiliza para calcular la acción integral del bloque PID. BIAS REAL Compensación agregada a la variable manipulada. ManualMV REAL Valor atribuido a la variable manipulada, cuando se utiliza el modo manual. MaxVarMV REAL Máxima variación de la variable manipulada, entre el ciclo actual y el ciclo anterior. En caso de que sea cero o negativa, el bloque PID no tiene límite de variación de MV. MaxMV REAL Máximo valor de la variable manipulada. En caso de que el valor calculado sea mayor que el configurado, el MV será igual al MaxMV. MinMV REAL Mínimo valor de la variable manipulada. En caso de que el valor calculado sea menor que el configurado, el MV será igual al MinMV. REAL Tiempo muerto. Mínimo valor de error que causará la corrección de MV en modo automático, es decir, pequeños errores (menores que DeadBand) no causarán alteraciones en la variable manipulada. MaxPV REAL Máximo valor de la variable de proceso. Caso el valor de PV sea mayor que el configurado, el bloque PID detendrá el cálculo y se generará un código de error en la salida. MinPV REAL Mínimo valor de la variable de proceso. DeadBand 181 4. Configuración Parámetros de Entrada Tipo Descripción En caso de que el valor de PV sea menor que el configurado, el bloque PID detendrá el cálculo y se generará un código de error en la salida. SampleTime REAL Tiempo de muestreo. Define el periodo de llamada del bloque PID, en segundos, lo que puede variar de 0,001 s a 1000 s. Ese parámetro se desconsidera si el MeasureST es verdadero. EnableP BOOL Cuando verdadero, habilita la acción proporcional del bloque PID. En caso de que sea falso, la acción proporcional va a cero. EnableD BOOL Cuando verdadero, habilita acción derivativa del bloque PID. En caso de que sea falso, la acción derivativa va a cero. EnableI BOOL Cuando verdadero, habilita la acción integral del bloque PID. En caso de que sea falsa, la acción integral va a cero. DerivPV BOOL Cuando verdadero, la acción derivativa se calcula en la variable de proceso, siendo diferente de cero solamente cuando PV se altera. En caso de que sea falso, la acción derivativa se calcula en el error, siendo dependiente de las variables SP y PV. Manual BOOL Cuando verdadero, habilita el modo manual. En caso de que sea falso, habilita el modo automático. El modo de control del bloque PID afecta la manera como el MV y la acción integral se calculan. Direct BOOL Cuando verdadero, se selecciona el control directo, lo que hace con que MV se incluya en la respuesta para que se incluya en el PV. En caso de que sea falso, se selecciona el control reverso, lo que hace con que MV sea disminuido de la respuesta para que se incluya en el PV. MeasureST BOOL Cuando verdadero, el tiempo de muestreo se mide. En caso de que sea falso, el tiempo de muestreo se informa por el usuario en la variable SampleTime. Restart BOOL Cuando verdadero, el bloque PID se reinicia, e inicia todas las variables. También se puede utilizarlo para limpiar las acciones integral y derivativa; y los códigos de error en la salida del bloque. IntegralAction REAL Almacena la acción integral, la cual se elimina en estado de error. Tabla 4-113. Parámetros de Entrada PID Parámetros de Salida Tipo MV REAL Variable manipulada. EffST REAL Tiempo efectivo de muestreo, en segundos, que se utiliza para los cálculos de acción derivativa y tasa límite de MV. Eff3ST REAL Tiempo efectivo de muestreo de los tres últimos ciclos, en segundos, que se utiliza para los cálculos de acción derivativa. MaxEffST REAL Máximo valor del tiempo efectivo de muestreo, en segundos, desde el inicio del bloque PID. MinEffST REAL Mínimo valor del tiempo efectivo de muestreo, en segundos, desde el inicio del bloque PID. UINT Código de error que se exhibe por el bloque PID. Para removerlo, basta con solucionar el problema y reiniciar el bloque a través de la variable Restart. A continuación, sigue la descripción de los errores: 0: sin error 1: MaxMV < MinMV 2: MaxPV < MinPV 3: PV > MaxPV 4: PV < MinPV 5: Ti < 0,001 s (con acción integral habilitada) 6: Td < 0 s (con acción derivativa habilitada) ErrorCode Descripción 182 4. Configuración 7: Gp ≤ 0 8: MaxVarMV < 0 9: DeadBand < 0 10: SampleTime < 0,001 s o SampleTime > 1000 s (con MeasureST = falso) Tabla 4-114. Parámetros de Salida PID La Figura 4-82 muestra el diagrama de bloques de un lacio PID, según la ejecución de la UCP Nexto. Figura 4-82. Diagrama PID Timer Retentivo El Timer Retentivo es un bloque de funciones desarrollado para aplicaciones, como relojes de línea de producción, las cuales necesitan almacenar su valor y reiniciar el conteo del mismo punto en caso de falla en la alimentación. Los valores, guardados por el bloque de función, solamente se irán a cero en caso de que haya un Reset en Frío, Reset Original o el Download de una nueva aplicación (ver Manual del Usuario MasterTool IEC XE - MU299800), siendo que los contadores siguen en funcionamiento, aunque la aplicación esté parada (Modo Stop). ATENÇÃO: Es importante resaltar que, para el correcto funcionamiento de los bloques funcionales Timer Retentivo, las variables de control se deben declarar como Retain (VAR RETAIN). También es importante señalar que en el modo de simulación los bloques funcionales Timer Retentivo no funcionan correctamente debido a la necesidad de UCP para el correcto funcionamiento. A continuación, se describen los tres tipos de bloques disponibles en la biblioteca Nexto del software MasterTool IEC XE (para realizar el procedimiento de inserción de una biblioteca, consultar el Manual de Programación IEC 61131 - MP399800, capítulo Bibliotecas). TOF_RET El bloque funcional TOF_RET implementa un tiempo de retraso para deshabilitar una salida. Cuando la entrada IN tiene su estado alterado de verdadero (TRUE) para falso (FALSE), es decir, un borde 183 4. Configuración de bajada, el tiempo especificado PT transcurrirá hasta que la salida Q también sea falsa (FALSE). Cuando la entrada IN tenga nivel lógico 1 (TRUE), la salida Q también permanecerá en el mismo estado (TRUE), aun que eso suceda en medio a un conteo. El tiempo PT se puede alterar durante el conteo, pues el bloque asumirá el nuevo valor, desde que el conteo no haya llegado al fin. La Figura 4-83 representa el bloque TOF_RET y la Figura 4-84 muestra su comportamiento gráfico. Figura 4-83. Bloque funcional TOF_RET Parámetros de Entrada Tipo Descripción IN BOOL Esa variable, cuando recibe un borde de bajada, habilita el conteo del bloque. PT TIME Esa variable especifica el límite de conteo del bloque (tiempo de retraso). Tabla 4-115. Parámetros de Entrada TOF_RET Parámetros de Salida Tipo Descripción Q BOOL Esa variable va a FALSE en cuanto la variable PT (tiempo de retardo) alcanza su valor máximo. ET TIME Esa variable exhibe el valor actual del tiempo de retraso. Tabla 4-116. Parámetros de Salida TOF_RET Figura 4-84. Comportamiento Gráfico del Bloque funcional TOF_RET Ejemplo de uso en lenguaje ST: PROGRAM MainPrg VAR RETAIN bStart : BOOL := TRUE; TOF_RET : TOF_RET; END_VAR // Cuando bStart=FALSE empieza contar TOF_RET( IN := bStart, PT := T#20S); // Ejecuta acciones al final del recuento IF (TOF_RET.Q = FALSE) THEN bStart := TRUE; END_IF 184 4. Configuración TON_RET El bloque funcional TON_RET implementa un tiempo de retraso para habilitar una salida. Cuando la entrada IN tiene su estado alterado de falso (FALSE) hacia verdadero (TRUE), es decir, un borde de subida, el tiempo especificado PT transcurrirá hasta que la salida Q también sea verdadera (TRUE). Cuando la entrada IN tenga nivel lógico 0 (FALSE), la salida Q también permanecerá en el mismo estado (FALSE), aun que eso suceda en medio de un conteo. El tiempo PT se puede alterar durante el conteo, pues el bloque asumirá el nuevo valor, desde que el conteo no haya llegado al fin. La Figura 4-85 representa el bloque TON_RET y la Figura 4-86 muestra su comportamiento gráfico. Figura 4-85. Bloque funcional TON_RET Parámetros de Entrada Tipo Descripción IN BOOL Esa variable, cuando recibe un borde de bajada, habilita el conteo del bloque. PT TIME Esa variable especifica el límite de conteo del bloque (tiempo de retraso). Tabla 4-117. Parámetros de Entrada TON_RET Parámetros de Salida Tipo Descripción Q BOOL Esa variable va a TRUE en cuanto la variable PT (tempo de retraso) alcanza su valor máximo. ET TIME Esa variable exhibe el valor actual del tiempo de retraso. Tabla 4-118. Parámetros de Salida TON_RET Figura 4-86. Comportamiento Gráfico del Bloque funcional TON_RET Ejemplo de uso en lenguaje ST: PROGRAM MainPrg VAR RETAIN bStart : BOOL; TON_RET : TON_RET; END_VAR // Cuando bStart=TRUE empieza a contar TON_RET( IN := bStart, PT := T#20S); 185 4. Configuración // Ejecuta acciones al final del recuento IF (TON_RET.Q = TRUE) THEN bStart := FALSE; END_IF TP_RET El bloque funcional TP_RET trabaja como un trigger. El timer, que inicia cuando la entrada IN tiene su estado alterado de falso (FALSE) hacia verdadero (TRUE), es decir, un borde de subida; es contado hasta que el límite de tiempo PT se alcance. Durante el conteo, la salida Q es verdadera (TRUE), en caso contrario es falsa (FALSE). El tiempo PT se puede alterar durante el conteo, pues el bloque asumirá el nuevo valor, desde que el conteo no haya llegado al final. La Figura 4-87 representa el bloque TP_RET y la Figura 4-88 muestra su comportamiento gráfico. Figura 4-87. Bloque funcional TP_RET Parámetros de Entrada Tipo Descripción IN BOOL Esa variable, cuando recibe un borde de subida, habilita el conteo del bloque. PT TIME Esa variable especifica el límite de conteo del bloque (tiempo de retraso). Tabla 4-119. Parámetros de Entrada TP_RET Parámetros de Salida Tipo Descripción Q BOOL Esa variable es verdadera durante el conteo. En caso contrario es falsa. ET TIME Esa variable exhibe el valor actual del tiempo de retraso. Tabla 4-120. Parámetros de Salida TP_RET Figura 4-88. Comportamiento Gráfico del Bloque funcional TP_RET Ejemplo de uso en lenguaje ST: PROGRAM MainPrg VAR RETAIN bStart : BOOL; TP_RET : TP_RET; END_VAR 186 4. Configuración // Configura TP_NR TP_RET( IN := bStart, PT := T#20S); bStart := FALSE; // Acciones durante el conteo IF (TP_RET.Q = TRUE) THEN // Ejecuta mientras el conteo está activo ELSE // Ejecuta solamiente cuando el conteo está desactivado END_IF Timer No-Redundante El timer no-redundante se utiliza en aplicaciones para la UCP NX3030 redundante que necesitan un timer en el programa no-redundante de un half-cluster. Este timer no utiliza el timer IEC, por lo tanto, no se irá sincronizar en el caso de que el half-cluster reserva asuma el estado activo y el activo pase a reserva. A continuación, se describen los tres tipos de bloques ya disponibles en la biblioteca NextoStandard del software MasterTool IEC XE (para realizar el procedimiento de inserción de una biblioteca, consultar el Manual de Programación IEC 61131 - MP399800, capítulo Bibliotecas). TOF_NR El bloque funcional TOF_NR implementa un tiempo de retraso para deshabilitar una salida y tiene el funcionamiento y configuración parecidos al bloque funcional TOF_RET, lo que lo diferencia sólo por no ser redundante y tampoco retentivo. Figura 4-89. Bloque funcional TOF_NR Ejemplo de uso en lenguaje ST: PROGRAM NonSkippedProg VAR bStart : BOOL := TRUE; TOF_NR : TOF_NR; END_VAR // Cuando bStart=FALSE empieza a contar TOF_NR( IN := bStart, PT := T#20S); // Ejecuta acciones al final del recuento IF (TOF_NR.Q = FALSE) THEN bStart := TRUE; END_IF 187 4. Configuración TON_NR El bloque funcional TON_NR implementa un tiempo de retraso para habilitar una salida y tiene el funcionamiento y configuración parecidos al bloque funcional TON_RET, lo que lo diferencia sólo por no ser redundante y tampoco retentivo. Figura 4-90. Bloque funcional TON_NR Ejemplo de uso en lenguaje ST: PROGRAM NonSkippedProg VAR bStart : BOOL; TON_NR : TON_NR; END_VAR // Cuando bStart=TRUE empieza a contar TON_NR( IN := bStart, PT := T#20S); // Ejecuta acciones al final del recuento IF (TON_NR.Q = TRUE) THEN bStart := FALSE; END_IF TP_NR El bloque funcional TP_NR trabaja como un trigger y tiene el funcionamiento y configuración parecidos al bloque funcional TP_RET, lo que lo diferencia sólo por no ser redundante y tampoco retentivo. Figura 4-91. Bloque funcional TP_NR Ejemplo de uso en lenguaje ST: PROGRAM NonSkippedProg VAR bStart : BOOL; TP_NR : TP_NR; END_VAR // Configura TP_NR TP_NR( IN := bStart, PT := T#20S); bStart := FALSE; // Acciones durante el conteo 188 4. Configuración IF (TP_NR.Q = TRUE) THEN // Ejecuta mientras el conteo está activo ELSE // Ejecuta solamente cuando el conteo está desactivado END_IF Log de Usuario Recurso que logra al usuario crear sus propios registros y grabar en archivos en la tarjeta de memoria presente en la UCP. Los archivos se generan en un directorio específico de la tarjeta de memoria en CSV, permitiendo la visualización en editores de texto e planillas. Lo separador adoptado fue el carácter ponto e vírgula. Para más informaciones acerca de la utilización de la tarjeta de memoria, vea el capítulo Configura - Tarjeta de Memoria. Hay dos funciones disponibles, una para registrar informaciones y otra para remover todos los registros. A continuación hay una descripción de los tipos de datos utilizados por las funciones: Tipo de Dato USER_LOG_EVENT_TYPES Opción Descripción USER_LOG_EVENT_ERROR El usuario es libre para usar la mejor indicación según la severidad de su mensaje de log. USER_LOG_EVENT_DEBUG USER_LOG_EVENT_INFO USER_LOG_EVENT_WARN Mensaje de registro con un máximo de 150 caracteres. USER_LOG_MESSAGE USER_LOG_OK USER_LOG_FAILED La operación se realizó con éxito. La operación no se realizó con éxito. El motivo de la falla se puede comprobar en los logs del sistema– ver capítulo Mantenimiento - Log de Sistema. USER_LOG_BUFFER_FULL Mensajes se están añadiendo más allá de la capacidad de procesamiento. USER_LOG_NO_MEMORY En este momento, no hubo recursos para ejecutar la operación. USER_LOG_FILE_SYSTEM_ERROR Hubo un error al acceder a la tarjeta de memoria o no hay espacio disponible. Informaciones de error se pueden verificarse en logs de sistema – ver capítulo Mantenimiento - Log de Sistema. USER_LOG_NO_MEMORY_CARD No hay una tarjeta de memoria presente en la UCP. USER_LOG_MEMORY_CARD_FULL No hay espacio libre disponible en la tarjeta de memoria. USER_LOG_ERROR_CODES USER_LOG_PROCESSING El recurso está ocupado ejecutando la última operación, por ejemplo, borrando todos los archivos de log. Tabla 4-121. Tipos de Datos para Log de Usuario A continuación se describen las dos funciones disponibles en la biblioteca LibLogs en MasterTool IEC X 1.40. Para realizar el procedimiento de inserción de una biblioteca, consultar el Manual de Programación IEC 61131 - MP399800, capítulo Bibliotecas. ATTENTION: Los Logs de Usuario están disponibles sólo a partir de la versión 1.3.0.20 de las UCPs de la Serie Nexto. Del mismo modo para utilizar esta funcionalidad es necesaria la versión 1.40 o superior de MasterTool IEC XE. UserLogAdd Esta función se utiliza para añadir un nuevo mensaje de log de usuario, agregando en una nueva línea en el archivo de log en la tarjeta de memoria. El mensaje debe tener un tamaño máximo de 150 189 4. Configuración caracteres y el tipo de evento del mensaje. Variables de la aplicación se pueden registrar mediante conversión para string y concatenación con el mensaje principal. Se añade automáticamente al mensaje, información de fecha y hora en UTC (timestamp) con una resolución de milisegundos en la cual se registró el evento. La información de fecha y hora se utiliza también en la formación de los nombres de los archivos de log. La función UserLogAdd se puede utilizar para insertar múltiples mensajes dentro de una sola tarea, y también en diferentes tareas de la aplicación. Pero independiente de cada ejecución de la función en la aplicación, que sea en la misma tarea o tareas diferentes, todos utilizan la misma función para grabar los mensajes deseados. Por esta razón, se recomienda que la adición de mensajes a través de la función UserLogAdd en la aplicación se lleve a cabo cada 50 ms para impedir el retorno de buffer lleno. Si la función se ejecuta en períodos menores, pero respeta el tiempo medio de 50 ms entre cada adición de mensaje al final del intervalo de la tarea, también impide el regreso de buffer lleno. Para los logs se agregan correctamente, es importante respetar los plazos cuando se inserta la tarjeta y en el arranque de la UCP. Ver capítulo Configuración - Tarjeta de Memoria. Después de la operación, la función vuelve a las opciones para el tipo de dato USER_LOG_ERROR_CODES según la Tabla 4-121. Cuando el retorno de la función es diferente de USER_LOG_OK, el mensaje no ha sido registrado y se debe volver a ejecutar la función UserLogAdd con el mensaje deseado. En caso de retorno de fallas consecutivas de escritura, la tarjeta de memoria puede estar dañada. El reemplazo de una tarjeta de memoria sana asegura que los últimos mensajes registrados sean grabados en la tarjeta que no está dañada, desde que la UCP no se reinicie. La Figura 4-92 representa la función UserLogAdd y la Tabla 4-122 los parámetros de entrada: Figura 4-92. Función UserLogAdd Parámetros de entrada Tipo Descripción byEventType BYTE Esta variable especifica el tipo de evento del log que se agrega según las opciones para el tipo de dato USER_LOG_EVENT_TYPES. USER_LOG_MESSAGE Esta variable debe contener el conjunto de caracteres que compone el mensaje que se agregará al archivo de log. El mensaje debe contener un máximo de 150 caracteres. pszMessage Tabla 4-122. Parámetros de Entrada Los archivos del log se generan y se organizan en la tarjeta de memoria en un camino de directorios específicos que depende del número de serie de la UCP y de la versión del firmware instalada. Por ejemplo, para una UCP con número de serie 445627 y versión de firmware 1.4.0.4, el lugar donde los archivos de log se deben grabar en la tarjeta de memoria es MemoryCard/UserLog/445627/1.4.0.4/. Los nombres de los archivos de log están formados por la fecha y hora (timestamp) del primer mensaje. Excepto cuando hay un problema para que se use este nombre, por ejemplo, otro archivo existente con el mismo nombre, en esta situación se utiliza la fecha y hora instantánea. El nombre del archivo sigue el siguiente patrón: año/mes/día/hora/minuto/segundo/milisegundos.CSV. Si un archivo presenta problemas en el acceso por sector defectuoso y no es posible seguir con la escritura, se añadirá al nombre de este archivo la extensión “.corrupted” y se creará un nuevo archivo. La cantidad de logs por archivo no es fija, varía dependiendo del tamaño de los mensajes. La cantidad de archivos creados se limita a 1024 con tamaño máximo de 1 MB cada uno, lo que requiere de la tarjeta de memoria 1 GB de espacio libre. Al alcanzar el límite de 1024archivos creados en la tarjeta de memoria durante el funcionamiento del UCP, se eliminan los archivos más antiguos para que se conserven archivos con registros más recientes, incluso en los casos en que se remueva de forma parcial manual los archivos en el directorio donde los archivos se están grabando. 190 4. Configuración La visualización de los archivos de log se puede realizar a través de planillas o editores de texto convencionales. Las informaciones concatenadas, para que mejor se vean pueden venir con punto y coma entre las strings del mensaje para separarlos. Se debe tener en cuenta en la formatación de celdas con valores en punto flotante. Ejemplo de utilización en Lenguaje ST: PROGRAM MainPrg VAR eLogError : USER_LOG_ERROR_CODES; sMessage :USER_LOG_MESSAGE; END_VAR IF (m_rTemperature > MAX_TEMPERATURE_ACCEPT) THEN sMessage := 'Temperatura arriba del esperado: '; sMessage := concat(sMessage, REAL_TO_STRING(m_rTemperature)); sMessage := concat(sMessage, 'º'); eLogError := UserLogAdd(USER_LOG_EVENT_WARN, sMessage); //Variable ‘eLogError’ recibe posibles errores de la función. END_IF Ejemplo de contenido del archivo de log: (UserLog-201308271506245738.csv) Modelo; NX3030 Número de la serie; 445627 Versión de firmware; 1.4.0.4 27/08/2013 15:06:24.5738; WARN; Temperatura más alta que lo esperado: 25º 27/08/2013 16:37:45.3476; WARN; Temperatura más alta que lo esperado: 25º 28/08/2013 09:10:55.4201; WARN; Temperatura arriba del esperado: 26º UserLogDeleteAll La función UserLogDeleteAll realiza la eliminación de los archivos de log presentes en el directorio creado específicamente para la UCP en la cual está insertada la tarjeta de memoria, es decir, sólo son borrados de los registros contenidos en el directorio nombrado con la versión de firmware de la UCP que existe dentro del directorio con la versión serial de la UCP. Los archivos de registro eliminados son solamente los archivos que existen en el momento del montaje de la tarjeta de memoria y los generados por la función UserLogAdd. No se eliminan los registros de otras UCPs y archivos añadidos manualmente por el usuario durante la ejecución. La Figura 4-93 representa la función UserLogDeleteAll. Figura 4-93. Función UserLogDeleteAll Ejemplo de utilización en Lenguaje ST: PROGRAM MainPrg VAR eLogError : USER_LOG_ERROR_CODES; END_VAR IF (m_DeleteLogs = TRUE) THEN eLogError := UserLogDeleteAll(); m_DeleteLogs := FALSE; //Variable ‘eLogError’ recibe posibles errores de la función. END_IF 191 4. Configuración ATENCIÓN: El retorno de la función UserLogDeleteAll no indica Operación completada, sólo la confirmación de ejecución que puede tomar una gran cantidad de tiempo si hay cientos de archivos de log en el directorio. La función para grabar nuevos logs de usuario no estará disponible en este momento, volviendo a la opción USER_LOG_PROCESSING para cualquier operación. El resultado de la operación también se puede verificar en el log del sistema. SNMP Introducción SNMP (Simple Network Management Protocol) es un protocolo muy utilizado por administradores de redes por proveer importantes informaciones y diagnósticos de equipos presentes en determinada red Ethernet. Este protocolo usa el concepto de agente y gerente, en el cual el gerente envía solicitudes de lectura o escritura de determinados objetos al agente. A través de una MIB (Management Information Base), el gerente tiene conocimiento de los objetos existentes en el agente, y de esa forma podrá hacer solicitudes de esos objetos, respetando sus permisiones de lectura o escritura. MIB es una colección de informaciones organizadas jerárquicamente, en la cual cada objeto de este árbol se llama OID (Object Identifier). Para todos los dispositivos con SNMP, es obligatorio el soporte a MIB II. En esta MIB se describen la informaciones más importantes para la gestión de redes Ethernet. SNMP en UCPs Nexto La UCPs de la Serie Nexto se comportan como agentes en la comunicación SNMP. Las informaciones disponibles a través del SNMP no se pueden manejar o acceder a través de la aplicación del usuario, es necesario un gerente SNMP externo para efectuar el acceso. La Tabla 4-123 contiene los objetos disponibles en las UCPs Nexto. Esta funcionalidad está disponible a partir de la versión de firmware 1.4.0.33, de las UCPs de la Serie Nexto, brindan soporte a los protocolos SNMPv1, SNMPv2c y SNMPv3, más allá de soporte la MIB-II, en la cual objetos obligatorios se describen en la RFC-1213. OID Nombre Descripción 1.3.6.1.2.1.1 System Contiene nombre, descripción, ubicación y otros datos de identificación del equipo. 1.3.6.1.2.1.2 Interfaces Contiene informaciones de las interfaces de red del equipo. La tabla ifTable (OID 1.3.6.1.2.1.2.2) posee los indexes 6 y 7 disponibles, por los cuales se pueden visualizar las estadísticas de las interfaces de red NET 1 y NET 2, respectivamente, de las UCPs de la serie Nexto. 1.3.6.1.2.1.3 At 1.3.6.1.2.1.4 Ip 1.3.6.1.2.1.5 Icmp 1.3.6.1.2.1.6 Tcp 1.3.6.1.2.1.7 Udp 1.3.6.1.2.1.11 Snmp 1.3.6.1.2.1.31 ifMib Contiene informaciones de las últimas conexiones solicitadas al agente. Contiene estadísticas de conexiones usando el protocolo IP. Contiene estadísticas para el protocolo ICMP. Contiene estadísticas para el protocolo TCP. Contiene las estadísticas para el protocolo UDP. Contiene las estadísticas para el protocolo SNMP. Extensión para Interfaces, OID 1.3.6.1.2.1.2. Tabla 4-123. Objetos de MIB-II - Agente SNMP de la Serie Nexto 192 4. Configuración Por estándar, el agente SNMP está activado, o sea, el servicio inicia en el momento en que la UCP se inicia. El acceso a las informaciones del agente ocurre a través de las interfaces Ethernet NET 1 y NET 2 de las UCPs de la Serie Nexto en la puerta TCP 161. Por lo tanto, cuando el servicio está activo, las informaciones del agente se podrán acceder a través de cualquiera de las dos interfaces Ethernet, según la disponibilidad de la UCP en uso. No es posible proporcionar informaciones del agente a través de las interfaces de Ethernet de los módulos NX5000. En la Figura 4-94 se muestra un ejemplo de gerente SNMP, en el cual se leen algunos valores. Figura 4-94. Ejemplo de Gerente SNMP Para SNMPv3, en la cual existe autenticación de usuario y contraseña para solicitudes por protocolo SNMP, se provee un usuario estándar descrito en la sección Usuario y Comunidades SNMP. En el caso de que el usuario desee desactivar el servicio, alterar el usuario SNMPv3 o las comunidades para SNMPv1/v2c predefinidos, será necesario acceder a la página web de la UCP. Para más detalles consulte la sección Configuración. Private MIB Más allá de soporte, la MIB-II, las UCPs de la serie Nexto ofrecen soporte a Private MIB a partir de la versión de firmware 1.4.0.25. Para eso, se reservó una PEN (Private Enterprise Number) con el número 43427 exclusivo para productos Altus S.A. Así, todos los objetos particulares de la Serie Nexto se pueden acceder mediante el OID .1.3.6.1.4.1.43427.1 (iso.org.dod.internet.private.enterprise.AltusSA.Nexto). En este OID hay tres subdivisiones relacionadas a las UCPs Nexto, como se puede ver en la Figura 4-95. Todos los objetos privados se describen en las MIBs ALTUS-NEXTO-NX3004-MIB, ALTUSNEXTO-NX3005-MIB, ALTUS-NEXTO-NX3010-MIB, ALTUS-NEXTO-NX3020-MIB y ALTUS-NEXTO-NX3030-MIB y pueden encontrarse en www.altus.com.br. 193 4. Configuración Figura 4-95. OID Tree View Los objetos disponibles por SNMP en las UCPs de la serie Nexto son diagnósticos ya existentes, y que poseen importancia para el gerenciamiento de redes. Estos objetos pueden verse en la Tabla 4-124. Para accederlos a través de un gerente SNMP, el usuario deberá hacer solicitudes a partir del OID .1.3.6.1.4.1.43427.1.4.1 para NX3004, 1.3.6.1.4.1.43427.1.5.1 para NX3005, .1.3.6.1.4.1.43427.1.1.1 para NX3010, .1.3.6.1.4.1.43427.1.2.1 para NX3020 e .1.3.6.1.4.1.43427.1.3.1 para NX3030. Por ejemplo, si el usuario desea monitorear la temperatura interna de una UCP NX3030, el OID correspondiente, en ese caso, será 1.3.6.1.4.1.43427.1.3.1.5.3. (iso.org.dod.internet.private.enterprise.AltusSA.Nexto.NX3030.NextoDiags.Thermometer.Temperat ure). Grupo Target Diagnóstico Descripción CPUModel NX30xx. CPUVersion Versión del firmware. Versión del bootloader. BootloaderVersion AuxprocVersion 1 Versión del procesador auxiliar. AuxprocFailure Falla de comunicación entre el procesador auxiliar y el procesador principal. RTCFailure El procesador principal no está habilitado para comunicarse con el RTC (reloj de la UCP). ThermometerFailure Falla de comunicación entre el termómetro y el procesador principal. 1 Hardware LCDFailure Falla de comunicación entre la pantalla LCD y el procesador principal. CPUInitStatus Status de la Inicialización de la UCP: 01: Hot start 02: Warm Start 03: Cold Start Obs.: Estas variables se reinician en todas las 1 RetainInfo 194 4. Configuración Grupo Descripción energizaciones. Diagnóstico CPUColdStartCounter Contador de Inicialización a frío: Se incrementará solamente debido a la retirada a caliente de la UCP en el bus y no debido al comando de Reset a Frío del MasterTool IEC XE (0 a 65535). CPUWarmStartCounter Contador de Inicialización a caliente: Se incrementará solamente durante la secuencia de energizaciones del sistema y no debido al comando de Reset a Caliente del MasterTool IEC XE (0 a 65535). CPUHotStartCounter Contador de disturbios menores que el tiempo de soporte a las fallas en la alimentación de la UCP (0 a 65535). 1 RTSResetCounter Contador de reset efectuados por el RTS (Runtime System) (0 a 65535). BrownOut La UCP reinició debido a una falla en la alimentación en la última inicialización. Watchdog La UCP reinició debido al perro guardián activo en la última inicialización. UnderTemperatureAlarm Alarma generada debido a que la temperatura interna está en 0 ºC o bajo 0 ºC. OverTemperatureAlarm Alarma generada debido a que la temperatura interna está en 85 ºC o arriba 85 ºC. Temperature Temperatura interna. ModbusRtuEthClient1 Cliente MODBUS RTU vía TCP. ModbusEthClient1 Cliente MODBUS TCP. ModbusRtuEthServer1 Servidor MODBUS RTU vía TCP. ModbusEthServer1 Servidor MODBUS TCP. Reset Thermometer NET 1 Ethernet ModbusRtuEthClient2 NET 2 ModbusEthClient2 Cliente MODBUS RTU vía TCP. 1 Cliente MODBUS TCP. ModbusRtuEthServer2 ModbusEthServer2 Application 1 1 Servidor MODBUS RTU vía TCP. 1 Servidor MODBUS TCP. CPUState Informa el estado de operación de la UCP: 00: Aplicación parada (Modo Stop) 01: Aplicación en ejecución (Modo Run) 02: Aplicación parada en Breakpoint 03: verbo ForcedIOs Hay uno o más puntos de IO forzados. ServiceEnabled Servicio SNTP habilitado. ActiveTimeServer Indica qué servidor está activo: 00: Ningún servidor activo 01: Servidor primario activo 02: Servidor secundario activo PrimaryServerDownCount Contador de veces que el servidor primario estuvo indisponible (0 a 65535). SecondaryServerDownCount Contador de veces que el servidor secundario estuvo indisponible (0 a 65535). RTCTimeUpdatedCount Contador de veces que el RTC se actualizó por el servicio SNTP (0 a 4294967295). LastUpdateSuccessful Indica el status de la última actualización: 00: No ha sido actualizado 01: verbo 02: Última actualización con éxito LastUpdateTimeServer Indica qué servidor se utilizó en la última actualización: 00: No hay actualización 01: Servidor primario 02: Servidor secundario LastUpdateTimeDayOfMonth Día de la última actualización del RTC. LastUpdateTimeMonth Mes de la última actualización del RTC. LastUpdateTimeYear Año de la última actualización del RTC. LastUpdateTimeHours Hora de la última actualización del RTC. SNTP 195 4. Configuración Grupo Diagnóstico Descripción LastUpdateTimeMinutes Minuto de la última actualización del RTC. LastUpdateTimeSeconds Segundo de la última actualización del RTC. LastUpdateTimeMilliseconds Milisegundos de la última actualización del RTC. ConnectionStatus1 SOE1 OverflowStatus1 1 Estado de la conexión del cliente 01. Status de la fila de eventos del cliente 01 FALSE - No hubo desbordamiento TRUE - Límite de la fila sobrepasado 1 1 Contador de eventos en la fila del cliente 01. EventsCounter1 SOE ConnectionStatus2 SOE2 OverflowStatus2 1 Status de conexión del cliente 02. Status de la fila de eventos del cliente 02 FALSE - No hubo desbordamiento TRUE - Límite de la fila sobrepasado 1 1 Contador de eventos en la fila del cliente 02. EventsCounter2 Tabla 4-124. Diagnósticos vía SNMP (1) Estos diagnósticos no están disponibles en la UCP NX3004 and NX3005. ATENCIÓN: Los ítems Ethernet NET2 y SOE están disponibles solamente para las UCPs NX3020 y NX3030. Configuración Las configuraciones del SNMP se pueden alterar a través de la página web, en la pestaña Gerenciamiento de la UCP, en el menú SNMP. Para tener acceso a las configuraciones, el usuario deberá primero efectuar el login, según la Figura 4-96. Figura 4-96. Pantalla de Login SNMP Efectuado el login con éxito, se podrá visualizar el estado actual del servicio (activado o desactivado), así como las informaciones de usuario SNMPv3 y comunidades para SNMPv1/v2c. El usuario podrá activar o desactivar el servicio a través de un checkbox en la parte superior de la pantalla. Es posible también alterar las informaciones de SNMPv3, al pulsar el botón Alterar abajo de las informaciones de usuario. Se abrirá un formulario en el cual es necesario llenar el espacio de usuario y contraseña antiguos, y el nuevo usuario y contraseña. Las demás informaciones de usuario SNMPv3 no se pueden alterar. 196 4. Configuración Para alterar los datos de las comunidades SNMPv1/v2c, el proceso es parecido, basta pulsar el botón Alterar abajo de las informaciones de las comunidades. Una nueva pantalla se abrirá donde se insertarán los nuevos datos para los campos rocommunity y rwcommunity. En el caso de que el usuario deje cualquiera de los campos sin llenar, la respectiva comunidad se desactivará. De esta forma, si el usuario deja los 2 campos sin llenar, el acceso al agente SNMP será posible solamente a través del SNMPv3. En el caso de que el usuario desee retornar a las configuraciones estándar, será necesario reconfigurarlas manualmente según la sección Usuario y Comunidades SNMP. Por lo tanto, todas las configuraciones SNMP actuales se mantendrán en el proceso de actualización de firmware. Estas opciones se pueden visualizar en la Figura 4-97. Figura 4-97. Pantalla de Configuración y Status SNMP ATENCIÓN: En el caso de que las pantallas presentadas sean diferentes de las visualizadas en el navegador, será necesario que se haga una limpieza de cache del navegador. ATENCIÓN: El usuario y la contraseña para login en la página web de las Configuraciones SNMP y para acceder al agente por protocolo SNMP son iguales. Usuario y Comunidades SNMP Para acceso al SNMPv1/v2c de las UCPs de la Serie Nexto, hay dos comunidades, como se muestra en la Tabla 4-125. Comunidades String Estándar Tipo rocommunity Public Solamente lectura rwcommunity Private Lectura y escritura Tabla 4-125. Informaciones de Comunidades Estándar SNMPv1/v2c Es posible acceder al SNMPv3 a través del usuario estándar, según se describe en la Tabla 4-126. 197 4. Configuración Usuario Tipo Protocolo de Autenticación Contraseña Autenticación Protocolo Privado Contraseña Privado administrator rwuser MD5 Administrator - - Tabla 4-126. Informaciones de Usuario Estándar SNMPv3 Para todas las configuraciones de comunidades, usuario y contraseña existen límites que se deben observar en la Tabla 4-127. Ítem configurable Tamaño mínimo Tamaño máximo Caracteres permitidos rocommunity - 30 [0-9][a-z][A-Z]@$*_. rwcommunity - 30 [0-9][a-z][A-Z]@$*_. Usuario v3 - 30 [0-9][a-z][A-Z]@$*_. Contraseña v3 8 30 [0-9][a-z][A-Z]@$*_. Tabla 4-127. Límites para Configuraciones SNMP Gerenciamiento de Usuarios y Derechos de Acceso Este provee funciones para definir cuentas de los usuarios y configurar los derechos de acceso al proyecto y a la UCP. Al utilizar el software MasterTool IEC XE es posible crear y gerenciar usuarios y grupos, configurándoles diferentes niveles de derechos de acceso al proyecto. Simultáneamente, las UCPs Nexto poseen un sistema de gerenciamiento de permisiones de usuario, que bloquea o permite ciertas acciones a cada grupo de usuarios en la UCP. Para más informaciones es necesario consultar el Manual del Usuario MasterTool IEC XE - MU299800, capítulo Gerenciamiento de Usuarios y Derechos de Acceso. 198 5. Programación Inicial 5. Programación Inicial El objetivo de este capítulo es ayudar en la programación y configuración de las UCPs de la Serie Nexto para que el usuario logre dar sus primeros pasos antes de iniciar la programación de un CP. Las UCPs de la Serie Nexto utilizan la norma estándar de lenguajes IEC 61131-3, que son IL, ST, LD, SFC y FBD, y, además, un lenguaje extra, CFC. Se pueden separar esos lenguajes en textuales y gráficos. IL y ST son lenguajes textuales y son semejantes al Assembly y el lenguaje C. LD, SFC y FBD son lenguajes gráficos. LD usa la representación de bloques de relés y es similar al diagrama de relés. SFC usa la representación de diagrama de secuencia, lo que posibilita una manera fácil de ver las secuencias de eventos. FBD usa un conjunto de bloques funciones que permiten una visión clara de las funciones ejercidas por cada acción. La programación se hace a través de la interfaz de desarrollo MasterTool IEC XE (IDE). La interfaz de desarrollo posibilita el uso de los seis lenguajes en el mismo proyecto, de esta forma, provee las mejores características que cada lenguaje puede ofrecer al usuario, lo que resulta en el desarrollo de aplicaciones más eficientes y permite la fácil documentación y mantenimiento futuros. Para más informaciones sobre Programación, consultar Manual del Usuario MasterTool IEC XE MU299800, Manual de Programación MasterTool IEC XE - MP399800 o el estándar IEC 61131-3. Organización y Acceso a la Memoria La Serie Nexto utiliza una innovadora característica de organización y acceso a la memoria denominada big-endian, es decir, el byte más significativo se almacena primeramente y siempre será el de menor dirección (Ej.: %QB0 siempre será más significativo que el %QB1, como en la Tabla 5-1. , donde, para la palabra UCPNEXTO, la letra U es el byte 0 y la letra O es el byte 7). El acceso a la memoria se debe realizar con cuidado pues las variables con mayor número de bits (WORD, DWORD, LONG), utilizan como índice el byte más significativo, es decir, la %QD4 siempre tendrá, como byte más significativo, el byte %QB4. De esta forma, no se necesitará realizar cálculos para descubrir cuál es la DWORD correspondiente a determinados bytes. A continuación, la Tabla 5-1. muestra un ejemplo de organización little-endian y big-endian: HSB <– Little-endian (Tradicional) –> LSB BYTE %QB7 %QB6 %QB5 %QB4 %QB3 %QB2 %QB1 %QB0 U C P N E X T O WORD %QW3 %QW2 %QW1 %QW0 UC PN EX TO DWORD %QD1 %QD0 UCPN EXTO LWORD %QL0 UCPNEXTO HSB <– Big-endian (NEXTO) –> LSB BYTE WORD %QB0 %QB1 %QB2 %QB3 %QB4 %QB5 %QB6 %QB7 U C P N E X T O %QW0 UC DWORD %QW2 %QW4 PN EX %QD0 %QW6 TO %QD4 UCPN EXTO LWORD %QL0 UCPNEXTO Tabla 5-1. Ejemplo 199 5. Programación Inicial IMPORTANCIA Bit Byte Word SUPERPOSICIÓN DWord LWord Byte Word DWord %QX0.7 %QX0.6 %QX0.5 %QX0.4 %QB00 %QB00 %QX0.3 %QX0.2 %QX0.1 %QX0.0 %QW00 %QW00 %QX1.7 %QX1.6 %QX1.5 HSB %QX1.4 %QB01 %QB01 %QX1.3 %QX1.2 %QX1.1 %QX1.0 %QD00 %QW01 %QD00 %QX2.7 %QX2.6 %QX2.5 LSB %QX2.4 %QB02 %QB02 %QX2.3 %QX2.2 %QX2.1 %QX2.0 %QW02 %QW02 %QD01 %QX3.7 %QX3.6 %QX3.5 %QX3.4 %QB03 %QB03 %QX3.3 %QX3.2 %QX3.1 %QX3.0 %QW03 %QL00 %QD02 %QX4.7 %QX4.6 %QX4.5 %QX4.4 %QB04 %QB04 %QX4.3 %QX4.2 %QX4.1 %QX4.0 %QW04 %QW04 %QD03 %QX5.7 %QX5.6 %QX5.5 %QX5.4 HSB %QB05 %QB05 %QX5.3 %QX5.2 %QX5.1 %QX5.0 %QW05 %QD04 %QX6.7 %QX6.6 %QX6.5 %QX6.4 LSB %QB06 %QB06 %QX6.3 %QX6.2 %QX6.1 %QX6.0 %QW6 %QW06 %QX7.7 %QX7.6 %QX7.5 %QX7.4 %QB07 %QB07 %QX7.3 %QX7.2 %QX7.1 %QX7.0 Tabla 5-2. Organización y Acceso a Memoria 200 %QD04 5. Programación Inicial La Tabla 5-2 muestra la organización y acceso a la memoria y ejemplifica la significancia de los bytes (Significance) y la disposición de los demás tipos de variable, incluso la sobreposición (Overlapping). Perfiles de Proyecto Un perfil de proyecto en el MasterTool IEC XE es un conjunto de reglas, características comunes y estándares utilizados en el desarrollo de una solución de automación industrial, un perfil que influye en la forma de implementación de la aplicación. Con la diversidad de tipos de aplicaciones soportadas por el Runtime System (RTS) de la Serie Nexto, seguir un perfil es una forma de reducir la complejidad en la programación. Las aplicaciones se pueden crear según uno de los siguientes perfiles: Simples Básico Normal Experto Personalizado Perfil de Máquina Para cada perfil definido para el RTS, el MasterTool IEC XE puede disponer de innúmeros templates compatibles. El usuario, al seleccionar un template como modelo en la creación de un proyecto, desarrollará la nueva aplicación según un determinado perfil, adoptando las reglas, características y estándares definidos por el perfil asociado al template. Cada perfil de proyecto define nombres estandarizados a las tareas y programas, los cuales se precrean por los templates de proyecto. El desarrollador está obligado a seguir rigurosamente la nomenclatura para tareas, pero puede seguir o no los nombres sugeridos para los respectivos programas. Para garantizar la compatibilidad de un proyecto a un determinado perfil a lo largo del desarrollo, se utilizan dos abordajes: El MasterTool IEC XE solamente permite la creación de proyectos basados en un template, seleccionando al mismo tiempo el perfil a utilizar. En la generación de código, el MasterTool IEC XE realiza la verificación de todas las reglas definidas para el perfil válido para el proyecto. Las próximas secciones detallan las características o estándares de cada perfil de proyecto que siguen una escala gradual de complejidad. Con base en estas definiciones, se recomienda que el usuario siempre busque utilizar el perfil más simple que atienda a las necesidades de su aplicación, y se desplace a otro más sofisticado solo cuando las reglas correspondientes estén siendo más trabas al desarrollo que simplificaciones didácticas. Cabe resaltar que la herramienta de programación permite la alteración del perfil de un proyecto existente (consultar la sección Actualización de proyecto, en el Manual del Usuario MasterTool IEC XE - MU299800), pero cabrá al desarrollador realizar cualquier ajuste necesario para que el proyecto se vuelva compatible con las reglas del nuevo perfil seleccionado. ATENCIÓN: En el transcurso de los perfiles de proyecto se nombran algunos tipos de tareas, las cuales se describen en la sección Configuración de las Tareas, en el Manual del Usuario MasterTool IEC XE MU299800. ATENCIÓN: Al utilizar más de una tarea, el acceso de E/S solo se debe ejecutar en el contexto de la tarea principal, MainTask (en el caso de que no se pueda utilizar la opción Enable I/O Update per Task, presente a partir de la versión 2.01 del MasterTool IEC XE). 201 5. Programación Inicial Simple En el perfil de proyecto Simple, la aplicación posee solo la tarea de usuario MainTask. Esta tarea es responsable de la ejecución de una única unidad de programación del tipo Program denominada MainPrg. Este único programa puede llamar a otras unidades de programación del tipo Programa, Función o Bloque Funcional, pero todos los códigos de usuario se ejecutarán exclusivamente por la tarea MainTask. En este perfil, la tarea MainTask será del tipo cíclica (Cyclic) con prioridad fijada como 13 (trece) y ejecuta exclusivamente el programa MainPrg en un lazo continuo. La tarea MainTask ya está completamente definida y el desarrollador necesita crear el programa MainPrg optando por cualquiera de los lenguajes de la norma IEC. No siempre es posible convertir un programa a otro lenguaje, pero siempre es posible crear un nuevo programa con el mismo nombre en sustitución que sea construido en lenguaje diverso. La opción estándar del MasterTool IEC XE es utilizar el MasterTool Standard Project asociado al perfil Single, el cual también incluye el programa MainPrg creado en el lenguaje elegido en la creación del proyecto. En una aplicación de este tipo, nunca se necesita tener en consideración cuestiones como consistencia de datos, compartición de recursos o mecanismos de exclusión mutua. Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Cíclica 20 ms - Tabla 5-3. Tarea en el Perfil Simple Básico En el perfil de proyecto Básico, la aplicación posee una tarea de usuario del tipo Continua denominada MainTask, que ejecuta en un lazo continuo (sin definición de intervalo) con prioridad fijada como 13 (trece). Esta tarea es responsable de la ejecución de una única unidad de programación POU denominada MainPrg. Es importante resaltar que el intervalo puede variar en función de la cantidad de tareas de comunicación utilizadas, pues en ese modo, la tarea principal se interrumpe por tareas de comunicación. Este perfil también permite la inclusión de dos tareas de evento con mayor prioridad que pueden interrumpir (preemptar) la MainTask a cualquier momento: la tarea llamada ExternInterrupt es una tarea de evento del tipo Extern con prioridad fijada en 02 (dos); la tarea llamada TimeInterruptTask00 es del tipo Cyclic con prioridad fijada como 01 (uno). El modelo de proyecto Básico, incluye estas tres tareas ya completamente definidas según lo presentado en la Tabla 5-4. El desarrollador necesita solo crear los programas asociados. Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Continua - - ExternInterruptTask00 ExternInterruptPrg00 02 Externa - IO_EVT_0 TimeInterruptTask00 TimeInterruptTask00 01 Cíclica 20 ms - Tabla 5-4. Tareas en el Perfil Básico Normal En el perfil de proyecto Normal, la aplicación posee una tarea de usuario del tipo Cyclic denominada MainTask. Esta tarea es responsable de la ejecución de una única unidad de programación del tipo Program denominada MainPrg. Este programa y esta tarea son equivalentes a la única tarea y único programa del perfil Single, pero aquí la aplicación puede integrar tareas adicionales de usuario. Estas otras tareas se denominan CyclicTask00 y CyclicTask01, cada cual responsable de la ejecución exclusiva del respectivo programa CyclicPrg<nn>. Las tareas CyclicTask<nn> son siempre del tipo cíclica (Cyclic) con prioridad fijada como 13 (trece), prioridad idéntica a la tarea MainTask. Estos dos tipos forman un conjunto denominado tareas básicas, cuyos programas asociados pueden llamar a otras POUs del tipo Programa, Función o Bloque Funcional. 202 5. Programación Inicial Este perfil puede también incluir tareas de evento con mayor prioridad que las tareas básicas y que por consecuencia pueden interrumpir (preemptar) la ejecución de las anteriores a cualquier momento. La tarea llamada ExternInterruptTask00 es una tarea de evento del tipo Externa (Extern) cuya ejecución dispara por algún evento externo, tales como variación de una señal de control en una puerta serial o variación de una entrada digital en el bus del NEXTO. La prioridad de esta tarea está fijada en 02 (dos), siendo responsable de la ejecución exclusiva del programa ExternInterruptPrg00. La tarea llamada TimeInterruptTask00 es una tarea de evento del tipo Cíclica (Cyclic) con prioridad fijada como 01 (un), siendo responsable de la ejecución exclusiva del programa TimeInterruptPrg00. En el modelo de proyecto Normal, existen cinco tareas, y sus POUS, ya completamente definidas según lo presentado en la Tabla 5-5. El desarrollador necesita solamente implementar los contenidos de los programas optando, en el wizard, por cualquiera de los lenguajes de la norma. Los intervalos y eventos de disparo de las tareas se pueden configurar por el desarrollador y las tareas no necesarias se deberán eliminar. Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Cíclica 20 ms - CyclicTask00 CyclicPrg00 13 Cíclica 200 ms - CyclicTask01 CyclicPrg01 13 Cíclica 500 ms - ExternInterruptTask00 ExternInterruptPrg00 02 Externa - IO_EVT_0 TimeInterruptTask00 TimeInterruptTask00 01 Cíclica 20 ms - Tabla 5-5. Tareas en el Perfil Normal Experto El perfil de proyecto Experto incluye las mismas tareas básicas, MainTask, CyclicTask<nn>, ExternInterruptTask00 y TimeInterruptTask00, con las mismas prioridades (13; 02 y 01 respectivamente), pero es una expansión de los anteriores, pues admite múltiples tareas de evento. Es decir, la aplicación puede incluir varias tareas ExternInterruptTask<nn> o TimeInterruptTask<nn> ejecutando los programas ExternInterruptPrg<nn> y TimeInterruptPrg<nn>. Las prioridades de las tareas de evento adicionales se pueden libremente seleccionar en la franja de 08 a 12. En este perfil, más allá de los programas estándares, cada tarea puede ejecutar programas adicionales. En este perfil de proyecto, la aplicación aún puede incluir la tarea de usuario FreeTask del tipo Freewheeling con prioridad 31, responsable de la ejecución del programa FreePrg. Como esta tarea es de baja prioridad puede ser interrumpida por todas las demás, de esta forma es capaz de ejecutar códigos que pueden quedar bloqueados. Existen ocho tareas ya completamente definidas según lo presentado en la Tabla 5-6, bien como los respectivos programas asociados creados en el lenguaje que el usuario seleccione. Los intervalos y eventos de disparo de cualquier tarea y las prioridades de las tareas de evento se pueden configurar también por el usuario. Al desarrollar la aplicación usando el perfil de proyecto Experto, es necesario un cuidado especial con el escalonamiento de las tareas de evento. En el caso de que exista compartición de informaciones y recursos entre estas tareas o entre estas y las tareas básicas es fuertemente recomendable adoptar estrategias para garantizar la consistencia de datos. 203 5. Programación Inicial Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Cíclica 20 ms - CyclicTask00 CyclicPrg00 13 Cíclica 200 ms - CyclicTask01 CyclicPrg01 13 Cíclica 500 ms - ExternInterruptTask00 ExternInterruptPrg00 02 Externa TimeInterruptTask00 TimeInterruptTask00 01 Cíclica 20 ms - ExternInterruptTask01 ExternInterruptPrg01 11 Externa - IO_EVT_1 TimeInterruptTask01 TimeInterruptPrg01 09 Cíclica 30 ms - FreeTask FreePrg 31 Continua - - IO_EVT_0 Tabla 5-6. Tareas en el Perfil Experto Personalizado El perfil de proyecto Personalizado permite al desarrollador explorar todas las potencialidades del Runtime System implantado en las unidades centrales de procesamiento de la Serie Nexto. Ninguna de las funcionalidades se deshabilita, ninguna prioridad, asociación entre tareas y programas o nomenclatura se impone. La única excepción se hace para la MainTask que debe existir siempre con este nombre en este Perfil. Más allá de las tareas en tiempo real con prioridades 00 a 15, las cuales se escalonan por prioridad, en este perfil también es posible definir tareas con prioridades menores en la franja 16 a 31. En esta franja, se usa el Completely Fair Scheduler (time sharing), lo que es necesario para la ejecución de códigos que pueden bloquearse (por ejemplo, uso de sockets). El desarrollador tiene la libertad para seguir parcialmente o no la organización definida en los demás perfiles de proyecto, según las particularidades de su aplicación. Por otro lado, el modelo personalizado, asociado a este perfil no necesita elementos predefinidos como tarea, programa o parámetro, cabiéndole al desarrollador la creación de todos los elementos que compone la aplicación. Sin embargo el usuario puede generar los mismos elementos disponibles para el perfil Experto. Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Cíclica 20 ms - CyclicTask00 CyclicPrg00 13 Cíclica 200 ms - CyclicTask01 CyclicPrg01 13 Cíclica 500 ms - ExternInterruptTask00 ExternInterruptPrg00 02 Externa - IO_EVT_0 TimeInterruptTask00 TimeInterruptTask00 01 Cíclica 20 ms - ExternInterruptTask01 ExternInterruptPrg01 11 Externa - IO_EVT_1 TimeInterruptTask01 TimeInterruptPrg01 09 Cíclica 30 ms - FreeTask FreePrg 31 Continua - - Tabla 5-7. Tareas en el Perfil Personalizado Perfil de Máquina En el perfil de Máquina, por estándar, la aplicación posee una tarea de usuario del tipo Cíclica denominada MainTask. Esta tarea es responsable por la ejecución de una única unidad de programación del tipo Program denominada MainPrg.Este programa puede llamar a otras unidades de programación del tipo Program, Function o Function Block, pero todo el código del usuario se ejecutará exclusivamente por la tarea MainTask. Este perfil se caracteriza por permitir intervalos menores en la tarea MainTask, lo que permite la ejecución más rápida del código del usuario. Esta optimización es posible pues la MainTask ejecuta también el procesamiento del bus. De esta forma, diferente de otros perfiles, el perfil de máquina no necesita conmutación de contexto para el tratamiento del bus, lo que reduce el tiempo de procesamiento general. 204 5. Programación Inicial Este perfil puede también incluir una tarea de interrupción de tiempo, denominada TimeInterruptTask00, con más prioridad que la tarea MainTask y que por consecuencia puede interrumpir su ejecución a cualquier momento. Tarea POU Prioridad Tipo Intervalo Evento MainTask MainPrg 13 Cíclica 20 ms - TimeInterruptTask00 TimeInterruptTask00 01 Cíclica 4 ms - Tabla 5-8. Tareas en el Perfil de Máquina Tabla General Perfiles de Proyecto Verificaciones Simple Máquina Básico Normal Experto Personaliza do 02 [01..03] [01..32] [01..32] [01..32] 01 01 <n> <n> Total de tareas Cantidad 01 Programas por tarea Cantidad 01 Main Task Nombre Time Interrupt Task Extern Interrupt Task Ciclic Task Free Task Event Task Tipo Cíclica Cíclica Continua Cíclica Cíclica <n> Prioridad 13 13 13 13 13 <n> Cantidad 01 01 01 01 01 01 Nombre <n> Tipo Cíclica Cíclica Cíclica Cíclica Cíclica Prioridad 01 01 01 01 o [08..12] <n> Cantidad [00..01] [00..01] [00..01] [00..31] [00..31] Nombre <n> Tipo Externa Externa Externa Externa Prioridad 02 02 02 o [08..12] <n> Cantidad [00..01] [00..01] [00..31] [00..31] Nombre CyclicTask <nn> CyclicTask<nn> <n> Tipo Cíclica Cíclica Cíclica Prioridad 13 13 <n> Cantidad [00..31] [00..31] [00..31] Nombre FreeTask <n> Tipo Rueda libre Rueda libre Prioridad 31 <n> Cantidad [00..01] [00..01] Nombre <n> Tipo Evento Prioridad <n> Cantidad [00..31] Tabla 5-9. Tabla General de Perfiles x Tareas ATENCIÓN: Los nombres sugeridos para las POUs asociadas a las tareas no son consistidos. Se pueden sustituir desde que se sustituyan también en las configuraciones de las tareas. Número Máximo de Tareas El número máximo de tareas que el usuario podrá crear solamente está definido para el perfil Personalizado, es decir, el único que tiene esa permisión. Los demás ya tienen sus tareas creadas y configuradas. Sin embargo las tareas que se crean deben utilizar los profijos, de acuerdo con el tipo 205 5. Programación Inicial de cada una de las tareas siguientes: CyclicTaskxx, TimeInterruptTaskxx, ExternInterruptTaskxx, donde xx es el número de la tarea que se está creando. A continuación, la Tabla 5-10. describe la cantidad máxima de tareas IEC por UCP y perfil de proyecto, siendo que las instancias de protocolo también se consideran tareas de comunicación por la UCP. 206 5. Programación Inicial Tipo de Tarea Configuration Task (Tarea WHSB) Tareas de Usuario NX3004/NX3005 NX3010 NX3020 NX3030 S B N E P M S B N E P M S B N E P M S B N E P M Cíclica 1 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 1 0 Cíclica 1 1 15 15 15 2 1 1 15 15 15 2 1 1 23 23 23 2 1 1 31 31 31 2 Disparada por Evento 0 0 0 0 15 0 0 0 0 0 15 0 0 0 0 0 23 0 0 0 0 0 31 0 Disp. Evento Externo 0 1 1 14 15 0 0 1 1 14 15 0 0 1 1 22 23 0 0 1 0 30 31 0 Continua 0 1 0 1 15 0 0 1 0 1 15 0 0 1 0 1 23 0 0 1 0 1 31 0 Disparada por Estado 0 0 0 0 15 0 0 0 0 0 15 0 0 0 0 0 23 0 0 0 0 0 31 0 NETs – Instancias Cliente o Servidor Cíclica 4 4 8 16 COM (n) – Instancias Maestro o Esclavo Cíclica 1 1 1 1 16 16 24 32 TOTAL Tabla 5-10. Número Máximo de Tareas IEC Notas: Leyenda del Perfil: Las letras S, B, N, E, P y M corresponden respectivamente a los Perfiles Simples, Básico, Normal, Experiente, Personalizado, Máquina. Valores: Los números definidos para cada tipo de tarea representan los valores máximos que se permiten. Tarea WHSB: La tarea WHSB que es una tarea de sistema se debe considerar para no sobrepasar el valor total. NETs: Instancias Cliente o Servidor: El valor máximo definido considera todas las interfaces Ethernet del sistema, es decir, incluye los módulos de expansión, cuando estos se aplican. Ejemplos para ese tipo de tarea son las instancias del Protocolo MODBUS. COM (n): Instancias Maestro o Esclavo: La "n" representa el número de la interfaz serial, es decir, aun con módulos de expansión, el valor de la tabla será el máximo por interfaz. Ejemplos para ese tipo de tarea son las instancias del Protocolo MODBUS. Total: El valor total no representa la suma de todas las tareas por perfil, sino, el valor máximo permitido por UCP. De esta forma, el usuario podrá crear varios tipos de tareas, desde que el número establecido para cada una y el valor total, no sean sobrepasados. 207 5. Programación Inicial Configurar la UCP La configuración de la UCP Nexto se basa en estructurar el área de diagnósticos, el área de memoria retentiva y persistente, modo de cambio en caliente, entre otros parámetros más. El usuario deberá hacer doble clic en la UCP Nexto, ubicada en el árbol de dispositivos, según muestra la Figura 5-1, y configurar los campos según lo descrito en el capítulo Configuración de la UCP. Figura 5-1. Configuración de la UCP Además, para que sea posible la comunicación entre la UCP y el MasterTool IEC XE, la interfaz Ethernet NET 1 se deberá configurar, según el capítulo Configuración de las Interfaces Ethernet – NET 1. Al hacer doble clic sobre el ícono NET 1 de la UCP, en el árbol de dispositivos, surgirá una nueva pestaña para configuración de la red de comunicación en la cual el módulo está conectado. Figura 5-2. Configurar la Puerta de Comunicación de la UCP 208 5. Programación Inicial En caso de que la UCP con el IP configurado no sea encontrada en la red o la UCP activa tenga un IP diferente de la activa, un mensaje surgirá en la pantalla durante el Login, solicitará al usuario la posibilidad de sustituir el IP antiguo por el configurado (opción Sim) o No para que no envíe el proyecto. Figura 5-3. Aviso de configuración IP Bibliotecas Existen distintos recursos de la herramienta de programación que están disponibles a través de bibliotecas. Así siendo, se deben insertar al proyecto para que su utilización sea posible. El procedimiento de inserción, así como más informaciones sobre las bibliotecas disponibles se puede encontrar en la Guía de programación IEC 61131 – MP399800, capítulo Bibliotecas. Insertando una Instancia de Protocolo Las propias UCPs de la Serie Nexto, según el capítulo Características Generales, disponen de protocolos, como el MODBUS. Basta con añadir y configurar (según el capítulo Configuración de Protocolos) la instancia del protocolo que se desea en la interfaz de comunicación. A continuación, se describen dos casos de inserción del protocolo MODBUS, uno en la interfaz serial y el otro en la interfaz Ethernet. MODBUS RTU El primer paso para configurar el MODBUS RTU, en modo esclavo, es incluir la instancia en la COM que se desea (en este caso, COM 1). Hacer clic con el botón derecho sobre la COM y seleccionar “Añadir Dispositivo...”, según muestra la Figura 5-4: 209 5. Programación Inicial Figura 5-4. Añadir la Instancia Enseguida, surgirá en la pantalla, los protocolos disponibles al usuario. En ese caso, seleccionar el “MODBUS RTU Slave” para configuración por Mapeo Simbólico o “MODBUS RTU Slave”, para configuración por Representación Directa (%Q). Enseguida, hacer clic en Añadir, según muestra la Figura 5-5: 210 5. Programación Inicial Figura 5-5. Seleccionar el Protocolo MODBUS Ethernet El primer paso para configurar el MODBUS ETHERNET, en modo cliente, es incluir la instancia en la NET que se desea (en este caso NET 1, pues la UCP NX3010 posee una interfaz Ethernet). Hacer clic con el botón derecho sobre la NET y seleccionar “Añadir Dispositivo...”, según muestra la Figura 5-6: 211 5. Programación Inicial Figura 5-6. Añadir la Instancia Ahora, surgirán en la pantalla, los protocolos disponibles al usuario. Definir el modo de configuración del protocolo, seleccionar el “MODBUS Symbol Client” para configuración por Mapeo Simbólico, o “MODBUS Client”, para configuración por Representación Directa (%Q). Enseguida, hacer clic en Añadir, según muestra la Figura 5-7: 212 5. Programación Inicial Figura 5-7. Seleccionar el Protocolo Ubicar la Red Como existe la posibilidad de que más UCPs estén conectadas a la red, el usuario debe ubicar todas las unidades de comunicación y seleccionar la que desea. Por primero, será necesario acceder a la opción Device, en el árbol de dispositivos, al hacer clic dos veces. En la pestaña “Configuraciones de Comunicación”, seleccionar el Gateway, o, en caso de que ningún Gateway exista o el usuario quiera añadir un nuevo Gateway, hacer clic en el botón “Añadir Gateway”, y configurar su IP en la ventana que se abrirá. Para mapear los dispositivos presentes en la red, se debe entonces hacer clic en el botón “Mapear Rede”. De esta forma, se debe aguardar mientras el software MasterTool IEC XE busca y presenta las UCPs disponibles en la red. 213 5. Programación Inicial Figura 5-8. Ubicar la UCP Enseguida, basta con seleccionar la UCP que se desea y hacer clic en la opción “Definir Camiño Activo”, haciendo con que se vuelva activa y el configurador sepa con quien debe comunicar y enviar el proyecto. Figura 5-9. Activar la UCP 214 5. Programación Inicial En caso de que sea necesario, el usuario puede alterar el nombre estándar del dispositivo que se exhibe. Para eso, debe hacer clic con el botón derecho del mouse sobre el dispositivo que se desee y seleccionar la opción “Change Node Name”. Tras un cambio de nombre, el dispositivo no volverá al nombre estándar en ninguna circunstancia. Login Tras compilar la aplicación y corregir todos los errores encontrados, es el momento de enviar el proyecto la UCP. Para que eso sea posible, basta con efectuar la operación de Login en el software MasterTool IEC XE. Esa operación puede llevar algunos segundos, lo que dependerá del tamaño del archivo generado. Para ejecutar el Login, basta con acceder al menú Comunicación y hacer clic en la opción “Login”, según muestra el ejemplo de la Figura 5-10. Figura 5-10. Enviar el Proyecto a la UCP Tras la ejecución del comando, podrán surgir algunos mensajes de interfaz con el usuario, los cuales se presentan debido a la diferencia entre un proyecto antiguo y el que se está enviando o, simplemente, alteración en el valor de alguna variable. La Figura 5-11 muestra el mensaje que el MasterTool IEC XE irá a presentar en caso de que el nuevo proyecto, que se está enviando, sea diferente al proyecto ya existente dentro de la UCP. Las opciones disponibles son las siguientes: Login with online change: ejecutar el login y enviar el nuevo proyecto sin que la aplicación actual de la UCP se detenga (ver ítem Modo Run), actualiza las alteraciones cuando un nuevo ciclo se ejecuta. Login with Download: ejecutar el login y enviar el nuevo proyecto con la UCP parada (ver ítem Modo Stop). Cuando la aplicación se inicia, las actualizaciones ya se habrán realizado. Login without any change: ejecuta el login sin enviar el nuevo proyecto. ATENCIÓN: Antes de la versión 2.01 del MasterTool IEC XE, cuando el Login con alteración online se ejecutaba, la aplicación no quedaba guardada en la memoria de programa. Era necesario ejecutar el comando “Crear Aplicación de Inicialización” en el menú Comunicación, sin efectuar el logout, para que la aplicación fuera grabada en la memoria de programa. A partir de la versión 2.01, esta operación pasó a ejecutarse de forma automática sin la necesidad de ejecutar el comando. 215 5. Programación Inicial Figura 5-11. Actualización del Proyecto en la UCP ATENCIÓN: En los cambios online no se permite asociar mapeos de variables simbólicas de una lista de variables globales (GVL) y utilizar esas variables en otra lista de variables globales (GVL). La Figura 5-12 muestra el mensaje que el MasterTool IEC XE exhibe cuando solamente se realizaron alteraciones en variables de la aplicación, hace con que no sea posible enviar el nuevo proyecto y que se actualice en un nuevo ciclo de la UCP, la cual está en ejecución (ver ítem Modo Run). De esta forma, el MasterTool IEC XE solicita al usuario si el login se debe ejecutar como download y la UCP detenida (ver ítem Modo Stop) o si la operación se debe cancelar. Obs.: El botón “Detalles...” presenta las modificaciones realizadas en la aplicación. Figura 5-12. Alteración de Variables En caso de que sea el primer envío de aplicación para la UCP, el mensaje de la Figura 5-13 surgirá en la pantalla del MasterTool IEC XE. Figura 5-13. Primer Envío de Aplicación Modo Run Enseguida de enviar el proyecto a la UCP, la aplicación no se ejecutará inmediatamente (solamente si se realiza un envío), antes que se seleccione un nuevo comando, el “Iniciar”. Esa función posibilita al 216 5. Programación Inicial usuario controlar la ejecución de la aplicación enviada a la UCP. Además, permite que valores iniciales se pre configuren, para que, en el primer ciclo ya se actualicen en la UCP. Para seleccionar dicha funcionalidad, basta con acceder al menú Depurar y hacer clic en “Iniciar”, según muestra la Figura 5-14. Figura 5-14. Iniciar la Aplicación A continuación, la Figura 5-15 muestra la aplicación en ejecución. En caso de que se seleccione la pestaña de una POU, las variables creadas se listarán en una ventana de monitoreo, en la cual valores se pueden forzar y ver por el usuario. En caso de que las variables se fuercen a través del comando F7 del teclado, la UCP indicará esta condición en el visor gráfico. Más detalles, consultar ítem Mantenimiento - 217 5. Programación Inicial Visor Gráfico. Figura 5-15. Programa en Ejecución En caso de que la UCP se inicie como una aplicación ya grabada internamente, automáticamente entrará en Modo Run, sin la necesidad de realizar el comando por MasterTool IEC XE. Modo Stop Para interrumpir la ejecución de la UCP, sin que el software MasterTool IEC XE pierda su conexión, el usuario debe seleccionar la opción Parar, disponible en el menú Depurar, “Stop”, según muestra la Figura 5-16. Figura 5-16. Parar la Aplicación 218 5. Programación Inicial En caso de que la UCP se inicie sin aplicación grabada, automáticamente entrará en Modo Stop, así como cuando ocurre una excepción de software. Escritura y Forzamiento de Variables Después de realizar un Login en una UCP, el usuario puede escribir o forzar valores a las variables del proyecto. El comando de escritura (Ctrl + F7), escribe un valor en una variable y este valor puede ser sobrescrito por instrucciones ejecutadas en la aplicación. Ya un comando de escritura forzada (F7) va a escribir un valor en la variable, sin permitir que este valor sea modificado hasta que sean liberadas las variables forzadas. Es importante resaltar que, al utilizar los protocolos MODBUS RTU Esclavo y MODBUS Ethernet Servidor y la opción “Read-only” de las relaciones configuradas no está seleccionada, el comando de escritura forzada (F7) se debe realizar sobre las variables disponibles en la ventana de monitoreo, pues el comando de escritura (Ctrl + F7) deja que las variables sean sobrescritas cuando se realicen nuevas lecturas. ATENCIÓN: El forzamiento de variables se puede realizar solamente en modo Online en la UCP. Variables de diagnósticos no se pueden forzar, sólo escrituras, pues diagnósticos se proveen por la UCP y se deben poder sobrescribir por estas. Cuando una escritura forzada es realizada en una variable redundante del CP Activo, la MainTask de la aplicación será afectada en su tiempo de ejecución, tanto en el CP Activo cuanto en el CP Reserva. Esto porque los dos half-cluster cambian informaciones sobre las variables forzadas en cada ciclo. Por lo tanto, cuando vaya a forzar variables en un sistema redundante, se debe considerar el incremento que puede tener la ejecución de la tarea. La Tabla 5-11 muestra el incremento de tiempo en la MainTask cuando variables son forzadas: CP Activo Tiempo de Ejecución CP Reserva 50 ms 100 ms 200 ms 50 ms 100 ms 200 ms Aumento con 10 forzamientos 2,4 % 2,2 % 1,7 % Aumento con 50 forzamientos 12,0 % 9,2 % 6,0 % 4,0 % 3,4 % 2,0 % 18,0 % 12,0 % Aumento con 128 forzamientos 26,0 % 21,0 % 16,0 % 56,0 % 8,0 % 34,0 % 22,5 % Tabla 5-11. La Influencia del Forzamiento de Variables en un CP Redundante ATENCIÓN: Cuando una UCP está con variables forzadas y se desenergiza, en la próxima inicialización las variables perderán el forzamiento. El límite de forzamientos para las UCPs Nexto es de 128 variables, independiente del modelo de UCP o configuración que se utilicen. Logout En caso de que la opción del usuario termine la comunicación con la UCP, se debe utilizar el comando “Logout”, ubicado en el menú Comunicación, “Logout”, según muestra la Figura 5-17. 219 5. Programación Inicial Figura 5-17. Interrumpir la Comunicación con la UCP Upload del Proyecto Las UCPs de la Serie Nexto posibilitan la grabación de un proyecto en la memoria del producto, el cual se puede recuperar y reutilizar a través del software MasterTool IEC XE. Para almacenar un proyecto en la memoria del producto, se debe conectar la UCP (Login) y se debe seleccionar la opción de envío de proyecto, juntamente con el aplicativo. Para recuperar el proyecto previamente almacenado, se deben seleccionar las opciones, según muestra la Figura 5-18. 220 5. Programación Inicial Figura 5-18. Opción de Upload de Proyecto Enseguida, basta con seleccionar la UCP que se desea y hacer clic en OK, según la Figura 5-19. Para garantizar que el proyecto cargado de la UCP sea completamente igual y se pueda cargar sin problemas a partir de otras estaciones, consulte el capítulo Método de Envío/Login de Proyectos Sin Diferencia de Proyectos del Manual del Usuario MasterTool IEC XE - MU299800. Figura 5-19. Seleccionar la UCP ATENCIÓN: El tamaño del área de memoria para almacenar un proyecto en las UCPs Nexto está definido en la Tabla 2-5. . 221 5. Programación Inicial ATENCIÓN: El Upload recupera el último proyecto almacenado en el controlador según lo descrito en los párrafos anteriores. En caso de que cargue sólo para la ejecución de un determinado aplicativo, no se podrá recuperarlo por el procedimiento de Upload. Estados de Operación de la UCP Run Cuando una UCP está en modo Run indica que todas las tareas de la aplicación están en ejecución. Stop Cuando una UCP está en modo Stop, indica que las tareas de la aplicación están paradas. El valor de las variables en las tareas se mantiene con el valor actual y variables de salida asumen valores definidos por el usuario. Cuando una UCP pasa al modo Stop a partir del envío de una aplicación, las variables en las tareas de la aplicación se perderán con excepción de las variables del tipo persistente. Las variables de salida asumirán el valor definido por el usuario y enseguida el valor de las salidas pasará al estado seguro. En cuanto la nueva aplicación se cargue las variables de salida asumirán nuevamente el valor definido por el usuario. Breakpoint Cuando una marca de depuración se alcanza en una tarea, dicha tarea se interrumpe. Todas las demás tareas activas en la aplicación no se interrumpirán, seguirán su ejecución. En este modo es posible recorrer un programa en el modo Online. Un paso a paso se puede ejecutar y las posiciones de las interrupciones de depuración dependen del editor. Para más informaciones sobre la utilización de marcas de depuración, consulte el Manual del Usuario MasterTool IEC XE – MU299800. Exception Cuando una UCP está en Exception indica que alguna operación indebida ha ocurrido en una de las tareas activas de la aplicación. La tarea que causó el Exception se suspenderá y las demás tareas irán hacia el modo Stop. Solamente es posible retirar las tareas de dicho estado y ponerlas en ejecución nuevamente después de una nueva condición de partida de la UCP. Por lo tanto solamente con un Reset a caliente, Reset a Frío, Reset Origen o una reinicialización de la UCP se coloca nuevamente la aplicación en modo Run. Reset a Caliente Este comando coloca la UCP en modo Stop e inicializa todas las variables de las tareas de la aplicación, con excepción de las variables de los tipos retentiva y persistente. Las variables inicializadas con un valor específico asumirán exactamente este valor, las demás variables asumirán el valor estándar de inicialización (cero). Reset a Frío Este comando coloca la UCP en modo Stop e inicializa todas las variables de las tareas de la aplicación, con excepción de las variables del tipo persistente. Las variables inicializadas con un valor específico asumirán exactamente este valor, las demás variables asumirán el valor estándar de inicialización (cero). Reset Origen Este comando remueve todas las variables de las tareas de la aplicación, incluso las variables del tipo persistente y apaga la aplicación de la UCP. 222 5. Programación Inicial Notas: Reset: Cuando un Reset se ejecuta los breakpoints definidos en la aplicación se deshabilitan. Comando: Para ejecutar un comando de cualquier tipo de Reset es necesario estar en modo Online en la UCP. 223 6. Redundancia con UCP NX3030 6. Redundancia con UCP NX3030 Introducción Este capítulo abarca la redundancia de CPs de la Serie Nexto, que se puede utilizar solamente con la UCP NX3030. Se trata de una redundancia del tipo hot-standby, en la cual los controladores se duplican. Uno de los controladores normalmente está en estado Activo y controla el proceso, mientras el otro controlador normalmente está en estado Reserva, manteniéndose sincronizado con el controlador Activo. En caso de que de que ocurra una falla en el controlador Activo, que lo impida seguir controlando el proceso, el controlador Reserva conmuta automáticamente para Activo, en un tiempo suficientemente bajo para que no se perturbe el proceso, sin causar discontinuidades en las salidas que controlan el proceso. La redundancia hot-standby es un método utilizado para aumentar la tolerancia a fallas y, consecuentemente, aumentar la disponibilidad del sistema de automación. La idea básica es que ninguna falla simple en componentes duplicados cause la interrupción del control del proceso. La redundancia hot-standby se aplica mucho en: Plataformas de exploración de petróleo Sistemas de generación y distribución de energía Intertrabamientos de seguridad (Sistemas Instrumentados de Seguridad) Procesos continuos, tales como plantas químicas, refinerías de petróleo, producción de celulosa, etc. Además de los controladores, se pueden también duplicar, opcionalmente, las redes de campo (PROFIBUS DP), las redes de supervisión Ethernet, y las redes de control Ethernet HSDN (High Speed Deterministic Network). Al hacer la opción por la duplicación de estas redes, se obtiene más disponibilidad aun. La redundancia hot-standby de CPs de la Serie Nexto no prevé duplicación de módulos de E/S. En caso de que de que la redundancia de módulos de E/S sea deseable, se puede tratar en nivel de aplicación, por el usuario final. Por ejemplo, el usuario puede duplicar o hasta mismo triplicar un módulo de entradas analógicas, y crear un algoritmo de votación para determinar cuál de las entradas se considerará en determinado momento en su aplicación. La Figura 6-1 muestra un ejemplo típico de arquitectura redundante con la UCP NX3030. La parte central de un CP redundante está formada por dos bastidores idénticos, denominados CPA y CPB, además de un panel de control de redundancia (PX2612). En el contexto de la redundancia, cada bastidor (CPA y CPB) se denomina half-cluster y el conjunto formado por estos dos bastidores se llama cluster. En este ejemplo, se observan también duplicaciones en una red de campo PROFIBUS, en la red Ethernet de supervisión, y en la red de control Ethernet HSDN. 224 6. Redundancia con UCP NX3030 SCADAs MasterTo ol Ethernet A Ethernet B Canal de sincronismo NETA Otros CPs (redundantes o no) Canal de sincronismo NETB PX2612 N X 8 0 0 0 N X 3 0 3 0 N X 4 0 1 0 N X 5 0 0 1 N X 5 0 0 1 N X 5 0 0 0 N X 5 0 0 0 N X 5 0 0 0 CPA (half-cluster) N X 8 0 0 0 cluster de CPs PROFIBUS 1 A N X 3 0 3 0 N X 4 0 1 0 N X 5 0 0 1 N X 5 0 0 1 N X 5 0 0 0 N X 5 0 0 0 N X 5 0 0 0 CPB (half-cluster) PROFIBUS 1 B Ethernet no redundante Ethernet HSDN A Ethernet HSDN B Otros CPs en la HSDN (normalmente redundantes) PO5065 PO5065 módulos de E/S Serie Ponto E/S remoto Serie Ponto con red PROFIBUS redundante PO5063V5 AL-2433 PO5063V5 módulos de E/S Serie Ponto red PROFIBUS no redundante vía AL-2433 Esclavos PROFIBUS No Redundantes Figura 6-1. Ejemplo de Arquitectura Redundante con UCP NX3030 225 6. Redundancia con UCP NX3030 Descripción Técnica y Configuración Configuración Mínima de un CP Redundante (Sin utilizar el Panel de PX2612) Un CP redundante está compuesto, mínimamente, por: dos half-clusters idénticos Cada half-cluster está constituido, mínimamente, por los siguientes módulos: el propio bastidor en el cual los módulos se insertan, puede ser uno de los siguientes: o NX9001, con 12 posiciones o NX9002, con 16 posiciones o NX9003, con 24 posiciones la fuente de alimentación NX8000, en las posiciones 0 y 1 del bastidor la UCP NX3030, en las posiciones 2 y 3 del bastidor el módulo NX4010, en las posiciones 4 y 5 del bastidor La Figura 6-2 muestra un ejemplo de configuración mínima de un CP redundante, utilizando el menor bastidor (NX9001, con 12 posiciones). En este caso, se observa que los 3 módulos insertados en el bastidor tienen doble ancho (ocupan dos posiciones del bastidor). Canal de sincronismo NETA (AL-2319) Canal de sincronismo NETB (AL-2319) 0 1 N X 8 0 0 0 2 3 4 5 N X 3 0 3 0 N X 4 0 1 0 6 7 8 9 10 11 0 1 cluster N X 8 0 0 0 2 3 4 5 N X 3 0 3 0 N X 4 0 1 0 6 7 8 9 10 11 bastidor NX9001 bastidor NX9001 half-cluster CPA half-cluster CPB Figura 6-2. Configuración Mínima de CP Redundante en Bastidor NX9001 Configuraciones Típicas de un CP Redundante Una configuración mínima, como esta que se muestra en la Figura 6-2, ya se puede útil como una “unidad de procesamiento redundante”. Sería posible utilizar los canales de comunicación seriales y Ethernet de la UCP NX3030, por ejemplo, para comunicación MODBUS TCP con un sistema SCADA, y comunicación MODBUS RTU y/o MODBUS TCP con dispositivos de campo inteligentes o sistemas de E/S remoto MODBUS. En configuraciones más típicas, sin embargo, se insertan módulos adicionales en los half-clusters CPA y CPB, por ejemplo, para proveer un sistema de E/S remoto PROFIBUS y canales Ethernet adicionales. Entre los módulos adicionales que, opcionalmente, se pueden insertar en los half-clusters, existen: Maestros PROFIBUS NX5001 Interfaces Ethernet NX5000 226 6. Redundancia con UCP NX3030 En caso de que de que sea necesario, se pueden utilizar bastidores mayores, como NX9002 (16 posiciones) y NX9003 (24 posiciones). Se debe observar que todos los módulos nombrados hasta el momento en este capítulo tienen doble ancho (ocupan dos posiciones). Además, también se puede utilizar el panel PX2612, que permite ejecutar algunas transiciones en la máquina de estados redundante que, en caso contrario, no serían posibles, más allá de la desconexión automática de half-clusters en algunas situaciones de falla. Adición de Módulos NX5001 para Redes PROFIBUS Es posible insertar hasta cuatro módulos NX5001 para la utilización de redes PROFIBUS en un CP redundante. Cada una de estas redes puede ser simple o redundante. En el caso de que la red PROFIBUS “n” (siendo “n” un número de 1 a 4) sea redundante, las dos redes que la componen se llamarán PROFIBUS “n” A y PROFIBUS “n” B. En el caso de que la red PROFIBUS “n” sea simple, la red que la compone se llamará PROFIBUS “n” A. Para crear una red PROFIBUS redundante, es necesario insertar dos módulos NX5001 en cada halfcluster. Para crear una red PROFIBUS simple, basta insertar un módulo NX5001 en cada halfcluster. De esta forma, es posible configurar hasta cuatro redes simples, o dos redes redundantes, o una redundante y dos simples. En los demás casos, menos que cuatro módulos NX5001 serán necesarios en cada half-cluster. Más informaciones en redes PROFIBUS se encuentran en la sección Principios de Funcionamiento - Configuraciones de Redes PROFIBUS. En el ejemplo de la Figura 6-1, existe sólo una red PROFIBUS (PROFIBUS 1), y esta es redundante (PROFIBUS 1 A y PROFIBUS 1 B). En este ejemplo, por lo tanto, se insertaron dos módulos NX5001 en cada half-cluster. Adición de Módulos NX5000 para Redes Ethernet Es posible insertar hasta seis módulos NX5000 en cada half-cluster, proveyendo seis canales Ethernet adicionales, además de los dos canales Ethernet que ya existen en la UCP NX3030. Los canales Ethernet se pueden usar de forma individual, u organizados en pares NIC Teaming. Pares NIC Teaming se utilizan para proveer canales Ethernet redundantes y se describirá con más detalles en la sección Principios de Funcionamiento - Redes Ethernet Redundantes con NIC Teaming. Una aplicación típica para el módulo NX5000 se puede construir una HSDN (High Speed Deterministic Network), para comunicación entre distintos CPs redundantes. A través de esta red, distintos CPs redundantes pueden intercambiar mensajes en una red totalmente segregada, para garantizar determinismo y una comunicación rápida. Además, al configurar esta red como redundante con pares NIC Teaming, se puede obtener excelente disponibilidad. Para construir una HSDN redundante, se debe insertar dos módulos NX5000 en cada half-cluster. La Figura 6-1 muestra un ejemplo de HSDN redundante, que utiliza dos módulos NX5000 en cada half-cluster. Aplicaciones en las cuales los módulos de entradas y salidas estén conectados a redes Ethernet pueden necesitar interfaces extras de módulos NX5000 para conectarse a estas redes. En estos casos, la red que conecta los módulos de entradas y salidas puede ser una red simple o redundante. Además, las interfaces se pueden configurar con la opción de generar falla vital. En este caso, una falla en la red provocará un switchover. La Figura 6-1 también muestra un ejemplo con un módulo NX5000 usado de forma aislada (sin redundancia NIC Teaming), insertado a la derecha de los demás módulos en cada bastidor. Módulo NX4010 El módulo NX4010, como muestra la Figura 6-3, fue creado para proveer la interconexión entre los dos half-clusters CPA y CPB, y también para conectar estos half-clusters al panel de control de redundancia PX2612. Más detalles sobre las conexiones de estos módulos se mostrarán en la sección Interconexiones entre Half-Clusters y Panel de Control de Redundancia PX2612. 227 6. Redundancia con UCP NX3030 Figura 6-3. Módulo NX4010 Características NX4010 Sus principales características son: Sincronismo de datos y aplicación entre dos half-clusters Interfaz de comunicación redundante entre dos half-clusters Switchover automático (cambio del half-cluster activo) en caso de que suceda time-out de comunicación entre NX4010 y su respectiva UCP Posibilidad de desconectar el otro half-cluster One Touch Diag Electronic Tag on Display Visor y LEDs para indicación de diagnósticos Demás características (generales, eléctricas, mecánicas y de ambiente) se encuentran en las Características Técnicas del Módulo de Redundancia NX4010 – CS114900. Panel de Control de Redundancia PX2612 El panel de control PX2612 es un elemento opcional en un sistema redundante. El panel se debe utilizar al seleccionar la opción de redundancia con painel en la creación del proyecto al usar el wizard. La Figura 6-4 muestra una fotografía del panel de control de redundancia PX2612, mientras la Figura 6-5 muestra con más detalles su panel frontal. A través del conector DB9 denominado CONTROL PLC A, se hace la conexión al conector CONTROL del NX4010 del PLCA, se utiliza el cable AL-2317/A. A través del conector DB9 denominado CONTROL PLC B, se hace la conexión al conector CONTROL del NX4010 del PLCB, se utiliza el cable AL-2317/B. Además, hay un conector con cinco bornes machos: GND: borne para conexión de aterramiento. 228 6. Redundancia con UCP NX3030 RL A: 2 bornes que corresponden a los terminales de un relé NA (normalmente abierto), que se puede comandar por el CPB para desconectar el CPA. Este relé se debe cerrar por el CPB para desconectar el CPA. RL B: 2 bornes que corresponden a los terminales de un relé NA (normalmente abierto), que se puede comandar por el CPA desconectar el. Este relé se debe cerrar por el CPA para desconectar el CPB. Un CP (CPA o CPB) podrá desconectar el otro CP (CPB o CPA) en algunas situaciones excepcionales, se utilizará, entonces, los relés NA en los conectores RL A y RL B. Dichas situaciones se describen en la sección Transiciones entre Estados de Redundancia. El PX2612 también dispone de seis botones para comandos de redundancia, y seis LEDs utilizados para indicaciones de estado de redundancia. Cada CP lee tres de estos botones y controla tres de estos LEDs. Más informaciones sobre las funciones de estos botones y LEDs más adelante en la sección Funciones del Panel de Comando de Redundancia PX2612. Figura 6-4. Panel de Control de Redundancia PX2612 Figura 6-5. Delantera del Panel de Control de Redundancia PX2612 Características PX2612 El panel de control de redundancia PX2612 posee características a continuación: CONTROL PLC A: conexión al módulo NX4010 del CPA CONTROL PLC B: conexión al módulo NX4010 del CPB RL A: terminales de un relé NA utilizado para desconectar el CPA RL B: terminales de un relé NA utilizado para desconectar el CPB 229 6. Redundancia con UCP NX3030 GND: aterramiento Demás características (generales, eléctricas, mecánicas y de ambiente) se encuentran en las Características Técnicas del Panel de Control de Redundancia PX2612 – CT112500. Interconexiones entre Half-Clusters y Panel de Control de Redundancia PX2612 La Figura 6-6 muestra cómo se deben hacer las conexiones entre CPA, CPB y PX2612, inclusive para posibilitar que un CP desconecte al otro, lo que es necesario en situaciones excepcionales. Dos cables AL-2319 se deben utilizar para los canales de sincronismo de redundancia NETA y NETB. Uno de estos cables interconecta los conectores NET 1 de los NX4010 de cada CP (canal NETA). El otro cable interconecta los conectores NET 2 de los NX4010 de cada CP (canal NETB). Un cable AL-2317/A interconecta el conector CONTROL del NX4010 del CPA al conector CONTROL PLC A del PX2612. Un cable AL-2317/B interconecta el conector CONTROL del NX4010 del CPB al conector CONTROL PLC B del PX2612. Además, es necesario hacer un circuito especial de alimentación, para que un CP sea capaz de desconectar al otro CP en casos extremos. Para más confiabilidad, se debe utilizar dos fuentes separadas de 24V, una para energizar el CPA, otra para energizar el CPB. Se percibe que es necesario utilizar dos relés externos del tipo normalmente cerrado (NF), con capacidad de corriente suficiente para energizar el NX8000. Estos relés se deben dimensionar para una corriente nominal de 2 A. Diodos en paralelo con las bobinas de los relés NF se deben utilizar para proteger los contactos de los relés NA del PX2612. 230 6. Redundancia con UCP NX3030 AL-2319 (NETA) AL-2319 (NETB) half-cluster CPB half-cluster CPA NET 1 NET 2 NET 1 NET 2 NX8000 24V NX3030 NX4010 0V ... NX8000 24V CONTROL AL-2317/A NX3030 ... NX4010 0V CONTROL AL-2317/B CONTROL PLC A CONTROL PLC B PX2612 RLA 24V GND 0V RLB 24V Fuente CPA 0V Fuente CPB Figura 6-6. Interconexiones entre CPA, CPB y PX2612 Características Generales Características Generales de un CP Redundante UCPs Permitidas NX3030 Tipo de Redundancia Hot-standby Tolerancia a Fallas Tolera, en lo mínimo, falla simple en equipos duplicados en los half-clusters. En casos específicos, puede tolerar múltiples fallas. 5 estados de redundancia de un half-cluster - No-Configurado: estado inicial, también considerado cuando CP está desconectado o no está ejecutando la tarea principal (MainTask). - Inicializando: estado temporario que ocurre después de NoConfigurado, en el cual algunos testes determinarán el próximo estado (Inactivo, Activo, Reserva – o de vuelta a NoConfigurado). - Inactivo: estado alcanzado después de determinados tipos de fallas o para mantenimiento programado. - Activo (Active): controla el proceso del usuario. - Reserva (Stand-by): apto para conmutar a Activo y controlar el proceso del usuario, en caso de que haya una demanda (ex: falla del CP Activo). Principales Fallas que Causan Switchover Entre CP Activo Y CP Reserva. CP Reserva Conmuta a Activo y El Activo Puede Ir A Inactivo o No Configurado. - Falta de alimentación. - Fuente. - UCP (parada de ejecución de la tarea principal - MainTask). - NX4010. - Falla de ambos los canales de sincronismo (NETA y NETB) sin que la causa sea interna al CP Reserva. En este caso, el CP Reserva, además de volverse Activo, desconecta el otro CP. - Falla de ambos canales de sincronismo (NETA y NETB) siendo 231 6. Redundancia con UCP NX3030 la causa interna al CP Activo. - Falla en alguna red PROFIBUS configurada como vital. Comandos que Causan Switchover Entre CP Activo y CP Reserva - Comandos por panel de control de redundancia (PX2612). - Comandos recibidos del MasterTool o de un sistema SCADA, a través de este CP (local) o del otro CP (remoto). - Comandos generados por la aplicación del usuario, por ejemplo, en función de otros diagnósticos (ej.: falla de comunicación Ethernet), a través de este CP (local) o del otro CP (remoto). Principales Fallas que Impiden a un CP De Permanecer en el Estado Reserva, O Asumir El Estado Reserva. Dichas Fallas Hacen Con Que Este CP Asuma los Estados No-Configurado O Inactivo. - Falta de alimentación. - Fuente. - UCP (parada de ejecución de la tarea principal - MainTask). - NX4010. - Falla de ambos los canales de sincronismo (NETA y NETB) en los cuales la causa es interna al CP Reserva. - Falla en el servicio de sincronismo de datos redundantes. - Falla en el servicio de sincronismo de la lista de forzamientos redundantes. - Falla total en alguna red PROFIBUS configurada como vital. - Proyecto diferente de aquel del CP Activo, con sincronización automática de proyectos habilitada. - Versión de firmware incompatible con CP Activo. Comandos que Retiran el CP del Estado Reserva - Comandos por panel de control de redundancia (PX2612). - Comandos recibidos del MasterTool o de un sistema SCADA, a través de este CP (local) o del otro CP (remoto). - Comandos generados por la aplicación del usuario, por ejemplo, en función de otros diagnósticos (ej.: falla de comunicación Ethernet), a través de este CP (local) o del otro CP (remoto). Tiempo de Switchover - Típicamente de uno a tres ciclos de la MainTask, depende del estímulo para cambio de estado (comando o falla). - En caso de que haya falla en la red PROFIBUS simple, dos ciclos de la MainTask + 500 ms. Switchover Sin Discontinuidades (Bump-Less) - Un switchover no provoca discontinuidades en las salidas del controlador, ni en variables internas. Overhead de La Redundancia (Consumo de UCP a Cada Ciclo De La Maintask Añadido Por La Redundancia) - Valor máximo calculado automáticamente por el MasterTool e informado al usuario, al considerar una lista de forzamientos redundantes vacía. - Valor mediano típico de 60 ms para 224 Kbytes de datos redundantes, en un sistema con una red PROFIBUS redundante y dos redes ETHERNET HSDN redundantes. Visor De La UCP Entre otros diagnósticos, muestra el estado de la redundancia (Activo, Reserva, Inactivo, No-Configurado, inicializando). Para la identificación del CP, es necesario verificar en el menú Redundancia, en el cual está la identificación del CPA o CPB. Panel De Control De Redundancia PX2612 - A través de botones, permite comandos de switchover o transiciones entre estados de redundancia para mantenimiento. - LEDs señalan el estado de la redundancia en cada half-cluster - Relé NA permite que un half-cluster desconecte el otro en casos extremos. Botón permite el reconexión del otro half-cluster - Recursos embutidos para test de los botones, LEDs y relés. Diagnósticos De La Redundancia - Indican fallas tanto en el CPA como en el CPB, independiente de sus estados (Activo o No-Activo). - Evitan “fallas ocultas. - Permiten mantenimiento rápido, lo que es esencial para obtener alta disponibilidad. Comandos De La Redundancia - Permiten ejecutar las mismas acciones del panel de control PX2612, además de otros comandos más (ej.: comandar switchovers). - Se pueden ejecutar en el CP local, o repasados hacia el otro CP (remoto) por canales de sincronismo NETA / NETB. - Se pueden recibir a partir del MasterTool o de un sistema SCADA. - Se pueden ejecutar a partir de la aplicación del usuario. Eventos De La Redundancia Registran modificaciones en los diagnósticos y comandos de redundancia, con marcación de tiempo, lo que permite una investigación de las causas de un switchover. SNTP (Simple Network Time Permite que los eventos tengan marcación de tiempo precisa y 232 6. Redundancia con UCP NX3030 Protocol) ajustada a la hora mundial. También sincroniza el reloj de tiempo real del CP para otras aplicaciones. Sincronización De Comandos Y Diagnósticos A cada ciclo de la MainTask, CPA y CPB intercambian diagnósticos y comandos A través de los canales de sincronismo NETA o NETB. De esta forma, un CP conoce los diagnósticos y comandos del otro. Sincronización De Datos Redundantes A cada ciclo de la MainTask, el CP Activo copia datos redundantes para el CP No-Activo a través de los canales de sincronismo NETA y NETB. Los datos no redundantes no se sincronizan. Sincronización de la lista de forzamientos redundantes Esta lista incluye sólo las variables redundantes forzadas. De esta manera, CPA y CPB pueden tener diferentes conjuntos de datos no redundante forzados, pues estos forzamientos no están sincronizados. Proyecto único para CPA y CPB Hay un único proyecto común para CPA y CPB, generado por MasterTool. El proyecto está compuesto por proyecto aplicativo (código ejecutable) y por el archivo de proyecto (código fuente). Identificación de un CP Por el MasterTool, se identifica una UCP NX3030 como CPA, CPB o CP no redundante. Este ID no es parte de la aplicación del proyecto generado por MasterTool, aunque esté escrito en un PC usando MasterTool. La identificación de cada CP habilita la característica a tener un diseño único para CPA y CPB. Sincronización automática del proyecto Si el proyecto del CP activo se vuelve diferente del proyecto del CP no- activo, este se copia del CP activo al CP inactivo. Esta sincronización puede llevar varios ciclos de MainTask. Cabe recordar que el proyecto está compuesto por el proyecto aplicativo (código ejecutable) y por el código fuente (archivo de proyecto), ambos sincronizados. Esta sincronización se puede desactivar en circunstancias especiales, para hacer factibles modificaciones en el proyecto que sólo se podrían cargar off-line en CPs no redundantes. Expansión a caliente de módulos y remotas PROFIBUS Hay cambios en el proyecto que no se pueden hacer en caliente (en línea) en un CP no redundante, tales como la inclusión de nuevos módulos o remotas PROFIBUS. Sin embargo, aprovechando la redundancia del CP y de las redes PROFIBUS, un procedimiento se ha establecido para alcanzar este objetivo, muy importante para los sistemas que requieren alta disponibilidad. Direcciones IP Privadas Para CPA Y CPB Es posible conectarse a un CP específico utilizando una dirección IP privado para esto, para, por ejemplo, obtener diagnósticos específicos de este half-cluster. La Dirección de IP del CPA estará siempre asociada a la interfaz NET (i) del CPA, y la Dirección de IP del CPB estará siempre asociada a la interfaz NET (i) del CPB. Ip Activo Nombre de una estrategia que permite que clientes Ethernet se conecten a un servidor en el CP redundante y utilicen siempre la misma dirección de IP. Esto evita la necesidad de complexos scripts para cambiar la dirección IP cuando ocurren switchovers debido a la redundancia. La Dirección de IP Activo estará siempre asociada a la interfaz NET (i) del CP Activo. Nic Teaming Nombre de una estrategia que permite que dos interfaces Ethernet de un half-cluster formen un par redundante compartiendo una misma dirección IP. De esta forma, se pueden construir redes Ethernet redundantes con más facilidad, sin que los clientes conectados a un par NIC Teaming tengan de implementar complejos scripts para conmutar direcciones IP. Redes PROFIBUS Y Configuración De Fallas Vitales El CP soporta hasta dos redes PROFIBUS, cada una puede ser redundante o no-redundante. También es posible configurar si la falla de cada red PROFIBUS se considera vital (causa switchover) o no. Tarea De Usuario Única Y Cíclica Solamente una tarea de usuario se permite, siendo denominada MainTask. Esta tarea es cíclica. Pous Principales: Nonskippedprg Y Activeprg En la creación de un proyecto redundante, el MasterTool genera automáticamente dos program POUs vacías que se deben llenar por el usuario: - NonSkippedPrg: esta program POU se ejecuta en los dos CPs (CPA y CPB), independiente del estado de redundancia (Activo o No-Activo). Se destina al gerenciamiento de diagnósticos y comandos especiales. 233 6. Redundancia con UCP NX3030 - ActivePrg: esta program POU se ejecuta solamente en el CP Activo, y se destina al control del proceso del usuario final. Tabla 6-1. Características Generales de un CP Redundante Datos para Compra La configuración mínima de un CP redundante implica en la adquisición de los siguientes módulos: Dos bastidores, que se deben elegir entre tres modelos disponibles según los módulos que se deben instalar: o o o o NX9000: ocho posiciones (cuatro módulos dobles) NX9001: doce posiciones (seis módulos dobles) NX9002: dieciséis posiciones (ocho módulos dobles) NX9003: veinticuatro posiciones (doce módulos dobles) Dos NX8000 Dos NX3030 Dos NX4010 Dos AL-2319 Además, puede ser necesario adquirir los siguientes módulos opcionales: Un PX2612 Un AL-2317/A Un AL-2317/B Dos módulos NX5001 para cada red PROFIBUS simple adicional Cuatro módulos NX5001 para cada red PROFIBUS redundante adicional Dos módulos NX5000 para cada red Ethernet simple adicional Cuatro módulos NX5000 para cada red Ethernet redundante adicional (NIC Teaming) ATENCIÓN: Se puede instalar hasta cuatro módulos PROFIBUS en un CP redundante. Esto significa que podemos configurar hasta 4 redes PROFIBUS simple o hasta dos redes PROFIBUS redundantes. Principios de Funcionamiento En esta sección, se describen las funciones de un CP redundante con UCP NX3030, su comportamiento y estados. También se presentan conceptos y restricciones de programación y configuración que se utilizarán en los próximos capítulos. Identificación de un UCP NX3030 Una UCP NX3030 posee un registro de identificación, no volátil, en el cual es posible identificarla como: No Redundante: no se puede utilizar en un CP redundante (configuración estándar de fábrica). CPA: utilizada en el CPA de un CP redundante CPB: utilizada en el CPB de un CP redundante. El registro de identificación se puede ajustar con el programador MasterTool. Lo primero a hacer en una UCP NX3030, antes de cargar el proyecto del CP redundante en esta, es identificarla como CPA o CPB. En caso de que la identificación no se realice, muchas características de la redundancia no van a funcionar correctamente, como, por ejemplo, la sincronización de la aplicación entre los CPs. 234 6. Redundancia con UCP NX3030 ATENCIÓN: El registro de Identificación del CP no hace parte del proyecto del CP redundante, y por lo tanto no es salvado como parte de este proyecto en la computadora donde el MasterTool IEC XE se ejecuta. El registro se salva sólo en la memoria no volátil de la UCP. Proyecto Redundante Único Gracias al registro de identificación descrito anteriormente, existe un único proyecto para el CP redundante, idéntico para los CPA y CPB. Parámetros de configuración que deben ser diferentes entre CPA y CPC (ej.: direcciones IP de las interfaces Ethernet) aparecen duplicadas en el proyecto de CP redundante (uno para CPA, otro para el CPB). Cada CP tendrá en cuenta el que le corresponde, tras analizar su registro de identificación. Estructura del Proyecto Redundante Redundancy Template El proyecto de un CP redundante se crea automáticamente a partir de un modelo, denominado Redundancy Template. El template parte de la configuración mínima de un CP redundante, según lo definido en la sección Configuración Mínima de un CP Redundante (Sin utilizar el Panel de PX2612). Además, algunos diálogos con el usuario se realizan para inserción de módulos adicionales en los half-clusters, tales como maestros PROFIBUS (NX5001) y módulos Ethernet (NX5000). Remotas PROFIBUS se deben insertar por el usuario, abajo de los maestros PROFIBUS NX5001 ya insertados. Además, se crean tareas y POUs básicas del tipo programa, según lo descrito en las próximas secciones. Tarea Única y Cíclica MainTask El proyecto de un CP redundante tiene una sola tarea, llamada MainTask, que es cíclica. El usuario puede ajustar el rango de la tarea. Programa MainPrg La tarea MainTask está asociada a un única POU del tipo programa, denominada MainPrg. El programa MainPrg es criado automáticamente. El código del programa MainPrg es el siguiente, en lenguaje ST: fbRedundancyManagement(); NonSkippedPrg(); IF fbRedundancyManagement.m_fbDiagnosticsLocal.eRedState = REDUNDANCY_STATE.ACTIVE THEN ActivePrg(); END_IF MainPrg llama otras dos POUs del tipo programa, NonSkippedPrg y ActivePrg. NonSkippedPrg siempre se solicita, pues se ejecuta tanto en el CP Activo como en el No-Activo. Ya la POU ActivePrg sólo se solicita cuando la condición “RedDgnLoc.sGeneral.Diag.eRedState = Active” es verdadera, o sea, cuando el CP se encuentra en estado Activo. Por lo tanto, el programa NonSkippedPrg será siempre ejecutado en ambos CPs (CPA y CPB), independiente del estado de redundancia de este CP. Por otro lado, el programa ActivePrg será ejecutado solamente en el CP que se encuentra en estado Activo. Al contrario del programa MainPrg, que no se debe modificar, el usuario puede modificar los programas NonSkippedPrg y ActivePrg. Inicialmente, cuando el proyecto redundante se crea a partir 235 6. Redundancia con UCP NX3030 del Redundancy Template, estos dos programas se crean “vacíos”, pero el usuario podrá insertar código en los estos. Programa ActivePrg El principal objetivo de este programa, que se ejecuta solamente en el CP Activo, es controlar el proceso del usuario final. Este programa normalmente actúa sobre las variables redundantes, entre las cuales se encuentran las variables de representación directa %I y %Q asociadas al sistema de E/S remoto. Para más informaciones, consultar el capítulo Programación de un CP Redundante - Configuraciones de la MainTask - Programa ActivePrg. ATENCIÓN: Habiendo éxito o no en la compilación, el MasterTool informa si la holgura se respeta y el cálculo del overhead de redundancia en la ventana de mensajes. Programa NonSkippedPrg Este programa, que se ejecuta en ambos CPs (CPA y CPB) independiente del estado de redundancia, es típicamente utilizado para funciones como: Organizar diagnósticos no redundantes para reportar a un sistema SCADA. Recibir y ejecutar comandos no redundantes a partir de un sistema SCADA. Gerenciar condiciones de switchover normalmente no contempladas automáticamente por el CP redundante, que pueden variar de usuario a usuario. Por ejemplo, determinado usuario podrá ejecutar un switchover para el CP Reserva si el CP Activo no se está comunicando con el sistema SCADA, y otro usuario puede no desear un switchover en esta situación Habilitar o deshabilitar I/O drivers en función del estado de redundancia, por ejemplo, deshabilitar un maestro MODBUS RS-485 en el CP No-Activo Detectar fallas en I/O drivers en un CP No-Activo, para evitar fallas ocultas. Algunos I/O drivers no contemplan detección automática de dichas fallas. Otros I/O drivers, como el PROFIBUS, lo hacen automáticamente. Otras actividades que, por algún motivo, se necesitan ejecutar tanto en el CP Activo como en el CP Reserva. Para más informaciones, consultar el capítulo Programación de un CP Redundante - Configuraciones de la MainTask - Programa NonSkippedPrg. Variables Redundantes y No Redundantes Las variables de un CP redundante se pueden clasificar entre redundantes y no redundantes. Variables redundantes se copian del CP Activo para el CP No-Activo, en el inicio de cada ciclo de la MainTask, a través de los canales de sincronismo NETA y NETB. Por otro lado, variables no redundantes no son copiadas entre half-clusters y, por lo tanto, pueden tener valores diferentes en los CPs A y B. Las variables no redundantes se utilizan para almacenar informaciones privativas de cada half-cluster (CPA o CPB), tales como diagnósticos de un módulo dentro de este half-cluster, incluye los diagnósticos de la redundancia (estado de la redundancia de este half-cluster, etc.). Las variables redundantes dicen respecto a las informaciones compartidas y relativas al control del proceso. Las variables asociadas a los módulos de E/S son ejemplos típicos de variables redundantes. Variables %I Redundantes y No Redundantes La UCP NX3030 ubica 96 kbytes de variables %I (%IB0 ... %IB98303). Los primeros 80 kbytes pueden ser redundantes (%IB0 ... %IB81919). Los últimos 16 kbytes siempre son no redundantes (%IB81920 ... %IB98303). 236 6. Redundancia con UCP NX3030 El área de 80 kbytes que puede ser redundante típicamente se ubica para entradas, que pueden ser leídas a partir de un sistema de E/S remoto (PROFIBUS, MODBUS, etc.). El área de 16 kbytes no redundante se ubica para diagnósticos privados rápidos de un half-cluster y, también, para los botones del panel de comando de redundancia PX2612. Diagnósticos rápidos son los que, necesariamente, se deben actualizar a cada ciclo de la MainTask. El usuario puede configurar la cantidad de variables %I redundantes, entre 0 bytes y 81920 bytes, en múltiples de 1 byte (el valor default es 16384 bytes - %IB0 ... %IB16383). La configuración adecuada de la cantidad de %I redundantes a partir de %IB0 es importante para reducir el tiempo necesario para sincronizar variables redundantes (reducir el overhead de la redundancia). Por ejemplo, si la aplicación real ubica sólo %IB0 ... %IB1499 para entradas redundantes, se puede definir el tamaño del área redundante de %I en 1500 bytes. La figura siguiente ilustra la ubicación de variables de representación directa %I redundantes y no redundantes, en la cual RI es la cantidad de %I configurados como redundantes de hecho. %I redundantes de hecho 80 kbytes 16 kbytes reservado para expansión de %I redundantes RI kbytes RI = 0 ... 80 RI default = 16 80-RI kbytes %I no redundantes Figura 6-7. Ubicación de %I Redundantes y no Redundantes Variables %Q Redundantes y No Redundantes La UCP NX3030 ubica 96 kbytes de variables %Q (%QB0 ... %QB98303). Los primeros 80 kbytes pueden ser redundantes (%QB0 ... %QB81919). Los últimos 16 kbytes siempre son no redundantes (%QB81920 ... %QB98303). El área de 80 kbytes que puede ser redundante está dividida en dos secciones: Los primeros bytes se reservan para salidas que pueden ser redundantes, y típicamente ubicadas para un sistema de E/S remoto (PROFIBUS, MODBUS, etc.). El tamaño de esa sección es configurable, y su valor estándar es 16384. Lo que abarca %QB0 ... %QB16383, puede ser configurada para hasta 64 kbytes (%QB0 ... %QB65535). Los próximos bytes se reservan para diagnósticos que pueden ser redundantes, por ejemplo, del sistema de E/S (diagnósticos de módulos de E/S, de interfaces de comunicación esclavos PROFIBUS, etc.). Al contrario de los diagnósticos rápidos (ubicadas en %I), tales diagnósticos ubicados en %Q pueden llevar más que un ciclo de la MainTask para actualizarse. Por estándar, esta sección abarca 16 kbytes (%QB65536 ... %QB81919). El área no redundante (%QB81920 ... %QB98303) típicamente se ubica para diagnósticos y comandos privados de un half-cluster, y también para los LEDs y relé del panel de comando de redundancia PX2612. El usuario puede reducir la cantidad de variables %Q redundantes en cada una de las dos secciones que pueden ser redundantes: 237 6. Redundancia con UCP NX3030 En la primera sección, el tamaño del área redundante se puede configurar entre 0 bytes y 65535 bytes, en múltiples de 1 byte (el valor default es 16384 bytes). La configuración adecuada de la cantidad de %Q redundantes en esta sección es importante para reducir el tiempo necesario para sincronizar variables redundantes (reducir el overhead de la redundancia). Por ejemplo, si la aplicación real ubica sólo %Q0 ... %Q1499 para salidas redundantes, se puede definir el tamaño de esta sección redundante de %Q en 1500 bytes. En la segunda sección, el tamaño del área redundante se puede configurar entre 0 bytes y 81919 bytes, en múltiples de 1 byte (el valor default es 16384 bytes). La configuración adecuada de la cantidad de %Q redundante en esta sección es importante para reducir el tiempo necesario para sincronizar variables redundantes (reducir el overhead de la redundancia). Por ejemplo, si la aplicación real ubica sólo %QB65536 ... %QB66999 para diagnósticos redundantes, se puede definir el tamaño de esta sección redundante de %Q en 1464 bytes. La figura siguiente ilustra la ubicación de variables de representación directa %Q redundantes y no redundantes, en la cual RQS es la cantidad de %Q de salidas configuradas como redundantes en la primera sección, y RQD es la cantidad de %Q de diagnósticos configurados como redundantes en la segunda sección. %Q salidas redundantes 65 kbytes reservado para expansión de %Q salidas redundantes %Q diagnóstico redundantes 96 kbytes 80 kbytes 16 kbytes reservado para expansión de %Q diagnóstico redundantes %Q no redundantes RQS kbytes RQS = 0 ... 65535 RQS default = 16384 65536 - RQS RQD kbytes RQD = RQS ... 81919 RQD default = 16384 81920 - RQD 16 kbytes Figura 6-8. Ubicación de %Q Redundantes y no Redundantes Variables %M Redundantes y No Redundantes La UCP NX3030 ubica 64 kbytes de variables %M (%MB0 ... %MB65535). Todos los 65536 bytes pueden ser redundantes (%MB0000 ... %MB65535). Por estándar, la cantidad de variables %M redundantes es 0. El uso de variables %M redundantes se debe evitar, se debe preferir la utilización de variables simbólicas (ver sección Variables Simbólicas Redundantes y No Redundantes). 238 6. Redundancia con UCP NX3030 Variables Simbólicas Redundantes y No Redundantes Además de las variables de representación directa (%I, %Q e %M) que son ubicadas automáticamente, el usuario puede declarar explícitamente variables simbólicas, dentro de POUs o GVLs. El tamaño máximo permitido para ubicación de variables simbólicas redundantes es de 512 kbytes. ATENCIÓN: No se debe confundir variables simbólicas con variables que utilizan la directiva AT. Variables simbólicas que utilizan la directiva AT son nombres simbólicos atribuidos a variables de representación directa (%I, %Q y %M). Por lo tanto, variables que utilizan la directiva AT no ubican ninguna memoria de variables simbólicas. Variables simbólicas son redundantes en los siguientes casos: Cuando declaradas en POUs del tipo “programa” creadas en la aplicación del usuario, con excepción del programa NonSkippedPrg. Cuando declaradas en GVLs creadas en la aplicación del usuario y estas GVLs marcadas como redundantes. Variables simbólicas son no redundantes en los siguientes casos: Cuando declaradas en el programa NonSkippedPrg, ya descrito anteriormente en la sección Programa NonSkippedPrg. Cuando declaradas en POUs del tipo “función”. Observar que tales tipos de POUs normalmente deberían ubicar variables sólo en la pila (no estáticas), que consecuentemente no necesitan ser redundantes. Aun sabiendo que el usuario puede declarar variables estáticas (VAR STATIC) dentro de POUs del tipo “función”, esto es considerado una mala práctica de programación. Dichas variables estáticas, en caso de que se creen, serán consideradas no redundantes. Cuando declaradas en POUs del tipo “bloque funcional”. Observar que la simple declaración de un “bloque funcional” no ubica memoria (lo que ubica memoria es instanciar un Bloque Funcional). Se debe observar que instancias de bloques funcionales, declaradas dentro de POUs del tipo programa o dentro de GVLs, se portan como variables simbólicas, o sea, ubican memoria redundante. De la misma forma que variables simbólicas, cuando instancias de bloque funcional se declaran en el programa NonSkippedPrg o cuando la GVL no está marcada como redundante, dichas instancias son no redundantes. Mapeos Múltiples Si el usuario desea mapear las variables de comandos de la redundancia en más de una puerta de comunicación (COMx o NETx) será necesaria la implementación de un control por el usuario en la propia aplicación. La lógica de control a implementarse deberá escribir en las variables de control de la redundancia basado en los valores de las variables (comandos) provenientes de cada una de las puertas de comunicación(COMx o NETx). Además, la lógica de control debe reinicializar las variables de comandos de las puertas de comunicación, una vez que el control de la redundancia solo reinicializa sus propias variables de comandos. Sigue un ejemplo de esa implementación: VAR var_comando_StandBy_relacao_Ethernet : BOOL; var_comando_StandBy_relacao_Serial : BOOL; var_comando_Inactive_relacao_Ethernet : BOOL; var_comando_Inactive_relacao_Serial : BOOL; var_comando_TurnOn_relacao_Ethernet : BOOL; var_comando_Turn_relacao_Serial : BOOL; 239 6. Redundancia con UCP NX3030 END_VAR // Lógica para colocar el PLC Local para StandBy IF var_comando_StandBy_relacao_Ethernet = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal := TRUE; var_comando_StandBy_relacao_Ethernet:=FALSE; END_IF IF var_comando_StandBy_relacao_Serial = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal:=TRUE; var_comando_StandBy_relacao_Serial:=FALSE; END_IF //// Lógica para colocar el PLC Local para Inactivo IF var_comando_Inactive_relacao_Ethernet = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bInactiveLocal:= TRUE; var_comando_Inactive_relacao_Ethernet:=FALSE; END_IF IF var_comando_Inactive_relacao_Serial = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bInactiveLocal:=TRUE; var_comando_Inactive_relacao_Serial:=FALSE; END_IF // Lógica para reconectar el PLC Local desconectado por el PX2612 IF var_comando_TurnOn_relacao_Ethernet = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bTurnOnLocal:= TRUE; var_comando_TurnOn_relacao_Ethernet:=FALSE; END_IF IF var_comando_Turn_relacao_Serial = TRUE THEN DG_NX4010.tRedundancy.RedCmdLoc.bTurnOnLocal:=TRUE; var_comando_Turn_relacao_Serial:=FALSE; END_IF Tenemos un ejemplo de una lógica en lenguaje ST, en la cual el comando de la redundancia se puede hacer por dos variables, que provienen de puertas de comunicación diferentes. En el ejemplo, realizamos tres comandos (StandBy, Inactive y TurnOn). Dónde: var_comando_StandBy_relacao_Ethernet: variable del tipo Bool atribuida a un Coil de la comunicación Ethernet que realizará el comando para colocar el Half-Cluster Local para Stand-By. var_comando_StandBy_relacao_Serial: variable del tipo Bool atribuida a un Coil de la comunicación Serial que realizará el comando para colocar el Half-Cluster Local para Stand-By. DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal: este comando produce una acción equivalente al botón STAND-BY del PX2612, e el CP local. var_comando_Inactive_relacao_Ethernet: variable del tipo Bool atribuida a un Coil de la comunicación Ethernet que realizará o comando para colocar o Half-Cluster Local para Inactivo. var_comando_Inactive_relacao_Serial: variable del tipo Bool atribuida a un Coil de la comunicación Serial que realizará el comando para colocar el Half-Cluster Local para Inactivo. DG_NX4010.tRedundancy.RedCmdLoc.bInactiveLocal: este comando produce una acción equivalente al botón INACTIVE do PX2612, en el CP local. var_comando_TurnOn_relacao_Ethernet: variable del tipo Bool atribuida a un Coil de la comunicación Ethernet que realizará el comando para reconectar el Half-Cluster Local después que el relé del PX2612 lo desconecto. var_comando_TurnOn_relacao_Serial: variable del tipo Bool atribuida a un Coil de la comunicación Serial que realizará el comando para reconectar el Half-Cluster Local después que el relé del PX2612 lo desconecto. 240 6. Redundancia con UCP NX3030 DG_NX4010.tRedundancy.RedCmdLoc.bTurnOnLocal este comando produce una acción equivalente al botón STAND-BY del PX2612, en el CP local. Estructuras de Datos de Diagnósticos, Comandos y Usuario Cada CP dispone de diversas estructuras de datos relacionadas con la redundancia. Las siguientes estructuras son variables simbólicas que utilizan la directiva AT para mapear variables del tipo %Q: RedDgnLoc: contiene diagnósticos de este CP (local) relacionados con la redundancia, como por ejemplo, el estado de la redundancia de este CP. RedDgnRem: es una copia de RedDgnLoc del otro CP, recibida por canales de sincronismo NETA / NETB. De esta forma, este CP (local) tiene acceso a los diagnósticos del otro CP (remoto). RedCmdLoc: contiene comandos que se deben aplicar en este CP (cuando tiene sufijo Local) o en el otro CP (cuando tiene sufijo Remote). Por ejemplo el campo StandbyLocal de esta estructura de datos corresponde a un comando que se debe ejecutar en este CP (local), y el campo StandbyRemote corresponde a un comando que se debe ejecutar en el otro CP (remoto). RedCmdRem: es una copia de RedCmdLoc del otro CP, recibida por canales de sincronismo NETA / NETB. De esta forma, este CP puede ejecutar comandos recibidos del otro CP que tengan el sufijo Remote. RedUsrLoc: contiene 128 bytes de datos llenados libremente por el usuario (ex: diagnósticos de comunicación con un sistema SCADA). Estos 128 bytes de datos pueden ser intercambiados con el otro CP (remoto). RedUsrRem: es una copia de RedUsrLoc del otro CP, recibida vía canales de sincronismo NETA / NETB. En la sección Mantenimiento, las siguientes subsecciones suministrarán más detalles sobre estas estructuras de datos: Estructura de Diagnósticos de la Redundancia Comandos de la Redundancia Informaciones del Usuario Cambiados entre CPA y CPB Servicios de Sincronización Cíclicos a través de NETA y NETB Esta sección describe los tres servicios de sincronización que ocurren cíclicamente en un CP redundante, entre CPA y CPB, a través de los canales de sincronismo NETA y NETB. Estos servicios se ejecutan en el inicio de cada ciclo de la MainTask, y en la secuencia en que aparecen a continuación, o sea: Primero, se ejecuta el servicio Cambio de Diagnósticos y Comandos. Segundo, se ejecuta el servicio Sincronización de Datos Redundantes. Tercero, se ejecuta el servicio Sincronización de la Lista de Forzamientos Redundantes. Cambio de Diagnósticos y Comandos Este servicio es responsable del intercambio de las siguientes estructuras de datos, en cada ciclo de la MainTask: Copiar RedDgnLoc del CPA para RedDgnRem do CPB Copiar RedCmdLoc del CPA para RedCmdRem do CPB Copiar RedUsrLoc del CPA para RedUsrRem do CPB Copiar RedDgnLoc del CPB para RedDgnRem do CPA Copiar RedCmdLoc del CPB para RedCmdRem do CPA Copiar RedUsrLoc del CPB para RedUsrRem do CPA El servicio se ejecutará utilizando sólo uno de los canales de sincronismo (NETA o NETB). De esta forma, el servicio se puede completar aunque uno de los canales esté con problemas. 241 6. Redundancia con UCP NX3030 Sincronización de Datos Redundantes Este servicio es responsable por la transferencia de variables redundantes, del CP Activo hacia el CP No-Activo. Según lo visto anteriormente, existen variables redundantes simbólicas y también variables redundantes de representación directa (%I, %M e %Q). Para que este servicio se ejecute, distintas condiciones se deben satisfacer: El servicio de sincronización anterior de este ciclo de la MainTask (Cambio de Diagnósticos y Comandos) debe haberse completado con éxito. En caso de que este CP está en estado Activo, el otro debe estar en estado No-Activo. Por otro lado, en caso de que este CP esté en estado No-Activo, el otro debe estar en estado Activo. Los proyectos de los 2 CPs deben estar idénticos, excepto cuando la sincronización automática de proyectos está deshabilitada (ver sección Deshabilitación de la Sincronización de Proyectos). Necesario por lo menos un canal de sincronismo (NETA y/o NETB) en estado operacional. Si ambos los canales están en operación, la comunicación se distribuye entre ambos (load balance) para reducir el tiempo de la sincronización. En caso de que sólo un canal esté en operación, el sincronismo seguirá siendo realizado solamente por este canal, garantizando de esta forma, la sincronización de los datos redundantes. Sincronización de la Lista de Forzamientos Redundantes Este servicio es responsable por la transferencia de la lista de forzamientos redundantes del CP Activo para el CP No-Activo. Para que este servicio se ejecute, distintas condiciones se deben satisfacer: Los dos servicios de sincronización anteriores de este ciclo (Cambio de Diagnósticos y Comandos, Sincronización de Datos Redundantes) deben haberse completado con éxito. En caso de que este CP esté en estado Activo, el otro debe estar en estado No-Activo. Por otro lado, en caso de que este CP esté en estado No-Activo, el otro debe estar en estado Activo. Los proyectos de los 2 CPs deben estar idénticos, excepto cuando la sincronización automática de proyectos esté deshabilitada (ver sección Deshabilitación de la Sincronización de Proyectos). Necesario por lo menos un canal de sincronismo (NETA y/o NETB) en estado operacional. Si ambos los canales están en operación, la comunicación se distribuye entre ambos (load balance) para reducir el tiempo de la sincronización. En caso de que sólo un canal esté en operación, el sincronismo seguirá siendo realizado solamente por este canal, garantizando de esta forma, la sincronización de los datos redundantes. ATENCIÓN: La lista de forzamientos redundantes contiene sólo forzamientos sobre variables redundantes. En cada uno de los CPs (CPA y CPB), puede existir una lista diferente de forzamientos sobre variables no redundantes. Servicios de Sincronización Esporádicos a través de NETA y NETB Los siguientes servicios de sincronización se ejecutan de forma esporádica. O sea, no se ejecutan a cada ciclo de la tarea MainTask y otra tarea del sistema ejecuta estos servicios esporádicos en segundo plano. Sincronización de Proyectos Este servicio es responsable de mantener sincronizados los proyectos de los CPs Activo y No-Activo. Esto ocurre sólo cuando los proyectos están diferentes y la sincronización automática de proyectos está habilitada en ambos CPs. La sincronización es siempre en el sentido del CP Activo hacia el No-Activo y basta que uno de los canales de sincronismo (NETA o NETB) esté operacional para que este servicio se ejecute. Cuando la sincronización está habilitada, se sincronizarán los siguientes archivos y servicios: 242 6. Redundancia con UCP NX3030 Proyecto aplicativo (código ejecutable) Project archive (código fuente) Usuarios y grupos Derechos de acceso Trace El servicio de sincronización se iniciará en hasta treinta segundos, después que uno de los CPs entre en el modo Activo, y, después de su inicio, chequeará el CRC de los proyectos a cada cinco segundos. Cuando una sincronización se inicie, el CP No-Activo irá hacia el modo Stop, en el estado de No Configurado. Tras la transferencia de todos los archivos necesarios, el CP No-Activo irá hacia Run, en el estado de Inicializando. En caso de que la transferencia falle, el CP volverá hacia el estado NoConfigurado. El tiempo que la sincronización llevará para efectuarse dependerá del tamaño del proyecto. En un promedio, la tasa de transferencia entre los canales de sincronismo es de aproximadamente 500 kbytes/s. En caso de que la sincronización se interrumpa (pérdida de la comunicación entre los canales de sincronismo) durante la transferencia de los archivos del CP Activo hacia el No-Activo, el procedimiento será suspendido y reinicializará en cuanto la comunicación se restaure. Solamente tras la conclusión de todo el procedimiento el CP No-Activo irá para el modo Run. Además de mantener sincronizados los proyectos, la Sincronización del Proyecto también impedirá que el CP No-Activo asuma estados superiores a Inicializando en caso de que el CRC esté diferente o algún Online Change esté pendiente en el CP Activo. ATENCIÓN: Una sincronización de proyecto tendrá los mismos efectos de un download en el CP No-Activo. Este servicio no se ejecuta si la sincronización automática de proyectos está deshabilitada, según se describe en la sección Deshabilitación de la Sincronización de Proyectos. Ningún servicio de sincronización entre el CPA y el CPB funcionará en caso de que se inviertan los cables de los canales de sincronismo. Por ejemplo, conectar el canal NET A del CPA en el NET B del CPB y el canal NET B del CPA en el NET A del CPB. ATENCIÓN: En la actualización de la versión 1.20 a versiones superiores del MasterTool IEC XE, se ha modificado el protocolo de comunicación entre los canales de sincronismo. Por conseguiente, no és possible sincronizar datos entre dos CPs cuando una de las aplicaciones se ha creado en una versión anterior a la versión 1.21 e otra en una versión igual o superior. Para volver a realizar la sincronización se debe No Cargar la Aplicación en la Inicialización de lo CP con uno proyecto más antiguo y dejar que la aplicación sea sincronizada automáticamente en la inicialización, cuando lo CP va al estado No-Configurado. ATENCIÓN: Antes de la versión 2.01 del MasterTool IEC XE, al enviar el código fuente al CP Activo, el CP Reserva se volvía estado No-Configurado para su sincronización. Sin embargo, al concluir la operación de sincronización, el CP permanecía en el estado No-Configurado, siendo necesario pasar el CP al estado Reserva a través del botón STAND-BY del PX2612 o de comando equivalente. A partir de la versión 2.0.1, el CP que está en Reserva alterará su estado a No-Configurado durante el proceso de sincronización, pero volverá automáticamente cuando los códigos fuente sean iguales entre los dos Half-Clusters. 243 6. Redundancia con UCP NX3030 Deshabilitación de la Sincronización de Proyectos En la sección Servicios de Sincronización Esporádicos a través de NETA y NETB se describen servicios para la sincronización del proyecto aplicativo y del project archive. Estos servicios normalmente deben estar habilitados y son útiles cuando las modificaciones de proyecto se pueden cargar on-line en el CP Activo, siendo, a continuación, automáticamente retrasmitidas para el CP Reserva por canales de sincronismo NETA / NETB. Sin embargo, existen modificaciones de proyecto que no se pueden cargar online en ningún CP, como por ejemplo la inclusión de módulos en una remota PROFIBUS, o la inclusión de una nueva remota PROFIBUS. En estos casos, valiéndose de la redundancia del CP y de la red PROFIBUS, se pueden hacer dichas modificaciones sin interrumpir el control de proceso. Un procedimiento para alcanzar este objetivo se describe en la sección Explorar la Redundancia para Carga Offline de Modificaciones sin Interrupción del Control del Proceso. En este procedimiento, es necesario deshabilitar temporariamente las sincronizaciones de proyecto, permitiendo que, por algún tiempo, uno de los CPs opere con la nueva versión del proyecto, mientras tanto el otro CP aun opera con la versión antigua del proyecto. Una UCP NX3030 posee un registro de Deshabilitación de la Sincronización de Proyectos, no volátil, que permite deshabilitar los servicios para sincronización del proyecto aplicativo y del project archive. Este registro se puede ajustar con el programador MasterTool. Basta deshabilitar la sincronización de proyectos en uno de los dos CPs para que no ocurra más. Para deshabilitar la sincronización de proyectos, debe se, en primer lugar, conectar en el CP con el software MasterTool (consulte la sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante). A continuación, en el menú Comunicación / Configuración Básica del Cluster, se abre la combo-box “Sincronización del Proyecto”, que permite seleccionar una de las dos siguientes opciones: Habilitar Deshabilitar Se debe seleccionar la opción “Deshabilitar” y después presionar el botón “Escribir”, al lado de esta combo-box. Un mensaje informará si la operación tuvo éxito o no. La configuración de la Deshabilitación de sincronismo de proyectos no hace parte del proyecto redundante desarrollado con el MasterTool. Tal configuración se ubica sólo en un área de memoria no-volátil de la UCP, que se puede leer o grabar con el MasterTool. El MasterTool no salva esta configuración en ningún archivo. Esta configuración se copia a cada ciclo de la memoria no volátil para el diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bProjectSyncDisable. El usuario puede verificar este diagnóstico en el CP para verificar si el comando tuvo éxito, desde que el esté en modo Run (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag. bProjectSyncDisabledebe valer 1). En caso de que el CP no esté en modo Run, es posible verificar esta configuración directamente en el visor de la UCP NX3030 en el CP No-Activo (ver sección Diagnósticos de la Redundancia en el Visor Gráfico de la UCP NX3030). El diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag. bProjectSyncDisabledel CP No-Activo se puede observar también en el CP Activo, a través del diagnóstico DG_NX4010.tRedundancy.RedDgnRem.sGeneral_Diag. bProjectSyncDisable (desde que el CP NoActivo esté en modo Run). Determinado CP (Activo o No-Activo) suspenderá el servicio de sincronización de proyectos siempre que cualquiera de los siguientes bits esté conectado: DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag. bProjectSyncDisable o bit local, de este CP. Este CP está con la sincronización de proyectos deshabilitada. DG_NX4010.tRedundancy.RedDgnRem.sGeneral_Diag. bProjectSyncDisable o bit remoto, del otro CP. El otro CP está con la sincronización de proyectos deshabilitada. 244 6. Redundancia con UCP NX3030 ATENCIÓN: El registro de Deshabilitación de la Sincronización de Proyectos no hace parte del proyecto del CP redundante, y por lo tanto no se salva como parte de este proyecto en la computadora en la cual el MasterTool ejecuta. El registro se salva sólo en la memoria no volátil de la UCP. Configuraciones de Redes PROFIBUS Es posible instalar hasta cuatro módulos Maestro PROFIBUS NX5001 en cada half-cluster. Por consiguiente, se puede configurar hasta dos redes PROFIBUS redundantes, denominadas PROFIBUS 1 y PROFIBUS 2, o cuatro redes simples, denominadas PROFIBUS 1, PROFIBUS 2, PROFIBUS 3 y PROFIBUS 4 , o aun una red redundante y dos simples, denominadas PROFIBUS 1, PROFIBUS 2 y PROFIBUS 3. Redundancia PROFIBUS Cada una de las redes PROFIBUS puede ser redundante o no redundante. Por ejemplo, si la red PROFIBUS 1 es redundante, se dividirá en redes PROFIBUS 1 A y PROFIBUS 1 B. En caso de que no sea redundante, existirá sólo la red PROFIBUS 1 A. Analógicamente esto vale para la PROFIBUS 2. La Figura 6-1 muestra un ejemplo con una única red PROFIBUS (PROFIBUS 1), que es redundante (PROFIBUS 1 A y PROFIBUS 1 B). Solamente algunos tipos de remotas se pueden conectar directamente a este tipo de red PROFIBUS redundante: PO5063V5: esclavo PROFIBUS DP-V0 para remotas de la Serie Ponto PO5065: esclavo PROFIBUS DP-V1 con Hart, para remotas de la Serie Ponto AL-3416: esclavo PROFIBUS DP-V0 para CP AL-2004 NX5210: esclavo PROFIBUS DP-V0 para remotas de la Serie Nexto La Figura 6-1 también muestra la posibilidad de conectar remotas no redundantes a este tipo de red PROFIBUS redundante, a través del módulo AL-2433(ProfiSwitch). Dichas remotas PROFIBUS no redundantes pueden ser de cualquier marca o modelo. Modos de Falla PROFIBUS Vital y No-Vital Cada una de las redes PROFIBUS se puede configurar en dos modos diferentes: Falla vital: en caso de que esta red falle completamente, esta falla podrá determinar una transición de estado de redundancia en el CP redundante (switchover). En el caso de una red PROFIBUS redundante, una falla completa consiste en la falla de las dos redes que la componen. Falla no vital: aun que esta red falle completamente, esta falla no determinará una transición de estado de redundancia en el CP redundante (switchover). Redes Ethernet Redundantes con NIC Teaming La Figura 6-1 muestra dos ejemplos de red Ethernet redundantes, con NIC Teaming. En el primer caso, la UCP NX3030 se conecta a la red de supervisión (SCADAs), también utilizada para configuración a través del MasterTool. Las dos puertas Ethernet de la UCP NX3030 (NET 1 y NET 2) forman un par redundante NIC Teaming, interconectadas en dos switches diferentes (Ethernet A y Ethernet B). En algún punto, estos dos swtiches se deben interconectar, para que exista conexión entre las dos puertas NIC Teaming y disponibilidad aun mayor (contra fallas dobles). En el segundo caso, dos módulos NX5000 también forman un par redundante NIC Teaming, interconectados en dos switches diferentes (Ethernet HSDN A y Ethernet HSDN B). En algún punto, estos dos switches se deben interconectar, para que exista conexión entre las dos puertas NIC Teaming y disponibilidad aun mayor (contra fallas dobles). Tales arquitecturas Ethernet posibilitan excelente disponibilidad, contra fallas en las puertas Ethernet, en cables y en switches. 245 6. Redundancia con UCP NX3030 ATENCIÓN: Si dos módulos consecutivos, o puertas Ethernet, forman un par Redundante NIC Teaming, la configuración de parámetros básicos y la adición de dispositivos MODBUS sólo será posible en la primera interfaz; la siguiente, tendrá sus parámetros bloqueados. Un conjunto de dos puertas Ethernet formando un par NIC Teaming posee una única dirección IP, vinculada al par de puertas. De esta forma, un cliente como un SCADA o MasterTool, conectado a un servidor en el CP, no necesita preocuparse en cambiar la dirección IP en caso de que haya falla en alguna de las puertas del par NIC Teaming. Además, cada una de las interfaces que forman uno par NIC Teaming mantiene diagnósticos aparte, destinados a facilitar la depuración de fallas que puedan ocurrir en cualquiera de las interfaces. Más detalles sobre configuración y diagnósticos de puertas NICTeaming se en las secciones: Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2) Configuración de los Módulos NX5000 Métodos de Cambio de IP Un cluster redundante de la Serie Nexto dispone de cuatro métodos para el cambio de IP de las puertas Ethernet de los módulos NX5000 de cada half-cluster y un método para el cambio de IP de las puertas NET1 y NET2 de la UCP NX3030. Estos métodos definen el comportamiento de las puertas, en lo que se refiere al IP de la misma, según el estado actual del half-cluster (Activo o NoActivo) y con el half-cluster en cuestión (CPA o CPB). Los métodos son: IP Fijo, Troca Automática de IP, IP Activo y Multiple IP. Al todo, podemos relacionar hasta cuatro IPs, según el método de cambio de IP. IP Fixo Es el método más simple de direccionamiento IP y se puede configurar en las interfaces Ethernet de los módulos Ethernet NX5000. En ese método, solamente relacionamos las direcciones de IP del CPA y del CPB. Independiente del estado de la redundancia, CP Activo o No-Activo, el CPA siempre responderá por el IP configurado, así como el CPB. Figura 6-9. Método de IP Fijo Parámetros que se deben configurar en el método de IP Fijo: IP Address PLC A: dirección para comunicación con el CPA IP Address PLC B: dirección para comunicación con el CPB Subnetwork Mask Gateway Address 246 6. Redundancia con UCP NX3030 Troca Automática de IP El (Cambio Automático de IP) se puede configurar en las interfaces Ethernet de los módulos Ethernet NX5000. En ese método, el IP del half-cluster dependerá del estado del CP (Activo o No-Activo). A cada switchover ocurre el cambio de IPs entre los half-clusters para que asuman la dirección IP del nuevo estado de la redundancia. Observación: para este método de direccionamiento, las puertas Ethernet de ambos CPs (CPA y CPB) asumir la misma dirección IP mientras los dos CPs estén en el estado no-activo, provocando conflicto de direccionamiento en la red. Considerando que esta es una situación poco común, en la cual ningún CP está controlando el sistema, esto puede no llegar a ser un problema grave, pero que debe tener en cuenta. Figura 6-10. Método de Cambio Automático de IP Parámetros que se deben configurar en el método Cambio Automático de IP: IP Address Active: dirección de IP para comunicación con el CP Activo IP Address Non Active: dirección de IP para comunicación con el CP No-Activo Subnetwork Mask Gateway Address IP Activo Ese método es el utilizado en las NETs de la UCP redundante y también es posible configurarlo en los módulos NX5000. En ese método hay un IP para el half-cluster Activo y más dos IPs, uno para el CPA y otro para el CPB. En las NETs de la UCP NX3030 redundante, la Dirección de IP Activo se añadirá a la interfaz del CP Activo, y podrán utilizarse tanto la Dirección de IP Activo, como en la Dirección de IP del CPX para comunicarse con el CP. Para los módulos Ethernet NX5000, la Dirección de IP Activo sustituirá la Dirección de IP del CPX No Activo, cuando el CP esté en modo Activo. 247 6. Redundancia con UCP NX3030 Figura 6-11. Método Active IP – NX3030 Redundante Parámetros que se deben configurar en el método Active IP para las NETs de un UCP NX3030 Redundante: IP Address Active: dirección de IP se añade a interfaz cuando el CP esté en estado Activo. IP Address PLC A: dirección para comunicación con el CPA, independiente de su estado actual. IP Address PLC B: dirección para comunicación con el CPB, independiente de su estado actual. Subnetwork Mask. Gateway Address. Figura 6-12. Método IP Activo – NX5000 Parámetros que se deben configurar en el método de Active IP para módulos Ethernet NX5000: IP Address Active: dirección para comunicación con el CP Activo. Sustituye la Dirección de IP del CPX No-Activo. IP Address PLC A Non Active: dirección comunicación con el CPA, cuando en estado NoActivo. IP Address PLC B Non Active: dirección comunicación con el CPB, cuando en estado NoActivo. Subnetwork Mask. Gateway Address. 248 6. Redundancia con UCP NX3030 Multiple IP El método Multiple IP se puede configurar en las interfaces Ethernet de los módulos Ethernet NX5000. En ese método, hay un IP para cada half-cluster y para cada estado del CP. El CPA asumirá una dirección IP cuando esté en Activo y otra dirección IP cuando esté en No-Activo. Lo mismo ocurre para el CPB en función de su estado (Activo y No-Activo). Figura 6-13. Método Multiple IP Parámetros que se deben configurar en el método Multiple IP: IP Address PLC A Active:: dirección para comunicación con el CPA, cuando este esté en estado Activo. IP Address PLC A Non Active: dirección para comunicación con el CPB, cuando este esté en estado No-Activo. IP Address PLC B Active: dirección para comunicación con el CPB, cuando este esté en estado Activo. IP Address PLC B Non Active: dirección para comunicación con el CPB, cuando este esté en estado No-Activo. Subnetwork Mask. Gateway Address. Uso Combinado de NIC Teaming y Active IP En caso de que determinado par de puertas forme un par NIC Teaming en un CP redundante, estas puertas pueden implementar, al mismo tiempo, las estrategias NIC Teaming e Active IP. Por ejemplo, si las puertas NET 1 y NET 2 de la UCP NX3030 forman un par NIC Teaming, entonces: Dirección de IP del CPA: dirección IP de las puertas NET 1 + NET 2 de la UCP NX3030 del CPA Dirección de IP do CPB: dirección IP de las puertas NET 1 + NET 2 de la UCP NX3030 del CPB Dirección de IP Activo: dirección IP de las puertas NET 1 + NET 2 de la UCP NX3030 que esté en el CP Activo De esta forma, se asocia la excelente disponibilidad de la estrategia NIC Teaming con la practicidad de la estrategia de IP Activo, que no necesita scripts en sistemas SCADA o en otros clientes conectados a servidores en el CP Activo. 249 6. Redundancia con UCP NX3030 Uso de Interfaces Ethernet con Indicación de Falla Vital Las puertas Ethernet de la UCP NX3030 y de los módulos NX5000 se pueden configurar para generar fallas vitales. Esta opción es importante para las aplicaciones en las cuales los módulos de entradas y salidas están distribuidos a través de red Ethernet. En este caso, si ocurre una falla en la puerta Ethernet, eso generará un switchover. Este comportamiento se aplica solo en puertas Ethernet en las cuales exista por lo menos un driver de comunicación que genere falla. Los drivers de comunicación que generan falla vital son MODBUS Client y el MODBUS Symbol Client (todas las referencias a MODBUS Client en las próximas secciones se aplican a los dos casos). Los drivers MODBUS Server, MODBUS Symbol Server y EtherCAT Master no generan falla vital De esta forma, si una puerta Ethernet tiene un driver MODBUS Client configurado y ocurre una falla en la puerta Ethernet, se generará un switchover si la opción de falla vital está habilitada. Si el driver configurado en la puerta Ethernet es un MODBUS Server, aun que ocurra falla en la puerta, eso no generará una falla vital que causa un switchover. Para que una falla se considere falla vital en una puerta Ethernet de un MODBUS Client, todos los servers configurados en el driver deben estar en falla. O sea, en el caso de que exista más de un driver MODBUS Client configurado en la misma puerta Ethernet, se considerará falla vital cuando todos los servers de ambos Clients estén en falla. Cuando la puerta Ethernet está configurada para operar con NIC Teaming, la falla vital se considerará solo cuando las dos puertas del par fallen. Falla en la Interfaz Ethernet Un switchover se puede generar debido a la falla en la interfaz Ethernet, por ejemplo, una pérdida de link. La pérdida de link puede ocurrir, por ejemplo, por el rompimiento de un cable o falla en un switch en la red Ethernet. En estas condiciones, es necesario que, más allá de estar configurado para generar falla vital, exista una instancia MODBUS Client configurada en la interfaz Ethernet. Cuando el intervalo de la MainTask es mayor o igual a 100 ms, tras detectar la falla, el switchover sucederá en hasta dos ciclos de la MainTask. Al ser el intervalo de la MainTask menor que 100 ms, el switchover ocurrirá en hasta 100 ms más el tiempo de la MainTask tras la detección de la falla. Falla en MODBUS Server Conectado El tiempo para detectar la falla en una remota MODBUS Server depende de las configuraciones de time-out configuradas en cada MODBUS Client. Al detectarse la falla en todos los Servers, el diagnóstico bAllDevicesCommFailure (ver sección Diagnósticos MODBUS utilizados en la ) cambia su estado a TRUE. Al suceder eso, el switchover sucederá en 3 segundos tras esta transición. Uso de Comunicación OPC con Proyectos Redundantes El protocolo OPC DA se puede configurar para la comunicación de clusters redundantes con sistemas SCADA. Al seleccionar esta opción en la creación de un proyecto redundante, el objeto Symbol Configuration se añade al proyecto. En este objeto se configuran las variables del sistema que se enviarán al sistema SCADA. Esta opción de comunicación se habilita en las puertas Ethernet de la UCP NX3030. Para más informaciones acerca de la configuración de la comunicación OPC con proyectos redundantes consulte la sección Configuración con CP en el Servidor OPC con Redundancia de Conexión de este Manual. Estados de un CP Redundante En un sistema redundante, un CP (CPA o CPB) puede asumir los siguientes estados: Activo Reserva Inactivo No-Configurado Inicializando 250 6. Redundancia con UCP NX3030 ATENCIÓN: Frecuentemente este manual utilizará la designación “No-Activo” para cualquier estado diferente de Activo, o sea, para designar cualquiera de los otros cuatro estados (Reserva, Inactivo, NoConfigurado e Inicializando). A continuación, estos cinco estados se describen brevemente. Más detalles sobre los estados de un CP redundante se tratarán en la sección Transiciones entre Estados de Redundancia, al describir la máquina de estados y las causas de las transiciones entre ellos. Estado No-Configurado Este es el estado de redundancia inicial. El CP se encuentra en este estado de redundancia: Por convención, mientras el CP esté desconectado. Antes de iniciar la MainTask. Antes de conmutar hacia el estado Inicializando. En caso de que ocurra una reinicialización a través de un comando como Reset warm, Reset cold o Reset origin. En caso de que la MainTask se esté ejecutando en el estado No-Configurado, las siguientes tareas se ejecutarán: Los maestros PROFIBUS están deshabilitados. Los servicios de sincronización cíclicos se ejecutan (ver sección Servicios de Sincronización Cíclicos a través de NETA y NETB), desde que las condiciones para su ejecución estén presentes. Los servicios de sincronización esporádicos también se pueden ejecutar (ver sección Servicios de Sincronización Esporádicos a través de NETA y NETB). El CP permanecerá bloqueado en el estado No-Configurado si el otro CP está en estado Activo, y el proyecto de este CP es diferente del proyecto del CP Activo (excepto si la sincronización automática de proyectos está deshabilitada – ver sección Deshabilitación de la Sincronización de Proyectos). En caso de que esta situación no ocurra, ocurre una transición del estado No-Configurado hacia el estado Inicializando en cuanto llegue una solicitud de configuración. Algunas veces, el CP entra en el estado No-Configurado aunque haya recibido una solicitud de configuración automática, no siendo necesaria una nueva solicitud para cambiar al estado Inicializando. Esto ocurre, por ejemplo, en la energización del CP. Otras veces, el usuario deberá solicitar manualmente esta configuración, por ejemplo, al presionar un botón del panel de comando de redundancia PX2612. Solicitudes de configuración manuales típicamente son necesarias cuando algún mantenimiento por parte del usuario es necesaria antes de salir del estado No-Configurado, por ejemplo, si el CP alcanzó el estado No-Configurado debido a alguna falla. Después de salir del estado No-Configurado, el CP puede volver a este estado, debido a eventos tales como: Reinicialización (Reset a Caliente, Reset a Frío o Reset Origen) Desconexión del CP Diferencia de proyecto entre este CP y el CP Activo Estado Inicializando Diferente de todos los otros cuatro estados que pueden tener duración indeterminada, el estado Inicializando es temporario, dura pocos segundos. Este estado siempre se alcanza desde el estado NoConfigurado, a través de una solicitud de configuración. Al entrar en el estado Inicializando, diversas acciones, tests y verificaciones se ejecutan, para decidir cuál será el próximo estado: 251 6. Redundancia con UCP NX3030 Maestros PROFIBUS se habilitan en estado pasivo. El modo pasivo sirve para testear los circuitos de transmisión y recepción PROFIBUS y el medio físico, para evitar el suceso de una falla oculta. Verificar si la identificación del CP está correcta (debe ser CPA o CPB). Verificar se hay problemas en los parámetros de configuración extraídos del proyecto MasterTool. Verificar la integridad del módulo NX4010. Los servicios de sincronización cíclicos se ejecutan (ver sección Servicios de Sincronización Cíclicos a través de NETA y NETB), desde que las condiciones para su ejecución estén presentes. Verificar compatibilidad de versiones de firmware entre los dos CPs. Verificar la igualdad de proyectos entre los dos CPs, si la sincronización automática de proyectos está habilitada (ver sección Deshabilitación de la Sincronización de Proyectos). En caso de que el otro CP esté en estado Activo, verificar la posibilidad de establecer comunicación PROFIBUS pasiva con el mismo. El modo pasivo sirve para testear los circuitos de transmisión y recepción PROFIBUS y el medio físico, para evitar el suceso de una falla oculta. En caso de que el otro CP esté en estado desconocido debido a fallas en NETA y NETB, verificar la posibilidad de establecer comunicación PROFIBUS pasiva con el mismo. Dependiendo del resultado de estas verificaciones y tests, el CP puede ir del estado Inicializando hacia cualquiera de los otros cuatro estados. Estado Activo En este estado, el CP controla el proceso automatizado, usando el programa ActivePrg, ejecutado solamente en este estado. El CP Activo también actualiza el sistema de E/S remoto PROFIBUS, colocando sus maestros PROFIBUS en modo activo. El modo activo sirve para establecer comunicación con las remotas (esclavos) PROFIBUS. El CP Activo también verifica sus diagnósticos internos y solicitudes de switchover del usuario para determinar si un switchover es necesario. El CP normalmente solo saldrá del estado Activo si sabe que el otro CP está en estado Reserva, y apto a asumir como Activo. Sin embargo, existen algunas situaciones en que el CP Activo podrá salir del estado Activo aun sin estar seguro de que el otro CP está en estado Reserva (por ejemplo, si este CP se desconecta). Estado Reserva En este estado, el CP está pronto para conmutar hacia el estado Activo, en caso de que haya una demanda para eso, tal como una falla en el CP Activo. El CP Reserva también verifica sus propios diagnósticos, y podrá conmutar hacia el estado NoConfigurado o Inactivo en función de algunas fallas. Maestros PROFIBUS son habilitados en estado pasivo. El modo pasivo sirve para testear los circuitos de transmisión y recepción PROFIBUS y el medio físico, para evitar el suceso de una falla oculta. Fallas totales en redes PROFIBUS configuradas como vitales causan una conmutación hacia el estado Inactivo. Una falla total en una red PROFIBUS alcanza a las dos redes que la componen (red PROFIBUS redundante) o la única red que la compone (red PROFIBUS no redundante). Si se están usando las interfaces ethernet con la opción de falla vital habilitada, los clientes se habilitan en estado pasivo. Fallas totales en redes ethernet configuradas como vitales causan una conmutación al estado Inactivo. Una falla total en una red Ethernet alcanza a las dos redes que la componen (opción de Redundancia de Comunicación habilitada) o la única red que la compone (opción de Redundancia de Comunicación deshabilitada). 252 6. Redundancia con UCP NX3030 Estado Inactivo Este estado normalmente se alcanza después de algunos tipos de fallas, o debido a alguna solicitud manual antes de un mantenimiento programado. Maestros PROFIBUS se habilitan en estado pasivo. El modo pasivo sirve para testear los circuitos de transmisión y recepción PROFIBUS y el medio físico, para evitar el suceso de una falla oculta. Antes de dejar este estado, primero se debe corregir las fallas diagnosticadas o ejecutar los mantenimientos programados, que causaron la transición hacia el estado Inactivo. Después, se debe causar una transición hacia el estado No-Configurado ya solicitando una configuración, para enseguida conmutar hacia el estado Inicializando. Después del estado Inicializando, el CP puede: Volver al estado Inactivo, si determinados tipos de fallas persisten Volver al estado No-Configurado, para otros tipos de fallas Ir hacia el estado Reserva, si el otro CP está en el estado Activo Ir hacia el estado Activo, si el otro CP no está en el estado Activo Funciones del Panel de Comando de Redundancia PX2612 El panel de comando de redundancia PX2612 se muestra en la Figura 6-4. La Figura 6-5 muestra su serigrafía delantera con más detalles y la Figura 6-6 muestra como este panel se debe interconectar a los half-clusters CPA y CPB. El PX2612 se divide en dos secciones, una controlada por el CPA, y otra por el CPB. Estos controles ocurren a través de los cables AL-2317/A para el CPA, y AL-2317/B para el CPB, y permiten que cada CP lea tres botones, y escriba sobre tres LEDs y sobre un relé NA. Al observar la parte delantera en la Figura 6-5: CPA ejecuta a lectura del botón TURN ON PLC B. CPA ejecuta la escritura en los tres LEDs (ACTIVE, STAND-BY e INACTIVE) del sector PLC A. CPA ejecuta la escritura en el relé RL B, que se utiliza para desconectar el CPB. CPB ejecuta la lectura de los botones STAND-BY e INACTIVE dentro del sector PLC B. CPB ejecuta la lectura del botón TURN ON PLC A. CPB ejecuta la escritura en los tres LEDs (ACTIVE, STAND-BY e INACTIVE) del sector PLC B. CPB ejecuta la escritura en el relé RL A, que se utiliza para desconectar el CPA. Botones del PX2612 Esta sección describe las funciones de los botones del PX2612. El botón STAND-BY tiene las siguientes funciones: Solicitar una conmutación del estado Activo para el estado Reserva, lo que puede ser útil para ejecutar algún mantenimiento programado en el CP Activo. Después que el CP Activo conmuta hacia Reserva (y como consecuencia el CP Reserva conmuta a Activo), es posible conmutarlo de Reserva hacia Inactivo al usar el botón INACTIVE, y entonces ejecutar el mantenimiento programado en el estado Inactivo. Solicitar una configuración que provoca una conmutación del estado No-Configurado hacia el estado Inicializando, típicamente después de reparar fallas que han provocado la transición hacia el estado No-Configurado. Después del estado Inicializando, normalmente se espera que el CP vaya al estado Reserva (o Activo, si el otro CP no está en el estado Activo). Solicitar una conmutación del estado Inactivo hacia el estado No-Configurado ya solicitando una configuración. Esto ocurre típicamente después de corregir fallas que provocaron la transición al estado Inactivo. Después del estado No-Configurado, la configuración ya debe ir hacia el estado Inicializando. Después del estado Inicializando, normalmente se espera que el CP vaya al estado Reserva (o Activo, si el otro CP no está en el estado Activo). 253 6. Redundancia con UCP NX3030 El botón INACTIVE solicita una conmutación del estado Reserva hacia el estado Inactivo, lo que es útil para ejecutar algún mantenimiento programado en el CP Reserva. Después de este mantenimiento, se puede utilizar el botón STAND-BY para intentar volver al estado Reserva, y pasar por los estados No-Configurado e Inicializando (ver descripción anterior de las funciones del botón STAND-BY). El botón TURN ON PLCx (x = B para CPA, o x = A para CPB) sirve para provocar una reconexión del otro CP, en caso de que este CP lo haya desconectado anteriormente. Según lo que se verá en la sección Transiciones entre Estados de Redundancia, existen situaciones excepcionales en las que un CP desconecta el otro al asumir como Activo, para evitar que haya la posibilidad de que ambos CPs asuman a la vez el estado Activo. ATENCIÓN: Para que la presión a un botón se considere, se debe mantenerlo presionado por lo mínimo por 1 segundo. Durante este segundo, solamente este botón se debe presionar (los otros 2 botones se deben liberar). ATENCIÓN: Existen formas alternativas de generar los mismos efectos de los botones STAND-BY, INACTIVE y TURN ON PLCx. Se puede utilizar comandos generados por este CP o por el CP remoto, según lo descrito anteriormente en la sección Estructuras de Datos de Diagnósticos, Comandos y Usuario. Una descripción más detallada de estos comandos se puede encontrar en la sección Comandos de la Redundancia. LEDs del PX2612 Los LEDs del PX2612 sirven para informar el estado de redundancia, según muestra la tabla a continuación: Estado de redundancia No-Configurado Inicializando Activo LED ACTIVE LED STANDBY LED INACTIVE apagado apagado apagado encendido encendido encendido encendido apagado apagado parpadeando apagado apagado encendido parpadeando apagado parpadeando parpadeando apagado Reserva apagado encendido apagado Inactivo apagado apagado encendido Activo (reciente) Activo (desconectando otro CP) Activo (reciente y desconectando otro CP) Tabla 6-2. LEDs del PX2612 Cada LED puede estar apagado, encendido o parpadeando. En caso de que esté parpadeando, permanece encendido por 0.5 segundos, y apagado por 0.5 segundos. Se percibe que existen cuatro animaciones diferentes para el estado Activo, debido a las dos siguientes características: En los dos primeros segundos en estado Activo el LED ACTIVE queda parpadeando, y después permanece encendido. Esta animación ha sido creada porque, en estos primeros instantes en estado Activo, normalmente el CP no aceptará comandos que lo hagan salir del estado Activo. Más detalles sobre este comportamiento del CP Activo se exhibirán en la sección Transiciones entre Estados de Redundancia y en la sección Primeros Instantes en Estado Activo. En caso de que este CP esté desconectando el otro CP a través de su relé del PX2612, el LED STAND-BY queda parpadeando, y de lo contrario permanece apagado. 254 6. Redundancia con UCP NX3030 Relés del PX2612 El PX2612 posee dos relés NA. El CPA puede controlar RL B, para comandar la desconexión del CPB. El CPB puede controlar RL A, para comandar la desconexión del CPA. Dichas situaciones de desconexión ocurren en situaciones excepcionales, descritas en la sección Transiciones entre Estados de Redundancia. Transiciones entre Estados de Redundancia La figura siguiente muestra la máquina de estados de la redundancia, que ilustra todas las posibles transiciones entre estados de redundancia. NoConfigurado 2 6 Inicializando 3 Inactivo 1 10 11 7 4 5 Reserva 12 Activo 9 8 Figura 6-14. Máquina de Estados de la Redundancia Las siguientes subsecciones describirán todas estas transiciones, y las causas que pueden dispararlas. Para interpretar correctamente el funcionamiento de esta máquina de estados, es necesario establecer algunas reglas y secuencias: Transiciones que se originan del mismo estado se deben evaluar en la secuencia dada por el número de la transición. Por ejemplo, las transiciones 2, 3, 4 y 5 se originan del estado Inicializando. En este ejemplo, se evalúa primero la transición 2, después la 3, después la 4 y finalmente la 5. En caso de que la transición 2 sea disparada, las transiciones 3, 4 y 5 no se evaluarán. Dentro de una subsección específica que describe una transición, distintas condiciones pueden disparar esta transición. Estas condiciones se deben evaluar en el orden que aparecen en la subsección. Cualquiera de estas condiciones que se vuelvan verdaderas puede causar la transición. Si una condición causa la transición, las próximas condiciones no se evaluarán. Transiciones solo se pueden disparar si el CP está energizado y la MainTask se está ejecutando. De lo contrario, se asume que el CP está en el estado No-Configurado. En distintos casos, se mencionan transiciones causadas por botones del panel PX2612. Se debe recordar que existen alternativas para estos botones, que son comandos internos provenientes de este CP o del otro CP (por NETA / NETB). Dichos comandos se mencionaron preliminarmente en la sección Estructuras de Datos de Diagnósticos, Comandos y Usuario, y serán mejor detallados en la sección Comandos de la Redundancia. En las subsecciones siguientes, por simplicidad, estos comandos alternativos no se nombrarán, pero se debe tener conciencia de que pueden causar las mismas transiciones del botón equivalente en el PX2612. 255 6. Redundancia con UCP NX3030 Transición 1 - No-Configurado Hacia Inicializando ATENCIÓN: Las condiciones de esta subsección no se deben evaluar en caso de que el otro CP esté en estado Activo y los proyectos estén diferentes. Este CP debe permanecer en el estado No-Configurado mientras su proyecto esté diferente del proyecto del otro CP, si el otro CP está en estado Activo. Esta nota no es válida si la sincronización automática de proyectos está deshabilitada (ver sección Deshabilitación de la Sincronización de Proyectos, pues en este en caso se admiten diferencias de proyectos entre los CPs. Un pedido de configuración ya existía al entrar en el estado No-Configurado. Esto ocurre en la energización del CP, y también en demás situaciones, descritas en las próximas subsecciones. El botón STAND-BY se presionó durante el estado No-Configurado. Esto causa un pedido de configuración manual. El usuario típicamente aprieta STAND-BY después de reparar fallas que anteriormente llevaron este CP al estado No-Configurado. Transición 2 - Inicializando Hacia No-Configurado Este CP se desconectó o reinicializó (Reset warm, Reset cold o Reset origin) o su UCP entró en modo Stop. El registro de identificación de este CP es inválido (diferente de CPA o CPB). Existen errores lógicos de configuración en el proyecto recibido del MasterTool IEC XE. El otro CP está en el estado Activo, y la versión de firmware de este CP es incompatible con la versión de firmware del CP Activo. El otro CP está en estado Activo, y el proyecto de este CP es diferente del proyecto del CP Activo. Además de ir hacia el estado No-Configurado, una solicitud de configuración se hace. De esta forma, después que los proyectos se sincronicen, el CP sale automáticamente del estado No-Configurado hacia el estado Inicializando. Esta condición no se evalúa si la sincronización automática de proyectos está deshabilitada (ver sección Deshabilitación de la Sincronización de Proyectos). Transición 3 - Inicializando Hacia Inactivo Módulo NX4010 no detectado en el bus, o falla en su microprocesador. Algunos de los canales de sincronismo está en falla (NETA o NETB), y este CP sabe que esta falla ha sido causada por componentes de hardware o software internos (fallas internas de NETA o NETB). El otro CP está en estado Activo. Sin embargo, no es posible sincronizar los datos redundantes o la lista de forzamientos redundantes. El estado del otro CP no se puede descubrir por NETA / NETB, pero este CP consigue monitorear tráfico en alguna de las redes PROFIBUS configurada en modo de falla vital. De esta forma, parece que el otro CP está controlando el proceso, aunque NETA / NETB no estén funcionando para asegurarse de esto. Transición 4 - Inicializando Hacia Activo El otro CP se encuentra en estado No-Activo. Antes de hacer esta transición, esta condición debe permanecer verdadera durante algún tiempo. Cuando el CPA y CPB se energizan simultáneamente, el CP que termine la inicialización del sistema antes asume como Activo. El estado del otro CP no se puede descubrir por NETA / NETB, y además este CP no consigue monitorear tráfico en ninguna de las redes PROFIBUS configuradas en modo de falla vital, o entonces no posee ninguna red PROFIBUS configurada en modo de falla vital. Por lo tanto, parece realmente que el otro CP está desconectado o fuera de ejecución. Por razones de seguridad, además de conmutar hacia Activo, este CP desconectará el otro CP utilizando su relé del PX2612. Esta condición se debe mantener durante algún tiempo antes de hacer esta transición. 256 6. Redundancia con UCP NX3030 Transición 5 - Inicializando Hacia Reserva El otro CP se encuentra en estado Activo y los servicios de sincronización de datos redundantes y de sincronización de la lista de forzamientos redundantes están funcionando correctamente. Transición 6 - Inactivo Hacia No-Configurado Este CP ha sido desconectado o reinicializado (Reset a caliente, Reset a Frío o Reset Origen) o su UCP entró en Modo Stop. El botón STAND-BY ha sido presionado en el PX2612. Además de ir hacia el estado NoConfigurado, una solicitud de configuración se hace. De esta forma, el CP sale automáticamente del estado No-Configurado hacia el estado Inicializando. El usuario típicamente aprieta este botón después de reparar una falla que llevó el CP anteriormente al estado Inactivo. Este CP está con la sincronización deshabilitada y el proyecto está diferente del CP Activo, al presionar el botón STAND-BY, el CP va de inactivo hacia No-Configurado. Transición 7 - Activo Hacia No-Configurado Este CP ha sido desconectado o reinicializado (Reset en Caliente, Reset en Frío o Reset Origen) o su UCP entró en Modo Stop. Transición 8 - Activo Hacia Inactivo Módulo NX4010 no detectado en el bus, o falla en su microprocesador. Además, este CP sabe que el otro CP estaba en estado Reserva antes de que esta falla ocurra. Esta condición no se evalúa en los primeros 2 segundos en estado Activo. Este CP perdió comunicación con el otro CP por NETA y NETB debido a una falla interna, pero sabe que el otro CP estaba en estado Reserva poco antes de que esta falla ocurra. Esta condición no se evalúa en los primeros 2 segundos en estado Activo. Este CP no consigue controlar todas las redes PROFIBUS configuradas en modo de falla vital, y sabe que el otro CP está en estado Reserva. Esta condición no se evalúa en los primeros 2 segundos en estado Activo. Transición 9 - Activo Hacia Reserva Los dos CPs, por algún motivo, están en el estado Activo, y este conflicto se debe resolver. El CPA conmutará hacia el estado Reserva en caso de que este conflicto dure cierto tiempo, y el CPB hará lo mismo después de un tiempo diferente, que es menor que el tiempo del CPA. De esta forma, en caso de conflicto, el CPA tiene prioridad para seguir en estado Activo. El botón STAND-BY ha sido presionado, y este CP sabe que el otro CP se encuentra en el estado Reserva. Esta condición no se evalúa en los primeros 2 segundos en estado Activo. Transición 10 – Reserva Hacia No-Configurado Este CP ha sido desconectado o reinicializado (Reset en Caliente, Reset en Frío o Reset Origen) o su UCP entró en Modo Stop. El otro CP se encuentra en estado Activo y el proyecto de este CP es diferente del proyecto del CP Activo. Además de ir hacia el estado No-Configurado, una solicitud de configuración se hace. De esta forma, después que los proyectos se sincronicen, el CP sale automáticamente del estado NoConfigurado hacia el estado Inicializando. Esta condición no se evalúa si la sincronización automática de proyectos está deshabilitada (ver sección Deshabilitación de la Sincronización de Proyectos). El otro CP está en el estado Activo, y la versión de firmware de este CP es incompatible con la versión de firmware del CP Activo. Transición 11 – Reserva Hacia Inactivo Módulo NX4010 no detectado en el bus, o falla en su microprocesador. 257 6. Redundancia con UCP NX3030 El botón INACTIVE ha sido presionado en el PX2612. Esto se hace típicamente para ejecutar un mantenimiento programado en el CP No-Activo. Se debe evitar hacer mantenimientos programados en el CP Reserva, por ello, antes es aconsejable conmutarlo hacia Inactivo. El otro CP se encuentra en estado Activo. Sin embargo, el servicio de sincronización de datos redundantes no funcionó correctamente en los últimos cuatro ciclos de la MainTask, o el servicio de sincronización de diagnósticos redundantes no funcionó correctamente en los últimos dos ciclos de esta. El otro CP se encuentra en estado Activo. Sin embargo, este CP no consigue monitorear tráfico PROFIBUS en todas las redes configuradas en modo de falla vital. El otro CP se encuentra en estado Activo. Sin embargo, este CP detectó falla en las puertas Ethernet configuradas en modo de falla vital. Transición 12 – Reserva Hacia Activo El estado del otro CP es desconocido debido a fallas en NETA y NETB. En este caso, más allá de ir hacia el estado Activo, por seguridad, este CP desconecta al otro CP usando el relé del PX2612. Cuando la Redundancia no usa el panel PX2612 y no existe red PROFIBUS DP, esta condición no se genera, permaneciendo el CP en estado Reserva. En esta condición, en el caso de que la falla haya sido generada por el otro CP, para volver a controlar el proceso, es necesario ejecutar el comando para pasar el CP hacia el estado Inactivo y después, el comando para pasar el CP al estado Reserva. Al ejecutarse esta secuencia, este CP asumirá el estado Activo. El estado del otro CP se conoce y es diferente de Activo. Primeros Instantes en Estado Activo Si la aplicación utiliza el Panel de PX2612, en los primeros 2 segundos en estado Activo, según ya se describió en la sección Funciones del Panel de Comando de Redundancia PX2612, el LED ACTIVE comienza a parpadear, y sólo después de este tiempo se enciende. En los casos en que no se utiliza el painel PX2612, este comportamiento se puede observar en los diagnósticos de la redundancia, en la variable que refleja el estado del LED. Mientras el LED ACTIVE está parpadeando, diversas transiciones que normalmente podrían retirar al CP del estado Activo no se evalúan (ver subsecciones anteriores que definen transiciones a partir del estado Activo). Por ejemplo, durante este tiempo, no es suficiente apretar el botón STAND-BY para intentar hacer que el CP vaya hacia el estado Reserva. Sólo dos condiciones permiten que el CP salga del estado Activo mientras el LED ACTIVE está parpadeando. Estas condiciones están a continuación: 1. Este CP ha sido desconectado o reinicializado (Reset en Caliente, Reset en Frío o Reset Origen) o su UCP entró en el Modo Stop, lo que causa transición para No-Configurado. 2. Los dos CPs, por algún motivo, están en el estado Activo, y este conflicto se debe resolver. El CPA conmutará hacia el estado Reserva en caso de que este conflicto dure cierto tiempo, y el CPB hará lo mismo después de un tiempo diferente, que es menor que el tiempo del CPA. De esta forma, en caso de conflicto, el CPA tiene prioridad para seguir en estado Activo. Además, en los primeros instantes que un CP asume el estado Activo, algunos diagnósticos que no son redundantes pueden no ser válidos, por ejemplo, los diagnósticos de los módulos NX5000 y NX5001. El procedimiento para no considerar estos diagnósticos posiblemente “no válidos” se describe el sección Lectura de Diagnósticos No-Redundantes. Fallas más Comunes Causadoras de Switchovers Automáticos entre Half-Clusters En esta sección, se presentan las fallas más comunes que, de forma automática, causan un switchover del CP Activo para No-Activo, y del CP Reserva para Activo. Estas fallas disparan un subconjunto de las transiciones examinadas en la sección Transiciones entre Estados de Redundancia. 258 6. Redundancia con UCP NX3030 Falta de alimentación en el CP Activo. Es importante que los dos CPs tengan sistemas de alimentación redundantes, para que una falla común en la alimentación no afecte también el CP Reserva. Falla en la fuente de alimentación NX8000 del CP Activo. Falla en el bus del bastidor (NX9001, NX9002 o NX9003) del CP Activo. Fallas en la UCP NX3030 del CP Activo, tales como: o o o o Watchdog Reinicialización (Reset a Caliente, Reset a Frío o Reset Origen) Parada (Stop) Falla en las interfaces de bus en uno o ambos canales de sincronismo NETA y NETB Fallas en el NX4010 del CP Activo, tales como: o Módulo no reconocido en el bus por la UCP NX3030. o Falla en el microprocesador del NX4010, que impiden actualización de los diagnósticos internos de NETA / NETB y del panel de control PX2612 (botones, LEDs y relé). o Fallas internas que afectan a uno o ambos canales de sincronismo NETA y NETB. Falla total de una red PROFIBUS en el CP Activo, en caso de que esta red esté configurada en modo vital. En caso de que la red PROFIBUS sea redundante, ambas redes que la componen deben estar en falla (doble falla). Falla total de una red Ethernet en el CP Activo, en el caso de que esta red esté configurada con vital. En el caso de que la red Ethernet sea redundante, ambas redes que la componen deben estar en falla (doble falla). Fallas Asociadas a Switchovers entre Half-Clusters Gerenciados por el Usuario Entre las transiciones examinadas en la sección Transiciones entre Estados de Redundancia, algunas posibilitan que el usuario maneje switchovers entre half-clusters, debido a fallas que normalmente no generan switchovers de forma automática. Existen casos muy particulares, que dependen de la filosofía de cada cliente. Fíjese en un ejemplo en que el sistema SCADA pierde comunicación con el CP Activo, pero se mantiene comunicando con el CP Reserva. Algunos clientes podrán preferir un switchover manual, en el cual el operador presiona el botón STAND-BY del PX2612, hacia el CP Activo. El switchover provoca la retomada de la comunicación con el nuevo CP Activo. Una solución alternativa sería provocar el switchover al enviar un comando del SCADA hacia el CP Reserva, lo que lo repasaría al CP Activo por NETA / NETB, usando las estructuras de datos RedCmdLocal (CP Reserva) y RedCmdRem (CP Activo) para transportar un comando equivalente al botón STAND-BY del PX2612. También sería posible que el propio CP Activo detectara su pérdida de comunicación con el SCADA, y activara un comando en RedCmdLocal, equivalente al botón STAND-BY del PX2612. Esta sería una solución totalmente automática y sin intervención del operador, que típicamente se implementaría en la POU ActivePrg. A través de estructuras de datos como las presentadas en la sección Estructuras de Datos de Diagnósticos, Comandos y Usuario, es posible cambiar diagnósticos y comandos entre los halfclusters por NETA y NETB y, de esta forma, el usuario puede ejecutar gerenciamientos especiales de redundancia, para fallas que normalmente no causarían switchovers. Más detalles sobre estas estructuras de datos se presentarán en las secciones: Estructura de Diagnósticos de la Redundancia Comandos de la Redundancia Informaciones del Usuario Cambiados entre CPA y CPB 259 6. Redundancia con UCP NX3030 Abajo se ilustra cómo el usuario puede administrar e ejecutar un switchover debido a un error en las interfaces Ethernet de lo CP Activo (el código debe ser utilizado en la POU ActivePrg): //Verifica se NIC Teaming está habilitado o no. IF ((DG_NX3030.tDetailed.Ethernet.NET1.szIP = '0.0.0.0') OR (DG_NX3030.tDetailed.Ethernet.NET2.szIP = '0.0.0.0')) THEN //NIC Teaming habilitado: error en dos NETs para ejecutar switchover. IF (DG_NX3030.tDetailed.Ethernet.NET1.bLinkDown AND DG_NX3030.tDetailed.Ethernet.NET2.bLinkDown) THEN //Coloca el CP Local en Reserva. DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal := TRUE; END_IF ELSE //NIC Teaming deshabilitado: error en una NET para ejecutar switchover. IF (DG_NX3030.tDetailed.Ethernet.NET1.bLinkDown OR DG_NX3030.tDetailed.Ethernet.NET2.bLinkDown) THEN //Coloca el CP Local en Reserva. DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal := TRUE; END_IF END_IF ATENCIÓN: Cuando dos interfaces forman uno par NIC Teaming, la interfaz inactiva siempre tene la dirección de IP 0.0.0.0. Esto no es una dirección de IP válida y no es posible configurar manualmente una interfaz con esta dirección. Tolerancia a Fallas El objetivo principal de un CP redundante es el aumento de la disponibilidad del sistema. La disponibilidad es la razón entre el tiempo en que el sistema está funcionando correctamente y el tiempo total desde la implantación del sistema. Por ejemplo, si un sistema se implantó hace 10 años, y durante este tiempo estuvo parado debido a fallas por un año, entonces su disponibilidad fue de sólo de un 90%. Disponibilidades a este respecto son generalmente inaceptables para sistemas críticos, siendo que valores del orden de 99,99% o aun superiores se pueden solicitar en estos sistemas. Para alcanzar disponibilidades de este tipo, se deben cumplir varias estrategias: Utilización de componentes más confiables (con alto MTBF, o tiempo promedio entre fallas), lo que contribuirá para el aumento del MTBF del sistema como un todo. Utilización de redundancia por lo menos para los componentes más críticos o componentes con menor MTBF, de tal forma que la falla de un componente se pueda tolerar sin parar el sistema. Si la redundancia se implementa a través de la duplicación de componentes, será necesario que los dos fallen para que el sistema como un todo se vuelva indisponible. Gran cobertura de diagnósticos, en especial de componentes redundantes. La redundancia de componentes es poco útil para el aumento de la disponibilidad cuando no se puede descubrir que un componente redundante ha fallado. En este caso, la primera falla en uno de los componentes aun no compromete el sistema, pero por permanecer oculta, algún día ocurrirá la segunda falla que comprometerá el sistema, ya que la primera falla aún no se ha reparado. Las fallas pueden ser clasificadas entre diagnosticables y ocultas, siendo altamente deseable que todas las fallas de componentes redundantes sean diagnosticables. También es importante que componentes no redundantes tengan amplia cobertura de diagnósticos, pues muchas veces el sistema puede seguir funcionando aun con la falla de un componente no redundante. Puede que el componente no se esté solicitando. Por ejemplo, un relé con contacto abierto, que raramente tiene su bobina accionada, no tiene su falla detectada hasta el momento en que el sistema solicite su cierre. Bajo tiempo de reparo de componentes no redundantes. La falla de un componente no redundante puede comprometer el sistema, y durante el reparo, el sistema estará indisponible. 260 6. Redundancia con UCP NX3030 Posibilidad de reparar o sustituir un componente redundante sin parar el sistema. Si esta posibilidad existe, se obtiene un gran aumento de disponibilidad. De lo contrario, se debe programar una parada del sistema para sustituir el componente, y el tiempo de reparo cuenta como tiempo indisponible. Bajo tiempo de reparo de componentes redundantes. La falla de un componente redundante no compromete el sistema, pero durante su reparo, eventualmente puede ocurrir una falla en su par redundante. Por este motivo, es importante que la falla sea reparada brevemente, enseguida de los diagnósticos. Cuanto mayor el tiempo de reparo, mayor la probabilidad de que ocurra una segunda falla en el componente redundante durante el reparo de la primera falla, lo que comprometería el sistema. Por lo tanto, cuanto mayor el tiempo de reparo, menor la disponibilidad del sistema. Programar tests off-line periódicos en componentes para detectar fallas no diagnosticables automáticamente por el sistema. El objetivo es detectar fallas ocultas, especialmente en componentes redundantes o componentes simples que no se estén solicitando (por ejemplo, un relé de seguridad). Tests off-line a veces implican en paradas en el sistema, lo que disminuye la disponibilidad. Normalmente se aprovechan ocasiones especiales, así como paradas programadas de mantenimiento de la planta. Cuanto mayor el periodo entre tests off-line, mayor el tiempo en que una falla puede permanecer oculta, y por lo tanto mayor la probabilidad de que una falla comprometa el sistema, o sea, menor la disponibilidad del sistema. Estos principios se consideraron en el proyecto de CPs redundantes con UCP NX3030. Las próximas subsecciones analizan distintos tipos de fallas y como se toleran o no, y si existen switchovers asociados a las fallas toleradas. Fallas Simples con Indisponibilidad Algunos componentes, por el hecho de que son duplicados, no toleran ni siquiera falla simple sin causar algún tipo de indisponibilidad. En un CP redundante con UCP NX3030, estos son los siguientes componentes: Remotas (esclavos) PROFIBUS en una red PROFIBUS no redundante Remotas (esclavos) Ethernet en red Ethernet no redundante Módulos de E/S La intolerancia a fallas de una red PROFIBUS no redundante se puede resolver al optar por una red PROFIBUS redundante, que se aconseja en sistemas que demandan alta tolerancia a fallas. La Figura 6-1 muestra un ejemplo de arquitectura con una red PROFIBUS redundante. De la misma forma, la intolerancia a fallas de una red Ethernet no redundante se puede resolver al usar una red Ethernet redundante con la configuración de NIC Teaming. Cuanto a la indisponibilidad de un módulo de E/S, se debe observar que la esta no se constituye en una indisponibilidad total del sistema, sino que se constituye en una indisponibilidad parcial, solamente de las mallas de control que utilizan este módulo de E/S. Aunque no haya previsión de redundancia de módulos de E/S, la aplicación del usuario puede administrarla, en casos especiales. Por ejemplo, el usuario puede insertar tres módulos de entradas analógicas en tres remotas PROFIBUS diferentes, e implementar un esquema de votación entre triples de entradas analógicas, para algún sistema crítico. Sin embargo, dichas soluciones, como se dijo anteriormente, se deben administrar por el usuario. No existe ningún soporte automático para estas. Dichas soluciones, en general, también conllevan en la redundancia de transductores y actuadores en el campo. Fallas Simples sin Indisponibilidad Causando un Switchover Algunos componentes redundantes toleran fallas simples sin causar indisponibilidad, pero causan switchover: Bastidores (NX9001, NX9002 o NX9003) Fuentes de alimentación (NX8000) 261 6. Redundancia con UCP NX3030 UCPs (NX3030) Módulo NX4010 Módulos NX5001 (maestros PROFIBUS) en configuración de red PROFIBUS no redundante Módulos NX5000 (Ethernet) en configuraciones sin NIC Teaming Interfaz esclavo PROFIBUS de una remota redundante (PO5063V5, PO5065 o AL-3416). En este caso, diferente de los anteriores, el switchover sucede dentro de la remota, entre las redes PROFIBUS A y B. ATENCIÓN: En el caso de falla de la UCP NX3030 o del módulo NX4010 en arquitecturas en la cual no se utiliza panel PX2612 ni red PROFIBUS, el CP permanecerá en el estado actual. En este caso, si la falla ocurre en el half-cluster Activo, ocurre indisponibilidad del sistema. Fallas Dobles sin Indisponibilidad Causando un Switchover Algunos componentes se duplican en cada half-cluster, de esta forma, antes de causar un switchover, es necesario que ambos fallen: Módulos NX5001 (maestros PROFIBUS) en configuración redundante, configurados en modo de falla vital. Módulos NX5000 (Ethernet) en configuraciones con NIC Teaming (redundancia gerenciada por el usuario). Overhead de la Redundancia Una aplicación redundante causa un aumento en el tiempo de procesamiento de una aplicación, cuando comparado al tiempo necesario para una aplicación equivalente no redundante. Este tiempo adicional se debe principalmente a la ejecución de los servicios de sincronización cíclicos, descritos en la sección Servicios de Sincronización Cíclicos a través de NETA y NETB, además de un tiempo menor para el propio gerenciamiento de la redundancia (máquina de estados, etc.). El tiempo adicional total, debido a la redundancia (overhead de la redundancia), se estima por el MasterTool y se exhibe en la ventana de Mensajes, tras compilar el proyecto del CP redundante. ATENCIÓN: El overhead calculado por el MasterTool considera una lista de forzamientos de variables redundantes vacía. Al usuario le cabe definir un intervalo para la MainTask que arregle: El tiempo adicional para redundancia estimado por el MasterTool. El tiempo necesario para ejecutar las POUs principales (NonSkippedPrg y ActivePrg). Este tiempo normalmente se mide tras el desarrollo del proyecto (al descontar el tiempo adicional para redundancia). Alguna holgura del ciclo de MainTask, para ejecución de otras tareas de la UCP (sistema operacional, I/O drivers PROFIBUS, MODBUS, etc.). El porcentaje de esta holgura puede variar según el desempeño solicitado de estas otras tareas. Por ejemplo, si la comunicación MODBUS con el sistema SCADA necesita ubicar mucho procesamiento para alcanzar un desempeño satisfactorio, esta holgura se deberá aumentar. ATENCIÓN: Dependiendo de la alineación de memoria, el número de bytes utilizados en el cálculo del overhead de redundancia podrá ser mayor que el total de bytes declarados en las variables. 262 6. Redundancia con UCP NX3030 Programación de un CP Redundante Wizard para Creación de un Nuevo Proyecto Redundante Para crear un nuevo proyecto redundante, se debe utilizar el comando Archivo / Nuevo Proyecto, y seleccionar el Proyecto MasterTool Estándar. Inicialmente, el usuario debe informar el nombre que desea darle al proyecto y el directorio en el cual desea almacenarlo, según muestra la Figura 6-15: Figura 6-15. Nuevo Proyecto A continuación, el Wizard que genera el proyecto de redundancia realiza algunos cuestionamientos al usuario cuanto a la configuración que se desea, los cuales se deben contestar sucesivamente. El primer punto a definir es la configuración inicial de hardware del half-cluster: Seleccionar el modelo de la UCP: Como la redundancia está implementada solamente en la NX3030, esta la debe seleccionar el usuario. Seleccionar el modelo del rack: Existen tres opciones de bastidores disponibles y la elección de este dependerá de la cantidad de módulos utilizados en la redundancia. El MasterTool define el tamaño del rack según la cantidad de redes configuradas (próximo ítem del Wizard). Seleccionar el modelo de la fuente de alimentación. Seleccionar la configuración de la redundancia. Para un proyecto redundante es necesario elegir la opción Con Redundancia. Seleccionar el modo de operación de la redundancia. En este caso, las opciones son operación con panel de redundancia (PX2612) o sin él. Seleccionar si la opción de comunicación OPC estará habilitada o no. Seleccionar si se usará redundancia en la expansión de bus o no. 263 6. Redundancia con UCP NX3030 Figura 6-16. Configuración Inicial de Hardware Enseguida, el usuario debe definir las redes de comunicación utilizadas en la aplicación redundante: Seleccionar el número de redes PROFIBUS: En el Wizard es posible es posible la creación de hasta cuatro redes PROFIBUS, sean simples o redundantes. Es importante resaltar que el Wizard sólo propone la creación de arquitecturas típicas de aplicación. Tras la conclusión del Wizard, el MasterTool, és posible la configuración de más redes PROFIBUS, redundantes o únicas, respectando el límite de cuatro módulos en cada half-cluster. Seleccionar el tipo de las redes PROFIBUS: o No existe (ningún módulo NX5001 ubicado) o Red única (ubica un módulo NX5001) o Red redundante (ubica dos módulos NX5001) Seleccionar el número de redes Ethernet: En este caso el Wizard posibilita al usuario crear hasta cuatro redes simples, o tres redundantes, o ninguna. Es importante resaltar que esta configuración sólo se indica mediante el Wizard, que sólo propone arquitecturas típicas. Tras terminar el Wizard, el MasterTool permite la creación de más redes Ethernet, mientras se respete el límite de seis módulos en cada half-cluster. Seleccionar el tipo de red Ethernet: o No existe (ningún módulo NX5000 asignado) o Red simple con modo de falla deshabilitado (ubica un módulo NX500 y no genera switchover en caso de falla) o Red simple con modo de falla habilitado (ubica un módulo NX5000 y genera switchover en caso de falla) o Red redundante con modo de falla deshabilitado (ubica dos módulos NX5000 y no genera switchover en caso de falla) o Red redundante con modo de falla habilitado (ubica dos módulos NX5000 y genera switchover en caso de falla) 264 6. Redundancia con UCP NX3030 Figura 6-17. Configuración de las Redes de Comunicación Entonces, se debe seleccionar el perfil de proyecto y el lenguaje estándar para la creación de los programas: Seleccionar el perfil del proyecto: Solamente es posible utilizar el perfil de proyecto Single para la redundancia, enseguida la opción de selección se deshabilita. Seleccionar el lenguaje estándar para todos los programas: El lenguaje seleccionado por el usuario será el estándar para todos los programas, sin embargo puede optar por utilizar otro cualquiera para una POU específica. Figura 6-18. Perfil de Proyecto y Lenguaje Estándar Para finalizar, el usuario debe seleccionar el lenguaje de programas comunes y asociados a la redundancia: Programa asociado a la MainTask (MainPrg): Deberá ser, obligatoriamente, en lenguaje ST, siendo que el MasterTool deshabilita las demás opciones. Programas asociados a las tareas principales de la redundancia. 265 6. Redundancia con UCP NX3030 Figura 6-19. Lenguaje de los Programas Específicos ATENCIÓN: Las POUs ActivePrg e NonSkippedPrg se crean automáticamente, vacías, en el lenguaje seleccionado en las preguntas anteriores. En POUs creadas manualmente por el usuario, se podrá utilizar cualquiera de los lenguajes disponibles, excepto en POUs redundantes, que no se pueden escribir en el lenguaje SFC, pues esta utiliza el timer IEC en segundo plan. Para más informaciones, ver la sección Limitaciones en la Programación de un CP Redundante. ATENCIÓN: La POU MainPrg siempre se generará automáticamente en lenguaje ST, y el usuario no lo puede alterar. Esta POU llama a las POUs ActivePrg (solamente en el CP Activo) y NonSkippedPrg (en ambos CPs). Después de obtener respuestas para las preguntas anteriores, el Wizard genera el proyecto inicial y define un half-cluster con la siguiente configuración inicial de hardware: Bastidor seleccionado Fuente de alimentación (posiciones 0 y 1) UCP NX3030 (posiciones 2 y 3) Módulo NX4010 (posiciones 4 y 5) y Panel PX2612, en caso que ha sido seleccionado. Después del módulo NX4010, se insertan los módulos NX5001 necesarios para implementar la red PROFIBUS con las características definidas antes por el usuario. Enseguida de los módulos NX5001, se insertan los módulos NX5000 necesarios para la implementar la red Ethernet con las características definidas anteriormente por el usuario. Configuración de los Half-Clusters El Wizard siempre se utiliza para generar la primera versión de un proyecto redundante. Esto garantiza que la versión inicial del proyecto se genere rápida y correctamente. Sin embargo, es posible que algunas modificaciones sean necesarias en un half-cluster, tal como la inserción de nuevos módulos NX5001 y NX5000, que se pueden hacer al alterar la pantalla de configuración del half-cluster. Los capítulos a continuación muestran como añadir y configurar los módulos NX5000, NX5001 y NX4010. 266 6. Redundancia con UCP NX3030 Algunas reglas y precauciones se deben seguir para un proyecto redundante, según describe la siguiente sección. Configuración Fija en las Posiciones 0 a 5 del Bastidor En las posiciones 0 a 5 del bastidor seleccionado siempre se deben instalar los siguientes módulos: Fuente de alimentación (posición 0) UCP NX3030 (posición 2) Módulo NX4010 (posición 4) Estos módulos no se deben remover del proyecto original generado por el Wizard. Cualquier configuración diferente en estas posiciones resultará en un error notificado por el MasterTool en la compilación del proyecto. Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2) Configuración de la Dirección de IP La Figura 6-20 muestra las configuraciones de la puerta NET 1 de la UCP NX3030 (la pantalla para configuración de la puerta NET 2 contiene un subconjunto de estos parámetros). Para abrir esta pantalla, se debe dar un doble clic sobre NET 1 o NET 2, abajo de la UCP NX3030 en el árbol de dispositivos. Figura 6-20. Parámetros de la Puerta Ethernet NET 1 A continuación se deben editar los parámetros básicos para las interfaces NET 1 y NET 2. El direccionamiento será según el método Active IP, según está descrito en Principios de Funcionamiento - Métodos de Cambio de IP. ATENCIÓN: Las dos direcciones IP de las interfaces NET 1 y NET 2, bien como la Dirección del Gateway, deben pertenecer a la misma subred. ATENCIÓN: La pantalla de configuración de NET 2 posee la misma estructura de la pantalla de configuración de la NET 1, sin embargo no contiene la opción de configuraciones avanzadas, o sea, los parámetros del NIC Teaming. 267 6. Redundancia con UCP NX3030 NIC Teaming entre NET 1 y NET 2 La opción Avanzado, en la pantalla de configuración de la interfaz NET 1, abre una nueva pantalla de configuración, la cual define si NET 1 será redundante. En caso de que el checkbox de Redundancy of Communication se marque, las interfaces NET 1 y NET 2 formarán un par redundante con NIC Teaming, según lo descrito en la sección Principios de Funcionamiento - Redes Ethernet Redundantes con NIC Teaming. Automáticamente, otros parámetros se habilitarán y se deberán configurar: Período de Testeo de la Redundancia (ms): Periodo de envío del frame de teste de comunicación entre las dos NETs. Se puede configurar con valores entre 100 y 9900; Número de Reintentos de Testeo de la Redundancia: Número máximo de veces que la NET que envió el frame esperará por la respuesta. Se puede configurarlo con valores entre 1 y 100; Período para Conmutación (s): Tiempo máximo que la NET Activa esperará por un paquete cualquiera. Se puede hacer la configuración con valores entre 1 y 25. Figura 6-21. Configuraciones Avanzadas de la Ethernet En caso de que el tiempo de respuesta del Teste de Redundancia alcance el Periodo de Teste veces el Número de Reintentos y la interfaz activa permanezca por un tiempo mayor que el Periodo para Conmutación sin recibir ningún paquete, ocurrirá un switchover, volviendo activa la interfaz que hasta entonces estaba inactiva. Es importante destacar que hay un retardo entre una detección de fallos y la activación de la interfaz inactiva debido al tiempo requerido para su configuración. Este retardo puede llegar a varias decenas de milisegundos. Cuando una de las NETs esté activa, esta asumirá la dirección de IP configurado, permaneciendo la NET inactiva con sus parámetros de Dirección de IP, Máscara de Subred y Dirección del Gateway en blanco en los diagnósticos de la UCP. ATENCIÓN: Cuando un comando de Reset Origin es ejecutado en una UCP con NIC Teaming configurado en las interfaces frontales NET1 y NET2, solamente la interfaz que estaba activa antes del comando seguirá asequible. Después del comando, se puede ver la interfaz habilitada en el Menú Informativo y de Configuración de la UCP. Configuración de falla vital en NET 1 y NET 2 La opción Avanzado, en la pantalla de configuración de las interfaces NET 1 y NET2, abre una pantalla de configuración donde más allá de habilitar la redundancia de comunicación también es posible configurar si la interfaz genera un switchover en caso de falla en la interfaz, según lo descrito en Principios de Funcionamiento - Uso de Interfaces Ethernet con Indicación de Falla Vital. Cuando configurada en conjunto con la redundancia NIC Teaming, la falla vital se considerará al ocurrir falla en las interfaces NET1 y NET2. 268 6. Redundancia con UCP NX3030 Configuraciones de los Módulos NX5001 Inserción o Remoción de Módulos NX5001 Se pueden insertar o remover módulos NX5001 en el bastidor del half-cluster. Para ejecutar esta operación de forma correcta, se debe tener conciencia de las siguientes reglas: El número de módulos NX5001 en cada half-cluster puede variar entre cero y cuatro. Se puede definir un máximo de 4 redes PROFIBUS simple o 2 redes PROFIBUS redundantes, respetando el límite de 4 módulos maestro PROFIBUS NX5001 en cada half-clúster Cuando una red PROFIBUS es simple, necesita un único módulo NX5001 en cada half-cluster. Cuando es redundante, necesita 2 módulos NX5001 en cada half-cluster. Dos módulos NX5001 utilizados para componer una red PROFIBUS redundante deben ocupar posiciones vecinas en el bastidor. La cantidad de módulos NX5001 en el bastidor debe ser compatible con el número de redes PROFIBUS existentes, y con el atributo de redundancia de cada red, es decir: o 0 x NX5001: Ninguna red PROFIBUS o 1 x NX5001: Una red PROFIBUS simple o 2 x NX5001: En este caso hay dos opciones: Dos redes PROFIBUS simple Una red PROFIBUS redundante o 3 x NX5001: En este caso hay dos opciones: Tres redes PROFIBUS simple Una rede PROFIBUS simple y una red PROFIBUS redundante o 4 x NX5001: En este caso hay tres opciones: Cuatro redes PROFIBUS simple Dos redes PROFIBUS simple e una red PROFIBUS redundante Dos redes PROFIBUS redundantes Después de insertar o remover módulos NX5001, se debe revisar la configuración de los módulos NX5001 que quedaron en el bastidor. Ajuste de Parámetros de los Módulos NX5001 Cada módulo NX5001 utilizado en una red PROFIBUS simple, o cada par redundante de NX5001 utilizado en una red PROFIBUS redundante, posee los siguientes parámetros que se deben ajustar: 269 6. Redundancia con UCP NX3030 Figura 6-22. Parámetro de Redundancia NX5001 Para agrupar dos módulos NX5001 en una red PROFIBUS redundante, se debe hacer un doble clic en un módulo NX5001 desagrupado que tenga otro módulo NX5001 también desagrupado a su derecha en el bastidor. A continuación, se debe marcar como verdadero (TRUE) el parámetro “Redundancia de Red” disponible en la pestaña “Parámetros del Módulo”, según muestra la Figura 6-22. Para desagruparlos, basta seguir el mismo procedimiento, pero marcando el parámetro como falso (FALSE). Si este parámetro está marcado como verdadero (TRUE), los parámetros DP y parámetros del módulo NX5001 a su derecha estarán bloqueados para edición. ATENCIÓN: En caso de redes redundantes, se debe ajustar sólo los parámetros del NX5001 presente más a la izquierda en el bus, mientras los parámetros del NX5001 de la derecha permanecen bloqueados para edición. Algunos parámetros de una red son idénticos a los de la otra, mientras que otros se calculan automáticamente a partir de los parámetros de la red del NX5001 de la izquierda. Se aconseja que la dirección configurada para un maestro NX5001 en un CP redundante sea 2, pues la dirección del maestro NX5001 en el CP No-Activo se decrementa en uno, por lo tanto la dirección del maestro NX5001 quedaría 1. Además, recuérdese que: Las direcciones de 3 a 125 son generalmente utilizadas para esclavos PROFIBUS. La dirección 0 es frecuentemente utilizada para configuración y diagnósticos de los dispositivos. La dirección 1, en especial, se reserva para asumirse, dinámicamente, por el maestro PROFIBUS en el CP No-Activo (maestro PROFIBUS en modo pasivo). La dirección 126 es muy utilizada por dispositivos esclavos cuando salen de la fábrica. La dirección 127 se utiliza para enviar frames en broadcast. En la próxima compilación del proyecto, el MasterTool verificará posibles errores que el usuario pueda haber cometido al insertar o remover módulos NX5001 manualmente. Importante resaltar que, durante la ejecución de un proyecto redundante configurado con módulos NX5001, el bit 0 de Comandos (Canal Enable Interfaz %QXn.0 en la pestaña Bus: Mapeo de E/S) se 270 6. Redundancia con UCP NX3030 maneja por la aplicación redundante. Las interfaces deben permanecer habilitadas durante toda la ejecución del programa. De esta forma, un comando ejecutado por el usuario para deshabilitar una interfaz no se ejecutará de la forma que se puede esperar. Por ejemplo: si una interfaz tiene el estado de este bit alterado de TRUE a FALSE en un CP Activo, eso no se interpretará como una falla que llevaría el CP Activo hacia el estado Inoperante. En este caso, el CP Activo permanecerá Activo y el otro CP irá hacia el estado Inoperante. Por estas razones, este bit de comando no debe ser manejado por el usuario en una aplicación redundante. Más detalles sobre la configuración de redes PROFIBUS se presentan en el Manual de utilización Maestro PROFIBUS DP NX5001. Configuraciones de Remotas PROFIBUS Para configurar remotas PROFIBUS abajo de un maestro NX5001, se debe consultar, además del Manual de Utilización Maestro PROFIBUS DP NX5001, los siguientes manuales: Manual de Utilización de la Serie Ponto Manual de Utilización Cabeza PROFIBUS PO5063V1 y Cabeza Redundante PROFIBUS PO5063V5 Manual de Utilización Cabeza PROFIBUS PO5064 y Cabeza Redundante PROFIBUS PO5065 Manual de Utilización Red HART sobre PROFIBUS. Para uno sistema redundante debe ser consciente en la configuración del parámetro de watchdog de la remota. Si, en la pantalla de configuración de la remota, el checkbox de “Controlo de Watchdog” está habilitado, el campo “Tiempo” debe ser correctamente configurado. Existen dos opciones de configuración y el tiempo utilizado debe ser el mayor tiempo entre: WT ≥ I x 2 + 500ms; y WT ≥ I x 3; Donde WT es el tiempo de watchdog y I es lo intervalo de la tarea MainTask. Figura 6-23. Configuración de watchdog de la remota PROFIBUS Configuraciones de los Módulos NX5000 Inserción o Remoción de Módulos NX5000 Se puede insertar o remover módulos Ethernet NX5000 en el bastidor del half-cluster. Para ejecutar esta operación de forma correcta, se debe tener conciencia de que el número de módulos NX5000 en cada half-cluster puede variar entre cero y seis. Se debe estar atento también al hecho de que módulos que formarán un par redundante NIC Teaming se deben insertar en posiciones vecinas en el bastidor. En la próxima compilación del proyecto, el MasterTool verificará posibles errores que el usuario pueda haber cometido al insertar o remover módulos NX5000 manualmente. Por ejemplo, si el usuario insertó más que 6 módulos NX5000, habrá un error. La interfaz de cada módulo se identificará con NET 1, así como se identifican en la mecánica del producto. En caso de que el usuario añada manualmente módulos NX5000 en el bus, la identificación ocurre de la misma forma que en el Wizard. Después de insertar o remover módulos NX5000, se debe revisar la configuración de los módulos NX5000 que quedaron en el bastidor. 271 6. Redundancia con UCP NX3030 Configuración de los Módulos NX5000 Para cada módulo NX5000 en un CP redundante, se deben ajustar los parámetros de dirección, según lo descrito en la sección Principios de Funcionamiento - Métodos de Cambio de IP, los cuales se pueden acceder a través de un doble clic sobre la interfaz NET 1, en la parte inferior de cada módulo NX5000 ubicado en el árbol de dispositivos. ATENCIÓN: En caso de que dos módulos consecutivos formen un par redundante NIC Teaming, se configuran los parámetros básicos solamente del NX5000 de la izquierda, y la edición de los parámetros del NX5000 de la derecha estará bloqueada. Agrupamiento de Módulos NX5000 con Redundancia NIC Teaming Los módulos NX5000, así como la interfaz NET 1 de las UCPs NX3020 y NX3030, presentan una pantalla de configuraciones avanzadas, que definirá si el módulo formará un par NIC Teaming Redundante con el módulo a su derecha. La configuración se hace según lo descrito antes en la sección NIC Teaming entre NET 1 y NET 2. Para agrupar dos módulos NX5000 como un par redundante, la siguiente condición se debe tener en cuenta: Estos dos módulos NX5000 deben ocupar posiciones vecinas en el bastidor. Al hacer esto, el módulo a la derecha tiene la edición de sus parámetros bloqueada y los parámetros editados en el módulo a la izquierda pasan a ser comunes a los dos módulos. Al retirar la marcación, el checkbox “Redundancia de Comunicación” del módulo a la izquierda, se provoca la separación de los módulos, que vuelven a portarse como módulos individuales sin redundancia NIC Teaming. Configuración de Falla Vital Los módulos NX5000, así como las interfaces NET 1 y NET 2 permiten configurar si la interfaz genera un switchover en el caso de falla en la interfaz, según lo descrito en Principios de Funcionamiento - Uso de Interfaces Ethernet con Indicación de Falla Vital. Al estar configurado en conjunto con la redundancia NIC Teaming, la falla vital se considerará al ocurrir falla en los dos módulos del par redundante. Configuraciones del Módulo NX4010 Las configuraciones relacionadas a las variables %I, %Q y %M redundantes se pueden acceder a través de un doble clic sobre el módulo NX4010, seguido de la selección de la pestaña “Parámetros de Redundancia”. Para entender estos parámetros, se debe leer las secciones Variables %I Redundantes y No Redundantes, Variables %Q Redundantes y No Redundantes y Variables %M Redundantes y No Redundantes. Los siguientes parámetros se deben configurar: Configuración Estándar de Fábrica Descripción Posibilidades Memoria (%M) Redundancy %M memory offset Dirección inicial de la memoria %M redundante 0 Redundancy %M memory length Tamaño de la memoria %M redundante 0 Redundancy %I memory offset 0 (deshabilitado) 0 a 65536 Memoria (%I) Dirección inicial de la memoria %I redundante 272 0 0 (deshabilitado) 6. Redundancia con UCP NX3030 Redundancy %I memory length Tamaño de la memoria %I redundante Redundancy %Q memory offset reserved for I/O drivers Dirección inicial de la memoria %Q redundante reservado para drivers de entrada y salida 0 0 (deshabilitado) Redundancy %Q memory length reserved for I/O drivers Tamaño de la memoria %Q redundante reservado para drivers de entrada y salida 16384 0 a 81920 Redundancy %Q memory offset reserved for diagnostics Dirección inicial de la memoria %Q redundante reservada para la área de diagnósticos 65536 0 a 81919 Redundancy %Q memory length reserved for diagnostics Tamaño de la memoria %Q redundante reservada para la área de diagnósticos 16384 0 a 81920 16384 0 a 81920 Memoria (%Q) Tabla 6-3. Parámetros NX4010 Configuraciones de I/O Drivers La configuración de I/O drivers, en principio, no presenta diferencias en relación a un CP no redundante. Lo que se puede percibir es que algunos I/O drivers poseen comandos que permiten su uso en un CP redundante, pero esto no conlleva en diferencias de configuración de estos. Estos comandos normalmente se deben ejecutar en el programa NonSkippedPrg. Por ejemplo, un driver maestro MODBUS RTU en una red serial RS-485 se debe deshabilitar en un CP en estado No-Activo, al usar el código insertado por el usuario en NonSkippedPrg. Más informaciones sobre cómo administrar un driver MODBUS en un sistema redundante se pueden encontrar en la sección Gerenciamiento de Instancias MODBUS en Sistemas Redundantes. En el caso de la red PROFIBUS, también existen comandos especiales diferenciados para los CPs en estado Activo y No-Activo. En este caso, sin embargo, el gerenciamiento de la redundancia ejecuta dichos comandos de forma automática, sin que sea necesario cualquier gerenciamiento por parte del usuario. Para configuración de E/S remoto PROFIBUS, lo que incluye remotas y módulos de E/S, se debe consultar el Manual de utilización Maestro PROFIBUS DP NX5001, además de la sección Configuraciones de los Módulos NX5001. Configuraciones de la MainTask La pantalla de configuraciones asociadas a la única tarea de un CP redundante, denominada MainTask, la cual es cíclica, se puede acceder al hacer clic sobre MainTask en el árbol de dispositivos. Dos parámetros se deben ajustar en esta pantalla: Intervalo de la MainTask Tiempo de watchdog Además, una estimativa del tiempo necesario para gerenciamiento de la redundancia se calcula por el MasterTool. Dicha estimativa sólo es confiable después que el proyecto está completo, con todas las POUs desarrolladas, y áreas de memoria redundantes definidas. Diversas consideraciones se deben hacer para ajustar adecuadamente el intervalo de la MainTask: 273 6. Redundancia con UCP NX3030 El intervalo debe ser suficientemente bajo para controlar el proceso efectivamente, observando los tiempos de respuesta de todos los lazos de control. El intervalo debe ser suficientemente alto para acomodar, en lo mínimo, la suma de los dos siguientes tiempos: o El tiempo máximo de ejecución de las POUs NonSkippedPrg e ActivePrg, en conjunto. o El tiempo necesario para gerenciar la redundancia (overhead de la redundancia). Además, el intervalo debe tener una holgura adicional, necesaria para que otros procesos tengan tiempo de ejecutarse (comunicación PROFIBUS, comunicación Ethernet con sistemas SCADA, etc.). El MasterTool tiene condiciones de calcular el tiempo necesario para gerenciar la redundancia (overhead de redundancia), después que el proyecto está terminado (todas la POUs desarrolladas y áreas de memoria redundantes definidas). Cuanto al tiempo máximo de ejecución de las POUs NonSkippedPrg y ActivePrg, es posible medir los tiempos después que estas POUs se desarrollan. Inicialmente, el MasterTool prevé 10 ms para el tiempo máximo de estas dos POUs en conjunto, pero el usuario deberá revisar este tiempo posteriormente, en función de medidas ejecutadas usando el proyecto final. Tras cada compilación del proyecto, el MasterTool suma el overhead de redundancia calculado con el parámetro que informa los tiempos de las POUs (NonSkippedPrg y ActivePrg), y verifica si la holgura mínima parametrizada se está obedeciendo. Por ejemplo: Parámetros configurados en la pantalla de la MainTask. o Intervalo de la MainTask: 100 ms o Tiempo estimado para POUs NonSkippedPrg + ActivePrg: 10 ms o Holgura Mínima: 30% Overhead calculado para redundancia: 50 ms En este caso, el tiempo total utilizado es de 60 ms (10 ms + 50 ms), lo que consiste en 60% del ciclo de la MainTask (100 ms). De esta forma, la holgura es de 40%, y por lo tanto la holgura mínima de 30% se está respetando. ATENCIÓN: Un error de compilación se puede generar en caso de que la holgura mínima no se respete. Desde que esté configurado en los Parámetros del Proyecto de la UCP. ATENCIÓN: Habiendo éxito o no en la compilación, el MasterTool informa si la holgura se respeta y el cálculo del overhead de redundancia en la ventana de mensajes. Programa ActivePrg En esta POU el usuario debe crear la aplicación principal, responsable del control de su proceso. Esta POU es llamada por la POU principal (MainPrg), y se ejecuta sólo en el CP Activo. El usuario también puede crear POUs adicionales (programa, funciones o bloque funcional), y llamarlas o instanciarlas dentro de la POU ActivePrg, para fines de estructuración de su programa. También es posible llamar funciones e instanciar bloques funcionales definidos en bibliotecas. Se debe recordar que todas las variables simbólicas definidas en la POU ActivePrg, así como instancias de bloques funcionales definidas, serán variables redundantes. Variables simbólicas definidas en POUs adicionales del tipo programa que se llamen dentro de ActivePrg también serán variables redundantes. 274 6. Redundancia con UCP NX3030 ATENCIÓN: Variables del tipo VAR_TEMP no se deben utilizar en el programa redundante. Programa NonSkippedPrg Esta POU se destina para controles que se deben ejecutar en ambos CPs (CPA y CPB), independiente de su estado de redundancia. Esta POU también es llamada por la POU principal (MainPrg). Se debe recordar que todas las variables simbólicas definidas en la POU NonSkippedPrg, así como instancias de bloques funcionales definidas, serán variables no redundantes. El usuario también puede crear POUs adicionales, (programa, funciones o bloque funcional), y llamarlas o instanciarlas dentro de la POU NonSkippedPrg, para fines de estructuración de su programa. También es posible llamar funciones e instanciar bloques funcionales definidos en bibliotecas. ATENCIÓN: Al llamar POUs adicionales del tipo programa dentro de NonSkippedPrg, retire la marcación de estas en la ventana Redundancy Configuration del MasterTool. Por estándar las variables simbólicas declaradas dentro de estas POUs serán redundantes y, dentro de la NonSkippedPrg, normalmente se desean variables no redundantes. Normalmente el código de NonSkippedPrg es pequeño, lo que dispensa la llamada de POUs adicionales del tipo programa para su estructuración, pero, caso su estructuración sea necesaria lo más recomendable es utilizar bloque funcional o funciones. Ejemplos típicos de controles ejecutados en la NonSkippedPrg, a continuación: Crear una estructura compacta de diagnósticos (%Q) para reportar a un sistema SCADA, a partir de una estructura completa de diagnósticos, en la cual distintos diagnósticos no son de interés para el sistema SCADA. Estos diagnósticos se pueden extraer de estructuras de datos como RedDgnLoc, RedDgnRem, RedUsrLoc, RedUsrRem, etc. Copiar comandos recibidos de un SCADA para los respectivos campos de la estructura de datos RedCmdLoc, e intertrabar estos comandos si necesario. Gerenciar switchovers controlados por el usuario, en función de fallas no-vitales así como la comunicación con un sistema SCADA o con dispositivos MODBUS. Habilitar o deshabilitar algunos I/O drivers específicos, dependiendo del estado de la redundancia (Activo o No-Activo). Por ejemplo, un driver maestro MODBUS RTU en un bus RS-485 se debe deshabilitar en el CP No-Activo. Para más informaciones, consultar la sección Gerenciamiento de Instancias MODBUS en Sistemas Redundantes. ATENCIÓN: No se recomienda utilizar los bloques funcionales TOF_RET, TON_RET, TOF y TON en el programa NonSkippedPrg. Ver sección Limitaciones en la Programación de un CP Redundante. Objeto Redundancy Configuration Este objeto, localizado en el árbol de dispositivos del proyecto, es creado automáticamente por el Wizard. El es utilizado para determinar qué POUs y GVLs son redundantes, y por lo tanto sincronizadas entre los CPs. Por estándar, POUs y GVLs creadas por el usuario son marcadas como redundantes, dependiendo de él cambiarlas cuando necesario. ATENCIÓN: Los objetos PV, PIDControl y PidRetainGVL no pueden ser marcados individualmente. Caso sea necesario que estos sean alterados, debe ser marcada la opción Seleccionar Todos. 275 6. Redundancia con UCP NX3030 GVL Diagnostics Esta GVL especial se crea y se llena automáticamente por el Wizard, y el usuario no la puede modificar. Diagnósticos y comandos del sistema, inclusive de las estructuras de datos de redundancia (RedDgnLoc, RedDgnRem, RedCmdLoc, RedCmdRem), residen en variables de representación directa %Q o %I especiales. La GVL Diagnostics contiene diversas sentencias con la directiva AT para definir nombres simbólicos para estos diagnósticos y comandos. De esta forma, cuando el usuario necesite referenciar estas variables, podrá usar un nombre simbólico y no una referencia numérica. GVLs con Variables Simbólicas Redundantes El usuario puede crear otras GVLs, diferentes de las citadas anteriormente, para declarar variables simbólicas redundantes. Para esto, tras la creación de la GVL, se debe marcarla en la configuración del objeto Redundancy Configuration, en el árbol de dispositivos del proyecto. Por estándar, todas las GVLs creadas por el usuario serán, inicialmente, redundantes. ATENCIÓN: Por buena práctica, se recomienda evitar la utilización de la directiva AT en GVLs que contengan declaraciones de variables simbólicas redundantes, para evitar el mapeo de variables en áreas noredundantes. POUs del Tipo Program con Variables Simbólicas Redundantes El usuario puede declarar variables simbólicas redundantes en POUs del tipo programa, con excepción de la POU NonSkippedPrg en la cual las variables simbólicas declaradas se consideran no redundantes. Para definir una nueva POU como redundante se debe, tras la creación de la POU, marcarla en la configuración del objeto Redundancy Configuration, en el árbol de dispositivos del proyecto. Por estándar, todas las POUs creadas por el usuario serán, inicialmente, redundantes. ATENCIÓN: Por buena práctica, se recomienda evitar la utilización de la directiva AT en POUs que sean redundantes, a fin de evitar el mapeo de variables en áreas no-redundantes. Utilización de Breakpoints en Sistemas Redundante Para sistemas redundantes, lo recomendado es utilizar breakpoints sólo en el half-cluster Activo, con el otro half-cluster desconectado. En caso contrario, cuando la ejecución de la aplicación alcance un breakpoint, el half-cluster Reserva asumirá el estado Activo, desconectando el CP activo. Gerenciamiento de Instancias MODBUS en Sistemas Redundantes Para el caso de que la utilización de la falla vital de las interfaces Ethernet esté deshabilitada o en el caso de instancias MODBUS Server, las instancias MODBUS son independientes de la redundancia y, por lo tanto, se deberán gerenciar en la aplicación, estando al criterio del usuario cuáles instancias se deberán habilitar/deshabilitar cuando un CP entra en un estado No-Activo. Cuando vaya a habilitar la falla vital para puertas Ethernet con MODBUS Client, no es necesario implementar código adicional para controlar el switchover. El ejemplo abajo, insertado en el programa NonSkippedPrg, hace la verificación del estado actual del CP y, en caso de que esté en un estado No-Activo, deshabilita las instancias MODBUS RTU Maestro y Esclavo y la instancia MODBUS Ethernet Servidor: VAR eRedStateLocal : REDUNDANCY_STATE; eRedStateLocal_old : REDUNDANCY_STATE; 276 6. Redundancia con UCP NX3030 END_VAR // Lectura del estado actual del CP local eRedStateLocal := DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState; // El estado del CP local ha cambiado? IF eRedStateLocal <> eRedStateLocal_old THEN IF eRedStateLocal = REDUNDANCY_STATE.ACTIVE THEN // CP local ha entrado en estado Activo Diagnostics.DG_MODBUS_RTU_Slave.tCommand.bRestart := TRUE; Diagnostics.DG_MODBUS_RTU_Master.tCommand.bRestart := TRUE; Diagnostics.DG_MODBUS_Server.tCommand.bRestart := TRUE; ELSE // CP local ha entrado en un estado No Activo Diagnostics.DG_MODBUS_RTU_Slave.tCommand.bStop := TRUE; Diagnostics.DG_MODBUS_RTU_Master.tCommand.bStop := TRUE; Diagnostics.DG_MODBUS_Server.tCommand.bStop := TRUE; END_IF // Salva el último estado del CP local eRedStateLocal_old:= eRedStateLocal; END_IF Limitaciones en la Programación de un CP Redundante En un CP redundante, existirán algunas limitaciones cuanto a la programación de los half-clusters. Estas limitaciones se presentan en las subsecciones a continuación. Limitaciones en GVLs y POUs Redundantes En una GVL o en una POU del tipo programa que sean redundantes, las siguientes limitaciones se deben respetar para el correcto funcionamiento de los half-clusters: No utilizar variables del tipo VAR_TEMP; No mezclar tipos de variables (VAR, VAR RETAIN, VAR PERSISTENT, etc.), se debe utilizar solamente uno de los tipos en cada GVL o POU; No mezclar declaración de variables simbólicas con ATs en las GVLs. Se deben crear GVLs separadas, declarando en una las variables del tipo AT y en otra las variables simbólicas. No almacenar la dirección de una variable en una variable redundante (hacer de una variable redundante un puntero para un dirección), pues los direcciones de las variables pueden ser diferentes en el CPA y en el CPB. No utilizar bloques funcionales en POUs redundantes. Más detalles se pueden encontrar en el capítulo Reloj RTC. Limitaciones en el Programa No-Redundante (NonSkippedPrg) En una POU del tipo programa que no sea redundante, en el caso, la POU NonSkippedPrg, las siguientes limitaciones se deben respetar para un correcto funcionamiento de los half-clusters: No se pueden utilizar los bloques funcionales TON y TOF tradicionales, pues estos mismos utilizan el timer IEC. Cuando el CP Reserva entra en estado activo (con el otro half-cluster saliendo del estado Activo), el timer IEC se sincronizará, causando una discontinuidad en el valor del timer. Se debe optar por los bloques funcionales TON_NR y TOF_NR ofrecidos en la library NextoStandard. Ver capítulo Configuración - Bloques Funcionales - Timer NoRedundante. No se pueden utilizar POUs del tipo programa escrituras en el lenguaje SFC (Gráfico de Funciones Secuenciales), pues estas utilizan el timer IEC para temporizar las transiciones. No mezclar declaración de variables simbólicas con ATs en las GVLs. Se deben crear GVLs separadas, declarando en una las variables del tipo AT y en otra las variables simbólicas. 277 6. Redundancia con UCP NX3030 Obtener el Estado Redundante de un Half-Cluster Es posible verificar el estado de la redundancia de uno half-cluster en la Estructura de Diagnósticos de la Redundancia: VAR eRedStateLocal : REDUNDANCY_STATE; END_VAR eRedStateLocal := DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState Así, el usuario puede controlar las lógicas que dependen del estado redundante de la del CP. Lectura de Diagnósticos No-Redundantes Un proyecto redundante, además de presentar diagnósticos redundantes (Estructura de Diagnósticos de la Redundancia o los diagnósticos de una remota PROFIBUS), presenta también diagnósticos noredundantes (diagnósticos específicos de los módulos NX5000, NX5001, NX3030). Estos diagnósticos no-redundantes podrán no ser válidos en los primeros instantes después del CP asumir el estado Activo, ya que los mismos no son sincronizados con el otro CP (no es posible saber el estado en que se encontraban los diagnósticos cuando el CP remoto estaba en el estado Activo). Por lo tanto, estos diagnósticos no deben ser considerados en los primeros instantes del CP en estado Activo, hasta que tengan valores válidos. Típicamente, el tiempo durante el cual los diagnósticos no deben ser considerados es de 5 s. El siguiente ejemplo muestra cómo ignorar los diagnósticos bSlaveNotPresent y bPbusCommFail del módulo Maestro PROFIBUS NX5000 durante los primeros 5 s en que el CP se encuentra en estado Activo. Lógica en NonSkippedPrg: PROGRAM NonSkippedPrg VAR TON_DiagEnable : TON_NR; bDiagEnable : BOOL; bIsActiveState : BOOL; bIsActiveState_old : BOOL; END_VAR bIsActiveState := (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.eRedState = REDUNDANCY_STATE.ACTIVE); TON_DiagEnable(IN:= (bIsActiveState = bIsActiveState_old), PT:= T#5S, Q=> bDiagEnable); bIsActiveState_old := bIsActiveState; Lógica en ActivePrg: IF NonSkippedPrg.bDiagEnable THEN IF DG_NX5001.tGeneral.bSlaveNotPresent OR DG_NX5001.tGeneral.bPbusCommFail THEN //Ejecuta acciones de diagnóstico activo END_IF END_IF Carga de Programas en un CP Redundante La sección Programación de un CP Redundante trató de aspectos relativos al desarrollo de un proyecto para un CP redundante con UCP NX3030. En esta sección, se discuten métodos y etapas para cargar este proyecto en un CP redundante, considerando diversas situaciones, así como: 278 6. Redundancia con UCP NX3030 Carga del proyecto en una UCP NX3030 nueva retirada de la caja, o en una UCP que contiene un proyecto desconocido. Carga online de modificaciones. Carga offline de modificaciones con interrupción del control del proceso, durante una parada programada del proceso. Carga offline de modificaciones sin interrupción del control del proceso, valiéndose de características de la redundancia. Carga Inicial de un Proyecto Redundante Esta sección describe los pasos necesarios para hacer la primera carga de proyecto redundante en una UCP NX3030. Esto es necesario, por ejemplo, para una UCP nueva de fábrica, o para una UCP que contenga un proyecto desconocido. ATENCIÓN: Los pasos siguientes se deben ejecutar para los dos half-clusters (CPA y CPB) que componen un CP redundante. Primero se debe ejecutar todos los pasos para uno de los CPs, y después para el otro. Primer Paso - Descubierta de la dirección IP para Conexión del MasterTool Lo primero es descubrir la dirección IP del canal NET 1 de esta UCP, para conexión al MasterTool. Esto se debe hacer a través del visor y tecla de la UCP NX3030, según lo descrito en Menú Informativo y de Configuración de la UCP. El menú RED informa las direcciones IPs que se pueden utilizar para conexión por MasterTool. Segundo Paso – Verificar Conflicto de Direcciones IP Antes de ejecutar el próximo paso, se debe estar seguro de que no existe, en la red, otro equipo con la misma dirección IP descubierta en el primer paso. Esto se puede descubrir, por ejemplo, al desconectar el CP de la red y ejecutar un comando “ping” en su dirección IP. Como el CP está desconectado, se espera que este “ping” falle. Si el “ping” funciona, existe otro equipo con la misma dirección IP. En caso de que la dirección IP ya esté en uso por otro equipo en la red, se debe ejecutar el tercer paso, y también algunos pasos siguientes, utilizando un cable de crossover para conectar directamente el PC con el software MasterTool IEC XE al CP, evitando así conflictos de direcciones IP. En uno de los pasos siguientes, al cargar el proyecto en el CP, se actualizarán las direcciones IP definitivas del CP (ver sección Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2). Tercer Paso – Preparar Conexión del MasterTool (Definir Active Path) El tercer paso consiste en dar un doble clic sobre el Device (NX3030) en el árbol de dispositivos, entrar en la pestaña “Configuraciones de Comunicación”, hacer clic sobre el Gateway, y presionar el botón “Mapear Rede” para listar todos los CPs detectados por el MasterTool en la red. En este momento, se espera encontrar una lista de CPs cuya identificación contiene la dirección IP descubierta en el primer paso y el tipo de la UCP (NX3030). En caso de que el usuario haya cambiado anteriormente el nombre de la UCP en la red, este nombre se visualizará en este momento. La sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante describe con más detalles las posibles identificaciones que se pueden observar en esta lista. De cualquier forma, todas las posibles identificaciones poseen un campo que muestra la dirección IP o parte de esta. Por ejemplo, los bytes que están entre corchetes forman la dirección de la UCP. El byte que está a la derecha, entre los bytes que están entre corchetes, indica el final de la dirección IP en hexadecimal. Si los bytes forman la siguiente dirección [0010], esto significa que el byte con el valor 10 indica que el fin de la dirección IP de esa UCP es xxx.xxx.xxx.16. A continuación, se debe hacer clic sobre este CP en la lista y presionar el botón “Definir Camiño Activo”. Hecho esto, el CP seleccionado debe 279 6. Redundancia con UCP NX3030 aparecer en negrita en la lista, lo que indica que el MasterTool está preparado para conectarse a este CP. Cuarto Paso – Identificar la UCP NX3030 y Conferir en el Visor de la UCP El cuarto paso consiste en identificar el half-cluster, como CPA o CPB. Esto se hace a través del menú Comunicación / Configuración Básica de Cluster: A continuación, la combo-box “Identificación del CP” permite seleccionar una de las tres siguientes opciones: PLC A PLC B Non-Redundant Figura 6-24. Identificación del CP En el caso de un CP redundante, el usuario debe seleccionar CPA o CPB. Después de seleccionar la opción que desee, el botón “Escribir” al lado de esta combo-box se debe presionar. El MasterTool retornará un aviso de que la UCP se reinicializará y si el usuario desea confirmar la acción. Enseguida, aparecerá un mensaje que indica éxito o falla del comando y, en caso de éxito, la UCP se reinicializará. ATENCIÓN: La UCP NX3030 no puede estar en modo Run cuando este comando se ejecuta. Antes de ejecutar el comando, el usuario debe colocar la UCP en Modo Stop. En caso de que la UCP esté en modo Run, el comando no se ejecuta y el MasterTool avisa que el comando ha fallado. Enseguida, después de ejecutar el comando de identificación con éxito, se observa que la identificación seleccionada aparece en las Diagnósticos de la Redundancia en el Visor Gráfico de la UCP NX3030. La identificación del CP también estará disponible en un diagnósticos interno (DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.ePLC_ID). Este diagnóstico se actualiza a partir de la memoria no-volátil a cada ciclo de la MainTask, por lo tanto es necesario que el CP vuelva al modo Run para que se actualice. Abajo, están relacionados los códigos retornados por el diagnóstico y sus respectivas descripciones: No-Redundante: 0 CPA: 2 CPB: 3 280 6. Redundancia con UCP NX3030 La identificación de un CP no hace parte del proyecto redundante desarrollado con el MasterTool. Dicha identificación se ubica sólo en un área de memoria no-volátil de la UCP, que se puede modificar usando el MasterTool. CUIDADO: La redundancia no funcionará adecuadamente en caso de que una de las UCPs no se identifique como CPA y la otra UCP no se identifique como CPB, lo que puede ocasionar interrupción del control del proceso. En caso de que una UCP NX3030 se deba sustituir (ej.: después de un daño), la nueva UCP se debe previamente identificar con la misma identificación de la UCP que se está sustituyendo. Se debe usar el visor de la UCP para verificar si los dos CPs han sido correctamente identificados. Quinto Paso – Carga del Proyecto Redundante Este paso describe la carga del proyecto redundante en el CP. Este proyecto se debe preparar según lo descrito en la sección Programación de un CP Redundante. Un proyecto simple (básico) se puede preparar siguiendo, en lo mínimo, las siguientes subsecciones de esta sección: Wizard para Creación de un Nuevo Proyecto Redundante ; Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2). Obviamente, también es posible hacer un proyecto completo y sólo después cargarlo en el CPA y CPB, por ejemplo, en caso de que el hardware de estos CPs no esté disponible durante el desarrollo del proyecto con el MasterTool. La primera carga de un proyecto redundante en una UCP, previamente identificada como CPA o CPB, aún se debe hacer utilizando la dirección IP descubierta en el primer paso de este procedimiento, y seleccionada en el tercer paso de este procedimiento. La carga del proyecto se hace a través del menú Comunicación / Login. ATENCIÓN: Dentro del proyecto desarrollado con el MasterTool y cargado en el CP en este paso, se han definido nuevas direcciones IP para la interfaz NET 1 del CPA y CPB (Dirección de IP del CPA y Dirección de IP del CPB), así como una dirección IP para la interfaz NET 1 del CP Activo (Dirección de IP Activo) – ver sección Configuraciones de las Puertas Ethernet de la UCP NX3030 (NET 1 y NET 2). Por lo tanto, después de esta carga inicial, la dirección IP descubierta en el primer paso de este procedimiento normalmente no tendrá más validez. Este cambio de la dirección IP en NET 1 o NET2 provocará una pérdida de la conexión del MasterTool con el CP, que se notificará. Para más detalles sobre cómo reconectar el MasterTool, ver sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante. Conexión del MasterTool con una UCP NX3030 de un CP Redundante Después de ejecutar el procedimiento descrito en la sección Carga Inicial de un Proyecto Redundante en los dos CPs (CPA e CPB), la conexión al MasterTool, a través de la interfaz NET 1 de la UCP NX3030, se podrá hacer a través de una de las siguientes direcciones: Dirección de IP del CPA: dirección de NET 1 exclusiva para el CPA Dirección de IP del CPB: dirección de NET 1 exclusiva para el CPB Independiente del estado del CP, el MasterTool sólo consigue conectarse a este utilizando la dirección exclusiva del CP, configurado en Dirección de IP del CPX. Sin embargo, en caso de que el CP se encuentre en estado Activo, todos los demás servicios se podrán conectar al CP tanto por la dirección de IP del CPX como por la dirección de IP Activo. 281 6. Redundancia con UCP NX3030 Para conectarse a determinado CP, en primer lugar se debe hacer un doble clic sobre el Device (NX3030) en el árbol de dispositivos, entrar a la pestaña “Configuraciones de Comunicación”, hacer clic sobre el Gateway, y presionar el botón “Mapear Red” para listar todos los CPs detectados por el MasterTool en la red. En esta lista, será posible encontrar las siguientes identificaciones estándar, en caso de que el nombre del CP en la red no haya sido alterado anteriormente por el usuario: NX3030_<IP address>_PLCA: identificación relacionada al CPA. En este caso, el campo <IP address> debe coincidir con la dirección de IP del CPA configurado en el proyecto. NX3030_<IP address>_PLCB: identificación relacionada al CPB. En este caso, el campo <IP address> debe coincidir con la dirección de IP del CPB configurado en el proyecto. A continuación, se debe seleccionar el CP de esta lista en la cual el MasterTool se debe conectar, y presionar el botón “Set Definir Camiño Activo”. Posteriormente, al ejecutar el comando del menú Comunicación / Login, el MasterTool se conectará a este CP. ATENCIÓN: El MasterTool sólo consigue conectarse a un CP a la vez. Para conectarse a distintos CPs, se deben abrir múltiples instancias del MasterTool, teniendo atención para siempre abrir el proyecto correcto en cada instancia. Carga de Modificaciones en un Proyecto Redundante Después que los dos CPs (CPA y CPB) que forman un CP redundante ya recibieron una carga inicial, según lo descrito en la sección Carga Inicial de un Proyecto Redundante, es posible cargar modificaciones sucesivas del proyecto, a la medida que dichas modificaciones se hagan necesarias. La conexión del MasterTool a los CPs para ejecutar la carga de modificaciones de debe hacer según se describe en la sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante. En esta sección se explica cómo es posible conectarse a un CP específico (CPA o CPB), o al CP Activo, o al CP No-Activo. Normalmente las modificaciones se deben cargar en el CP Activo, y a seguir se sincronizarán automáticamente para el CP No-Activo, a través de los canales de sincronismo NETA/NETB. Por lo tanto, el MasterTool normalmente debe usar la dirección de IP exclusiva del CP Activo (Dirección de IP del CPX) para conectarse al canal NET 1 de la UCP NX3030 del CP Activo. Para verificar cual de los CPs está en estado Activo, se podrá seguir el mismo paso descrito en Carga Inicial de un Proyecto Redundante - Cuarto Paso – Identificar la UCP NX3030 y Conferir en el Visor de la UCP. ATENCIÓN: Cargar un proyecto en el CP No-Activo normalmente es inútil, pues la sincronización automática de proyectos (del CP Activo hacia el CP No-Activo) anularía el efecto de esta carga. Sin embargo, hay situaciones especiales en que la sincronización de proyectos se puede deshabilitar temporariamente, siendo posible y útil cargar un proyecto diferente en el CP No-Activo. Estas situaciones especiales se discuten en la sección Explorar la Redundancia para Carga Offline de Modificaciones sin Interrupción del Control del Proceso. Carga de Modificaciones Offline y Online Modificaciones de proyecto se pueden cargar offline u online. Cargas offline requieren la parada del CP en la cual la modificación se debe cargar. Por otro lado, cargas online permiten que el CP siga ejecutando su aplicación mientras la modificación se carga. Algunos tipos de modificaciones exigen carga offline, o sea, no se pueden cargar on-line en el CP en el cual el MasterTool está conectado. En este caso, existen dos opciones: Interrumpir el control del proceso al ejecutar el procedimiento descrito en la sección Carga Offline de Modificaciones con Interrupción del Control de lo Proceso. 282 6. Redundancia con UCP NX3030 Valerse de la redundancia del CP y de las redes PROFIBUS para no interrumpir el control del proceso, aun con la necesidad de hacer cargas off-line en cada uno de los half-clusters (CPA o CPB). Un procedimiento para alcanzar este objetivo se describe en la sección Planificación Previa para Modificaciones Offline sin Interrupción del Control del Proceso. Modificaciones que Demandan Carga Offline con la Interrupción del Control del Proceso La siguiente modificación en un proyecto hará con que sea imposible de cargar lo mismo en un sistema redundante sin la interrupción del control del proceso. Modificaciones en las áreas de memoria redundantes (modificar los parámetros de redundancia del módulo NX4010). ATENCIÓN: No se puede cambiar el tamaño de las áreas de memoria redundantes sin interrumpir el control del proceso. Por lo tanto, estas áreas deben ser cuidadosamente planeadas y configuradas previamente. Modificaciones que Demandan Carga Offline Las siguientes modificaciones demandan carga off-line en el CP: Añadir o remover dispositivos en el árbol de dispositivos, por ejemplo: o Módulos en el bastidor principal (maestros PROFIBUS NX5001, interfaces Ethernet NX5000, etc.) o Remotas en redes PROFIBUS o Módulos de E/S en remotas en redes PROFIBUS o Instancias MODBUS Modificar parámetros dentro de dispositivos existentes en el árbol de dispositivos, por ejemplo: o o o o Direcciones IP y otros parámetros de interfaces Ethernet Parámetros de maestros PROFIBUS Parámetros de remotas PROFIBUS Parámetros de módulos de E/S dentro de remotas PROFIBUS Modificaciones en las configuraciones de las tareas. Actualización de Proyecto debido a Actualización del Programador MasterTool IEC XE Modificaciones que Permiten Carga Online En principio, las modificaciones no presentadas en las secciones Modificaciones que Demandan Carga Offline con la Interrupción del Control del Proceso y Modificaciones que Demandan Carga Offline, permiten carga on-line. Aun así, a continuación se presentarán las principales modificaciones que permiten carga on-line en el CP en el cual el MasterTool está conectado. Las modificaciones abajo son válidas para variables, POUs y GVLs, redundantes o no. Añadir POUs del tipo programa, desde que estas POUs no necesiten asociarse a alguna tarea. Remover POUs del tipo programa, desde que estas POUs no estén asociadas a alguna tarea. Añadir o remover POUs del tipo función o bloque funcional. Modificar el código de cualesquier tipos de POU (programa, función o bloque funcional). Añadir o remover variables simbólicas en cualesquier tipos de POU (programa, función o bloque funcional siendo ellas redundantes o no). Añadir o remover instancias de bloque funcional en POUs del tipo programa o bloque funcional. Añadir o remover GVLs. Añadir o remover variables simbólicas o instancias de bloque funcional en GVLs. 283 6. Redundancia con UCP NX3030 Carga Online de Modificaciones En la sección Carga de Modificaciones Offline y Online, se describieron modificaciones que demandan carga off-line y las que permiten carga on-line. Una carga online se debe hacer al conectar el MasterTool al canal NET 1 del CP Activo, utilizando su dirección exclusiva de IP, y, enseguida del envío de la aplicación, el usuario deberá seleccionar la opción “Crear Aplicación de Inicialización” en el menú Comunicación, para que las modificaciones se envíen para el área de memoria no-volátil de la UCP y se puedan sincronizar. ATENCIÓN: Es importante recordar que modificaciones online, sin que la opción mencionada anteriormente se seleccione, serán perdidas en caso de un Reset en Caliente o la UCP se desconecte. ATENCIÓN: Una alteración online en la declaración de variables retentivas de la aplicación (inclusión o exclusión de variables) seguido de una falta de energía del CP antes de “Crear Aplicación de Inicialización”, irá corromper la memoria retentiva, pues el valor de las variables retentivas que fueron salvadas y recuperadas no corresponde a las variables de la aplicación en memoria y que fue restaurada. Cuando el CP No-Activo percibe que posee un proyecto diferente del CP Activo, ejecuta las siguientes acciones: Negocia una sincronización automática de proyecto con el CP Activo. En caso de que esté en el estado Reserva o Inicializando, conmuta hacia el estado NoConfigurado, y permanece en este estado hasta que los proyectos estén nuevamente sincronizados. Después, vuelve automáticamente al estado Reserva. En caso de que esté en el estado No-Configurado o Inactivo, el botón STAND-BY del panel PX2612 se debe presionar, o comando equivalente a este botón se debe ejecutar. De esta forma, después de la sincronización del proyecto, saldrá del estado No-Configurado y podrá ir al estado Reserva, o volver hacia el estado Inactivo si ocurre alguna falla. Carga Offline de Modificaciones con Interrupción del Control de lo Proceso En esta sección, se define el procedimiento para ejecutar una carga off-line que interrumpirá el control del proceso. Tal situación se acepta en determinados tipos de procesos y durante paradas programadas de este proceso. Una carga offline de este tipo se debe hacer conectando el MasterTool al canal NET 1 del CP Activo, utilizando la dirección exclusiva del CP en estado Activo (Dirección de IP del CPX). Antes de iniciar una carga offline en el CP Activo, el usuario recibe o siguiente aviso del MasterTool: Figura 6-25. Aviso de Carga Off-Line 284 6. Redundancia con UCP NX3030 Al presionar el botón Sí el proyecto se envía. Cuando una carga off-line se ejecuta, el control del proceso se interrumpe, ya que el envío del proyecto se debe hacer pare el CP Activo que salirá del modo de ejecución (Run), y, así, estará en el estado No-Configurado. Otro punto importante es que si el otro CP está en estado Reserva, se debe pasarlo hacia el estado Inactivo, por ejemplo, apretando el botón INACTIVE del PX2612 para este CP. De esta forma, se evita que el otro CP desconecte este CP y asuma como Activo. ATENCIÓN: Cuando el CP Activo sale del modo Run y va hacia el estado No-Configurado, si el otro CP fue olvidato en estado Reserva, el otro CP asumirá como Activo y desconectará el CP que pasó de Activo a No-Configurado. En este caso, por lo tanto, la carga off-line no se podrá completar porque el CP conectado al MasterTool ha sido desconectado. Cuando la carga off-line termine, es posible reiniciar la ejecución del programa en el CP en el cual la aplicación ha sido cargada (colocar en el modo Run nuevamente). Después de algunos segundos, este CP reasume el estado Activo. Después que este CP reasuma el estado Activo, se puede retirar el otro CP del estado Inactivo, por ejemplo, apretando el botón STAND-BY del PX2612 para este CP. Esto provocará la transición de este CP hacia el estado No-Configurado. Este CP permanecerá en el estado No-Configurado hasta que el proceso automático de sincronización de proyectos termine. Después, este CP pasa al estado Inicializando y después volverá al estado Reserva. Planificación Previa para Modificaciones Offline sin Interrupción del Control del Proceso La subsección siguiente – Planificación Previa para Modificaciones a Caliente en Redes PROFIBUS Redundantes– describe un procedimiento muy importante que permite hacer cargas off-line de modificaciones sin interrumpir el control del proceso. Aunque este procedimiento no se aplique a cualesquier modificaciones que demanden carga off-line, este se aplica a las modificaciones realizadas con más frecuencia. Sin embargo, para que el procedimiento sea aplicable, los proyectos se deben desarrollar con alguna planificación previa, particularmente para modificaciones que afectan a la red PROFIBUS. Las siguientes subsecciones describen dichas planificaciones previas para modificaciones que afectan a la red PROFIBUS, y también para las demás modificaciones. Planificación Previa para Modificaciones a Caliente en Redes PROFIBUS Redundantes Entre las modificaciones que afectan una red PROFIBUS y demandan carga off-line, las siguientes se soportan por el procedimiento que permite hacer cargas off-line de modificaciones sin interrumpir el control del proceso, desde que la red PROFIBUS sea redundante: Insertar una nueva red PROFIBUS. Insertar una nueva remota de la Serie Ponto. Insertar un nuevo módulo de E/S en una remota de la Serie Ponto. Modificar parámetros en remotas de la Serie Ponto o en módulos de E/S de remotas de la Serie Ponto. ATENCIÓN: Es posible insertar remotas no redundantes debajo de una red PROFIBUS redundante al utilizar el módulo AL-2433 (ProfiSwitch), según el ejemplo presentado en la Figura 6-1. Sin embargo, dichas remotas no redundantes sufrirán discontinuidades (desconexión de salidas) cuando se carguen modificaciones offline. A continuación, se describen las etapas de una planificación que debe iniciar en el momento de la creación de una nueva red PROFIBUS redundante. 285 6. Redundancia con UCP NX3030 Etapa 1 – Planificar Expansión Futura de las Remotas Insertadas en la Versión Inicial de la Red PROFIBUS Por primero, se debe hacer una lista de los módulos de E/S que compondrán cada remota PROFIBUS redundante de la Serie Ponto, en la versión inicial de la red PROFIBUS. En la lista, debe constar la posición en la cual cada módulo de E/S se insertará en el bastidor de la remota. A continuación, se debe planificar como cada una de estas remotas se podrá expandir posteriormente. Para tanto, se debe hacer una lista complementaria con módulos de E/S que se podrán insertar futuramente. En la lista complementaria, debe constar la posición en la cual cada módulo de E/S se insertará futuramente en el bastidor de cada remota. ATENCIÓN: En la construcción física de estas remotas (armarios eléctricos), se recomienda insertar bases compatibles con los módulos de E/S futuros en las respectivas posiciones. De esta forma, cuando sea necesario insertar el módulo de E/S en esta remota, no se necesitará desconectarla para insertar la base. En caso de que este detalle no se observe, se necesitará desconectar esta remota específica, pues no es posible insertar una base a caliente en una remota. Se percibe que la parada de una remota específica en algunos casos se puede tolerar, pero en otros casos no. ATENCIÓN: Se debe colocar los módulos de E/S originales en las primeras posiciones del bastidor de la remota, y los módulos de E/S futuros en las últimas posiciones del bastidor de la remota. ATENCIÓN: Considerar las limitaciones de las remotas redundantes de la Serie Ponto al elaborar esta lista, según el Manual de Utilización Cabeza PROFIBUS PO5063V1 y Cabeza Redundante PROFIBUS PO5063V5, y el Manual de Utilización Cabeza PROFIBUS PO5064 y Cabeza Redundante PROFIBUS PO5065. Existen límites cuanto al número de módulos por remota, número de bytes de E/S por remota, consumo de corriente por fuente, etc. Estos límites se pueden verificar automáticamente al utilizar el "ProPonto". Para más informaciones, consulte el Manual de Utilización MT6000 MasterTool ProPonto – MU299040. Etapa 2 – Insertar la Versión Inicial de la Red PROFIBUS Redundante al Proyecto Para insertar la versión inicial de red PROFIBUS redundante al Proyecto, inicialmente se deben insertar los 2 módulos NX5001 redundantes al bastidor, o utilizar los que ya están insertados por el Wizard de la redundancia. Enseguida, se debe insertar cada una de las remotas al árbol de dispositivos abajo del primer NX5001 del par redundante en el árbol de dispositivos, bien como los módulos de E/S abajo de cada remota. En cuanto a los módulos de E/S insertados, existen dos categorías que se deben tratar de forma diferente: Los que hacen parte de la versión inicial de la red PROFIBUS, y se instalarán inmediatamente. Los que se utilizarán para expansión posterior. En el en caso de los que hacen parte de la versión inicial de la red PROFIBUS, se debe insertar el propio módulo al árbol de dispositivos, en la posición planificada de la remota correspondiente. En el en caso de los que se utilizarán para expansión posterior, se debe insertar un módulo virtual correspondiente en la posición planificada. Un módulo virtual simula un módulo real y necesita ubicar el mismo número de bytes de E/S que el módulo real. La inserción de un módulo virtual en lugar de un módulo real impide que diagnósticos de ausencia del módulo real se produzcan. 286 6. Redundancia con UCP NX3030 La Tabla 6-4 ejemplifica algunos módulos reales y sus respectivos módulos virtuales correspondientes: Módulo Real Módulo Virtual Correspondiente PO1000 PO9999 – 2 bytes input PO1001 PO9999 – 2 bytes input PO1002 PO9999 – 2 bytes input PO1003 PO9999 – 2 bytes input PO2020 PO9999 – 2 bytes output PO2022 PO9999 – 2 bytes output Tabla 6-4. Módulos Virtuales Correspondientes a los Módulos Reales Etapa 3 – Ubicar Áreas de Variables %I y %Q para la Red PROFIBUS considerando Expansión para Remotas Posteriores A medida que los NX5001, remotas y módulos de E/S se fueron insertando al árbol de dispositivos en la etapa 2 anterior se ubicaron variables %I y %Q en 3 áreas diferentes: Área de variables %I para entradas Área de variables %Q para salidas Área de variables %Q para diagnósticos El MasterTool ejecuta la ubicación de cada una de estas 3 áreas de variables de forma contigua, sin dejar intervalos en las ubicaciones. Se debe planificar la dirección inicial y final de cada una de estas 3 áreas, al considerar las remotas inicialmente instaladas en la red (ver etapas 1 y 2 anteriores), pero también remotas que se podrán ser insertar posteriormente en esta misma red PROFIBUS. Al definir la dirección inicial de cada área, es importante reservar expansión para el dispositivo que ubica direcciones inmediatamente antes del inicio de esta área. Por otro lado, al definir la dirección final de cada área, es importante reservar expansión para esta red PROFIBUS. A continuación, se muestra un ejemplo de tal planificación, para el área de variables %I de entrada: Red PROFIBUS 1: o %IB0 ... %IB499 (direcciones ubicadas para remotas ya instaladas). o %IB500 ... %IB999 (direcciones ubicadas para remotas futuras). Red PROFIBUS 2: o %IB1000 ... %IB1499 (direcciones ubicadas para remotas ya instaladas). o %IB1500 ... %IB1999 (direcciones ubicadas para remotas futuras). Servidor MODBUS TCP: o %IB2000 ... %IB2999 (direcciones ubicadas para mapeos actuales). o %IB3000 ... %IB3999 (direcciones ubicadas para mapeos futuros). Para las otras dos áreas (%Q de salida, %Q de diagnósticos) se podrían mostrar ejemplos similares de planificaciones. Es posible prever el tamaño de las áreas inicialmente ubicadas y de expansión posterior al utilizar la siguiente tabla, que indica las cuantidades de bytes ubicados en cada una de las 3 áreas, para cada módulo: Módulo %I entradas (bytes) %Q salidas (bytes) %Q diagnósticos (bytes) NX5001 4 2 86 PO5063V5 0 0 25 PO5065 0 0 25 287 6. Redundancia con UCP NX3030 PO9100 (un por remota) 2 2 10 PO1000 2 0 10 PO2020 0 2 10 PO9999 – 2 bytes output 0 2 10 PO9999 – 2 bytes input 2 0 10 Tabla 6-5. Ubicación de Variables %I y %Q para Módulos de la Red PROFIBUS Nota: Ubicación de variables: Más informaciones sobre el tamaño y el tipo de memoria ubicado para cada módulo se pueden encontrar en el Manual de utilización Maestro PROFIBUS DP NX5001. Después de ejecutar la planificación de las 3 áreas (direcciones iniciales y final de cada área), se debe introducir las direcciones iniciales al proyecto iniciado en la etapa 2. Por primero, se debe modificar el parámetro “Diagnostic Offset in %Q Area” del primer módulo NX5001. Se debe utilizar la dirección inicial planificada para el área de variables %Q para diagnósticos. Por segundo, se debe buscar el primer módulo de E/S de la red, a partir de los NX5001, que ubique variables %I para entradas. Al encontrarlo, se debe alterar el parámetro “Dirección” correspondiente Y por último, se debe buscar el primer módulo de E/S de la red, a partir de los NX5001, que ubique variables %Q para salidas. Al encontrarlo, se debe alterar el parámetro “Dirección” correspondiente. ATENCIÓN: En este momento, se aconseja verificar la franja de direcciones ubicadas para las 3 áreas de variables, observando si las direcciones finales de cada área están dentro de la franja planificada, y si existe una buena expansión libre para nuevas remotas a insertarse posteriormente. Planificación Previa para Otras Modificaciones Existen otras modificaciones, que aunque no afecten una red PROFIBUS, también demandan carga off-line. A continuación, se muestran algunos ejemplos de modificaciones de este tipo soportadas por el procedimiento que permite hacer cargas off-line de modificaciones sin interrumpir el control del proceso: Inserción de módulos NX5000 (Ethernet) Inserción de I/O drivers de comunicación Ethernet o Serial Inserción de nuevos mapeos en I/O drivers de comunicación Ethernet o Serial Modificar el periodo de MainTask Algunas modificaciones simples, tales como modificar el periodo de MainTask, no exigen planificación previa alguna. Por otro lado, las demás modificaciones ejemplificadas anteriormente en esta sección abarcan la ubicación de variables de representación directa %I y %Q para diagnósticos, entradas y salidas, de forma similar a lo que se presentó en la etapa 3 de la planificación previa para modificaciones a caliente que afectan la red PROFIBUS (ver sección Etapa 3 – Ubicar Áreas de Variables %I y %Q para la Red PROFIBUS considerando Expansión para Remotas Posteriores). De esta forma, al insertar un módulo NX5000, o al insertar un I/O driver Ethernet o Serial, se debe planificar la ubicación de las 3 siguientes áreas para el dispositivo insertado: Área de variables %I para entradas Área de variables %Q para salidas Área de variables %Q para diagnósticos 288 6. Redundancia con UCP NX3030 La sección Etapa 3 – Ubicar Áreas de Variables %I y %Q para la Red PROFIBUS considerando Expansión para Remotas Posteriores muestra un ejemplo de ubicación conjunta de estas áreas, abarcando redes PROFIBUS y un I/O driver (Servidor MODBUS TCP). Incompatibilidad de Aplicaciones Si las áreas a ser utilizadas en el futuro no están diseñadas adecuadamente, las áreas de memoria redundantes pueden tener que ser alteradas, generando así un conflicto entre las aplicaciones. Esto resultará en sólo un CP seguir en el estado Activo, con el otro CP permaneció Inactivo, sin la posibilidad de sincronizar los datos redundantes o la aplicación entre los dos CPs. Esta incompatibilidad es informada por el diagnóstico de la redundancia: DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bApplicationIncompatible. Este diagnóstico es activo cuando se descarga una nueva aplicación para uno de los CPs, por lo general el No-Activo, con los siguientes cambios: Modificación en las áreas de datos redundantes (parámetros del módulo NX4010). Modificar (crear o eliminar) variables simbólicas redundantes, declaradas en POUs o GVLs redundantes. Es importante notar que, para el cambio de variables simbólicas redundantes el problema de incompatibilidad se produce sólo con un nuevo download para un dos CPs. Si las modificaciones entran en los grupos de Modificaciones que Permiten Carga Online, se puede hacer una Carga Online de Modificaciones y no generar ninguna incompatilidad en las aplicaciones. Actualizaciones de Proyecto Debido a Actualizaciones del MasterTool IEC XE La herramienta de programación MasterTool IEC XE pasa por un constante proceso de mejora, en el perfeccionamiento de sus características y al añadir nuevas. Al hacerse necesaria la actualización de la herramienta en un sistema redundante, el proyecto utilizado se necesita actualizar. Esta actualización se lleva a cabo a través del menú Proyecto/Actualización de Proyecto disponible en la herramienta. Tras actualizar el proyecto, el procedimiento de carga Off-Line sin Interrupción del Control del Proceso se puede llevar a cabo. Actualizaciones de Proyectos de Versiones Inferiores a 2.00 hacia versión 2.00 o Superior Entre los cambios entre versiones del software MasterTool IEC XE existe un caso especial que se debe planificar con más cuidado para evitar que pare el proceso. La actualización de proyecto creado con versión inferior a 2.00 del MasterTool IEC XE hacia la versión 2.00 o superior causa una reconfiguración en el área ubicada para objeto Variables Persistentes. Esta reconfiguración se ha implementado en la búsqueda de una optimización en la ubicación de esta área. Sin embargo, si este objeto está presente y marcado como redundante en un proyecto, esta reorganización no permitirá que los datos se sincronicen entre los dos proyectos, colocarán siempre uno de los Half-Clusters en estado Inoperante. De esta forma, si esta situación ocurre, el software de la UCP NX3030 consigue detectar la situación y para la sincronización de datos del objeto Variables Persistentes hasta que los proyectos en los dos Half-Clusters sean iguales y por consiguiente estén utilizando un proyecto con la versión actualizada del MasterTool IEC XE. Esta situación no parará el control del proceso, sin embargo si no se sigue una secuencia correcta de actualización, los datos del objeto Variables Persistentes se pueden reinicializar. En estos casos, la siguiente secuencia de Carga Off-Line se debe llevar a cabo: Alterar el proyecto del Half-Cluster en estado Activo al desmarcar el objeto PersistentVars dentro del objeto Redundancy Configuration. Esta carga se debe realizar como una carga OnLine y para que se pueda hacerlo, es necesaria una alteración más en el proyecto, por ejemplo, al declarar una variable dentro de la POU NonSkippedPrg 289 6. Redundancia con UCP NX3030 Al fin de la Carga On-Line será necesario ejecutar el comando Crear Aplicación de Inicialización al estar On-line en el CP que se encuentra en el estado Activo. Esto es necesario para que la aplicación se sincronice con el Half-Cluster que pasó al estado No Configurado tras la carga Actualizar el proyecto de la versión inferior a 2.00 hacia versión 2.00 o superior a través del menú Proyecto\Actualización de Proyecto del MasterTool IEC XE Deshabilitar el sincronismo de proyecto a través del menú Comunicación\Configuración de Redundancia Ejecutar la carga de proyecto actualizado en el Half-Cluster que se encuentra en el estado Reserva. Aparecerá un mensaje que indica la reorganización de las áreas de memoria del objeto PersistentVars. El procedimiento debe seguir y al fin de la carga del proyecto el Half-Cluster permanecerá en STOP con estado de redundancia como No Configurado Pasar la UCP a RUN. El Half-Cluster transicionará al estado Inicializando y después al estado Reserva. El Half-Cluster sincronizará sus datos con el otro que está en el estado Activo Los datos del objeto PersistentVars se deben copiar manualmente del Half-Cluster Activo hacia el Reserva o se debe utilizar el recurso de recetas para copiar los datos de un Half-Cluster al otro. Colocar el Half-Cluster del estado Activo en el estado Reserva. Con esta acción el estado del otro Half-Cluster se volverá Activo Habilitar el sincronismo de proyecto a través del menú Comunicación\Configuración de Redundancia. Tras este proceso, el Half-Cluster que estaba en el estado Reserva irá hacia el estado No Configurado y recibirá el proyecto del Half-Cluster en estado Activo. Al fin de este proceso, el estado del Half-Cluster cambiará a Inicializando y, por fin, de vuelta a Reserva Alterar el proyecto del Half-Cluster en estado Activo marcando el objeto PersistentVars dentro del objeto Redundancy Configuration. Esta carga se debe realizar como una carga On-Line y para que se pueda llevar a cabo se hace necesaria una alteración más en el proyecto, por ejemplo, remover una variable dentro de la POU NonSkippedPrg (por ejemplo, la declarada en el inicio de este procedimiento) Tras este proceso, el Half-Cluster que estaba en el estado Reserva irá hacia el estado No Configurado y recibirá el proyecto del Half-Cluster en estado Activo. Al fin de este proceso, el estado del Half-Cluster cambiará a Inicializando y, por fin, de vuelta a Reserva Explorar la Redundancia para Carga Offline de Modificaciones sin Interrupción del Control del Proceso En la sección Carga de Modificaciones Offline y Online, se ha informado que algunas modificaciones demandan carga off-line en el CP en el cual dichas modificaciones se deben cargar. En estos casos, el usuario tiene la opción de interrumpir el control del proceso, según procedimiento definido en la sección Carga Offline de Modificaciones con Interrupción del Control de lo Proceso. Para esto, generalmente se necesita programar previamente una parada del proceso, lo que no siempre es posible en el momento en que se necesita una modificación urgente. Gracias a la redundancia de los CPs y, en algunos casos, gracias a la redundancia de la red PROFIBUS, es posible realizar cargas off-line sin interrumpir el control del proceso para la mayor parte de las modificaciones usualmente necesarias. Para alcanzar este objetivo, es necesario seguir atentamente un procedimiento, cuyas etapas se describen en las siguientes subsecciones. Etapa 1 – Verificar Atención a los Requisitos Básicos Para que sean posibles cargas off-line sin interrumpir el control del proceso, los siguientes requisitos básicos se deben tener en cuenta: El proyecto original debe haber sido planificado en conformidad con las recomendaciones presentadas en la sección Planificación Previa para Modificaciones Offline sin Interrupción del Control del Proceso. El CP debe ser redundante. En caso de que la modificación afecte una red PROFIBUS, es necesario que esta red PROFIBUS sea redundante. Dichas modificaciones pueden ser: 290 6. Redundancia con UCP NX3030 o Inserción de nuevas remotas. o Inserción de módulos de E/S en remotas existentes, en posiciones previamente reservadas por módulos virtuales correspondientes. Para que la remota no se tenga que desconectar, además, se debe tener una base compatible con el nuevo módulo de E/S en la posición reservada para este. o Modificación de parámetros en remotas o módulos de E/S existentes. Los proyectos de ambos CPs deben estar sincronizados (iguales), y los servicios Sincronización de Datos Redundantes y Sincronización de la Lista de Forzamientos Redundantes deben estar funcionando correctamente sin ningún diagnóstico de falla. Estas condiciones están satisfechas cuando existe un CP en estado Activo y otro en estado Reserva. En caso de que el CP No-Activo no esté en estado Reserva, se puede observar los diagnósticos: o DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bRedDataSync = TRUE, indica éxito en el servicio Sincronización de Datos Redundantes. o DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bRedForceSync = TRUE, indica éxito en el servicio Sincronización de la Lista de Forzamientos Redundantes. o DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.dwApplicationCRC = DG_NX4010.tRedundancy.RedDgnRem.dwApplicationCRC, indica que los proyectos son iguales en los 2 CPs. Etapa 2 – No Cargar en Conjunto Modificaciones que se pueden Cargar Online Modificaciones que pueden ser cargadas on-line no se deben cargar junto con modificaciones que se deben cargar off-line sin interrupción del control del proceso. Siempre que sea necesario hacer estos dos tipos de modificaciones, se debe ejecutarlas y cargarlas separadamente. Para que dicho procedimiento tenga éxito, es absolutamente necesario que las modificaciones realizadas no cambien la estructura de las variables redundantes cambiadas entre CP Activo y NoActivo, a través de los servicios Sincronización de Datos Redundantes y Sincronización de la Lista de Forzamientos Redundantes. Estos dos servicios deben seguir funcionando correctamente aún mientras haya diferencias temporarias entre los proyectos de los dos CPs. Las modificaciones que se deben cargar off-line, y soportar por este procedimiento, no afectan la estructura de las variables redundantes. Sin embargo, algunas modificaciones que se pueden cargar on-line pueden alterar la estructura de las variables redundantes, por ejemplo: Inserción de variables simbólicas (redundantes o no), dentro de una POU o GVL existente, o en una nueva POU o GVL. Remoción de variables simbólicas (redundantes o no), dentro de una POU o GVL existente. La remoción de una POU o GVL también puede conllevar en la remoción de variables simbólicas. Modificación de tamaño/estructura de variables simbólicas (redundantes o no) en una POU o GVL existente. Etapa 3 – Backup del Proyecto Anterior Antes de editar las modificaciones que se deben cargar off-line sin interrumpir el proceso, por seguridad, se debe realizar un backup de la versión anterior del proyecto. Podrá ser necesario reinstalar la versión anterior en caso de que algún error se cometa durante la ejecución de este procedimiento. ATENCIÓN: La recomendación de tener un backup de todas las versiones que se carguen en los CPs no se debe seguir solamente para este procedimiento específico. Debe ser una práctica usual. Etapa 4 – Cuidados al Editar las Modificaciones Cargadas Offline Las modificaciones cargadas off-line a través de este procedimiento generalmente son las siguientes: 291 6. Redundancia con UCP NX3030 Inserción de nuevos dispositivos en el árbol de dispositivos. Alteración de propiedades o parámetros en dispositivos existentes en el árbol de dispositivos. Dicho dispositivos normalmente son los siguientes: Módulos así como maestros PROFIBUS (NX5001) o módulos Ethernet (NX5000) Remotas PROFIBUS da de la Serie Ponto Módulos de E/S dentro de remotas PROFIBUS de la Serie Ponto I/O drivers de comunicación MODBUS Mapeos de drivers de comunicación MODBUS Los siguientes cuidados se deben tomar al editar estas modificaciones en el proyecto: Si un mismo dispositivo existía en la versión anterior del proyecto y sigue existiendo en la versión modificada, las variables %I y %Q ubicadas para este deben seguir siendo las mismas (comandos, diagnósticos, entradas y salidas). Se debe tener cuidado para que las modificaciones insertadas en el proyecto no alteren dichas ubicaciones. Si un dispositivo se inserta en la versión modificada del proyecto, las variables %I y %Q ubicadas para este deben estar desubicadas en la versión anterior del proyecto (comandos, diagnósticos, entradas y salidas). Etapa 5 – Deshabilitar Sincronismo de Proyectos en el CP No-Activo En los procedimientos descritos en las secciones Carga Online de Modificaciones y Carga Offline de Modificaciones con Interrupción del Control de lo Proceso, el proyecto se sincroniza automáticamente, del CP Activo hacia el CP No-Activo. Sin embargo, durante el procedimiento de carga off-line sin interrupción del control del proceso, el sincronismo de proyectos se debe deshabilitar temporariamente. Este proceso se describe en la sección Deshabilitación de la Sincronización de Proyectos y la deshabilitación debe ser realizada en el CP No-Activo. Etapa 6 – Ejecutar las Modificaciones Físicas En este momento, se puede ejecutar las modificaciones físicas, así como: Instalar un nuevo módulo NX5000. Esto se puede hacer insertado el módulo a caliente en el rack de cada half-cluster, y después conectándolo a la red Ethernet. Instalar una nueva red PROFIBUS redundante. Los módulos NX5001 se pueden instalar a caliente en el rack de cada half-cluster. Enseguida, la red PROFIBUS redundante se puede conectar a estos. Instalar una nueva remota redundante de la Serie Ponto. En este caso, se debe instalar una cabeza remota a la vez, por ejemplo, primero en la red B, después en la red A: o Para instalar la cabeza en la red B, se puede necesitar abrir el cable o la terminación, y de esta forma perturbar la comunicación con las demás cabezas ya instaladas en la red B. Antes de hacer eso, se debe colocar todas las cabezas activas operando en la red A, y las cabezas reservas operando en la red B. o Para instalar la cabeza en la red A, se puede necesitar abrir el cable o la terminación, y de esta forma perturbar la comunicación con las demás cabezas ya instaladas en la red A. Antes de hacer esto, se debe colocar todas las cabezas activas operando en la red B, y las cabezas reservas operando en la red A. Instalar un módulo de E/S en una base previamente reservada para este, en una remota existente. Etapa 7 – Cargar las Modificaciones Offline en el CP No-Activo Por primero, el MasterTool debe estar conectado al CP No-Activo (ver sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante). 292 6. Redundancia con UCP NX3030 A continuación, se debe cargar las modificaciones off-line. Al cargarlas, la aplicación del CP NoActivo será automáticamente interrumpida (saldrá del modo Run). Etapa 8 – Volver el CP No-Activo al Modo Run para que vuelva al Estado Reserva Terminada la carga off-line, se puede volver el CP No-Activo para el modo Run. Algunos segundos después, el CP No-Activo debe asumir el estado Reserva. En caso de que el CP no asuma el estado Reserva, los siguientes problemas pueden haber causado este efecto: Las modificaciones realizadas terminaron por introducir modificaciones en la estructura de las variables redundantes, lo que impide la ejecución correcta del servicio Sincronización de Datos Redundantes. Esto se puede verificar a través del diagnóstico DG_NX4010.tRedundancy.RedDgnLoc. sGeneral_Diag.bRedDataSync (0 = falla) en el CP NoActivo. En este caso, se debe deshacer las modificaciones y recuperar el backup del proyecto anterior, e iniciar nuevamente este procedimiento. Otros problemas pueden, eventualmente, impedir la transición hacia el estado Reserva, aunque esto no se espere. En este caso, se debe observar los diagnósticos y log de la redundancia. En caso de que el CP haya asumido el estado Reserva, se aconseja verificar si los proyectos están diferentes entre CP Activo y CP No-Activo. Esto se puede hacer al comparar los diagnósticos DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.dwApplicationCRC y DG_NX4010.tRedundancy.RedDgnRem.dwApplicationCRC no CP No-Activo (los CRCs deben estar diferentes). En caso de que los proyectos estén iguales en los 2 CPs, es posible que la deshabilitación de sincronismo de proyectos (etapa 5) no se haya realizado correctamente. Esto se puede verificar a través del diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bProjectSyncDisable, que debería valer 1 en el CP No-Activo. Se esto no ocurre, se debe volver a la etapa 5. Etapa 9 – Ejecutar Switchover entre CPs Activo y Reserva Se debe ejecutar switchover entre los CPs, por ejemplo, apretando el botón STAND-BY del CP Activo. El CP Reserva, que posee el proyecto nuevo con las modificaciones, asume como Activo. El CP Activo, que posee el proyecto antiguo, asume como Reserva. Etapa 10 – Habilitar Sincronismo de Proyectos en el CP Activo En la etapa 5, el sincronismo de proyectos se ha deshabilitado en el CP que estaba en estado NoActivo. Se pude observar que ahora este CP está en estado Activo. En esta etapa, se debe habilitar nuevamente el sincronismo de proyectos en este CP. La pantalla y metodología utilizada para esto se ha descrito en la sección Deshabilitación de la Sincronización de Proyectos, bastando por esta vez seleccionar la opción “Habilitar” de la combo-box. De esta vez, el MasterTool debe estar conectado al CP Activo (ver sección Conexión del MasterTool con una UCP NX3030 de un CP Redundante). Después de habilitar el sincronismo de proyectos en el CP Activo, el usuario debe verificar si este comando tuvo éxito, verificando si DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag. bProjectSyncDisable = 0, en el CP Activo. En cuanto el sincronismo de proyectos se habilite nuevamente, la siguiente secuencia de acciones se espera: El CP No-Activo (en estado Reserva), que ya sabía de la diferencia entre los proyectos, sale del estado Reserva hacia el estado No-Configurado. El proyecto modificado (nuevo) se copia del CP Activo hacia el otro CP, temporariamente en estado No-Configurado. En cuanto los proyectos estén nuevamente sincronizados, el CP No-Configurado pasa al estado Inicializando y, después, se espera que vuelva al estado Reserva. 293 6. Redundancia con UCP NX3030 Etapa 12 – Reorganización Opcional de CP y Redes PROFIBUS en Estado Activo En el final del procedimiento, por cuestiones de estandarización u organización, el usuario podrá hacer un switchover para que el CPA asuma como Activo, y para que todas las cabezas remotas PROFIBUS en estado activo estén en la red A. Mantenimiento Cambio a Caliente de Módulos en un CP Redundante En caso de falla en algún módulo de uno de los CPs (CPA o CPB), se puede necesitar un cambio del módulo, sin interrumpir el control del proceso. Para eso, los siguientes pasos se deben seguir: Verificar si el half-cluster que no se modificará está en estado Activo o en estado Reserva y puede asumir el control del proceso. Colocar el half-cluster en el cual se efectuará el cambio del módulo en estado Inactivo, a través del Panel de Control de Redundancia PX2612 o de los Comandos de la Redundancia. Efectuar los cambios necesarios en el half-cluster Inactivo, según lo indicado en el capítulo Configuración de la UCP - Parámetros Generales - Como Realizar el Cambio en Caliente. Colocar el half-cluster nuevamente en estado Reserva o Activo, según se necesite Mensajes de Advertencia del MasterTool Cuando el MasterTool está con un proyecto redundante abierto, o cuando está conectado a una UCP NX3030 identificada como CPA o CPB, algunos mensajes de advertencia especiales podrán ocurrir, según se describe en las próximas subsecciones. Bloqueo de Carga de un Proyecto Redundante o No Redundante El MasterTool no permitirá la carga de un proyecto redundante, a menos que la UCP sea NX3030, y que esta UCP esté identificada como CPA o CPB (ver sección Identificación de un UCP NX3030). EL MasterTool tampoco permitirá la carga de un proyecto no-redundante en una UCP NX3030 identificada como CPA o CPB. En caso de que ocurra un intento de ejecutar alguna de estas acciones ilegales, el MasterTool lo advertirá con un mensaje apropiado. Alertas antes de Comandos que Pueden Parar el CP Activo Algunos comandos, como los siguientes, pueden parar un CP: Carga offline tras Comunicación / Login Depurar / Parar Depurar / Nuevo Breakpoint Comunicación / Reset (caliente, frío, origen) En caso de que el MasterTool esté logueado al CP activo y ocurra un intento de ejecución de uno de estos comandos, antes de enviarlo, el MasterTool envía el siguiente mensaje y aguarda autorización para enviar el comando: “Caso o outro CP estiver no estado Reserva, ele irá assumir como Ativo e desligará este CP. Caso contrário, isto não irá acontecer, mas o processo automatizado não será mais controlado.” Alerta antes de Loguearse al CP No-Activo En circunstancias normales, no es usual el MasterTool loguearse al CP No-Activo, por lo tanto, al haber un intento de ejecución de un comando de este tipo, el MasterTool emite el siguiente aviso: “Você está executando um comando de Login em um CP Não-Ativo e isso não é usual. Você tem certeza que deseja executar esse comando?” 294 6. Redundancia con UCP NX3030 Por otro lado, hay circunstancias (no muy usuales) en que es necesario loguearse al CP No-Activo, y en estos casos el usuario debe autorizar el login. Dichas circunstancias pueden ocurrir, por ejemplo: Para configuraciones iniciales, según lo descrito en la sección Carga Inicial de un Proyecto Redundante. Para cargar off-line un proyecto diferente en el CP No-Activo, según lo descrito en la sección Explorar la Redundancia para Carga Offline de Modificaciones sin Interrupción del Control del Proceso. Para monitorear o forzar variables no-redundantes en el CP No-Activo. Diagnósticos de la Redundancia en el Visor Gráfico de la UCP NX3030 Distintos diagnósticos relativos a la redundancia se pueden observar en el visor de la UCP NX3030. Estado de Redundancia del CP El estado de redundancia del CP, descrito en Estados de un CP Redundante, se ve en los tres caracteres iniciales de la segunda línea de la pantalla principal, según muestra el capítulo Mantenimiento-Visor Gráfico. La pantalla del visor se presenta en la inicialización, y vuelve a presentarse algunos segundos después de terminada la navegación (sin apretar la tecla de la UCP NX3030). Pantallas Abajo del Menú REDUNDANCIA Hay un menú denominado REDUNDANCIA, abajo del cual existen diversas pantallas. La descripción y el acceso a las pantallas de redundancia están disponibles en el capítulo Configuración – Menú Informativo y de Configuración de la UCP. Estructura de Diagnósticos de la Redundancia El área de diagnósticos del módulo NX4010 se mapea sobre variables de representación directa %Q, y definida simbólicamente a través de la directiva AT, en la GLV Diagnostics. Esta sección se divide en dos partes: DG_NX4010.tGeneral: Diagnósticos generales de operación del módulo NX4010. Estos se describen en las Características Técnicas del Módulo de Enlace de Redundancia – CS114900. DG_NX4010.tRedundancy: Diagnósticos específicos de redundancia, las cuales se describen durante el capítulo. Este ítem se divide en otras 6 estructuras de datos: o RedDgnLoc: Contiene diagnósticos de redundancia del CP local (conectado), como por ejemplo, el estado de la redundancia del CP. Esta sección se describe en Diagnósticos de la Redundancia. o RedDgnRem: Es una copia de RedDgnLoc del otro CP, recibida por canales de sincronismo NETA / NETB. De esta forma, el CP local tiene acceso a los diagnósticos del CP remoto. Esta sección se describe en Diagnósticos de la Redundancia. o RedCmdLoc: Contiene comandos de redundancia generados en este CP (local), por ejemplo, a través de escrituras a partir de un sistema SCADA, o generados en POUs de este CP (Ej.: ActivePrg o NonSkippedPrg). Esta sección se describe en Comandos de la Redundancia o RedCmdRem: Se trata de una copia de RedCmdLoc del otro CP (remoto), recibida por canales de sincronismo NETA / NETB. Esta sección se describe en Comandos de la Redundancia. o RedUsrLoc: Utilizado para que el usuario intercambie informaciones entre CPA y CPB. Esta sección se describe en Informaciones del Usuario Cambiados entre CPA y CPB. o RedUsrRem: Utilizado para que el usuario intercambie informaciones entre CPA y CPB. Esta sección se describe en Informaciones del Usuario Cambiados entre CPA y CPB. Es importante destacar que las estructuras de diagnóticos de la redundancia del CP remoto sólo se actualizan cuando se ocurre, con éxito, una sincronización de datos. Por lo tanto, mientras que no se 295 6. Redundancia con UCP NX3030 produce una nueva sincronización él diagnóstico se mantendrá con el valor leído en el intercambio de datos anterior. Además, las estructuras de datos del CP remoto son sólo para lectura. Los valores escritos en las estructuras serán sobrescritos, sin ser considerados, en la siguiente sincronización de datos. Así, no es posible utilizarse de la estructura RedCmdRem para ejecutar un comando en el CP remoto. La estructura que se utiliza para ejecutar comandos en debe siempre ser RedCmdLoc. Diagnósticos de la Redundancia Los diagnósticos de Redundancia pueden tener varias utilidades. Por ejemplo: Se pueden consultar para verificar la existencia de algún problema que necesita solución. Toda vez que ocurren variaciones en éstos, dichas variaciones se insertan como eventos en los logs de usuario. Al consultar la secuencia histórica de dichos eventos se puede descubrir, por ejemplo, la causa de un switchover. Se pueden referenciar en la aplicación del usuario (ActivePrg o NonSkippedPrg). Por ejemplo, se puede testear el estado del CP y, en caso de que no sea Activo, deshabilitar un I/O driver maestro serial MODBUS RTU, en NonSkippedPrg. ATENCIÓN: El diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bExchangeSync (definida a continuación) se debe testear para verificar si la estructura de datos RedDgnRem fue lida ha sido leída con éxito del CP remoto en el último ciclo de la MainTask. En caso de que el valor de este diagnóstico sea FALSE, esto significa que la estructura de datos RedDgnRem no ha sido leída con éxito del CP remoto y, por lo tanto, los valores de RedDgnRem pueden ser inválidos u obsoletos. Como RedDgnRem es una copia de RedDgnLoc del otro CP, las dos estructuras tienen el mismo formato. Estas aún se dividen en cuatro subestructuras: sGeneral_Diag: Diagnósticos generales de redundancia. sNETA_Diag: Diagnósticos del canal de sincronismo NETA. sNETB_Diag: Diagnósticos del canal de sincronismo NETB. sNET_Stat: Estadísticas comunes para los canales de sincronismo NETA y NETB, para conteo de éxitos y fallas de los servicios de sincronización. La subestructura “sGeneral_Diag” posee los siguientes campos para diagnósticos generales de la redundancia: Variable de Representación Directa Variable Bit Variable AT DG_NX4010.tRedundancy.R edDgnLoc.sGeneral_Diag.* Descripción TRUE – El proceso de configuración, ejecutado en el estado No-Configurado, ha terminado. 0 %QB(n+4) 1 bConfigDone FALSE – El proceso de configuración, ejecutado en el estado No-Configurado, aún no ha terminado o no se ejecutó. TRUE – El proceso de configuración, ejecutado en el estado No-Configurado, terminó con errores. Se trata de un error de sistema, normalmente no esperado. Contáctese con el soporte de Altus para reportarlo. Informe también el valor del diagnóstico ConfigErrorCode al soporte de Altus. bConfigError FALSE – El proceso de configuración ocurrió con éxito o no se realizó. 2 bTooManyRedAreas TRUE – El número de áreas redundantes sobrepasó el número máximo permitido. Se trata de un error de sistema, normalmente no esperado. Contáctese con el soporte de Altus para reportarlo. FALSE – El número de áreas redundantes está 296 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable Bit Variable AT DG_NX4010.tRedundancy.R edDgnLoc.sGeneral_Diag.* Descripción dentro de lo esperado. 3 bTemporaryBufferTooSmall TRUE – Estructura de datos intermediaria con tamaño insuficiente. Se trata de un error de sistema, normalmente no esperado. Contáctese con el soporte de Altus para reportarlo. FALSE – El tamaño de la estructura de datos está dentro de lo esperado. 4 5 6 7 bExchangeSync bRedDataSync bRedForceSync bApplicationIncompatible TRUE – El servicio de sincronización Cambio de Diagnósticos y Comandos se ejecutó con éxito en este ciclo de MainTask. FALSE – La estructura RedDgnRem tiene valores obsoletos o inválidos, pues no fue leída del otro CP (remota) en este ciclo de MainTask. TRUE – El servicio Sincronización de Datos Redundantes se ejecutó con éxito en este ciclo de MainTask. FALSE – El servicio Sincronización de Datos Redundantes no se ejecutó con éxito en este ciclo de MainTask. TRUE – El servicio Sincronización de la Lista de Forzamientos Redundantes se ejecutó con éxito en este ciclo de MainTask. FALSE – El servicio Sincronización de la Lista de Forzamientos Redundantes no se ejecutó con éxito en este ciclo de MainTask. TRUE – La aplicación no es compatible entre los dos CPs. Consultar sección Incompatibilidad de Aplicaciones FALSE La aplicación es compatible entre los dos CPs. 0 1 Reservado Bit reservado. bProjectSyncDisable %QB(n+5) TRUE – La sincronización de proyectos está deshabilitada. No será efectuada la sincronización de proyectos. Se trata de una copia de la variable no volátil utilizada para deshabilitar la sincronización de proyectos, según lo descrito en la sección Deshabilitación de la Sincronización de Proyectos. La sincronización de proyectos se puede deshabilitar tanto en el CP local como en el remoto, es decir, basta ejecutar el comando de Deshabilitación en uno de los CPs para que la sincronización de proyectos se deshabilite. Los comandos de Deshabilitación del sincronismo de proyectos se describen en la sección Deshabilitación de la Sincronización de Proyectos. FALSE - significa que la sincronización de proyectos está habilitada. 2 bIncompatibleFirmware TRUE – Este CP ha ido hacia el estado NoConfigurado pues su versión de firmware es incompatible con la versión de firmware del CP Activo. FALSE – La versión de firmware del CP activo es compatible con la versión de firmware del CP no-activo. 3 bApplicationProjectDiff 4 bProjectArchiveDiff TRUE – Lo proyecto aplicativo de este CP es diferente del proyecto aplicativo del CP Activo. FALSE – El proyecto aplicativo de este CP es igual al del CP Activo. TRUE – Lo project archive es diferente del project archive del CP Activo. FALSE – Lo project archive es igual al project 297 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable Bit Variable AT DG_NX4010.tRedundancy.R edDgnLoc.sGeneral_Diag.* Descripción archive del CP Activo 5 6 bOnlineChangeApply TRUE – Se realizó alguna alteración online en la aplicación y esta aun no se sincronizó con el CP reserva. FALSE – No se realizaron alteraciones online en la aplicación o estas ya han sido sincronizadas con el CP reserva. TRUE – Falla en el módulo NX4010. La UCP NX3030 no consigue comunicarse con este módulo a través del bus, o existe una falla en el microprocesador del NX4010. bFailedRED FALSE – El módulo NX4010 está en correcto funcionamiento. 7 bFailedPBUS1A TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 1 A. El modo activo (comunicando con esclavos) lo asume el CP Activo. El modo pasivo (que comunica con el maestro en modo activo) lo asume el CP NoActivo. Esta falla también se puede indicar en caso de que el módulo NX5001 tenga una falla en su microprocesador, o en caso de que no consiga comunicarse con la UCP NX3030 por bus. FALSE – No existen fallas en la red PROFIBUS 1 A. 0 bFailedPBUS1B TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 1 B. El modo activo (comunicando con esclavos) lo asume el CP Activo. El modo pasivo (que comunica con el maestro en modo activo) lo asume el CP NoActivo. Esta falla también se puede indicar en caso de que el módulo NX5001 tenga una falla en su microprocesador, o en caso de que no consiga comunicarse con la UCP NX3030 por bus. FALSE – No existen fallas en la red PROFIBUS 1 B. 1 bFailureProfibus_1 %QB(n+6) TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 1. En caso de que la red PROFIBUS 1 sea redundante, FailureProfibus_1 resulta de un “Y lógico” entre FailedPBUS1A y FailedPBUS1B. En caso de que la red PROFIBUS 1 no sea redundante, FailureProfibus_1 es una copia de FailedPBUS1A. FALSE – No existen fallas en la red PROFIBUS 1. 2 bFailedPBUS2A TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 2 A. El modo activo (que comunica con esclavos) lo asume el CP Activo. El modo pasivo (que comunica con el maestro en modo activo) lo asume el CP No-Activo. Esta falla también se puede indicar en caso de que el módulo NX5001 tenga un falla en su microprocesador, o en caso de que no consiga comunicarse con la UCP NX3030 por bus. FALSE – No existen fallas en la red PROFIBUS 2 A. 3 bFailedPBUS2B 298 TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 2 B. El modo activo (que comunica con esclavos) lo asume el CP Activo. El modo pasivo (que comunica con el maestro 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable Bit Variable AT DG_NX4010.tRedundancy.R edDgnLoc.sGeneral_Diag.* Descripción en modo activo) lo asume el CP No-Activo. Esta falla también se puede indicar en caso de que el módulo NX5001 tenga una falla en su microprocesador, o en caso de que no consiga comunicarse con la UCP NX3030 por bus. FALSE – No existen fallas en la red PROFIBUS 2 B. 4 bFailureProfibus_2 TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) en la red PROFIBUS 2. En caso de que la red PROFIBUS 2 sea redundante, FailureProfibus_2 resulta de un “Y lógico” entre FailedPBUS2A y FailedPBUS2B. En caso de que la red PROFIBUS 2 no sea redundante, FailureProfibus_2 es una copia de FailedPBUS2A. FALSE – No existen fallas en la red PROFIBUS 2. 5 bProfibusVitalFailureAny TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) con por lo menos una de las redes PROFIBUS configuradas en modo de falla vital. FALSE – No existen fallas en las redes PROFIBUS configuradas en modo de falla vital. 6 bProfibusVitalFailureAll TRUE – Este CP no consigue comunicarse en el papel de maestro (modo activo o pasivo) con todas las redes PROFIBUS configuradas en modo de falla vital. FALSE – No existen fallas en las redes PROFIBUS configuradas en modo de falla vital. 7 bTurnOffOtherPLC_Normal TRUE – Este CP está cerrando el relé del PX2612 para mantener el otro CP desconectado en condiciones normales, y no debido al modo test del panel PX2612. FALSE – El relé del PX2612 está conectado (bTurnOffOtherPLC_TestMode) o desconectado. 0 bTurnOffOtherPLC_TestMode TRUE – Este CP está cerrando el relé del PX2612 para mantener el otro CP desconectado debido al modo test del panel PX2612. FALSE – El relé del PX2612 está conectado (bTurnOffOtherPLC_Normal) o desconectado. TRUE – El LED ACTIVE del PX2612 está conectado. 1 2 bActiveLED FALSE – El LED ACTIVE del PX2612 está parpadeando (bBlinkActiveLED) o desconectado. bBlinkActiveLED %QB(n+7) TRUE – El LED ACTIVE del PX2612 está parpadeando. FALSE – El LED ACTIVE del PX2612 está conectado (bActiveLED) o desconectado. TRUE – El LED STAND-BY del PX2612 está conectado. 3 4 bStandbyLED bBlinkStandbyLED FALSE – El LED STAND-BY del PX2612 está parpadeando (bBlinkStandbyLED) o desconectado. TRUE – El LED STAND-BY del PX2612 está parpadeando. FALSE – El LED STAND-BY del PX2612 está conectado (bStandbyLED) o desconectado. TRUE – El LED INACTIVE del PX2612 está conectado. 5 bInactiveLED FALSE – El LED INACTIVE del PX2612 está desconectado o parpadeando (bBlinkInactiveLED). 299 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable %QB(n+8) Bit Variable AT DG_NX4010.tRedundancy.R edDgnLoc.sGeneral_Diag.* 6 bBlinkInactiveLED 7 bRedPanelTestMode - Descripción TRUE – El LED INACTIVE del PX2612 está parpadeando. FALSE – El LED INACTIVE del PX2612 está conectado (bInactiveLED) o desconectado. TRUE – El panel PX2612 está en modo test. FALSE – El panel PX2612 está en modo normal. Este diagnóstico informa la identificación de este CP: - 0 = no-redundante - 2 = CPA - 3 = CPB Se trata de una copia de la variable no-volátil que se utiliza para identificar el CP, según lo descrito en la sección Identificación de un UCP NX3030. En la sección Carga Inicial de un Proyecto Redundante se describe el comando del MasterTool que se utiliza para escribir sobre esta variable no-volátil. ePLC_ID Informa el estado de redundancia de este CP: - No-Configurado = 0 - Inicializando = 2 - Reserva = 3 - Activo = 4 - Inactivo = 5 %QB(n+9) - eRedState %QB(n+10) - ePreviousRedState Valor que el diagnóstico RedState poseía antes de la última transición de estados. %QW(n+11) - wRedStateDuration Mide desde hace cuanto tiempo (milisegundos) el estado de redundancia actual ha sido asumido. Este tiempo para de incrementar al alcanzar 65535 ms. %QW(n+13) - wConfigErrorCode Código de error descubierto durante el proceso de configuración en el estado No-Configurado. Ver diagnóstico ConfigError descrito anteriormente. %QD(n+15) - dwApplicationCRC CRC de 32 bits del proyecto aplicativo, se utiliza para detectar diferencias entre los proyectos aplicativos de los 2 CPs. %QD(n+19) - dwArchiveCRC %QD(n+23) - dwFirmwareVersion Versión de firmware de este CP, se utiliza para verificar compatibilidad entre el firmware de los 2 CPs. dwIECTimer La sincronización del IEC Timer es necesaria para operación bump-less de algunos bloques funcional como TON y TOF. A través de este diagnóstico el IEC Timer del CP Activo se recibe y actualizado en el CP No-Activo, desde que el servicio Cambio de Diagnósticos y Comandos haya sido ejecutado con éxito. Su conteo inicia en 0 e incrementa hasta 4294967295. Tras el desbordamiento de conteo, reinicia con valor 0. wCycleCounter Contador de 16 bits se utiliza como información auxiliar de secuencia en los Logs de Eventos de la Redundancia. En el CP Activo, se incrementa a cada ciclo de MainTask. En el CP No-Activo, recibe una copia del valor existente en el CP Activo, desde que el servicio Cambio de Diagnósticos y Comandos haya sido ejecutado con éxito. Su conteo inicia en 0 e incrementa hasta 65535. Tras el desbordamiento de conteo, reinicia con valor 0. %QD(n+27) %QW(n+31) - - CRC de 32 bits del project archive, se utiliza para detectar diferencias entre los project archives de los 2 CPs. Tabla 6-6. Diagnósticos Generales de la Redundancia 300 6. Redundancia con UCP NX3030 Notas: Visualización de las Estructuras de Diagnósticos: Las Estructuras de Diagnósticos añadidos al proyecto se pueden ver al acceder el ítem “Library Manager” en la tree view de la ventana del MasterTool IEC XE. Con eso, es posible ver todos los datatypes definidos en la estructura. Variable de Representación Directa: La “n” representa el valor configurado en el módulo NX4010, a través del software MasterTool IEC XE, como Dirección Inicial de Diagnósticos en %Q. Esta definición vale para todas las estructuras de diagnósticos. Directiva AT: La directiva AT es una palabra reservada en el software programador, que se relaciona a una dirección de una variable. En el caso del módulo NX4010 la variable DG_NX4010 está relacionada a la dirección inicial de diagnósticos del módulo. La subestructura “sNETA_Diag” posee los siguientes campos para diagnósticos de los canales de sincronismo NETA: DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bExchangeSync: Al estar esta variable de diagnóstico con el valor FALSE, no es posible definir el estado de algunos diagnósticos más, como por ejemplo bIncompatibleFirmware, bApplicationProjectDiff y bProjectArchiveDiff. No representarán el valor correcto pues dependen del correcto funcionamiento de la comunicación entre los dos CPs para que la información se pueda generar correctamente. Variable de Representación Directa Variable Bit 0 Variable AT DG_NX4010.tRedundancy.Re dDgnLoc.sNETA_Diag.* bGeneralFailure Descripción TRUE – El canal de sincronismo posee algún tipo de falla. Los 3 próximos diagnósticos indicarán la falla específica. FALSE – El canal de sincronismo está en correcto funcionamiento. 1 bInternalFailure TRUE – La falla detectada tiene su causa ubicada dentro de este CP. Dichas fallas se tratan de manera diferente. FALSE – El módulo NX4010 está en correcto funcionamiento. %QB(n+33) 2 bLinkDownFailure 3 bTimeoutFailure TRUE – El cable AL-2319A está desconectado del módulo NX4010 o roto, en uno de los 2 CPs. FALSE – El cable AL-2319A está conectado al módulo NX4010. TRUE – Esta falla se reporta en caso de que un servicio de sincronización no haya terminado con éxito hasta un time-out especificado, y no hayan sido encontradas fallas del tipo bInternalFailure o bLinkDownFailure que justificaran eso. FALSE – El módulo NX4010 está en correcto funcionamiento. 4a7 bReserved[4..7] Reservados. Tabla 6-7. Diagnósticos Específicos de la Interfaz NETA La subestructura “sNETB_Diag” posee los siguientes campos para diagnósticos de los canales de sincronismo NETB: Variable de Representación Directa Variable %QB(n+34) Bit 0 Variable AT DG_NX4010.tRedundancy.Re dDgnLoc.sNETB_Diag.* bGeneralFailure Descripción TRUE – O El canal de sincronismo posee algún tipo de falla. Las 3 próximps diagnósticos indicarán la falla específica. FALSE – El canal de sincronismo está en correcto funcionamiento. 301 6. Redundancia con UCP NX3030 1 TRUE – La falla detectada tiene su causa ubicada dentro de este CP. Dichas fallas se tratan de manera diferente. bInternalFailure FALSE – El módulo NX4010 está en correcto funcionamiento. 2 TRUE – El cable AL-2319B está desconectado del módulo NX4010 o roto, en uno de los 2 CPs. bLinkDownFailure FALSE – El cable AL-2319 está conectado al módulo NX4010. 3 TRUE – Esta falla se reporta en caso de que un servicio de sincronización no haya terminado con éxito hasta un time-out especificado, y no hayan sido encontradas fallas del tipo bInternalFailure o bLinkDownFailure que justificaran eso. bTimeoutFailure FALSE – El módulo NX4010 está en correcto funcionamiento. 4a7 bReserved[4..7] Reservados. Tabla 6-8. Diagnósticos Específicos de la Interfaz NETB La subestructura “sNET_Stat” contiene estadísticas de fallas y sucesos de los servicios. Las estadísticas de los CPs local y remoto se pueden reiniciar a través de los comandos: //CP Local DG_NX4010.tRedundancy.RedCmdLoc.bResetNETStatisticsLocal := TRUE; //CP Remoto DG_NX4010.tRedundancy.RedCmdLoc.bResetNETStatisticsRemote := TRUE; La subestructura contiene los siguientes contadores: Variable de Representación Directa Variable AT DG_NX4010.tRedundancy. RedDgnLoc.sNET_Stat.* %QW(n+35) wSuccessExchDgCmdSync %QW(n+37) wFailedExchDgCmdSync %QW(n+39) wSuccessRedDataSync %QW(n+41) wFailedRedDataSync %QW(n+43) wSuccessRedForceSync Conteo de sucesos del servicio Sincronización de Lista de Forzamientos Redundantes. (0 a 65535) %QW(n+45) wFailedRedForceSync Conteo de fallas del servicio Sincronización de Lista de Forzamientos Redundantes. (0 a 65535) %QB(n+47) byReserved[1..8] Descripción Conteo de sucesos del servicio Cambio de Diagnósticos y Comandos. (0 a 65535) Conteo de fallas del servicio Cambio de Diagnósticos y Comandos. (0 a 65535) Conteo de sucesos del servicio Sincronización de Datos Redundantes. (0 a 65535) Conteo de fallas del servicio Sincronización de Datos Redundantes. (0 a 65535) Reservados. Tabla 6-9. Diagnósticos Específicos de la Interfaz Nota: Contadores: Todos los contadores vuelven a cero cuando su valor límite sobrepasa. 302 6. Redundancia con UCP NX3030 Comandos de la Redundancia Los campos de comandos de las estructuras RedCmdLoc y RedCmdRem poseen siempre un sufijo que se pone en Local o Remote. Por ejemplo, existen los campos de comando StandbyLocal y StandbyRemote, que tiene efecto equivalente al botón STAND-BY del panel PX2612. Un comando con sufijo Local generado en RedCmdLoc se ejecutará en el propio CP (local). Por otro lado, un comando con sufijo Remote generado en RedCmdLoc se ejecutará en el otro CP (remoto). Esto funciona de la siguiente forma: El CP remoto, a cada ciclo de MainTask, recibe una copia de RedCmdLoc del CP local por NETA / NETB, y esta copia se llama RedCmdRem al CP remoto. El CP remoto solamente ejecuta comandos de RedCmdRem que tengan el sufijo Remote. Ejemplo 1: si el CP local está en estado Activo, y se desea conmutarlo al estado Reserva, se puede conectar el bit DG_NX4010.tRedundancy.RedCmdLoc.bStandbyLocal al CP local. Ejemplo 2: si el CP remoto está en estado Activo, y se desea conmutarlo hacia el estado Reserva, se puede conectar el bit DG_NX4010.tRedundancy.RedCmdLoc.bStandbyRemote al CP local. Esto es útil, por ejemplo, si la comunicación de un sistema SCADA no está disponible temporariamente con el CP remoto. En este caso, el comando se escribe por el SCADA en el CP local, que lo repasa al CP remoto por NETA / NETB. ATENCIÓN: Si el diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bExchangeSync indica falla en el servicio Cambio de Diagnósticos y Comandos, un comando con sufijo Remote no se podrá repasar hacia el CP remoto, y por lo tanto no se ejecutará. Para disparar un comando, se debe siempre conectar el bit correspondiente en RedCmdLoc. Esto se puede hacer por un sistema SCADA, haciendo una escritura por MasterTool, o incluso conectar el bit dentro de una POU como ActivePrg o NonSkippedPrg. El usuario no necesita preocuparse con la desconexión del bit de comando, que se hará automáticamente por el gerenciador de redundancia: En el caso de comandos ejecutados en el CP local (RedCmdLoc + comando con sufijo Local), el bit se desconecta en cuanto el comando se perciba y ejecute. En el caso de comandos ejecutados en el CP remoto (RedCmdRem + comando con sufijo Remote): o en el CP remoto, el comando se ejecuta cuando el gerenciador de redundancia percibe un borde de subida en el bit de comando. o en el CP local en el cual el comando se ha generado, el bit se desconecta automáticamente en el próximo ciclo de MainTask. ATENCIÓN: Hay dos bits de comando que normalmente se deben desconectar por el usuario: DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal Y DG_NX4010.tRedundancy. RedCmdLoc.bTestRelayLocal. Ver Más detalles sobre estos comandos adelante en esta sección. En caso de que el usuario haya olvidato de desconectarlos, existen mecanismos automáticos previstos para hacerlo. Es importante resaltar que cualesquier conexiones o desconexiones de comandos se registrarán en los logs de eventos de la redundancia, lo que es importante para evaluación histórica, por ejemplo, para determinar las causas de un switchover. A continuación, se definen los campos de las estructuras RedCmdLoc Y RedCmdRem: 303 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable Bit 0 Variable AT DG_NX4010.tRedundancy.Re dCmdLoc.* bButtonTurnOnLocal Descripción TRUE – Se trata de una copia procesada del botón TURN ON PLCx leído del panel PX2612. Este bit sólo se conecta un segundo después de que se presione el botón, y se desconecta inmediatamente al liberarlo. Es importante resaltar que este bit se conectará cuando el botón TURN ON del CP remoto esté presionado, visto que este tipo de comando siempre se envía del CP remoto. FALSE – El botón TURN ON PLCx no está presionado. 1 bButtonStandbyLocal TRUE – Se trata de una copia procesada del botón STAND-BY leído del panel PX2612. Este bit sólo se conecta un segundo después del presionamiento del botón, y se desconecta inmediatamente al liberarlo. FALSE – El botón STAND-BY no está presionado. 2 bButtonInactiveLocal TRUE – Se trata de una copia procesada del botón INACTIVE leído del panel PX2612. Este bit sólo se conecta un segundo después del presionamiento del botón, y se desconecta inmediatamente al liberarlo. FALSE – El botón INACTIVE no está presionado. %QB(n+55) 3 bAutoConfigLocal TRUE – Este diagnóstico informa una solicitud de configuración automática, necesaria para salir del estado NoConfigurado en algunas situaciones. FALSE – Solicitud de configuración automática deshabilitada. 4 bTurnOnLocal TRUE – Este comando produce una acción equivalente al botón TURN ON PLCX del PX2612, en el CP local. FALSE – El botón TURN ON PLCx del CP local no está presionado. 5 bStandbyLocal TRUE – Este comando produce una acción equivalente al botón STAND-BY del PX2612, en el CP local FALSE – El botón STAND-BY del CP local no está presionado. 6 bInactiveLocal TRUE – Este comando produce una acción equivalente al botón INACTIVE del PX2612, en el CP local. FALSE – El botón INACTIVE del CP local no está presionado. 7 bResetNETStatisticsLocal TRUE Este comando apaga las estadísticas de NETA / NETB (vea subestructura SNET_Stat en RedDgnLoc e RedDgnRem). Dichas estadísticas son contadores de fallas y éxitos en servicios de sincronización FALSE – El comando de reset de las estadísticas de NETA / NETB en el CP local no ha sido accionado. %QB(n+56) 0 bTestModeLocal 304 TRUE – Este comando coloca el panel PX2612 en modo test, lo que permite que sus componentes ejecuten autotests (LEDs, relés y botones), según se explica en la sección Test del Panel PX2612. El modo test del PX2612 sólo se acepta efectivamente cuando este bit se conecta en los dos CPs. Es decir, para que el PX2612 esté en modo test, el CP verifica si 6. Redundancia con UCP NX3030 Variable de Representación Directa Variable Bit Variable AT DG_NX4010.tRedundancy.Re dCmdLoc.* Descripción RedCmdLoc.bTestModeLocal y si RedCmdRem.bTestModeLocal están ambos conectados. El diagnóstico RedDgnLoc.bRedPanelTestMode se conecta para informar que el PX2612 está realmente en modo test. Normalmente, el usuario debe desconectar el bit bTestModeLocal en los 2 CPs en cuanto concluya los tests del PX2612, pero en caso de que se olvide de hacerlo, el bit se desconectará automáticamente 15 minutos después de que se conecte. FALSE – El comando que coloca el panel PX2612 en modo test está desactivado. 1 bTestRelayLocal TRUE – Este comando se usa para testear el relé NA del PX2612, y en consecuencia también el relé NF externo, que se usan para una eventual desconexión del otro CP. Este comando sólo se acepta mientras el PX2612 está en modo test, y se desconecta automáticamente e se ignora en caso de que el PX2612 no esté en modo test. Normalmente, el usuario debe desconectar el bit bTestRelayLocal en cuanto concluya el test del relé, pero en caso de que se olvide de hacerlo, el bit se desconectará en cuanto el modo test se cierre. Es importante también resaltar que este comando sólo se acepta en el CP Activo, para evitar que el CP No-Activo desconecte el CP Activo. FALSE – El comando utilizado para testear el relé NA del PX2612 está desactivado 2 bStandbyRemote TRUE – Este comando produce una acción equivalente al botón STAND-BY del PX2612, en el CP remoto. FALSE – El botón STAND-BY del CP remoto no está presionado. 3 bInactiveRemote TRUE – Este comando una acción equivalente al botón INACTIVE del PX2612, en el CP remoto. FALSE – El botón INACTIVE del CP local no está presionado. 4 bResetNETStatisticsRemote 5a7 bReserved[5..7] TRUE – Produce una acción equivalente al comando ResetNETStatisticsLocal, sin embargo, esta vez en el CP remoto. FALSE – El comando de reset de las estadísticas de NETA / NETB en el CP local no ha sido accionado Reservados. Tabla 6-10. Comandos de la Redundancia Informaciones del Usuario Cambiados entre CPA y CPB El servicio de sincronización Cambio de Diagnósticos y Comando, cambia las siguientes estructuras de datos entre los 2 CPs en cada ciclo de MainTask, al usar los canales de sincronismo NETA / NETB: Diagnósticos de Redundancia (RedDgnLoc y RedDgnRem), antes presentadas en la sección Estructura de Diagnósticos de la Redundancia. Comandos de Redundancia (RedCmdLoc y RedCmdRem), antes presentados en la sección Comandos de la Redundancia. 305 6. Redundancia con UCP NX3030 Informaciones del Usuario Cambiados entre CPA y CPB (RedUsrLoc e RedUsrRem), que se presentarán en esta sección. Las estructuras RedUsrLoc y RedUsrRem son simplemente un array de 128 bytes, cuya utilización se puede definir de forma libre por el usuario. Esto permite que el usuario transfiera, a cada ciclo, 128 bytes de información del CPA al CPB, y otros 128 bytes del CPB al CPA. RedUsrRem es una copia de RedUsrLoc del otro CP, recibida por NETA / NETB. Determinado CP escribe informaciones en RedUsrLoc, que se leerán en el otro CP en RedUsrRem. Estas estructuras de datos pueden tener distintas utilidades. Por ejemplo, suponiendo que el sistema SCADA se conecte solamente al CP Activo, y que se deseen ver algunas informaciones del CP NoActivo, el CP No-Activo puede colocar estas informaciones en esta estructura de datos. Entre dichas informaciones, por ejemplo, pueden constar algunos diagnósticos que no estén mapeadoas en RedDgnLoc y RedDgnRem. Diagnósticos MODBUS utilizados en la Redundancia Para verificar si existe falla en todos los MODBUS Server configurados en una instancia MODBUS Client, existe un diagnóstico específico en cada instancia MODBUS Client configurada. E la Tabla 6-11, se muestra el diagnóstico para este tipo de falla en una instancia MODBUS Client llamada MODBUS_Symbol_Client. Variable DG_MODBUS_Symbol_Clien t.tDiag.* Descripción TRUE – Todos los Servers configurados en este Client presentan error. FALSE –. bAllDevicesCommFailure FALSE – Existe por lo menos un Server configurado en este Client que no presenta error. Tabla 6-11. Diagnóstico MODBUS Client Al estar configurado con falla vital Ethernet, este diagnóstico se consulta y 3 segundos tras la alteración de su estado de FALSE a TRUE, ocurre un switchover en el caso de que las demás condiciones para este evento se vean satisfechas. Logs de Evento de la Redundancia El MasterTool permite observar distintos logs para un CP Nexto, entre los cuales se encuentran los Logs de Eventos de la Redundancia. Esos mensajes, específicas para redundancia, registran en el Log de Sistema modificaciones en prácticamente todos los campos de las estructuras de datos de diagnósticos y comandos de redundancia, que son las siguientes: RedDgnLoc RedDgnRem RedCmdLoc RedCmdRem En caso de que las estructuras de diagnósticos, sólo los campos a continuación no generan logs de eventos: wRedStateDuration wCycleCounter dwIECTimer SyncLinkStatistics NET_Stat Cada línea presentada en el log posee las siguientes columnas: Marca de Tiempo: fecha y hora del evento, con resolución de milisegundos. 306 6. Redundancia con UCP NX3030 Severidad: información, advertencia, error o excepción. Descripción: texto que describe el evento Componente: componente que generó el evento, que en el caso del Redundancy Event Log, será el “Redundancy Management”. El texto en la columna “Descripción” contiene las siguientes informaciones: El nombre del diagnóstico o comando que ha sufrido modificación. El nuevo valor asumido por este diagnóstico o comando. El valor de RedDgnLoclsGeneral_Diag.wCycleCounter, que se puede usar como información auxiliar de secuencia. El valor de RedDgnRem.sGeneral_Diag.CycleCounter, que se puede usar como información auxiliar de secuencia. Un ejemplo de la columna Descripción podría ser el siguiente: RedDgnLoc.sGeneral_Diag.eRedStat = Active [Local cycle = 1234, Remote cycle = 1233]. Para acceder a esta pantalla, se debe dar un doble clic sobre el dispositivo (NX3030) en el árbol de dispositivos, y después seleccionar la pestaña “Log”. Existe un filtro que permite seleccionar solamente el componente “Redundancy Management”, para exhibir solamente los eventos de redundancia. ATENCIÓN: Algunos diagnósticos pueden señalar posibles fallas durante la inicialización del sistema redundante y en los primeros ciclos de las tareas. Pero, para funcionar correctamente el sistema, estos diagnósticos vuelven a indicar la ausencia de errores enseguida después de la inicialización del sistema. Test del Panel PX2612 El panel PX2612 está constituido de botones, LEDs y relés. Muchos de estos recursos se utilizan poco, y por lo tanto difícilmente se testean para percibir que poseen algún defecto. Es importante que, periódicamente, se hagan tests para verificar si estos recursos están funcionando, para evitar que fallas permanezcan ocultas e impidan el uso del PX2612 cuando sea necesario. Entrada en el Modo Teste El primer paso para testear el PX2612 es colocarlo en modo teste. Esto se hace al conectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en los dos CPs. Determinado CP percibirá que está en modo teste siempre que los dos siguientes bits estén conectados: DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal (RedCmdLoc.bTestModeLocal conectado en este CP) DG_NX4010.tRedundancy.RedCmdRem.bTestModeLocal (RedCmdLoc.bTestModeLocal conectado en otro CP) Cuando estos dos bits están conectados, el CP conecta el bit de diagnóstico DG_NX4010.tRedundancy.RedDgnLoc.sGeneral_Diag.bRedPanelTestMode, para informar que el PX2612 está en modo teste. Salidas Manual y Automática del Modo Teste El usuario puede cerrar el modo teste manualmente, al desconectar el bit DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en los dos CPs. En verdad, basta desconectarlo en uno de los CPs, pues el modo test exige que este bit esté conectado en los 2 CPs. Sin embargo, se aconseja desconectarlo en los 2 CPs. 307 6. Redundancia con UCP NX3030 En caso de que el usuario se olvide de desconectar el DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal, este bit se desconecta automáticamente, 15 minutos después de haberse conectado, cerrando automáticamente el modo teste. Test de los LEDs Durante el modo teste, los 6 LEDs deben estar parpadeando, perdiendo su utilidad normal, que es mostrar el estado de redundancia. Test de los Botones Al presionar un botón en el modo test, un LED correspondiente no estará más parpadeando, y quedará encendido. La tabla a continuación muestra la correspondencia entre el botón presionado y el LED que permanecerá encendido. Botón testeado LED Correspondiente TURN ON PLC A ACTIVE – PLC B STAND-BY PLC A STAND-BY PLC A INACTIVE PLC A INACTIVE PLC A TURN ON PLC B ACTIVE – PLC A STAND-BY PLC B STAND-BY PLC B INACTIVE PLC B INACTIVE PLC B Tabla 6-12. Correspondencia entre Botones y LEDs en el Testeo de Botones del PX2612 Se percibe que, normalmente, el LED queda al lado del botón presionado, excepto para los botones TURN ON PLCx. Antes que el LED permanezca encendido, es necesario mantener el botón presionado por, en lo mínimo, un segundo. El LED vuelve a parpadear en cuanto el botón se libere. Durante el modo test, los botones no permiten ejecutar las funciones que ejecutarían fuera del modo test, así como provocar un cambio de estado de redundancia. Testeo de los Relés Para testear los relés, se creó el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal. Cuando se conectar este bit, si este CP esté en modo test, y también en estado Activo, este accionará el relé, lo que deberá provocar la desconexión del otro CP (No-Activo). Desconectando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal, el relé se libera, lo que permite la reconexión del otro CP. El comando no tiene efecto en el CP No-Activo, para evitar que este desconecte el CP Activo. El usuario deberá provocar un switchover entre CPs (Activo X No-Activo), para testear el relé en los 2 CPs. Cuando el CP que se ha desconectado se reconecta y reinicializa, vuelve con DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal desligado, por lo tanto, el modo teste se canceló. Se debe conectar nuevamente el bit DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en este CP, en este CP, y pasarlo al estado Activo, antes de testear su relé. Cuando el modo test se cierra, el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal se desconecta automáticamente, en caso de que el usuario lo haya olvidato conectado. Secuencia Sugerida para Ejecutar los Tests del PX2612 La siguiente secuencia se sugiere para ejecutar los tests del PX2612: 308 6. Redundancia con UCP NX3030 1. Conectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en los 2 CPs (CPA y CPB). 2. Se debe observar que los 6 LEDs están parpadeando. 3. Presionar, uno a uno, los 6 botones, y verificar si el LED correspondiente para de parpadear y permanece encendido mientras el botón está presionado. Hay que recordarse que el botón debe quedar presionado en lo mínimo por un segundo antes que el LED pare de parpadear y quede encendido, y que el LED volverá a parpadear en cuando se libere el botón. 4. Conectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal en el CP Activo. Se debe observar la desconexión del CP No-Activo. 5. Desconectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal en el CP Activo. . Se debe observar la reconexión del CP No-Activo. 6. Aguardar que el CP No-Activo se reinicialice y asuma el estado Reserva. El modo test no estará activo, pues el bit DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal se desconectó en la inicialización del CP que ahora está en Reserva. 7. Provocar un switchover entre CPs, presionando el botón STAND-BY del CP Activo. El uso normal del botón STAND-BY es posible porque el modo test no está activo. 8. Conectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en el nuevo CP Activo, que terminó de salir del modo Reserva. De esta forma, el modo test vuelve a estar activo. En caso de que el bit del CP Reserva esté desconectado, este se debe conectar nuevamente. 9. Conectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal en el CP Activo. Se debe observar la desconexión del CP No-Activo. 10. Desconectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestRelayLocal en el CP Activo. Se debe observar la reconexión del CP No-Activo. 11. Desconectar el bit de comando DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal en el CP Activo, para cerrar el modo test. No es necesario hacer esto en el CP Reserva, pues este se terminó de inicializar, con el bit DG_NX4010.tRedundancy.RedCmdLoc.bTestModeLocal desconectado. 309 7. Mantenimiento 7. Mantenimiento Diagnósticos del Módulo Una de las características de la Serie Nexto es la generación de diagnósticos de anormalidades, sean fallas, errores o modos de operación, lo que posibilita al operador identificar y solucionar problemas que vengan a ocurrir con el sistema con gran facilidad. Las UCPs Nexto proporcionan distintas maneras de visualizar los diagnósticos generados por el sistema: Diagnósticos One Touch Diagnósticos vía LED Diagnósticos vía WEB Diagnósticos vía Variables Diagnósticos vía Bloques Funcionales El primero es una característica innovadora de la Serie Nexto, la cual posibilita rápido acceso a las condiciones anormales de la aplicación. El segundo es puramente visual, generado a través de dos LEDs presentes en el panel (DG y WD) y también de los LEDs presentes en el conector RJ45 (exclusivos para la conexión Ethernet). La próxima característica es la visualización gráfica en una página WEB del bastidor y los respectivos módulos configurados, siendo que se permite el acceso individual del estado de operación y los diagnósticos activos. Los diagnósticos también se almacenan directamente en variables de la UCP, tanto de representación directa (%Q), como las simbólicas mapeadas a través de la directiva AT, y se pueden utilizar por la aplicación del usuario, por ejemplo, se presentan en un sistema de supervisión. Los últimos presentan condiciones específicas de funcionamiento del sistema. La función de estos diagnósticos es apuntar posibles problemas de instalación o configuración del sistema, y de problemas o deficiencias de las redes de comunicación. El capítulo de Mantenimiento se debe consultar por el usuario siempre que necesario. Diagnósticos One Touch One Touch Diag (OTD), es decir, con un sólo toque, es una exclusiva característica que la Serie Nexto trae a los controladores programables. Con este nuevo concepto el usuario puede verificar los diagnósticos de cualquier módulo presente en el sistema directamente en el visor gráfico de la UCP con un sólo toque en la tecla de diagnóstico del respectivo módulo. Esa es una poderosa herramienta de diagnóstico que se puede usar off-line (sin supervisor o software programador) lo que vuelve más fácil encontrar y resolver rápidamente posibles problemas. La tecla de diagnóstico está ubicada en la parte superior de la UCP, en lugar de fácil acceso, y, además de proveer los diagnósticos activos, permite el acceso al menú de navegación, descrito en el capítulo Configuración – Menú Informativo y de Configuración de la UCP. La Figura 7-1 muestra la ubicación de la tecla en la UCP: 310 7. Mantenimiento Figura 7-1. Tecla de Diagnóstico Con sólo un clic corto, la UCP comienza a mostrar los diagnósticos del bus (cuando activos, en caso contrario exhibe el mensaje “SIN DIAG”). Inicialmente, se verá la Tag (configurada en las propiedades del módulo en el software MasterTool IEC XE, siguiendo la IEC 61131-3), es decir, el nombre atribuido a la UCP, y se mostrarán todos los diagnósticos, a través de mensajes en el visor de la UCP. Ese proceso se ejecutará por dos veces en el visor. Todo ocurre de forma automática, siendo que el usuario solamente deberá hacer el clic corto inicial y la UCP será responsable por exhibir los diagnósticos. Los diagnósticos de otros módulos presentes en el bus también se exhibirán en el visor gráfico de la UCP, a través de un clic corto en la tecla de diagnóstico de los mismos, en lo mismo modelo de la presentación de los diagnósticos de la UCP. La Figura 7-2 muestra todo el proceso a partir del clic corto, siendo la condición y los tiempos de la UCP representados en los rectángulos menores. Es importante resaltar que los diagnósticos podrán tener más de una pantalla, es decir, el tiempo especificado en el flujograma a continuación es válido para cada una delas. 311 7. Mantenimiento Figura 7-2. Visualización de los Diagnósticos de la UCP Para finalizar, antes de que todo el proceso de visualización se efectúe, basta con hacer un clic corto en la tecla de diagnóstico, en cualquier momento, o presionar la tecla de diagnóstico de algún módulo de E/S presente en el bus. Además, es importante señalar que el One Touch Diag sólo está disponible cuando el módulo está en modo de funcionamiento. En caso de que se efectúe un clic largo, la UCP entrará en el menú de navegación, el cual se describe en el capítulo Configuración – Menú Informativo y de Configuración de la UCP. La Tabla 7-1 muestra la diferencia entre los tiempos del clic corto, clic largo y tecla presionada. Tipo De Toque Tiempo Mínimo Tiempo Máximo Condición para Indicación Sin Toque - 59,99 ms - Clic Corto 60 ms 0,99 s Liberación Clic Largo 1s 20 s Más que 1 s hasta 20 s Tecla Presionado 20,01 s (∞) Indicación en el diagnóstico, consultar la Tabla 7-6. Tabla 7-1. Tiempo de One Touch Los mensajes exhibidos en el visor gráfico de las UCPs Nexto, correspondientes a los diagnósticos, se describen en la sección Diagnósticos vía Variables, en la Tabla 7-6. En caso de una situación de tecla trabada en algún módulo de E/S presente en el bus, la tecla de diagnósticos deja de indicar los diagnósticos en el visor de la UCP cuando presionado. Neste caso la 312 7. Mantenimiento UCP irá parar de indicar que hay módulos con diagnóstico activo. Para que sea posible eliminar este diagnóstico ha de se realizar uno cambio en caliente del módulo con el diagnóstico activo. Para más detalles sobre el procedimiento de visualización de los diagnósticos de la UCP o de otros módulos del bus, ver descripción en el Manual del Usuario Serie Nexto – MU214300. Diagnósticos vía LED Las UCPs de la Serie Nexto poseen un LED para indicación de diagnósticos (LED DG) y un LED para indicar ocurrencia de watchdog (LED WD). Las Tabla 7-2. y Tabla 7-3 muestran el significado de cada estado y sus respectivas descripciones: DG (Diagnóstico) Verde Rojo Descripción Causas Prioridad Desconectado Desconectado No utilizado Sin fuente de alimentación. Problema de Hardware. - Conectado Desconectado Todas las aplicaciones en modo Ejecución (RUN) - 3 (Baja) Desconectado Conectado Todas las aplicaciones en modo Parada (STOP) - 3 (Baja) Desconectado Módulos del bus con diagnósticos En lo mínimo un módulo del bus, lo que incluye la UCP, está con algún diagnóstico activo. 1 2 0 (Alta) Parpadeando 2x Parpadeando 3x Desconectado Forzamiento de datos Alguna área de memoria está siendo forzada por el usuario por MasterTool IEC XE. Desconectado Parpadeando 4x Error de Configuración o de Hardware en el bus. EL Bus está dañado o no está configurado correctamente. Tabla 7-2. Descripción de los Estados del LED de Diagnósticos WD (Watchdog) LED Rojo Desconectado Descripción Causas Sin indicación de watchdog Operación normal. Parpadeando 1x Watchdog de software Watchdog de la aplicación de usuario. Conectado Watchdog de hardware Módulo dañado y/o sistema operacional corrompido. Prioridad 3 (Baja) 2 1 (Alta) Tabla 7-3. Descripción de los Estados del LED de Watchdog Notas: Watchdog de Software: Para remover la indicación de watchdog, se debe efectuar un reset de la aplicación o desconectar y ligar de nuevo a la UCP. Este watchdog ocurre cuando el tiempo de ejecución de la aplicación de usuario es mayor que el tiempo de watchdog configurado. El diagnóstico se puede verificar en el operando Exception.wExceptionCode, ver Tabla 7-10. Watchdog de Hardware: Para limpiar cualquier indicación de watchdog, como en el LED WD o en el operando Reset.bWatchdogReset, el módulo modulo se debe desconectar de la fuente de alimentación Para verificar las condiciones de la aplicación en la reinicialización del módulo, vea configuraciones en la Tabla 4-1. 313 7. Mantenimiento LEDs Conector RJ45 Los dos LEDs presentes en los conectores RJ45 (en el caso de la NX3010, un conector solamente), identificados por NET 1 y NET 2, auxilian el usuario en la detección de problemas en la red física instalada, lo que indica la velocidad del link de red y la existencia de tráfico de comunicación con la interfaz. El significado de los LEDs se presenta en la Tabla 7-4. Amarillo Verde Significado Ausencia de LINK de red. LINK de red de 10 Mbits/s. LINK de red de 100 Mbits/s. X – Ocurrencia de transmisión o recepción en la red Ethernet, por la o para esta dirección IP. Parpadea bajo demanda de la UCP Nexto, y no a cada transmisión o recepción, es decir, puede parpadear con una frecuencia menor que la frecuencia real de transmisión o recepción. Tabla 7-4. Significado de los LEDs Ethernet Diagnósticos vía WEB Además de las características presentadas anteriormente, la Serie Nexto trae al usuario una herramienta innovadora de acceso a los diagnósticos y estados de operación del sistema, a través de una página WEB. La utilización, además de dinámica, es bastante intuitiva y facilita las operaciones del usuario. Entre otras palabras, puede sustituir el uso de un sistema supervisorio cuando el uso es restricto a la verificación de status del sistema. Para acceder a la página WEB de la UCP que se desea, basta con utilizar un navegador estándar (Internet Explorer 7 o superior, Mozilla Firefox 3.0 o superior y Google Chrome 8 o superior) y digitar, en la barra de dirección, la dirección IP correspondiente la UCP (Ej.: http://192.168.1.1). Inicialmente, se presentarán las informaciones de la UCP, según muestra la Figura 7-3: Figura 7-3. Pantalla Inicial También existe la pestaña “Informaciones del Sistema”, la cual se puede ver a través del Rack o de la lista de los módulos presentes (opción del lado derecho de la pantalla). Cuando no hay ninguna aplicación en la UCP, se exhibirá en esta página una configuración con el mayor Rack disponible y una fuente de alimentación estándar, juntamente con la UCP conectada. Cuando la visualización por 314 7. Mantenimiento el Rack se utiliza, los módulos que tienen diagnósticos quedan parpadeando y asumen el color rojo, según muestra la Figura 7-4. En caso contrario se exhibirá una lista con los módulos presentes en el sistema, Tags correspondientes y número de diagnósticos activos. Figura 7-4. Informaciones del Sistema Cuando presionado sobre el módulo con diagnósticos, en el mismo instante se muestra la(s) diagnósticos activo(s) del módulo, según muestra la Figura 7-5: ATENCIÓN: Cuando una UCP reiniciar con excepción en la aplicación en el inicio del sistema, los diagnósticos no serán válidos. Es necesario corregir el problema que genera la excepción en la aplicación para que los diagnósticos se actualicen. Figura 7-5. Diagnósticos del Sistema En caso de que la pestaña Status se seleccione, el estado de todas los diagnósticos se exhiben con detalles en la pantalla, según muestra la Figura 7-6: 315 7. Mantenimiento Figura 7-6. Estado del Sistema Además, el usuario puede optar por visualizar tres opciones de idiomas: Portugués, Inglés y Español. Basta alterar el menú superior derecho hacia el idioma que se desee. En la pestaña Gerenciamiento de la UCP, existen otros recursos como Actualización de Firmware y SNMP. La pestaña Actualización de Firmware es restricta al usuario, o sea, es solamente para uso interno de la Altus. En casos donde la actualización se realiza remotamente (a través de una conexión de radio o satélite por ejemplo, la velocidad mínima de este link debe ser de 128Kbps). Diagnostic Explorer El Diagnostic Explorer es la inclusión de los diagnósticos por WEB dentro del MasterTool IEC XE, a fin de que el acceso sea más rápido y objetivo. El acceso a la característica ocurre de dos maneras: Al acceder a la opción “Diagnostic Explorer” en el árbol de dispositivos, ubicada a la izquierda de la pantalla del MasterTool IEC XE, se coloca el IP correcto en el campo indicado en la Figura 7-7. Se recuerda que para que la página de diagnósticos se exhiba, el usuario deberá estar conectado a la UCP (capítulo Programación Inicial-Login). 316 7. Mantenimiento Figura 7-7. Pantalla del Diagnostic Explorer Al hacer clic con el botón derecho del mouse sobre el módulo, y seleccionar “Diagnósticos”, el Diagnostic Explorer se abrirá y direccionará a la página de status del respectivo módulo. Diagnósticos vía Variables Las UCPs de la Serie Nexto poseen variables para indicación de diagnósticos. Existen estructuras de datos con los diagnósticos de todos los módulos declarados en el bus, mapeadas sobre variables de representación directa %Q, y definidas simbólicamente a través de la directiva AT, en la GLV Diagnostics creada automáticamente por el MasterTool IEC XE. La Tabla 7-5 hace un resumen de la división de los bytes/words de diagnósticos: Byte Descripción 0a3 Diagnósticos resumidos de la UCP 4 a 558 Diagnósticos detallados de la UCP (NX3004, NX3005 y NX3010) 4 a 693 Diagnósticos detallados de la UCP (NX3020 y NX3030) Tabla 7-5. División de los Diagnósticos de la UCP Diagnósticos Resumidos La Tabla 7-6 muestra el significado de cada bit de los diagnósticos resumidas de la UCP: Variable de Representación Directa Variable Bit - - 0.0 Mensaje de Diagnóstico Variable DG_Modulo.tSummarized.* SIN DIAG - CONFIG INCOMPATIBLE Descripción No existe diagnóstico activo. bConfigMismatch TRUE – Existe algún problema de configuración en el bus, como módulo en posición incorrecta. FALSE – El bus está configurado correctamente. %QB(n) 0.1 MODULOS AUSENTES bAbsentModules TRUE – Uno o más módulos declarados están ausentes. FALSE – Todos los módulos están presentes en el bus. MODULOS CAMBIADOS 0.2 TRUE – Dos módulos están cambiados en el bus. bSwappedModules FALSE – No existen módulos cambiados en el bus. 317 7. Mantenimiento Variable de Representación Directa Variable Mensaje de Diagnóstico Variable DG_Modulo.tSummarized.* Descripción Bit 0.3 0.4 0.5 0.6 MODULOS NO DECLARADOS MODULOS C/ DIAGNOSTICO MODULOS C/ ERROR FATAL MODULOS C/ ERROR PARAM. bNonDeclaredModules bModulesWithDiagnostic bModuleFatalError bModuleParameterError TRUE – Uno o más módulos, presentes en el bus, no han sido declarados. FALSE – Todos los módulos presentes en el bus han sido declarados. TRUE – Uno o más módulos del bus, están con diagnóstico activo. FALSE – No existen diagnósticos activos en los módulos del bus. TRUE – Uno o más módulos presentes en el bus están en estado no funcional. FALSE – Todos los módulos presentes en el bus están en correcto funcionamiento. TRUE – Uno o más módulos del bus están con error de parametrización FALSE – Todos los módulos están parametrizados. 0.7 1.0 ERROR EN EL BUS ERROR DE HARDWARE bWHSBBusError TRUE – Indicación del maestro que existe falla en el bus WHSB. FALSE – El bus WHSB está en correcto funcionamiento. TRUE – Falla en el hardware de la UCP. bHardwareFailure FALSE – El hardware está en correcto funcionamiento. 1.1 EXCEPCION EN EL SOFTWARE 1.2 1.3 %QB(n+1) 1.4 1.5 1.6 1.7 2.0 bSoftwareException bReserved_10 ERROR TARJ. DE MEMORIA ERROR CONF. COM1 ERROR CONF. COM2 ERROR CONF. NET1 ERROR CONF. NET2 FECHA/HORA INVALIDA bMemoryCardError bCOM1ConfigError bCOM2ConfigError bNET1ConfigError bNET2ConfigError bInvalidDateTime TRUE – Una o más excepciones generadas por el software. FALSE – No han sido generadas excepciones en el software. Reservado TRUE – La tarjeta de memoria está insertada en la UCP, sin embargo no está funcionando correctamente. FALSE – La tarjeta de memoria está funcionando correctamente. TRUE – Ocurrió algún error durante, o después, de la configuración de la interfaz serial COM 1. FALSE – La configuración de la interfaz serial COM 1 está correcta. TRUE – Ocurrió algún error durante, o después, de la configuración de la interfaz serial COM 2. FALSE – La configuración de la interfaz serial COM 2 está correcta. TRUE – Ocurrió algún error durante, o después, de la configuración de la interfaz Ethernet NET 1. FALSE – La configuración de la interfaz Ethernet NET 1 está correcta. TRUE –Ocurrió algún error durante, o después, de la configuración de la interfaz Ethernet NET 2. FALSE – La configuración de la interfaz Ethernet NET 2 está correcta. TRUE – La fecha o la hora no son válidas. FALSE – La fecha y la hora están correctas. %QB(n+2) RUNTIME RESET 2.1 bRuntimeReset TRUE – El RTS (Runtime System) ha sido reiniciado por lo menos una vez. Este diagnóstico solamente se limpia en la reinicialización del sistema. FALSE – El RTS (Runtime System) está operando normalmente. 2.2 ERROR TECLA OTD bOTDSwitchError 318 TRUE – La tecla ha quedato trabada por más de 20 s por lo menos una vez mientras la UCP estuvo 7. Mantenimiento Variable de Representación Directa Variable Mensaje de Diagnóstico Variable DG_Modulo.tSummarized.* Descripción Bit energizada. Este diagnóstico solamente se limpia en la reinicialización del sistema. FALSE – La tecla no está o ha quedato trabada mientras la UCP estuvo energizada. 2.3 a 2.7 bReserved_xx TRUE – Uno o más bastidores declarados están ausentes. BASTIDOR AUSENTE 3.0 Reservado bAbsentRacks FALSE – Todos los bastidores están presentes. TRUE – Hay un bastidor con el número de identificación duplicado. BASTIDOR DUPLICADO 3.1 bDuplicatedRacks TRUE – Hay un bastidor con el número de identificación inválido. BASTIDOR INVALIDO 3.2 bInvalidRacks %QB(n+3) bNonDeclaredRacks SLOT DUPLICADO 3.4 FALSE – No existen bastidores con el número de identificación inválido. TRUE – Hay un bastidor con el número de identificación no declarado. BASTIDOR NO DECLARADO 3.3 FALSE – No existen bastidores con el número de identificación duplicado. FALSE – No existen bastidores con el número de identificación no declarado. TRUE – Hay una dirección de slot duplicada. bDuplicatedSlots FALSE – No hay direcciones de slot duplicadas. 3.5 a 3.7 bReserved_xx Reservado Tabla 7-6. Tabla de los Diagnósticos Resumidos de la UCP Notas: Variable de Representación Directa: La “n” representa el valor configurado en la UCP, a través del software MasterTool IEC XE, como dirección inicial de diagnóstico. Directiva AT: En la descripción de las variables simbólicas que utilizan la directiva AT para hacer el mapeo en variables de direccionamiento directo la sintaxis que se debe colocar antes del diagnóstico resumido que se desea es DG_Modulo.tSummarized., la palabra Modulo se sustituye por la UCP utilizada. Por ejemplo, para el diagnóstico de configuración incompatible basta con utilizar la siguiente variable, DG_NX3010.tSummarized.bConfigMismatch. La directiva AT es una palabra reservada en el software programador, siendo que algunas variables simbólicas que utilizan esta directiva se utilizan para indicar los diagnósticos sirven para indicar los diagnósticos. Configuración Incompatible: El diagnóstico de configuración incompatible se genera en caso de que uno o más módulos del bus no esté(n) de acuerdo con lo que se ha declarado, así, en las condiciones de módulos ausente o diferente. Los módulos insertados en el bus que no eran declarados en el proyecto no son considerados. Módulos Cambiados: Si solamente dos módulos están incompatibles en el respectivo bus, entonces el diagnóstico de cambio se puede identificar. En caso contrario, el problema se tratará como “Configuración Incompatible”. 319 7. Mantenimiento Módulos con Error Fatal: En caso de que el diagnóstico de Módulos con Error Fatal sea verdadera, verificar cual es el módulo que tiene problema en el bus y encaminar a la Asistencia Técnica de Altus, pues el mismo presenta falla del hardware. Módulos con Error Param.: En caso de que el diagnóstico de Módulo con Error de Parametrización sea verdadera, verificar si los módulos del bus están configurados correctamente y si las versiones de firmware y del software MasterTool IEC XE están adecuadas. Si se produce el problema al insertar un módulo en el bus, asegúrese de que el módulo soporta el intercambio en caliente. Error en el Bus: Considerado un error fatal, interrumpe el acceso a los módulos del bus. En caso de que el diagnóstico de error en el bus sea verdadera, tal vez haya un problema de hardware en las líneas de comunicación del bus, siendo así, se debe contactar a la Asistencia Técnica de Altus. Error de Hardware: En caso de que el diagnóstico de Falla de Hardware sea verdadera, encaminar la UCP a la Asistencia Técnica de Altus, pues puede que esté presentando problemas en el RTC, procesador auxiliar, u otros recursos de hardware. Excepción en el Software: En caso de que el diagnóstico de excepción en el software sea verdadera, el usuario deberá verificar su aplicación para garantizar que no esté accediendo indebidamente a la memoria. Si el problema persiste, el sector de Soporte de Altus se deberá consultar. Los códigos de excepción en el software están descritos enseguida de la tabla de diagnósticos detallados de la UCP. Error de la tarjeta memoria: Los diagnósticos referentes a la tarjeta de Memoria están disponibles solamente para las UCPs NX3010, NX3020 y NX3030. Mensaje de Diagnóstico: Los mensajes de diagnósticos se pueden visualizar a través del visor gráfico de la UCP a través de la tecla OTD o a través de la WEB en la página de diagnósticos de la UCP. Interfaces Seriales: Los diagnósticos referentes a la interface COM 2 están disponibles solamente para las UCPs NX3010, NX3020 y NX3030. Interfaces Ethernet: Los diagnósticos referentes a la interfaz NET 2 están disponibles solamente para las UCPs NX3020 y NX3030. Diagnósticos Detallados Las tablas a continuación muestran los diagnósticos en detalle de las UCPs de la serie Nexto, para su consulta es importante verificar las observaciones abajo: Visualización de las Estructuras de Diagnóstico: Las Estructuras de Diagnóstico añadidas al proyecto se pueden visualizar al acceder el ítem “Library Manager” en la tree view de la ventana del MasterTool IEC XE. Con esto, es posible ver todos los datatypes definidos en la estructura. Contadores: Todos los contadores de los diagnósticos de la UCP van a cero al sobrepasar su valor límite. Variable de representación directa: La “n” representa el valor configurado en la UCP, a través del software MasterTool IEC XE, como dirección inicial de diagnósticos. Directiva AT: En la descripción de las variables simbólicas que utilizan la directiva AT para hacer el mapeo en variables de direccionamiento directo, la sintaxis que se debe colocar antes del diagnóstico resumido deseado esDG_Modulo.tSummarized., la palabra Modulo se deberá sustituir por la UCP utilizada. Por ejemplo, para el diagnóstico de configuración incompatible, basta utilizar la siguiente variable DG_NX3010.tSummarized.bConfigMismatch. La directiva AT es una palabra reservada en el software programador, siendo que algunas variables simbólicas que utilizan esa directiva sirven para indicar los diagnósticos. Variable de Representación Directa NX3004 NX3005 NX3010 %QD(n+4) NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* DWORD Target. dwCPUModel 320 Descripción NX3004 = 0x3004 NX3005 = 0x3005 NX3010 = 0x3010 7. Mantenimiento NX3020 = 0x3020 NX3030 = 0x3030 %QB(n+8) BYTE ARRAY(4) Target. abyCPUVersion %QB(n+12) BYTE ARRAY(4) Target. abyBootloaderVersion %QB(n+16) BYTE ARRAY(4) Target. abyAuxprocVersion Versión del firmware. Versión del bootloader. Versión del procesador auxiliar. Tabla 7-7. Descripción de los Diagnósticos Detallados Grupo Target Variable de Representación Directa NX3004 NX3005 Tamaño Variable AT DG_Modulo.tDetailed.* %QX(n+20).0 BIT Hardware. bAuxprocFailure Falla en la comunicación entre el procesador auxiliar y el procesador principal. %QX(n+20).1 BIT Hardware. bRTCFailure El procesador principal no está habilitado para comunicar con el RTC (reloj de la UCP). %QX(n+20).2 BIT Hardware. bThermometerFailure Falla en la comunicación entre el termómetro y el procesador principal. %QX(n+20).3 BIT Hardware. bLCDFailure Falla en la comunicación entre el visor LCD y el procesador principal. NX3010 NX3020 NX3030 Descripción Tabla 7-8. Descripción de los Diagnósticos Detallados Grupo Hardware Variable de Representación Directa NX3004 NX3005 Tamaño Variable AT DG_Modulo.tDetailed.* %QW(n+21) WORD Exception. wExceptionCode Código de Excepción generado por el RTS. %QB(n+23) BYTE Exception. byProcessorLoad Etapa, en porcentaje (%), de carga en el procesador. NX3010 NX3020 NX3030 Descripción Tabla 7-9. Descripción de los Diagnósticos Detallados Grupo Exception Nota: Código de excepción: El código de excepción generado por el RTS (Runtime System) se puede consultar a continuación: Código Descripción Código Descripción 0x0000 No existe código de excepción. 0x0051 Violación de acceso. 0x0010 Tiempo del Watchdog de la tarea IEC expirado (Watchdog de Software). 0x0052 Instrucción privilegiada. 0x0012 Error en la configuración de los IOs. 0x0053 Falla en la página. 0x0054 Overflow de la pila. 0x0013 Error de Checksum trás el download del Programa. 0x0055 Disposición no válida. 0x0014 Error Fieldbus. 0x0056 Maniobra no válida. 0x0015 Error en la actualización de los IOs. 0x0057 Página protegida. 0x0016 Tiempo de ciclo (ejecución) excedido. 0x0058 Doble falla. 0x0017 Actualización Online del programa es muy extensa. 0x0059 OpCode no válido. 0x0018 Referencias externas no resueltas. 0x0100 Desalineación del tipo de dato. 0x0019 Download ha sido rechazado. 0x0101 Límite de arrays excedidos. 321 7. Mantenimiento 0x001A Proyecto no cargado, pues las variables retentivas no se pueden reubicar. 0x0102 División por cero. 0x001B Proyecto no cargado y deleteado. 0x0103 Overflow. 0x001C Fuera de la pila de la memoria. 0x0104 No continuable. 0x001D Memoria retentiva corrompida y no se puede mapear. 0x0105 Watchdog en la carga del procesador de todas las tareas IEC detectadas. 0x001E Proyecto se puede cargar, pero causa una caída posteriormente. 0x0150 FPU: Error no especificado. 0x0021 Target de la aplicación de inicialización no corresponde al target actual. 0x0151 FPU: Operando no normal. 0x0022 Error en las tareas agendadas. 0x0152 FPU: División por cero. 0x0023 Checksum del archivo bajado no corresponde. 0x0153 FPU: Resultado inexacto. 0x0024 Identidad retentiva no corresponde a la actual identidad del programa de la aplicación de inicialización. 0x0154 FPU: Operación no válida. 0x0025 Falla en la configuración de la tarea IEC. 0x0155 FPU: Overflow. 0x0026 Aplicación funciona con target errado. 0x0156 FPU: Verificación de la pila. 0x0050 Instrucción ilegal. 0x0157 FPU: Underflow. Tabla 7-10. Códigos de Excepción RTS Variable de Representación Directa NX3004 NX3005 NA %QB (n+24) NX3010 NX3020 NX3030 NA Tamaño Variable AT DG_Modulo.tDetailed.* BYTE WebVisualization. byConnectedClients Descripción Número de cliente conectado a la visualización Web. Tabla 7-11. Descripción de los Diagnósticos Detallados Grupo WebVisualization Variable de Representación Directa NX3004 NX3005 NX3010 %QB(n+25) %QW(n+26) %QW(n+28) NX3020 NX3030 Tamaño BYTE WORD WORD 322 Variable AT DG_Modulo.tDetailed.* Descripción RetainInfo. byCPUInitStatus Status de la Inicialización de la UCP: 01: Hot start 02: Warm Start 03: Cold Start Obs.: Estas variables se reinician en todas las energizaciones. RetainInfo. wCPUColdStartCounter Contador de Inicializaciones en frío: Se incrementará solamente debido a la retirada en caliente de la UCP en el Bus y no debido al comando de Reset a Frio del MasterTool IEC XE. (0 a 65535) RetainInfo. wCPUWarmStartCounter Contador de Inicialización en caliente: Se incrementará solamente durante la secuencia de energizaciones del sistema y no debido al comando de Reset en Caliente del MasterTool IEC XE. (0 a 65535) 7. Mantenimiento %QW(n+30) WORD RetainInfo. wCPUHotStartCounter %QW(n+32) WORD RetainInfo. wRTSResetCounter %QW(n+34) WORD RetainInfo.wReserved_0 Contador de disturbios menores que el tiempo de soporte a la fallas en la alimentación de la UCP. (0 a 65535) Contador de reset efectuados por el RTS (Runtime System). (0 a 65535) Reservado Tabla 7-12. Descripción de los Diagnósticos Detallados Grupo RetainInfo Variable de Representación Directa NX3004 NX3005 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QX(n+36).0 BIT Reset. bBrownOutReset La UCP reinició debido a una falla en la alimentación en la última inicialización. %QX(n+36).1 BIT Reset. bWatchdogReset La UCP reinició debido al watchdog activo en la última inicialización. NX3010 NX3020 NX3030 Tabla 7-13. Descripción de los Diagnósticos Detallados Grupo Reset Nota: Reset por Brownout: El diagnóstico de reset por brownout solamente será verdadero cuando la alimentación de la fuente sobrepasa el límite mínimo exigido en sus características técnicas, manteniéndose con tensión baja, o sea, sin sufrir una interrupción. La UCP identificará la caída de la alimentación e indicará el diagnóstico de falla. Cuando se restablezca la energía, la CPU se reiniciará automáticamente y se indicará el diagnóstico de reset por brownout. Variable de Representación Directa NX3004 NX3005 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QX(n+37).0 BIT Thermometer. bOverTemperatureAlar m Alarma generada debido a que la temperatura es 85 ºC o superior. %QX(n+37).1 BIT Thermometer. bUnderTemperatureAlar m Alarma generada debido a que la temperatura interna es 0 ºC o inferior. %QD(n+38) DINT Thermometer. diTemperature NX3010 NX3020 NX3030 Temperatura leída en el sensor interno de la UCP. Tabla 7-14. Descripción de los Diagnósticos Detallados Grupo Thermometer Nota: Temperatura: Para la visualización de la temperatura directamente en la dirección de memoria, se debe realizar una conversión, pues el tamaño del dato es DINT y el monitoreo se realiza en 4 bytes. Por lo tanto, se indica la utilización de la variable simbólica asociada, ya que la misma provee el valor final de la temperatura. Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QB(n+42) BYTE Serial.COM1. byProtocol Protocolo seleccionado en la COM 1: 00: Sin protocolo 01: MODBUS RTU Master 02: MODBUS RTU Slave 03: Otro protocolo %QD(n+43) DWORD Serial.COM1. dwRXBytes Contador de caracteres recibidos a través de la COM 1 (0 a 323 7. Mantenimiento 4294967295) %QD(n+47) DWORD Serial.COM1. dwTXBytes Contador de caracteres transmitidos a través de la COM 1 (0 a 4294967295) %QW(n+51) WORD Serial.COM1. wRXPendingBytes Número de caracteres pendientes en el buffer de lectura en la COM 1 (0 a 65535) %QW(n+53) WORD Serial.COM1. wTXPendingBytes Número de caracteres pendientes en el buffer de transmisión en la COM 1 (0 a 65535) %QW(n+55) WORD Serial.COM1. wBreakErrorCounter %QW(n+57) WORD Serial.COM1. wParityErrorCounter %QW(n+59) WORD Serial.COM1. wFrameErrorCounter %QW(n+61) WORD Serial.COM1. wRXOverrunCounter %QW(n+63) WORD Serial.COM1. wReserved_0 Reservado %QW(n+65) WORD Serial.COM1. wReserved_1 Reservado Esos contadores se reiniciarán en las siguientes condiciones: - Energización - Configuración de la puerta serial COM 1 - Remoción de las filas RX y TX Obs.: Cuando la UCP está configurada con paridad NONE (sin paridad), el contador de errores de paridad no se incrementa en caso de que reciba una paridad diferente. En este caso, se indicará error de frame. El valor máximo de cada contador é 65535. Tabla 7-15. Descripción de los Diagnósticos Detallados Grupo Serial COM 1 Nota: Contador de error de paridad: Cuando la paridad de la interfaz serial COM 1 está configurada como Sin Paridad, este contador de errores no se incrementará al recibir un mensaje con paridad distinta. En este caso, se mostrará un error de frame. Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción NA %QB(n+67) BYTE Serial.COM2. byProtocol Protocolo seleccionado en la COM 2: 00: Sin protocolo 01: MODBUS RTU Master 02: MODBUS RTU Slave 03: Otro protocolo NA %QD(n+68) DWORD Serial.COM2. dwRXBytes Contador de caracteres recibidos a través de la COM 2 (0 a 4294967295) NA %QD(n+72) DWORD Serial.COM2. dwTXBytes Contador de caracteres transmitidos a través de la COM 2 (0 a 4294967295) NA %QW(n+76) WORD Serial.COM2. wRXPendingBytes Número de caracteres pendientes en el buffer de lectura en la COM 2 (0 a 65535) NA %QW(n+78) WORD Serial.COM2. wTXPendingBytes Número de caracteres pendientes en el buffer de transmisión en la COM 2 (0 a 65535) NA %QW(n+80) WORD Serial.COM2. wBreakErrorCounter NA %QW(n+82) WORD Serial.COM2. wParityErrorCounter NA %QW(n+84) WORD Serial.COM2. wFrameErrorCounter NA %QW(n+86) WORD Serial.COM2. 324 Estos contadores se reinician en las siguientes condiciones: - Inicialización - Configuración de la puerta serial COM 1 - Remoción de las filas RX y TX Obs.: Cuando la UCP está configurada con paridad NONE 7. Mantenimiento wRXOverrunCounter (sin paridad), el contador de errores de paridad no se incrementa en caso de que reciba una paridad diferente. En este caso, se indicará error de frame. El valor máximo de cada contador é 65535. NA %QW(n+88) WORD Serial.COM2. wReserved_0 Reservado NA %QW(n+90) WORD Serial.COM2. wReserved_1 Reservado Tabla 7-16. Descripción de los Diagnósticos Detallados Grupo Serial COM 2 Nota: Contador de error de paridad: Cuando la paridad de la interfaz serial COM 2 está configurada como Sin Paridad, este contador de errores no se incrementará al recibir un mensaje con paridad distinta. En este caso, se mostrará un error de frame. Variable de Representación Directa NX3004 NX3005 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QX(n+92).0 BIT Ethernet.NET1. bLinkDown Indica el estado del link en la NET 1. %QW(n+93) WORD Ethernet.NET1. wProtocol Protocolo seleccionado en la NET 1: 00: Sin protocolo %QX(n+93).0 BIT Ethernet.NET1. wProtocol.bMODBUS_R TU_ETH_Client Cliente MODBUS RTU vía TCP %QX(n+93).1 BIT Ethernet.NET1. wProtocol.bMODBUS_E TH_Client Cliente MODBUS TCP %QX(n+93).2 BIT Ethernet.NET1. wProtocol.bMODBUS_R TU_ETH_Server Servidor MODBUS RTU vía TCP %QX(n+93).3 BIT Ethernet.NET1. wProtocol.bMODBUS_E TH_Server Servidor MODBUS TCP %QB(n+95) STRING (15) Ethernet.NET1. szIP Dirección IP NET 1 %QB(n+111) STRING (15) Ethernet.NET1. szMask Máscara de Subred NET 1 %QB(n+127) STRING (15) Ethernet.NET1. szGateway Dirección Gateway NET 1 %QB(n+143) STRING (17) Ethernet.NET1. szMAC Dirección MAC NET 1 %QB(n+161) BYTE ARRAY(4) Ethernet.NET1. abyIP Dirección IP NET 1 %QB(n+165) BYTE ARRAY(4) Ethernet.NET1. abyMask Máscara de Subred NET 1 %QB(n+169) BYTE ARRAY(4) Ethernet.NET1. abyGateway Dirección Gateway NET 1 %QB(n+173) BYTE ARRAY(6) Ethernet.NET1. abyMAC Dirección MAC NET 1 %QD(n+179) DWORD Ethernet.NET1. dwPacketsSent Contador de paquetes enviados a través de la puerta NET 1 (0 a 4294967295) %QD(n+183) DWORD Ethernet.NET1. dwPacketsReceived Contador de paquetes recibidos a través de la puerta NET 1 (0 a 4294967295) %QD(n+187) DWORD Ethernet.NET1. dwBytesSent Contador de bytes enviados a través de la puerta NET 1(0 a 4294967295) %QD(n+191) DWORD Ethernet.NET1. Contador de bytes recibidos a NX3010 NX3020 NX3030 325 7. Mantenimiento dwBytesReceived través de la puerta NET 1 (0 a 4294967295) %QW(n+195) WORD Ethernet.NET1. wTXErrors Contador de errores de transmisión a través de la puerta NET 1 (0 a 65535) %QW(n+197) WORD Ethernet.NET1. wTXFIFOErrors Contador de errores en el buffer de transmisión a través de la puerta NET 1 (0 a 65535) %QW(n+199) WORD Ethernet.NET1. wTXDropErrors Contador de pérdidas de conexión en la transmisión a través de la puerta NET 1 (0 a 65535) %QW(n+201) WORD Ethernet.NET1. wTXCollisionErrors Contador de errores de colisión en la transmisión a través de la puerta NET 1 (0 a 65535) %QW(n+203) WORD Ethernet.NET1. wTXCarrierErrors Contador de errores de la portadora en la transmisión a través de la puerta NET 1. (0 a 65535) %QW(n+205) WORD Ethernet.NET1. wRXErrors Contador de errores de recepción a través de la puerta NET 1. (0 a 65535) %QW(n+207) WORD Ethernet.NET1. wRXFIFOErrors Contador de errores en el buffer de recepción a través de la puerta NET 1 (0 a 65535) %QW(n+209) WORD Ethernet.NET1. wRXDropErrors Contador de pérdidas de conexión en la recepción a través de la puerta NET 1. (0 a 65535) %QW(n+211) WORD Ethernet.NET1. wRXFrameErrors Contador de errores de frame en la recepción a través de la puerta NET 1. (0 a 65535) %QW(n+213) WORD Ethernet.NET1. wMulticast Contador de paquetes multicast a través de la puerta NET 1. (0 a 65535) %QW(n+215) WORD Ethernet.NET1. wReserved_0 Reservado. %QW(n+217) WORD Ethernet.NET1. wReserved_1 Reservado. Tabla 7-17. Descripción de los Diagnósticos Detallados Grupo Ethernet NET1 Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción NA %QX(n+219).0 BIT Ethernet.NET2. bLinkDown Indica el estado del link en la NET 2. NA %QW(n+220) WORD Ethernet.NET2. wProtocol Protocolo seleccionado en la NET 2: 00: Sin protocolo NA %QX(n+220).0 BIT Ethernet.NET2. wProtocol.bMODBUS_R TU_ETH_Client Cliente MODBUS RTU vía TCP NA %QX(n+220).1 BIT Ethernet.NET2. wProtocol.bMODBUS_E TH_Client Cliente MODBUS TCP NA %QX(n+220).2 BIT Ethernet.NET2. wProtocol.bMODBUS_R TU_ETH_Server Servidor MODBUS RTU vía TCP NA %QX(n+220).3 BIT Ethernet.NET2. wProtocol.bMODBUS_E TH_Server Servidor MODBUS TCP %QB(n+222) STRING (15) Ethernet.NET2. szIP Dirección IP NET 2 %QB(n+238) STRING (15) Ethernet.NET2. szMask Máscara de Subred NET 2 %QB(n+254) STRING (15) Ethernet.NET2. szGateway Dirección Gateway NET 2 NA NA NA 326 7. Mantenimiento Variable de Representación Directa NX3004 NX3005 NA NA NA NA NA NX3010 Tamaño Variable AT DG_Modulo.tDetailed.* %QB(n+270) STRING (17) Ethernet.NET2. szMAC Dirección MAC NET 2 %QB(n+288) BYTE ARRAY(4) Ethernet.NET2. abyIP Dirección IP NET 2 %QB(n+292) BYTE ARRAY(4) Ethernet.NET2. abyMask Máscara de Subred NET 2 %QB(n+296) BYTE ARRAY(4) Ethernet.NET2. abyGateway Dirección Gateway NET 2 %QB(n+300) BYTE ARRAY(6) Ethernet.NET2. abyMAC Dirección MAC NET 2 %QD(n+306) DWORD Ethernet.NET2. dwPacketsSent Contador de paquetes enviados a través de la puerta NET 2. (0 a 4294967295) %QD(n+310) DWORD Ethernet.NET2. dwPacketsReceived Contador de paquetes recibidos enviados a través de la puerta NET 2. (0 a 4294967295) %QD(n+314) DWORD Ethernet.NET2. dwBytesSent Contador de bytes enviados a través de la puerta NET 2. (0 a 4294967295) %QD(n+318) DWORD Ethernet.NET2. dwBytesReceived Contador de bytes recibidos a través de la puerta NET 2. (0 a 4294967295) %QW(n+322) WORD Ethernet.NET2. wTXErrors Contador de errores de transmisión enviados a través de la puerta NET 2. (0 a 65535) %QW(n+324) WORD Ethernet.NET2. wTXFIFOErrors Contador de errores en el buffer de transmisión a través de la puerta NET 2. (0 a 65535) %QW(n+326) WORD Ethernet.NET2. wTXDropErrors Contador de pérdidas de conexión en la transmisión a través de la puerta NET 2. (0 a 65535) %QW(n+328) WORD Ethernet.NET2. wTXCollisionErrors Contador de errores de colisión en la transmisión a través de la puerta NET 2. (0 a 65535) %QW(n+330) WORD Ethernet.NET2. wTXCarrierErrors Contador de errores de la portadora en la transmisión a través de la puerta NET 2. (0 a 65535) %QW(n+332) WORD Ethernet.NET2. wRXErrors Contador de errores de recepción a través de la puerta NET 2. (0 a 65535) %QW(n+334) WORD Ethernet.NET2. wRXFIFOErrors Contador de errores en el buffer de recepción a través de la puerta NET 2. (0 a 65535) %QW(n+336) WORD Ethernet.NET2. wRXDropErrors Contador de pérdidas de conexión en la recepción a través de la puerta NET 2. (0 a 65535) %QW(n+338) WORD Ethernet.NET2. wRXFrameErrors Contador de errores de frame en la recepción a través de la puerta NET 2. (0 a 65535) %QW(n+340) WORD Ethernet.NET2. wMulticast Contador de paquetes multicast a través de la puerta NET 2. (0 a 65535) %QW(n+342) WORD Ethernet.NET2. wReserved_0 Reservado %QW(n+344) WORD Ethernet.NET2. wReserved_1 Reservado. NX3020 NX3030 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA Descripción Tabla 7-18. Descripción de los Diagnósticos Detallados Grupo Ethernet NET2 327 7. Mantenimiento Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción Indica si la memoria utilizada para grabar archivos de usuario está lista para recibir los datos. %QB(n+219) %QB(n+346) BYTE UserFiles. byMounted %QD(n+220) %QD(n+347) DWORD UserFiles. dwFreeSpacekB Espacio libre de la memoria de archivos de usuario en Kbytes. %QD(n+224) %QD(n+351) DWORD UserFiles. dwTotalSizekB Capacidad de almacenaje de la memoria de archivos de usuario en kbytes. %QB(n+228) %QB(n+355) BYTE UserFiles.byReserved_0 Reservado. Tabla 7-19. Descripción de los Diagnósticos Detallados Grupo UserFiles Nota: Partición de Usuario: La partición de usuario es un área de la memoria reservada al almacenamiento de datos en la UCP. Por ejemplo: archivos con extensión PDF, DOC y otros datos. Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QB(n+229) %QB(n+356) BYTE UserLogs. byMounted Status de la memoria en que se insertan los logs de usuario. %QW(n+230) %QW(n+357) WORD UserLogs. wFreeSpacekB Espacio libre en la memoria de logs de usuario en Kbytes. %QW(n+232) %QW(n+359) WORD UserLogs. wTotalSizekB Capacidad de almacenaje de la memoria de logs de usuario en Kbytes. %QB(n+234) %QB(n+361) BYTE UserLogs. byReserved_0 Reservado. Tabla 7-20. Descripción de los Diagnósticos Detallados Grupo UserLogs Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción BYTE MemoryCard. byMounted Status de la tarjeta de Memoria: 00: Tarjeta de Memoria no montada 01: Tarjeta de Memoria insertada y montada. %QX(n+363).0 BIT MemoryCard. bMemcardtoCPUEnable d Nivel de Protección de la tarjeta de Memoria: Lectura de datos de la tarjeta de memoria por la UCP autorizada. %QX(n+ 236).1 %QX(n+363).1 BIT MemoryCard. bCPUtoMemcardEnable d Escritura de datos en la tarjeta de memoria por la UCP autorizada. NA %QD (n+237) %QD(n+364) DWORD MemoryCard. dwFreeSpacekB NA %QD (n+241) %QD(n+368) DWORD MemoryCard. dwTotalSizekB NA %QB (n+235) NA %QX(n+ 236).0 NA %QB(n+362) Espacio libre en la tarjeta de Memoria en Kbytes. Capacidad de almacenaje de la tarjeta de Memoria en Kbytes. Tabla 7-21. Descripción de los Diagnósticos Detallados Grupo MemoryCard 328 7. Mantenimiento Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción Informa la situación anormal en el bus que ocasionó la parada de la aplicación, para cada Modo de cambio en caliente: Consulte la Tabla 7-23 para detalles de las posibilidades. %QB(n+245) %QB(n+372) BYTE WHSB. byHotSwapAndStartupS tatus %QB(n+246) %QB(n+373) BYTE WHSB.byReserved_0 Reservado. %QD(n+374) DWORD ARRAY (32) WHSB. adwRackIOErrorStatus Identificación de errores en módulos de E/S, individualmente: Para más informaciones acerca de este diagnóstico, consulte la nota abajo. %QD(n+247) %QD(n+375) %QD(n+502) DWORD ARRAY (32) WHSB. adwModulePresenceSta tus Status de presencia de módulos declarados de E/S en buses, individualmente: Para más informaciones acerca de este diagnóstico, consulte la nota abajo. %QB(n+503) %QB(n+630) BYTE WHSB. byWHSBBusErrors Contador de fallas en el bus WHSB. Este contador se reinicia en la energización. (0 a 255) Tabla 7-22. Descripción de los Diagnósticos Detallados Grupo WHSB Notas: Diagnóstico de error de los módulos del bus: Cada DWORD del Array de este diagnóstico representa un bastidor, cuyas posiciones se representan por los bits de estas DWORDs. Por consiguiente, el Bit-0 de la DWORD-0 equivale a la posición cero del bastidor con dirección cero. Cada uno de esos Bits es el resultado de una operación lógica O entre los diagnósticos de configuración incompatible (bConfigMismatch), módulos ausentes (bAbsentModules), módulos cambiados (bSwappedModules), módulos con error fatal (bModuleFatalError) y el estado operacional del módulo de una determinada posición. Status de presencia de módulos: Cada DWORD del Array de este diagnóstico representa un bastidor, cuyas posiciones se representan por los bits de estas DWORDs. Por consiguiente, el Bit-0 de la DWORD-0 equivale a la posición cero del bastidor con dirección cero. Así, si el módulo está presente, este bit es verdadero. Es importante resaltar que este diagnóstico está válido para todos los módulos, excepto fuentes de alimentación, UCPs y módulos no declarados, o sea, no presentan la presencia en el bus en sus respectivas posiciones (bit permanece en falso). Situaciones que conllevan la parada de la aplicación: Los códigos de las posibles situaciones que conllevan a la parada de la aplicación se pueden consultar a continuación: Código Enumerable Descripción 00 INITIALIZING Este estado se presenta mientras los demás estados no están prontos. 01 RESET_WATCHDOG Aplicación en Modo Stop debido al reset por perro guardián de hardware o por una reinicialización del Runtime, al deshabilitar la configuración “Iniciar Aplicación de Usuario tras el Reset por Perro Guardián”. 02 ABSENT_MODULES_HOT_SWAP_ DISABLED Aplicación en Modo Stop debido a la activación del diagnóstico Módulos Ausentes, al configurar cambio a caliente deshabilitado o cambio a caliente deshabilitado solo para módulos declarados. 03 CFG_MISMATCH_HOT_SWAP_DIS ABLED Aplicación en Modo Stop debido a la activación del diagnóstico Configuración Incompatible, al configurar cambio a caliente deshabilitado o cambio a caliente deshabilitado solo para módulos declarados. 04 ABSENT_MODULES_HOT_SWAP_ STARTUP_CONSISTENCY Aplicación en Modo Stop debido a la activación del diagnóstico Módulos Ausentes, al configurar cambio a caliente con consistencia en la partida o cambio a caliente con consistencia en la partida solo para 329 7. Mantenimiento módulos declarados. 05 CFG_MISMATCH_HOT_SWAP_ST ARTUP_CONSISTENCY Aplicación en Modo Stop debido a la activación del diagnóstico Configuración Incompatible, al configurar cambio a caliente con consistencia en la partida o cambio a caliente con consistencia en la partida solo para módulos declarados. 06 APPL_STOP_ALLOWED_TO_RUN Aplicación en Modo Stop y todas las consistencias llevadas a cabo con éxito. Aplicación se puede colocar en el Modo Run. 07 APPL_STOP_MODULES_NOT_RE ADY Aplicación en Modo Stop y todas las consistencias llevadas a cabo con éxito. Los módulos de E/S no están aptos a la partida del sistema. No es posible colocar la Aplicación en Modo Run. 08 APPL_STOP_MODULES_GETTING _READY_TO_RUN Aplicación en Modo Stop y todas las consistencias llevadas a cabo con éxito. Los módulos de E/S se preparan para la partida del sistema. No es posible colocar la Aplicación en Modo Run. 09 NORMAL_OPERATING_STATE Aplicación en Modo Run. 10 MODULE_CONSISTENCY_OK Uso interno. 11 APPL_STOP_DUE_TO_EXCEPTIO N Aplicación en modo Stop pues una excepción ocurrió en la UCP. 12 DUPLICATED_SLOT_HOT_SWAP_ DISABLED Aplicación en Modo Stop debido a la activación del diagnóstico Slots Duplicados, al configurar cambio a caliente deshabilitado o cambio a caliente deshabilitado solo para módulos declarados. 13 DUPLICATED_SLOT_HOT_SWAP_ STARTUP_CONSISTENCY Aplicación en Modo Stop debido a la activación del diagnóstico Slots Duplicados al configurar cambio a caliente con consistencia en la partida o cambio a caliente con consistencia en la partida solo para módulos declarados. 14 DUPLICATED_SLOT_HOT_SWAP_ ENABLED Aplicación en Modo Stop debido a la activación del diagnóstico Slots Duplicados, al configurar cambio a caliente habilitado sin consistencia en la partida. 15 NON_DECLARED_MODULE_HOT_ SWAP_STARTUP_CONSISTENCY Aplicación en Modo Stop debido a la activación del diagnóstico Módulos No Declarados, al configurar cambio a caliente con consistencia en la partida. 16 NON_DECLARED_MODULE_HOT_ SWAP_DISABLED Aplicación en Modo Stop debido a la activación del diagnóstico Módulos No Declarados, al configurar cambio a caliente deshabilitado. Tabla 7-23. Códigos de Situaciones que Conllevan a la Parada de la Aplicación Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción %QB(n+504) %QB(n+631) BYTE Application. byCPUState Informa el estado de operación de la UCP: 01: Todas las aplicaciones de usuario están en Modo Start 03: Todas las aplicaciones de usuario están en Modo Stop %QX(n+505).0 %QX(n+632).0 BIT Application. bForcedIOs Existen uno o más puntos de IO forzados. Tabla 7-24. Descripción de los Diagnósticos Detallados Grupo Application Variable de Representación Directa NX3004 NX3005 %QX(n+532).0 NX3010 NX3020 NX3030 %QX(n+633).0 Tamaño Variable AT DG_Modulo.tDetailed.* BIT SNTP. bServiceEnabled Descripción Servicio SNTP habilitado. Indica cual servidor está activo: 00: Ningún servidor activo. 01: Servidor primario activo. 02: Servidor secundario activo. %QB(n+533) %QB(n+634) BYTE SNTP. byActiveTimeServer %QW(n+534) %QW(n+635) WORD SNTP. wPrimaryServerDownCo unt Contador de veces que el servidor primario estuvo indisponible. (0 a 65535) %QW(n+536) %QW(n+637) WORD SNTP. wSecondaryServerDow nCount Contador de veces que el servidor secundario estuvo indisponible (0 a 65535) 330 7. Mantenimiento %QD(n+538) %QD(n+639) %QB(n+542) %QB(n+643) DWORD BYTE SNTP. dwRTCTimeUpdatedCo unt Contador de veces que el RTC se actualizó por el servicio SNTP (0 a 4294967295) SNTP.byLastUpdateSuc cessful Indica el status de la última actualización: 00: No actualizado. 01: Falla en la última actualización. 02: Última actualización con éxito. %QB(n+543) %QB(n+644) BYTE SNTP.byLastUpdateTim eServer Indica cual servidor se utilizó en la última actualización: 00: Ninguna actualización. 01: Servidor primario. 02: Servidor secundario. %QB(n+544) %QB(n+645) BYTE SNTP.sLastUpdateTime .byDayOfMonth Día de la última actualización del RTC. %QB(n+545) %QB(n+646) BYTE SNTP.sLastUpdateTime .byMonth Mes de la última actualización del RTC. %QW(n+546) %QW(n+647) WORD SNTP.sLastUpdateTime .wYear Año de la última actualización del RTC. %QB(n+548) %QB(n+649) BYTE SNTP.sLastUpdateTime .byHours Hora de la última actualización del RTC. %QB(n+549) %QB(n+650) BYTE SNTP.sLastUpdateTime .byMinutes Minuto de la última actualización del RTC. %QB(n+550) %QB(n+651) BYTE SNTP.bReservedAlign Segundo de la última actualización del RTC. Milisegundo de la última actualización del RTC. Reservado %QB(n+551) %QB(n+652) BYTE SNTP.sLastUpdateTime .bySeconds %QW(n+552) %QW(n+653) WORD SNTP.sLastUpdateTime .wMilliseconds %QW(n+554) %QW(n+655) WORD SNTP.wReserved_0 Reservado %QW(n+556) %QW(n+657) WORD SNTP.wReserved_1 Reservado Tabla 7-25. Descripción de los Diagnósticos Detallados Grupo SNTP Variable de Representación Directa NX3004 NX3005 NA NX3010 NX3020 NX3030 %QX(n+659).0 Tamaño Variable AT DG_Modulo.tDetailed.* BIT SOE[1]. bConnectionStatus NA %QX(n+659).1 BIT SOE[1]. bOverflowStatus NA %QB(n+660) BYTE SOE[1].byReserved_0 NA %QW(n+661) WORD SOE[1]. wEventsCounter NA %QX(n+663).0 BIT SOE[2]. bConnectionStatus NA %QX(n+663).1 BIT SOE[2]. bOverflowStatus NA %QB(n+664) BYTE SOE[2].byReserved_0 WORD SOE[2]. wEventsCounter NA %QW(n+665) Descripción Status de conexión del cliente 01 Status de la fila de eventos del cliente 01 FALSE - No hubo desbordamiento TRUE - Límite de la fila excedido Reservado Contador de eventos en la fila del cliente 01 Status conexión del cliente 02 Status de la fila de eventos del cliente 02 FALSE - No hubo desbordamiento TRUE - Límite de la fila excedido Reservado Contador de eventos en la fila del cliente 02 Tabla 7-26. Descripción de los Diagnósticos Detallados Grupo SOE 331 7. Mantenimiento Notas: Sincronismo de los diagnósticos del grupo SOE en sistema operando con redundancia de HalfCluster: Cuando un proyecto se configura con redundancia de Half-Cluster, los diagnósticos del grupo SOE no se sincronizan entre los dos Half-Clusters. Actualización de los diagnósticos del grupo SOE en la transición hacia el estado activo: Cuando un Half-Cluster pasa del estado Reserva al estado Activo, los diagnósticos del grupo SOE pasan a actualizarse a partir del tercer ciclo. Variable de Representación Directa NX3004 NX3005 NX3010 %QD(n+506) NX3020 NX3030 %QD(n+667) %QD(n+510) %QD(n+671) Variable AT DG_Modulo.tDetailed.* Descripción DWORD Rack. dwAbsentRacks Cada bit representa un número de identificación del bastidor, si el bit es TRUE, significa que el bastidor con el referido número de identificación está ausente. DWORD Rack. dwDuplicatedRacks Cada bit representa un número de identificación del bastidor, si el bit es TRUE, significa que más de un bastidor es configurado con el mismo número de identificación. Cada bit representa un número de identificación del bastidor, si el bit es TRUE, significa que hay un bastidor configurado con un número de identificación no declarado en el proyecto. Tamaño %QD(n+514) %QD(n+675) DWORD Rack. dwNonDeclaredRacks %QW(n+518) %QW(n+679) WORD Rack.wReserved_0 Reservado Tabla 7-27. Descripción de los Diagnósticos Detallados Grupo Rack Variable de Representación Directa NX3004 NX3005 NX3010 NX3020 NX3030 Tamaño Variable AT DG_Modulo.tDetailed.* Descripción CRC de 32 bits de la aplicación. Cuando la aplicación se modifica y envía a la UCP, un nuevo CRC se calcula. %QD(n+520) %QD(n+681) DWORD ApplicationInfo. dwApplicationCRC %QD(n+524) %QD(n+685) DWORD ApplicationInfo. dwReserved_0 Reservado. %QD(n+528) %QD(n+689) DWORD ApplicationInfo. dwReserved_0 Reservado. Tabla 7-28. Descripción de los Diagnósticos Detallados ApplicationInfo Diagnósticos vía Bloques Funcionales Los bloques funcionales proporcionan la visualización de algunos parámetros que no se pueden acceder de otra manera. Las tres funciones sobre diagnósticos avanzados están ubicadas en la biblioteca Nexto y se describen a continuación. GetTaskInfo Esta función devuelve informaciones sobre una tarea de una determinada aplicación. Figura 7-8. Función GetTaskInfo 332 7. Mantenimiento A continuación, se describen los parámetros que se deben repasar a la función para que devuelva las informaciones de la aplicación. Parámetros de entrada Tipo Descripción psAppName POINTER TO STRING Nombre de la aplicación psTaskName POINTER TO STRING Nombre de la tarea pstTaskInfo POINTER TO stTaskInfo Puntero para recibir las informaciones de la tarea Tabla 7-29. Parámetros de Entrada Los datos que la función devuelve, a través del puntero informado en los parámetros de entrada, se describen en la Tabla 7-30. Parámetros retornados Tamaño Descripción dwCurScanTime DWORD Tiempo de ciclo (ejecución) de la tarea con 1µs de resolución. dwMinScanTime DWORD Tiempo mínimo de ciclo de la tarea con 1µs de resolución. dwMaxScanTime DWORD Tiempo máximo de ciclo de la tarea con 1µs de resolución. dwAvgScanTime DWORD Tiempo mediano de ciclo de la tarea con 1µs de resolución. dwLimitMaxScan DWORD Tiempo máximo de ciclo de la tarea antes de ocurrir watchdog. Tabla 7-30. Parámetros Retornados Posibles ERRORCODE: NoError: ejecución con éxito; TaskNotPresent: la tarea que se desea no existe. Ejemplo de utilización en Lenguaje ST: PROGRAM MainPrg VAR sAppName : STRING; psAppName : POINTER TO STRING; sTaskName : STRING; psTaskName : POINTER TO STRING; pstTaskInfo : POINTER TO stTaskInfo; TaskInfo : stTaskInfo; Info : ERRORCODE; END_VAR //ENTRADAS: sAppName := 'Application'; // Variable recibe el nombre de la aplicación. psAppName := ADR(sAppName); // Puntero con el nombre de la aplicación. sTaskName := 'MainTask'; // Variable recibe el nombre de la tarea. psTaskName := ADR(sTaskName); // Puntero con el nombre de la tarea. pstTaskInfo := ADR(TaskInfo); // Puntero que recibirá las informaciones de la tarea. //FUNCIÓN: // Llamada de la función. Info := GetTaskInfo (psAppName, psTaskName, pstTaskInfo); // Variable ‘Info’ recibe posibles errores de la función. 333 7. Mantenimiento Visor Gráfico El visor gráfico disponible en las UCPs de la Serie Nexto es una importante herramienta para el control de proceso, pues a través suyo es posible reconocer posibles condiciones de error, presencia de componentes o de diagnósticos activos. Además, es a través del visor gráfico que todos los diagnósticos, inclusive de los módulos de E/S, se exhiben al usuario. Más detalles de la utilización de la tecla de diagnósticos y de su visualización, consultar la sección Diagnósticos One Touch. A continuación, en la Figura 7-9, es posible visualizar todos los caracteres disponibles en el visor gráfico de la UCP Nexto y, a continuación, sus respectivos significados. Figura 7-9. Tela de Status da UCP Leyenda: 1. Indicación del estado de operación de la UCP. En caso de que la aplicación de la UCP esté en andamiento, el estado será RUN. En caso de que la aplicación de la UCP esté parada, el estado será STOP y cuando esté parado en marcas de depuración de la aplicación el estado será BRKP. Más detalles, consultar la sección Estados de Operación de la UCP. 2. Indicación de la presencia de la tarjeta de Memoria. Más detalles sobre la instalación de la tarjeta, consultar capítulo Instalación – Instalación de la Tarjeta de Memoria. 3. Indicación de Tráfico en la COM 1. La flecha hacia arriba (▲) indica transmisión de datos y la flecha hacia abajo (▼) indica recepción de datos. Más informaciones sobre la interfaz COM 1, consultar ítem Interfaces Seriales. 4. Indicación de Tráfico en la COM 2. La flecha hacia arriba (▲) indica transmisión de datos y la flecha hacia abajo (▼) indica recepción de datos. Más informaciones sobre la interfaz COM 2, consultar ítem Interfaces Seriales. 5. Indicación de la cantidad de diagnósticos activos en la UCP. En caso de que el número mostrado sea diferente de 0 (cero), existen diagnósticos activos en la UCP. Más detalles sobre su visualización en el visor gráfico de la UCP, a través de la Tecla de diagnósticos, consultar ítem Diagnósticos One Touch. 6. Indicación de variables forzadas en la UCP. En caso de que el carácter F esté exhibido en el visor gráfico, alguna variable está siendo forzada por el usuario, sea variable simbólica, variable de representación directa mapeada en una variable simbólica. Para más detalles sobre forzamiento de variables, consultar ítem Modo Run. 7. Identificación del estado de la redundancia en la UCP (mensaje válido solamente en la NX3030 en modo redundante). En caso de que la UCP sea el CP Activo, la información ACT será presentada. Los demás estados posibles son NCF (No Configurado), STR (Inicializando), INA (Inactivo) e SBY (Reserva). 8. Indicación de que se está ejecutando una sincronización de proyecto. La flecha hacia arriba (▲) indica transmisión de datos del proyecto y la flecha hacia abajo (▼) indica recepción de datos de un proyecto. Más informaciones sobre la sincronización de proyectos, consultar sección Sincronización de Proyectos. 334 7. Mantenimiento Además de los caracteres descritos arriba, las UCPs Nexto podrán presentar algunos mensajes en el visor gráfico, correspondientes a algún proceso que se está ejecutando en el momento. La Tabla 7-31 muestra los mensajes y sus respectivas descripciones: Mensaje Descripción FORMATO... Indica que la UCP está formateando la tarjeta de memoria. ERROR FORMATO Indica que ocurrió un error durante la formatación de la tarjeta de memoria por la UCP. FORMATO INCORR. Indica que el formato de la tarjeta de memoria está incorrecto. CONTRASENA INCORRECTA Indica que la contraseña digitada no es igual a la contraseña configurada. TRANSFERENCIA... Indica que el proyecto se está transfiriendo. ERROR TRANSFER. Indica que ocurrió un error en la transferencia del proyecto, ocasionado por algún problema en la tarjeta de memoria o la remoción de esta durante la transferencia. TRANSFER. COMPLETO Indica que la transferencia ha sido completada con éxito. TIMEOUT TRANSFER. Indica que ocurrió un time-out (ha expirado tiempo de comunicación) durante la transferencia del proyecto. MODELO UCP INVALIDO Indica que el modelo de la UCP es diferente de lo configurado en el proyecto que está en la tarjeta de memoria. VERSION UCP INVALIDA Indica que la versión de la UCP es diferente de lo configurado en el proyecto que está en la tarjeta de memoria. APLICACION DANADO Indica que la aplicación que está en la tarjeta de memoria está corrompida. APLICACION INEXISTENTE Indica que no existe aplicación dentro de la tarjeta de memoria para que se transfiera a la UCP. CRC INEXISTENTE Indica que el CRC de la aplicación no existe. MCF INEXISTENTE Indica que no existe el archivo MCF dentro de la tarjeta de memoria. SIN TAG No existe Tag configurada para la UCP en el MasterTool IEC XE. SIN DESC No existe Descripción configurada para la UCP en el MasterTool IEC XE. ERROR MSG. Indica que hay error(s) en lo(s) mensaje(s) de diagnóstico(s) del(s) módulo(s) solicitado(s). SIN FIRMA Indica que el producto presentó un problema inesperado. Contáctese con el sector de Soporte de Altus. APL. ERROR REINICIANDO Indica que ocurrió un error en la aplicación y el Runtime está reiniciando la aplicación. APL. NO CARGADA Indica que el Runtime no cargará la aplicación. CARGANDO APL. Indica que el Runtime cargará la aplicación. POSICION INCORRECTA Indica que la UCP está en una posición incorrecta en el rack. ERROR FATAL Indica que hay problemas graves en la inicialización de la UCP como por ejemplo, las particiones de la UCP no han sido debidamente armadas. Contáctese con el sector de soporte de Altus HW-SW INCOMPATIBLE Indica que el software y hardware de la UCP no son compatibles pues el producto presentó algún problema inesperado. Contáctese con el sector de soporte de Altus. ACTUALIZ. FIRMWARE Indica que el firmware se está actualizando en la UCP. RECIBIENDO FIRMWARE Indica que el archivo de actualización se está transfiriendo para la UCP. ACTUALIZADO: Exhibe la versión de firmware actualizada en la UCP. ERROR ACTUALIZ. Indica que hubo algún error durante la actualización de firmware de la UCP, ocasionado por falla en la comunicación o problemas de configuración. REINICIANDO SISTEMA... Indica que la UCP se está reiniciando para que las actualizaciones tengan efecto. Tabla 7-31. Otras Mensajes del Visor Gráfico 335 7. Mantenimiento Log de Sistema Log de Sistema es un recurso disponible en el programador MasterTool IEC XE. Es una importante herramienta para el control de proceso, pues a través de este es posible ubicar eventos en la UCP que pueden indicar condiciones de error, presencia de componentes o de diagnóstico activos. Dichos eventos se pueden visualizar en orden cronológica con una resolución de milisegundos, con una capacidad de almacenaje de hasta mil entradas de Log. Para acceder a estos Logs, basta ir al Árbol de Dispositivos y dar un doble clic en Device, y enseguida ir a la pestaña Log, donde se pueden visualizar los cientos de operaciones como: ciclo máximo de las tareas, acceso de usuarios, download de la aplicación, alteración online, download y upload de la aplicación, forzamiento de las variables, sincronización de la aplicación en CPs redundantes, actualización de firmware entre otros eventos y acciones. Para que los Logs se puedan visualizar, basta estar conectado a una UCP (Camiño Activo seleccionado) y hacer clic en el botón . Al presionar este botón, los Logs se mostrarán y su actualización se hará de forma automática. Al no estar el botón presionado, los Logs se mantendrán en la pantalla, pero no se actualizarán. Es decir, este botón tiene dos estados, un estado mantiene los logs siendo actualizados y en el otro estado la actualización está deshabilitada. Para dejar de mostrar los Logs, basta pulsar en . Es posible filtrar los Logs en 4 tipos diferentes: Warning(s), Error(es), Exception(s) e Information(s). Otra manera de filtrar los mensajes exhibidos para el usuario es seleccionar cual el componente que queremos visualizar. La Marca de Tiempo de la pestaña de Log se presenta por la herramienta MasterTool a partir de informaciones brindadas por el dispositivo (UCP). La herramienta MasterTool puede presentar la Marca de Tiempo en el horario local (de la computadora) o en el horario UTC, si marcada la opción Tiempo UTC. ATENCIÓN: Si el horario o el parámetro de huso horario del dispositivo están incorrectos, la Marca de Tiempo presentada por la herramienta MasterTool no corresponderá al tiempo esperado. Para más informaciones sobre los Logs de Sistema, consulte el Manual del usuario MasterTool IEC XE - MU299800 y los sub-capítulos Reloj RTC y Sincronización de Tiempo. ATENCIÓN: Los logs de sistema de las UCPs de la serie Nexto, a partir de la versión de firmware 1.4.0.33, se recargan en el caso de una reinicialización de la UCP o por una reinicialización del Runtime System, es decir, será posible visualizar a los logs más antiguos cuando una de estas condiciones ocurra. No Cargar la Aplicación en la Inicialización En caso de que sea necesario, el usuario puede optar por no cargar una aplicación ya existente en la UCP durante su inicialización. Para esto, basta energizar la UCP con la tecla de diagnóstico presionado y mantenerlo así até ser exhibida la mensaje en la tela “APL. NÃO CARREGADA”. Después de la inicialización de la UCP se exhibirá en el visor un mensaje que avisa que la aplicación no se cargará e inicializará en Modo Stop. En caso de que se haga un login, el software MasterTool IEC XE indicará que no existe ninguna aplicación en la UCP. Para volver a cargar la aplicación, la UCP se debe reinicializar, o un nuevo download de la aplicación se debe hacer. Falla en la Alimentación La fuente de alimentación de la Serie Nexto (NX8000) posee un sistema de detección de falla, según los niveles definidos en sus características técnicas (consultar Características Técnicas del Módulo de 336 7. Mantenimiento Alimentación 30W 24Vdc – CS114200). En este momento, existen dos formas de diagnosticar la caída. En caso de que la fuente NX8000 se energice con tensión inferior al límite mínimo exigido, se generará un diagnóstico de falla de alimentación, la cual será reconocida por la UCP y el mensaje de “FALLA DE ENERGIA” se exhibirá en su visor. Cuando la alimentación esté dentro de los límites establecidos, la UCP reconocerá y, automáticamente, se reiniciará con la aplicación del usuario. El diagnóstico aun estará activo para mostrar al usuario que en la última inicialización ocurrió falla en la alimentación. En caso de que la fuente NX8000 tenga una caída de tensión para un valor inferior al límite mínimo exigido y vuelva para un valor arriba en menos, o igual, a 10 ms, la falla de alimentación no se reconocerá por la UCP y no se generará el diagnóstico, pues el sistema se mantiene intacto durante ese tiempo. Sin embargo, si la caída de tensión es superior a los 10 ms, el mensaje de “FALLA DE ENERGIA” se exhibirá en el visor de la UCP y el diagnóstico se activará. Figura 7-10. Mensaje de Falla en la Alimentación El usuario puede alterar el valor de la variable atribuida a la falla en la alimentación para FALSE durante la ejecución del aplicativo, lo que facilita la verificación y tratamiento de este diagnóstico. El diagnóstico de FALLA DE ENERGIA ya está previamente mapeado en una región específica de memoria, definida como Diagnósticos Detallados de la UCP. De esta forma, basta con utilizarla como una variable global. El nombre de la variable se encuentra mejor descrita en la lista de diagnósticos detallados de la UCP en el capítulo Mantenimiento - Diagnósticos vía Variables. Problemas más Comunes Si, al energizar la UCP, la UCP no entra en funcionamiento, los siguientes ítems se deben verificar: La temperatura ambiente está dentro de la franja soportada por los equipos? La fuente de alimentación del bastidor se está alimentando con la tensión correcta? La fuente de alimentación es el módulo, insertado en el bastidor, más a la izquierda (bastidor siendo visto de frente), seguido por la UCP de la Serie Nexto a su derecha? Los equipos de la red, como hubs, switches o rotadores, están alimentados, interconectados, configurados y funcionando de forma correcta? El cable de red Ethernet está debidamente conectado a la puerta NET 1 o NET 2 de la UCP Nexto y al equipo de red? La UCP de la Serie Nexto está conectada, en modo de ejecución (Run) y sin diagnósticos relacionados al hardware? Si la UCP Nexto indica el estado ejecución (Run), pero no responde a las comunicaciones solicitadas, sean por el MasterTool IEC XE o a través de protocolos, los siguientes ítems se deben verificar: La configuración de los parámetros Ethernet de la UCP está correcta? EL respectivo protocolo de comunicación está configurado correctamente en la UCP? Las variables que habilitan las relaciones MODBUS están debidamente habilitadas? Si ningún problema se identifica, consulte el Soporte a Clientes Altus. Solución de Problemas La Tabla 7-32 muestra los síntomas de algunos problemas con sus posibles causas de problemas y posibles soluciones. Si el problema persiste, contáctese con el Soporte Técnico de Altus. 337 7. Mantenimiento Síntoma Posible Causa Solución Falta de alimentación o alimentado incorrectamente. Verificar si la UCP está conectada correctamente en el bastidor. Des energizar y retirar todos los módulos del Bus, menos la fuente de alimentación y la UCP. Energizar el Bus y verificar el funcionamiento de la fuente de alimentación, tanto la externa como la fuente conectada al Bus. Verificar si la tensión de alimentación llega al borne de la fuente de alimentación Nexto, y también si la polarización está correcta. Visor Gráfico de la UCP presenta a mensaje WRONG SLOT UCP en la posición incorrecta En el caso de los Modelos NX3010, NX3020 y NX3030, la UCP debe ocupar los slots 2 y 3 del rack 0. Ponerla en la posición correcta. Las UCPs NX3004 y NX3005 deben ocupar los slots 0 y 1 del rack 0. Ponerla en la posición correcta, desconectarla y conectarla nuevamente. No comunica Mal contacto o mal configurado. Verificar todas las conexiones de los cables de comunicación. Verificar las configuraciones de las interfaces serial y Ethernet en el software MasterTool IEC XE. Mal conectado o desmontado Verificar si la tarjeta de memoria está conectada correctamente en el compartimiento. Verificar si la tarjeta de memoria se ha puesto del lado correcto, según la indicación en el panel delantero de la UCP. Verificar si la tarjeta de memoria no ha sido desmontada a través del botón MS, ubicado en el panel delantero, al visualizar la indicación en el visor gráfico de la UCP. No prende No reconoce la tarjeta de memoria Tabla 7-32. Solución de Problemas Mantenimiento Preventivo Se debe verificar, a cada año, si los cables de interconexión están con las conexiones firmes, sin depósitos de polvo, principalmente los dispositivos de protección. En ambientes sujetos a la contaminación excesiva, se debe limpiar periódicamente el equipo, retirando residuos, polvo, etc. Los diodos TVS utilizados para la protección contra transientes causados por descargas atmosféricas se deben inspeccionar periódicamente, pues pueden estar dañados o destruidos en caso de que la energía absorbida esté por encima del límite. En muchos casos, la falla puede no ser evidente o fácilmente visible. En aplicaciones críticas, es recomendable la sustitución periódica de los diodos TVS, mismo los que no presentan señales visibles de falla. Apretar, y limpiar el Bus a cada 6 meses. Para más informaciones, consultar el Manual del Usuario Serie Nexto – MU214300. 338 8. Glosario 8. Glosario Bus Baud rate Bit Broadcast Byte Canal serial Watchdog de hardware Controlador programable CP Directiva AT DG Diagnóstico Download E/S EIA RS-485 Dirección de módulo Entrada/salida Esclavo Frame Full Duplex Gateway Conjunto de señales eléctricas agrupados lógicamente con la función de transferir información y control entre diferentes elementos de un subsistema. Tasa con que los bits de información se transmiten a través de una interfaz serial o red de comunicación (medido en bits/segundo). Unidad básica de información, puede estar en el estado 0 o 1. Diseminación simultánea de información a todos los nodos interconectados a una red de comunicación. Unidad de información compuesta por ocho bits. Interfaz de un equipo que transfiere datos en el modo serial. Circuito electrónico destinado a verificar la integridad del funcionamiento de un equipo. También chamado de CP. Equipo que realiza control bajo el comando de un programa aplicativo. Está compuesto por una UCP, una fuente de alimentación y una estructura de E/S. Vea controlador programable. Las palabras reservadas en el software programador, se utiliza para asignar las variables simbólicas en variables de direccionamiento directo. Acrónimo utilizado para indicar diagnóstico vía LED Procedimiento utilizado para detectar y aislar fallas. Es también el conjunto de datos usados para tal determinación, que sirve para el análisis y corrección de problemas. Carga de programa o configuración en el CP. Vea entrada/salida. Estándar industrial (nivel físico) para comunicación de datos. Dirección por el cual el CP accede a un determinado módulo de E/S. También llamado E/S. Dispositivos de E/S de datos de un sistema. En el caso de CPs, corresponden típicamente a módulos digitales o analógicos de entrada o salida que monitorean o accionan el dispositivo controlado. Equipo conectado a una red de comunicación que sólo transmite datos si le solicita otro equipo denominado maestro. Una unidad de información transmitida en la red. Indica que los dispositivos pueden realizar comunicaciones transmitiendo y recibiendo datos en ambas direcciones de forma simultánea, es decir, puede transmitir y recibir al mismo tiempo. Equipo para la conexión de dos redes de comunicación con diferentes protocolos. GVL Global Variable List, objeto en el que las variables globales se declaran en la aplicación utilizada. Half Duplex Indica que los dispositivos pueden realizar comunicaciones transmitiendo o recibiendo datos, pero sólo en una dirección en un momento, es decir, puede transmitir o recibir datos. Hardware Equipos físicos usados en procesamiento de datos en los cuales normalmente se ejecutan programas (software). HSDN High Speed Deterministic Network. Red determinística, normalmente redundante, que se utiliza para cambio de mensajes de intertrabamiento entre CPs. IEC Sigla para International Electrotechnical Commission, o Comisión Electrotécnica Internacional, es un organismo internacional de normalización que prepara y publica estándares internacionales en tecnologías eléctricas, electrónicas y afines. IEC 61131 IEC-61131-3 Interfaz Interrupción kbytes LED Lenguaje de programación Lógica MasterTool IEC XE Menú Norma genérica para operación y utilización de CPs. Antigua IEC 1131. La tercera parte del estándar genérico para la operación y el uso de CPs, IEC61131. Dispositivo que adapta eléctrica y/o lógicamente la transferencia de señales entre dos equipos. Evento con atención prioritaria que temporariamente suspende la ejecución de un programa y desvía hacia una rutina de atención específica Unidad representativa de cantidad de memoria. Representa 1024 bytes. Sigla para light emitting diode. Es un tipo de diodo semiconductor que emite luz al estimularse por electricidad. Se utiliza como indicador luminoso. Un conjunto de reglas y convenciones utilizado para la elaboración de un programa. Matriz gráfica en la cual se insertan las instrucciones de lenguaje de un diagrama de relés que compone un programa aplicativo. Un conjunto de lógicas ordenadas secuencialmente que constituye un módulo de programa. Identifica el programa Altus para microcomputadora, ejecutable en ambiente Windows, que permite el desarrollo de aplicativos para los CPs de las series Nexto. A lo largo del manual, este programa está referido por la propia sigla o como programador MasterTool IEC XE. Conjunto de opciones disponibles y exhibidas por un programa en el video y que se pueden seleccionar por el usuario a fin de activar o ejecutar una determinada tarea. 339 8. Glosario Maestro Equipo conectado a una red de comunicación de donde se originan solicitudes de comandos para otros equipos de la red. Módulo (refiriéndose a hardware) Elemento básico de un sistema completo que posee funciones bien definidas. Normalmente está conectado al sistema por conectores, se puede fácilmente sustituirlo. Módulo (refiriéndose a software) Parte de un programa aplicativo capaz de realizar una función específica. Se puede ejecutarlo independientemente o en conjunto con otros módulos y cambiar informaciones a través del pasaje de parámetros. Módulo de E/S Nodo Módulo perteneciente al subsistema de entradas y salidas. Cualquier estación de una red con capacidad de comunicación, utiliza un protocolo establecido. Operandos Elementos sobre los cuales las instrucciones actúan. Pueden representar constantes, variables o un conjunto de variables. Protocolo Reglas de procedimientos y formatos convencionales que, mediante señales de control, permiten el establecimiento de una transmisión de datos y la recuperación de errores entre equipos. PLC Acrónimo de Programmable Logic Controller. Es la abreviatura de controlador programable en inglés. POU Program Organization Unit, o Unidad de Organización de Programa, es una subdivisión del programa de aplicación que se puede escribir en cualquiera de los lenguages disponibles. Programa aplicativo Es el programa cargado en un CP, que determina el funcionamiento de una máquina o proceso. Red de comunicación Conjunto de equipos (nodos) interconectados por canales de comunicación. Red de comunicación determinística Red de comunicación en la cual la transmisión y la recepción de informaciones entre los distintos nodos se garantizan, con un tiempo máximo conocido. Red de comunicación maestro-esclavo Red de comunicación en la cual las transferencias de informaciones se inician solamente a partir de un único nodo (maestro de la red) conectado al Bus de datos. Los demás nodos de la red (esclavos) sólo responden cuando se solicitan. Red de comunicación multimaestro Red de comunicación en la cual las transferencias de informaciones se inician por cualquier nodo conectado al Bus de datos. RX Sistema redundante SNTP SOE Software Subred Sigla usada para indicar recepción serial. Sistema que contiene elementos de reserva o duplicados para ejecutar determinada tarea, que pueden tolerar determinados tipos de falla sin que la ejecución de la tarea se comprometa. Simple Network Time Protocol. Protocolo para la sincronización de tiempo vía red. Sequence Of Events. Servicio para monitorear la variación de las entradas digitales pre-configurados, guardar la fecha / hora del cambio y su nuevo estado. Programas de computadora, procedimientos y reglas relacionadas a la operación de un sistema de procesamiento de datos. Segmento de una red de comunicación que interconecta a un grupo de equipos (nodos) con el objetivo de aislar el tráfico local o utilizar diferentes protocolos o medios físicos. Tag Nombre asociado a una variable o a una lógica que permite una identificación resumida de su contenido. Timeout Tiempo preestablecido máximo para que una comunicación se complete. Si se exceden, procedimientos de retentiva o diagnósticos se activarán. Cambio en caliente TX UCP UCP activa UCP inoperante UCP redundante UCP reserva Upload Variable de Representación Directa Variable Simbólica WD Word Tiempo de ejecución Tiempo de ciclo Intervalo LCD Procedimiento de sustitución de módulos de un sistema sin la necesidad de su desenergización. Normalmente se utiliza en cambios de módulos de E/S. Sigla usada para indicar transmisión serial. Sigla para unidad central de procesamiento. Controla el flujo de informaciones, interpreta y ejecuta las instrucciones del programa y monitorea los dispositivos del sistema. En un sistema redundante, la UCP activa realiza el control del sistema, y lee los valores de los puntos de entrada, ejecuta el programa aplicativo y acciona los valores de las salidas. Es la UCP que no está en el estado activo (controlando el sistema) tampoco en el estado reserva (supervisando la UCP activa). No puede asumir el control del sistema. Corresponde a la otra UCP del sistema, como, por ejemplo, la UCP2 en relación a la UCP1 y viceversa. En un sistema redundante, es la UCP que supervisa la UCP activa, no realiza el control del sistema, pero al estar lista para asumir el control en caso de que haya falla en la UCP activa. Lectura del programa o configuración del CP. La variable se puede acceder directamente en la memoria, al utilizar la dirección que se desea. Por ejemplo: %QB0, %MW100. Variables IEC creadas en POUs y GVLs durante el desarrollo del aplicativo, las cuales no se direccionan directamente en la memoria. Sigla para watchdog en inglés. Unidad de información compuesta por 16 bits. Véase tiempo de ciclo. Es el tiempo que tarda la UCP para realizar una tarea determinada en su aplicación. Establece cuánto en cuánto se ejecutará una tarea determinada. Acrónimo de Liquid Cristal Display. RS-232 Es un estándar para el intercambio de datos en serie entre dos puntos (punto a punto) RS-422 Es un estándar para el intercambio de datos en serie entre dos o más puntos (punto a punto en half 340 8. Glosario duplex) RS-485 10Base-T Categoría 5 Es un estándar para el intercambio de datos en serie entre dos o más puntos (punto a punto en full duplex). Tipo de nivel físico para redes Ethernet, definidos por IEEE 802.3 i en 1990. Soporta velocidades de 10 Mbps sobre dos pares de cables trenzados de categoría 3. Una de las categorías de cable UTP: par trenzado sin blindaje con 100 ohm de impedancia y características eléctricas que soportan frecuencias de transmisión hasta 100 MHz. Definido por el estándar TIA/EIA 568-A, puede utilizarse en redes 10Base-T y 100Base-TX, entre otros. ScTP Acrónimo de screened twisted pair. Mismo que el cable UTP sin embargo, todos los pares de hilos están rodeados por una lámina de metal, o por un alambre trenzado de metal, a fin de minimizar la radiación y la susceptibilidad al ruido externo. También es conocido por sUTP (Screened Unshielded Twisted Pair) o FTP (Foil Twisted Pair). UTP Acrónimo de unshielded twisted pair. Tipo de cable compuesto por pares de hilos trenzados sin blindaje. Para aplicaciones de red, el término UTP generalmente se refiere al cable de 100 ohm, categoría 3, 4 o 5, especificado por el estándar TIA/EIA 568-A. Normalmente el cable UTP tiene 4 pares de hilos trenzados dentro de la misma vaina (encapsulado externo). 341 Anexo A. Interoperabilidad DNP3 Anexo A. Interoperabilidad DNP3 Perfil de Dispositivo DNP3 DNP3 DOCUMENTO DEL PERFIL DE DISPOSITIVO Identificación del Dispositivo Nombre del Fornecedor Altus S/A Nombre de dispositivo NX3030 Función del dispositivo Esclavo Nivel DNP soportado para Solicitudes: Ninguna Respuestas: Ninguna Conexiones soportadas Red IP Métodos para definir parámetros Software: MasterTool IEC XE Tipo de Punto Final: TCP Listening (solamente Outstation) Acepta conexiones TCP de Permite todas Dirección (es) IP a partir de las cuales las conexiones se aceptan: *.*.*.* Número de TCP Listen Port Configurable, franja 1 hasta 65535 Temporización de TCP Keep-alive Configurable, franja 0 hasta 4294967295 Múltiples conexiones maestros Soporta hasta dos maestros Basado en el número de puerta TCP Red IP Soporte a sincronización de tiempo SNTP Camada de Link Dirección de link de datos Configurable, franja 0 hasta 65519 Self Address Support usando dirección 0xFFFC No Solicita confirmación de la camada de link de datos Nunca Número máximo de octetos transmitidos en el Frame de Link de Datos Fijo en 292 Número máximo de octetos que se pueden recibir en el Frame de Link de Datos Fijo en 292 Camada de Aplicación Número máximo de octetos transmitidos en el Fragmento de la capa de aplicación Fijo en 2048 Número máximo de octetos que se pueden recibir en el Fragmento de la capa de aplicación Fijo en 2048 Time-out en espera para la confirmación de la aplicación de la mensaje de respuesta solicitada Fijo en 10000 ms Problema en Dispositivo Bit IIN1.6 Este bit se definirá se el CP no esté en modo RUN Comportamiento de overflow en el buffer de eventos Descarta el evento más antiguo Envío de respuestas multifragmentadas Sí Soporta Respuestas No Solicitadas de la Estación Soporta a informe no solicitado No 342 Anexo A. Interoperabilidad DNP3 DNP V3.0 de Implementación GRUPO DE OBJETO DNP y VALOR REQUEST Maestro debe analizar pendencia en la estación Núm. Grupo Núm. Var. Descripción Cód. Función (dec) Cód. Calificador (hex) 1 0 Entrada Binaria – Cualquier Valor 1 (read) 00, 01 (iniciarparar) 06 (sin franja, o toda) 1 1 Entrada Binaria –Formato Encapsulado 1 (read) 00, 01 (iniciarparar) 06 (sin franja, o toda) 2 0 Evento de Entrada Binaria– Cualquier Valor 1 (read) 06 (sin franja, o toda) 07, 08 (cuantidad limitada) 2 2 Evento de Entrada Binaria – Con tiempo absoluto 1 (read) 06 (sin franja, o toda) 07, 08 (cuantidad limitada) 60 1 Objetos de Clase– Datos de Clase 0 1 (read) 06 (sin franja, o toda) 60 2 Objetos de Clase – Datos de Clase 1 1 (read) 06 (sin franja, o toda) 07, 08 (cuantidad limitada) 80 1 Indicaciones Internas – Formato Encapsulado 1 (read) 00, 01 (iniciarparar) 2 (write) 00 (iniciarparar) index=7 343 RESPUESTA Maestro debe analizar pendencia en la estación Cód. Función (dec) Cód. Calificador (hex) 129 (respuesta) 00, 01 (iniciarparar) 129 (respuesta) 17, 28 (index) 129 (respuesta) 00 (iniciarparar)
