El envío y recepción de datos entre dos PLC no siempre se realiza de forma óptima.

Para enviar una señal de un PLC a otro en la mayoría de las ocasiones se  hace simplemente realizando el envío y te olvidas.

En general parece ser suficiente porque las cosas funcionan y no se necesita más.

Pero en algunas ocasiones, la comunicación se ralentiza, o  hay señales que no llegan a la vez, o sí porque una se retrasa y no deberían llegar a la vez, o cualquier cosa que arruinan el envío y recepción de datos. Es ahí  cuando comienza tu pesadilla.

Entonces, ¿cómo podemos realizar un envío y recepción de datos de forma segura entre dos PLC?

Empecemos por un error que he visto alguna vez.

Imagina que necesitas un dato por el cual, dependiendo del valor que tome, la máquina receptora de la información hará  un trabajo A o un trabajo B.

Así, con un dato booleano es suficiente: si llega un TRUE, hacemos la opción A.

Si por el contrario llega un FALSE, realizaremos el B…

Bien ¿no?

Sobre el papel, así es. Con un dato booleano debería ser suficiente.

El problema, es que ante la inexistencia de información (un FALSE), se realiza una acción, lo cual puede ser un problema.

Esto puede suceder porque por ejemplo, se haya interrumpido la comunicación o el equipo emisor esté apagado.

Este problema lo he sufrido entre un PC y un PLC, en el que el PC mandaba una colección de datos a unos servos Fanuc en función de si un bit enviado por el PLC estaba a 1 o estaba a 0.

A veces, sin motivo aparente, equivocaba el envío.

Todo parecía estar bien cuando acudíamos a ver qué había pasado, pero lo cierto es que había enviado la colección equivocada.

Sospechamos que en algunas circunstancias, la comunicación entre el PC y el PLC se interrumpía, y por tanto, al PC no le llegaba información actualizada.

Por tanto, no debes usar datos booleanos para realizar dos acciones, sino para tomar decisiones del estilo:

• False: no se hace nada y el estado es seguro para la máquina, proceso y personas.
• True: se hace la acción requerida. Segura para las personas y el proceso también (lógicamente).

Para toma de decisiones donde siempre hay una acción a realizar, lo mejor es usar un número, de tal forma que:

• 0: Como en el caso anterior, no se hace nada.
• 1: Opción A
• 2: Opción B

Lógicamente será válido si necesitas más de 2 opciones simplemente cambiando el valor numérico que envías.

Pero en definitiva, lo que te quiero transmitir es que siempre que se envíen datos, si la comunicación no se establece por la razón que sea, las acciones ejecutadas por el autómata siempre deben ser seguras.

La forma correcta de realizar un envío y recepción de datos

Siguiendo con el envío de información booleana, te voy a contar como hemos resuelto un problema de marcaje de piezas.

Para asegurarnos que una pieza queda marcada desde una aplicación de Windows realizada en .NET a través de un OPC, lo hemos resuelto de esta forma:

• Cuando se tiene que marcar la piezas, desde el OPC se pone un bit a TRUE.
• Del lado del PLC, cuando recibe esta señal booleana,  tratamos este dato para marcar la pieza para mandarla a inspeccionar
• Ponemos un bit diferente a uno de vuelta (acknowledge o reconocimiento) para que el OPC sea consciente de que su información ha llegado.
• El PC entonces quita su envío volviéndolo a FALSE.
• De nuevo en el PLC,  ponemos a cero nuevamente el Ack porque recibe un cero en el envío desde el PC.

Como resumen, sería como se indica en la siguiente imagen:

Este esquema es aplicable a un envío con un número y un bit de reconocimiento del envío. Solamente que tras el Ack, el envío cambiará el valor X por un 0, indicando que el envío ha terminado.

¿Es necesario hacer esto siempre?

No, no siempre.

Si es un dato para visualizar o un dato poco relevante, que porque llegue un poco más tarde no tiene una importancia capital, se puede simplificar y simplemente enviar los datos y los dioses de los OPC proveerán.

Con tener una señal a modo de watchdog, será suficiente para saber si la comunicación está activa.

Un watchdog siemplemente es un valor que cambie.

Es decir, que ambos interlocutores tienen que ver que lo que envían y lo que reciben, no es lo mismo.

Para ello, simplemente lo que se hace es que uno de los interlocutores reenvíe el dato del watchdog y el otro interlocutor lo que hará es invertir el valor.

Por ejemplo, en este caso se puede hacer simplemente con un bit:

• Uno de los interlocutores reenvía lo que le llega de su pareja
• El otro interlocutor cambia el sentido del bit.

Volviendo al ejemplo entre el PC y el PLC, sería algo así:

Así, desde cualquiera de los lados, PC o PLC como en este caso, las aplicaciones tienen que ver que dicho bit se mueve más que los precios, y que si se queda fijo, es que la comunicación ha caído.

Este watchdog lo puedes hacer también numérico: uno de los interlocutores envía lo que recibe, y el otro a lo que recibe, le suma una unidad.

Lo importante es que el valor, sea el que sea, varíe en el tiempo.

¿Qué te ha parecido?

Espero que te haya servido para aclarar cómo puedes realizar la estructura de comunicación entre dos interlocutores.

¿sueles hacerlo así también?