Descargas
¿Para qué sirve esto?
A veces es necesario enviar datos de un controlador a otro y estar seguro de que los datos que se envían/reciben son precisos y no una combinación de datos antiguos y nuevos. Esta nota de aplicación muestra cómo enviar un paquete (500 bytes) de datos almacenados en búfer mediante una conexión de producción/consumo (clase 1) a través de Ethernet/IP.
Características Generales:
- Almacenamiento de datos
- Handshake
Ventajas: Esta secuencia facilita la implementación y configuración rápida cuando es necesario enviar un paquete de datos almacenados en buffer usando una conexión Produce/Consume (Clase 1) sobre Ethernet/IP, sin ningún otro hardware.
Limitaciones/Desventajas: Esta secuencia está disponible para Controladores CompactLogix / ControlLogix.
Tenga en cuenta: deberá aceptar los Términos y Condiciones para cada descarga.
¿Necesita ayuda?
Si necesita ayuda con alguna aplicación o tiene comentarios acerca del Innovation Center, por favor contáctenos.
¿Esto me resulta útil?
Este código se define para aplicaciones cuando es necesario enviar un paquete de datos almacenados en búfer a través de Ethernet/IP.
Áreas de aplicación: Alimentos, Manufactura, Bebidas
¿Cómo puedo hacerlo funcionar?
- Hardware
- Computadora personal con un puerto USB disponible
- Controlador CompactLogix, ControlLogix
- Software
- Studio 5000, versión 21 o posterior
- Conocimientos
- Conocimientos intermedios de programación y configuración en el software Studio 5000: Lenguaje de escalera (LD)
Guía de implementación
Paso 01
Los siguientes pasos ofrecen una explicación del código y de cómo almacenar en búfer los datos antes de enviarlos a otro controlador y usar números de enlace (#) para indicar cuándo ha llegado un nuevo paquete de datos.
Almacenamiento en búfer de datos: una razón para almacenar en búfer los datos sería mantener una lista actualizada de los datos antes de transferirlos en caso de que haya una falla de comunicación. Otra razón sería asegurarse de que el paquete de datos que está creando esté completo. En este ejemplo, estoy almacenando en búfer 10 paquetes (492 bytes) en un orden de entrada/salida. Si esto es demasiado almacenamiento en búfer de datos, puede personalizarlo para su aplicación.
El encabezado se usa para indicar cuándo se está enviando/recibiendo un nuevo paquete de datos. Algunas aplicaciones usan lo que se llama un pie de página # al final del paquete, otras aplicaciones usan un encabezado # al comienzo del paquete. En este ejemplo, estoy usando un encabezado y un pie de página #. El funcionamiento básico de esto es el siguiente: Cada vez que un nuevo paquete de datos está listo para ser enviado, los números de encabezado y pie de página incrementados se adjuntan al principio y al final del paquete de datos (492 bytes), lo que lo convierte en un paquete de producción/consumo completo (500 bytes). Cuando el otro controlador ve que hay una diferencia entre el antiguo número de encabezado/pie de página y el nuevo, sabe que se trata de un nuevo paquete de datos y lo almacena en su memoria. Este nuevo número de encabezado/pie de página se almacena para comprobarlo más tarde cuando se vuelva a enviar un nuevo paquete. Esto se lleva un paso más allá al introducir un método de protocolo de enlace bidireccional. Esto significa que estoy enviando el número de encabezado o pie de página de vuelta al productor de los datos como un disparador para enviar otro paquete.
send-data-between-controllers-with-handshake-in-studio-5000_Step 1-Image1
Hay dos programas ControlLogix, un programa está produciendo datos y el otro programa está consumiendo datos. El programa que está produciendo datos se llama CLX1_producing_ data_with_handshaking_ and_Buffering1. El programa que está consumiendo datos se llama CLX2_using_data_with_handshaking. Serán referenciados como programa CLX1_Produce y CLX2_Consume.
Los datos se deben recopilar y almacenar en el búfer antes de enviarlos a la etiqueta producida.
Consulte los Rungs 7, 8 y 9 del programa CLX1_produced.
Rung 7. Los datos se recopilan y almacenan en el búfer de la siguiente manera: primero en entrar, primero en salir. En este ejemplo, se almacena en el búfer 10 paquetes de datos (123dint) (1 a 10). Si no hay datos en el décimo paquete de datos almacenado en el búfer, agregue 123 al puntero de datos almacenados en el búfer; si hay datos allí, deje de llenar el registro almacenado en el búfer.
Rung 8. Cuando aparecen datos en el décimo registro almacenado en el búfer (paquetes de datos 123dint), el área del registro almacenado en el búfer está llena y se establecerá la salida de búfer completo.
Rung 9. Si se establece la salida de búfer completo, desplace los paquetes de datos almacenados en el búfer 2 a 10 hacia arriba en (123dint). Luego, complete el décimo paquete de datos almacenado en el búfer con ceros.
-
Paso 02
Ahora que tenemos los datos almacenados en el búfer, comenzamos a producirlos en la red Ethernet. Consultamos los Rungs 10 y 11 del programa CLX1_produced. El Rung 10 copiará el primer paquete de datos del búfer a la etiqueta producida.
El Rung 11 asignará un número de identificación de encabezado y pie de página. Estos números oscilarán entre (0 y 100). Estos identificadores también se utilizarán como números de enlace entre los dos procesadores CLX. El siguiente escaneo de los identificadores se incrementará en 1.
En este punto, el paquete se forma y se ve así:
- Producing_data_to_CLX1
- [0] = Header ID#
- [1] - [123] = Data
- [124] = Footer ID#
send-data-between-controllers-with-handshake-in-studio-5000_Step2-Image1
- Producing_data_to_CLX1
-
Paso 03
Otro procesador CLX2 está consumiendo los datos a través de Ethernet. La etiqueta de consumido se ve así:
- Consumed_data_from_CLX1
- [0] = Header ID#
- [1] - [123] = Data
- [124] = Footer ID#
Consulte el programa CLX2_consumed, Rung 1.
Rung 1. Compara los nuevos ID asignados en el paso 2, Rung 11, con los antiguos ID almacenados en el búfer del paso 6, Rung 6. Si los ID son diferentes, sabe que está leyendo un nuevo paquete de datos.
send-data-between-controllers-with-handshake-in-studio-5000_Step3-Image1
- Consumed_data_from_CLX1
-
Paso 04
Si las comunicaciones se detienen, el control debe estar al tanto de esto; consulte los renglones 2, 3 y 4 del programa CLX2_consumed.
Rung 2. Cada vez que se observa una ID diferente, el contador cuenta +1.
Rung 3. Si el contador no se completa en 5 segundos, el temporizador retentivo se agota.
Rung 4. Si el temporizador retentivo se completa, no ha habido comunicaciones durante más de 5 segundos y se establece la salida sin comunicaciones entre clx1 y clx2. Esto se puede utilizar como un bit de alarma.
send-data-between-controllers-with-handshake-in-studio-5000_Step4-Image1
-
Paso 05
Vuelva a verificar que los identificadores de encabezado y pie de página no hayan cambiado. Consulte el programa CLX2_consumed, Rung 5.
send-data-between-controllers-with-handshake-in-studio-5000_Step5-Image1
-
Paso 06
Ahora es el momento de copiar los datos de la etiqueta de consumo a un registro diferente en el CLX2, para utilizarlos en su programa.
A continuación, mueva los números de identificación de encabezado y pie de página actuales al registro de identificación anterior para compararlos más tarde cuando se envíe el siguiente paquete de datos nuevos. Ahora, la parte de negociación del programa.
El número de identificación de pie de página se envía de vuelta al CLX1, en una etiqueta producida, para que actúe como la pieza de datos de negociación, que se comparará en el CLX1 como verá en el paso 8. Consulte el programa CLX2_consumed, Rung 6 a 8.
send-data-between-controllers-with-handshake-in-studio-5000_Step6-Image1
-
Paso 07
Una vez más, si las comunicaciones se detienen, el control debe estar al tanto de esto. Consulte los renglones 2, 3 y 4 del programa producido por CLX1.
Rung 2. Cada vez que se observa una ID diferente, el contador cuenta +1.
Rung 3. Si el contador no se completa en 5 segundos, el temporizador retentivo se agota.
Rung 4. Si el temporizador retentivo se completa, no ha habido comunicaciones durante más de 5 segundos y se establece la salida sin comunicaciones entre clx1 y clx2. Esto se puede utilizar como un bit de alarma.
send-data-between-controllers-with-handshake-in-studio-5000_Step7-Image1
-
Paso 08
En referencia al Paso 6, el ID de pie de página está siendo producido por CLX2 y ahora será consumido por CLX1. Si el ID producido inicialmente coincide con el ID consumido ahora, todavía hay comunicaciones, el protocolo de enlace está completo y CLX1 ahora está listo para producir un nuevo paquete de datos.
Pero antes de producir un nuevo paquete de datos, debemos examinar si nuestro ID ha llegado a 100, si es así, restablecerlo a 0 y comenzar a contar hasta 100 nuevamente. Consulte los Rungs 5 y 6 del programa CLX1_produced.
send-data-between-controllers-with-handshake-in-studio-5000_Step8-Image1
Secuencia de Buffer de Datos y Handshake en Studio 5000
Versión 1.0 - Noviember de 2024
