Contexto: Los reactores en muchas industrias son equipos clave para transformar las materias primas en productos intermedios o finales. Para lograr esta transformación, en algunos casos se requiere un control de temperatura para garantizar la temperatura de operación.
Objetivo: Utilizar el control de temperatura para garantizar la operación del rendimiento de las reacciones químicas.
Cómo usar:
Elementos supuestos:
1 - El volumen del reactor 1.1 [m³]
2 - Reacción de primer orden con respecto a la concentración de óxido de propileno y de orden cero con respecto al exceso de agua, se sigue el modelo de reacción.
3 - Representación de la reacción.
Descargas
Tenga en cuenta: Deberá aceptar los Términos & Conditions para cada descarga.
¿Necesita ayuda?
Si necesita ayuda con una aplicación o desea enviar comentarios al Innovation Center, por favor contáctenos.
4 - La energía de activación es
5 - Las unidades son
6 - Se supone que la conversión de la reacción es del 85%
7 - Flujo inicial,
Limitaciones:
En la configuración actual, el reactor elegido es un reactor de mezcla perfecta ideal (CSTR ideal) de modo que en el líquido del interior se supone que:
1 - En el reactor no existe evaporación de ninguno de los componentes y adicionalmente se considera el proceso adiabático.
2 - No se consideran las propiedades de la mezcla, es decir, las propiedades de la mezcla serán la suma ponderada de las propiedades de cada una de las especies.
3 - Todas las propiedades de las sustancias son independientes de la composición y, por tanto, invariantes en el tiempo.
4 - Se asume reacción directa.
Problema por abordar:
La idea es tener un elemento de configuración inicial, en el cual la temperatura es un parámetro importante para la producción de propilenglicol.
Enlaces de interés (internos o externos)
¿Le ha sido ú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: Alimentación, manufactura, bebidas
¿Cómo puedo hacer que esto funcione?
Guía de implementación
Step 01
Los pasos siguientes ofrecen una explicación sobre el código y cómo almacenar en búfer los datos antes de enviarlos a otro controlador y usar los números de handshake (#) 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 continua de datos antes de transferirlos en caso de que se produzca un fallo 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 byte) en orden de llegada (first in / first out). Si esto es demasiado almacenamiento en búfer de datos, se puede personalizar según su aplicación.
El handshaking se usa para indicar cuándo se envía/recibe 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 principio del paquete. En este ejemplo, uso tanto un encabezado como un pie de página #. La operación básica de esto es la siguiente: cada vez que un nuevo paquete de datos está listo para enviarse, los encabezados y pies de página # incrementados se adjuntan al principio y al final del paquete de datos (492 bytes), convirtiéndolo en un paquete de producir/consumir completo (500 bytes). Cuando el otro controlador ve que hay una diferencia entre el encabezado/pie de página # antiguo y el encabezado/pie de página # nuevo, sabe que este es un nuevo paquete de datos y lo almacena en su memoria. Este nuevo encabezado/pie de página # se almacena para ser verificado más tarde cuando se envíe un nuevo paquete nuevamente. Esto se lleva un paso más allá al introducir un método de handshaking bidireccional. Esto significa que estoy enviando ya sea el encabezado o el 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 produce datos y el otro programa consume datos. El programa que produce datos se llama CLX1_producing_data_with_handshaking_and_Buffering1. El programa que consume datos se llama CLX2_consuming_data_with_handshaking. Se hará referencia a ellos como programa CLX1_Produce y CLX2_Consume.
Los datos deben recolectarse y almacenarse en búfer antes de enviarlos al tag producido.
Consulte los renglones 7, 8 y 9 del programa CLX1_produced.
Renglón 7. Los datos se recolectan y almacenan en búfer de manera FIFO. En este ejemplo estoy almacenando en búfer 10 (123dint) fragmentos de datos (1–10). Si no hay datos en el fragmento de datos almacenado en búfer 10, añada 123 al puntero de datos almacenados en búfer; si hay datos allí, deje de llenar el registro almacenado en búfer.
Renglón 8. Cuando aparecen datos en el registro de fragmento de datos almacenado en búfer 10 (123dint), el área de registro almacenado en búfer está llena y establecerá la salida Buffer full.
Renglón 9. Si se establece la salida Buffer full, desplace los fragmentos de datos almacenados en búfer 2–10 hacia arriba por (123dints). Luego llene el fragmento de datos almacenado en búfer 10 con ceros.
Paso 02
Ahora que tenemos datos almacenados en el búfer, comience a producir estos datos en la red Ethernet. Consulte los renglones 10 y 11 del programa CLX1_produced.
Escalón 10.Copiará el primer segmento de datos del búfer al tag producido.
Escalón 11.Asignará un encabezado y pie de página ID #. Estos números oscilarán entre 0–100. Estos ID también se usarán como números de handshaking entre los dos procesadores CLX. El siguiente escaneo a través de los ID se incrementará en 1.
En este punto, el paquete se forma y se ve así:
send-data-between-controllers-with-handshake-in-studio-5000_Step2-Image1
Paso 03
Los datos están siendo consumidos por otro procesador CLX2 a través de la red Ethernet. El tag consumido se ve así:
Consulte el programa CLX2_consumed, Rung 1.
Rung 1.Compara las nuevas ID asignadas en el Step 2 Rung 11 con las ID antiguas almacenadas en búfer en el Step 6 Rung 6. Si las ID son diferentes, sabe que está leyendo un nuevo paquete de datos.
send-data-between-controllers-with-handshake-in-studio-5000_Step3-Image1
Step 04
Si las comunicaciones se detienen, el control debe saberlo; consulte el programa CLX2_consumed, renglón 2, 3 y 4.
Renglón 2.Cada vez que hay una diferencia en las ID vistas, el contador cuenta 1 + 1
Renglón 3.Si el contador no se completa en 5 s, el temporizador retentivo expira.
Renglón 4. Si el temporizador retentivo se completa, no ha habido comunicaciones durante más de 5 s y se establece la salida de no comunicaciones entre CLX1 y CLX2. Esto se puede usar como un bit de alarma.
send-data-between-controllers-with-handshake-in-studio-5000_Step4-Image1
Paso 05
Verifique que los ID de encabezado y pie de página no hayan cambiado. Consulte el renglón 5 del programa CLX2_consumed.
send-data-between-controllers-with-handshake-in-studio-5000_Step5-Image1
Step 06
Ahora es momento de copiar datos del tag consumido a un registro diferente en el CLX2, para usarse en su programa.
A continuación, mueva los ID # de encabezado y pie de página actuales al registro Old ID para compararlo más tarde cuando se envíe el siguiente paquete de datos nuevos. Ahora para la porción de handshaking del programa.
El ID # de pie de página se envía de vuelta al CLX1, en un tag producido, para actuar como la pieza de datos de handshaking, que se comparará en el CLX1 como verá en el paso 8. Consulte el programa CLX2_consumed, renglón 6 a 8.
send-data-between-controllers-with-handshake-in-studio-5000_Step6-Image1
Paso 07
Una vez más, si se interrumpen las comunicaciones, el control debe estar al tanto de esto. Consulte el programa CLX1_produced, Rung 2, 3 y 4.
Rung 2. Cada vez que hay una diferencia en las ID vistas, el contador cuenta 1 + 1
Rung 3. Si el contador no termina en 5 s, el temporizador retentivo se desborda.
Rung 4. Si el temporizador retentivo termina, no ha habido comunicaciones durante más de 5 s y se establece la salida de no comms. entre clx1 y clx2. Esto puede usarse como un bit de alarma.
send-data-between-controllers-with-handshake-in-studio-5000_Step7-Image1
Step 08
Con 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 inicial coincide con el ID # consumido ahora, todavía hay comunicaciones, el handshaking está completo y CLX1 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í, restablezca a 0 y comience a contar hasta 100 nuevamente. Consulte el programa CLX1_produced, renglón 5 y 6.
send-data-between-controllers-with-handshake-in-studio-5000_Step8-Image1
Enviar datos entre controladores con handshake en Studio 5000
Versión 1.0 – noviembre 2024