Generic serial and TCP

Equipos que hablan un protocolo propio de texto o de bytes, como básculas y lectores de códigos de barras, por una línea serie, TCP o UDP: cómo terminan y se comprueban sus mensajes, y cómo cada tag saca de ellos su valor.

El driver Generic serial and TCP lee y escribe equipos que hablan un protocolo propio, hecho de texto o de bytes sencillos, donde no se aplica ningún protocolo estándar: una báscula, un lector de códigos de barras o de RFID, un instrumento antiguo, una impresora de etiquetas. A un equipo así no se le puede preguntar qué es, así que no se descubre nada. Usted le dice al dispositivo cómo termina un mensaje que envía y cómo se comprueba su suma de verificación, y le dice a cada tag cómo obtiene su valor, qué mensajes son suyos y qué caracteres del mensaje son el valor.

Un dispositivo llega a su equipo de una de tres formas, elegida al crearlo:

Un dispositivo en una línea serie cuelga de su línea, así que esa parte del árbol se lee Driver → Línea → Dispositivo → Tag, como en Modbus RTU. Un dispositivo de red cuelga del driver y se puede archivar en carpetas como el de cualquier otro driver, Driver → Carpeta → Dispositivo → Tag. Un dispositivo se queda en el lado en que se creó: TCP y UDP se intercambian, pero un dispositivo nunca pasa de una línea a la red ni de la red a una línea.

La página del driver

La frase bajo la cabecera dice "Las líneas serie llevan los instrumentos que comparten un bus, y los dispositivos de red cuelgan del driver. Agregue una línea o un dispositivo y después ábralo para describir sus mensajes." y la página tiene dos tablas, una debajo de la otra:

La cabecera cuenta los dispositivos entre paréntesis, y la fila del driver en el árbol cuenta los dos niveles en cuanto existe una línea ("1 línea · 2 dispositivos"). La barra del driver no tiene Descubrir. El clic derecho sobre la fila del driver ofrece Agregar dispositivo, Agregar línea, Nueva carpeta y Actualizar, y luego, tras un separador, Quitar el driver; en el menú Nuevo… de la columna, la entrada del driver ofrece Nuevo dispositivo, Nueva línea serie y Nueva carpeta, y luego sus líneas, carpetas y dispositivos. Una vez agregado, el driver queda bajo la carpeta Drivers del árbol, con línea o dispositivo o sin ellos.

Línea serie

Una línea de este driver es la línea descrita en Líneas serie, con menos campos. Su página dice "Un bus serie físico: los ajustes de puerto que comparten sus instrumentos, una solicitud a la vez." y su tarjeta Línea física tiene:

Una línea creada aquí empieza desactivada, para que los ajustes del puerto se escriban antes de que se abra el puerto. El puerto, los baudios y el formato solo cambian con la línea desactivada; el nombre cambia en cualquier momento. Una línea de este driver no tiene modo de transmisión, tiempo de espera de respuesta, intervalo mínimo entre transacciones ni silencio automático: cada dispositivo que tiene indica en su propio panel cómo terminan sus mensajes y cuánto espera una respuesta, como dice la tarjeta Dispositivos bajo la línea: "Todos los dispositivos de esta línea comparten sus ajustes de puerto. Cada uno indica en su propio panel cómo terminan sus mensajes y cuánto espera una respuesta." No tiene la tarjeta Descubrir unidades y su tabla Dispositivos no tiene la columna ID de unidad, porque un instrumento se distingue por lo que dicen sus solicitudes, no por una dirección.

Agregar dispositivo en la línea, o en su menú del clic derecho, crea un dispositivo de este driver en esa línea. Una línea pertenece para siempre al driver bajo el que se creó: un dispositivo Modbus RTU y un dispositivo de este driver nunca comparten una línea, y un agente que apunta un dispositivo a una línea del otro driver es rechazado. Los estados de la línea (Apagada, En reposo, Conectando…, En línea, Falla del puerto) son los de toda línea serie, en Activación y estado de salud.

En la línea, el driver abre el puerto una vez para todos sus dispositivos y envía una solicitud cada vez, esperando su respuesta antes de la siguiente. Entre solicitudes, lo que llega se ofrece a todos los dispositivos de la línea, y cada uno lo corta en mensajes según sus propias reglas. Un puerto que falla lo vuelve a abrir la línea para todos sus dispositivos, esperando cada vez más entre intentos mientras siga fallando.

Dispositivo

Conexión

Un dispositivo TCP nuevo dice "Host aún sin indicar" y no se conecta hasta tener un host y un puerto. Un dispositivo con host y sin puerto, y un dispositivo UDP sin su puerto local, no se pueden guardar: "Indique el puerto: el del dispositivo por TCP, el puerto local de escucha por UDP." Un dispositivo en una línea no tiene host, puerto ni carpeta, ni ID de unidad.

La Base URI que muestra la cabecera es la dirección de ejecución: generic://tcp/<host>:<port>, generic://udp/<local port> (con from=<sender> cuando Aceptar de está relleno) o generic://serial/<line id>/<port>/<baud>/<format>, seguida de cómo terminan y se comprueban los mensajes (end, start, terminator, length, gap, timeout, checksum y el resto). Los bytes que lleva son bytes, nunca la notación en que se escribe el dispositivo. La copia de un dispositivo en una línea se queda en esa línea; la copia de un dispositivo de red va al nivel propio del driver.

La tarjeta Mensajes

Bajo la tarjeta Conexión, la tarjeta Mensajes dice cómo se escriben los bytes y cómo termina un mensaje.

Un campo que el final elegido no lee no se dibuja y conserva su valor para cuando ese final vuelva. Un valor con el que el dispositivo no puede trabajar no se guarda, y el registro de acciones dice por qué, por ejemplo "Indique el terminador con que terminan los mensajes, como \r\n." o "La longitud del mensaje debe estar entre 1 y 1024 bytes."

La tarjeta Suma de verificación

Todos los campos salvo el algoritmo se dibujan solo cuando se elige una suma de verificación. La suma cubre el mensaje desde su primer byte hasta el byte anterior a la suma, salvo los bytes excluidos. Un mensaje cuya suma no coincide nunca se lee como valor: se descarta, y el diario técnico lo anota bajo el dispositivo como mucho una vez por minuto. La suma solo se comprueba: las solicitudes y las escrituras se envían exactamente como se escribieron, así que una solicitud que necesita suma de verificación la lleva en sus propios bytes.

Direccionamiento del tag

Un tag de este driver no tiene dirección que escribir: su tarjeta Fuente pregunta cómo obtiene su valor, en los campos de abajo. Los bytes se escriben en la notación del dispositivo.

Los caracteres se cuentan desde el principio del mensaje, incluido el marcador de inicio; el terminador, la suma de verificación y los bytes que la suma excluye justo antes no forman parte de lo que lee un tag. Un patrón es una expresión regular de .NET, y un mensaje que tarda más de 250 ms en leer no se lee. Un tag de solo escritura no tiene campos de solicitud, filtro ni valor; un tag sin mensaje de escritura es de solo lectura.

Los tipos de datos son Boolean, Int32, Int64, Float, Double y String. El texto recortado se lee como el tipo del tag antes de que las etapas propias del tag lo conviertan, como en todo driver (vea La cadena de conversión): un Boolean lee 1, true, on o yes y 0, false, off o no; un entero lee un número entero (12.0 se lee como 12, 12.5 se rechaza); un Float o un Double lee un número decimal; un String toma los caracteres tal cual. Los espacios alrededor de un número, y entre su signo y sus dígitos, se ignoran, porque los indicadores rellenan sus números con espacios. Un tag cuyos campos no pueden funcionar no se guarda, y la página del tag dice qué le falta, por ejemplo "Indique la solicitud que envía este tag." o "El patrón necesita exactamente un grupo de captura, alrededor del valor."

La vista previa de solo lectura de la dirección de bus muestra ask o listen seguido de lo que aplique, por ejemplo listen?extract=position&start=5&length=6, o ask?send=01RD%0D&extract=field&separator=,&field=3 para un tag que envía 01RD y un CR y lee el tercer campo separado por comas de la respuesta.

Lectura

Los mensajes que no responden a ninguna solicitud pasan a los tags en escucha del mismo dispositivo, así que un dispositivo puede tener las dos clases de tags. Los tags en escucha con el mismo filtro comparten lo que se oyó, y pueden sacar campos distintos del mismo mensaje.

Escritura

Una escritura pasa por el mismo embudo que la de cualquier otro driver: la casilla de escritura recibe el valor de ingeniería, y las etapas de conversión se invierten antes de enviar el valor bruto (vea Connector).

Las escrituras esperan su turno en la cola del dispositivo como las de todo driver: en una línea comparten la solicitud a la vez de la línea, en TCP la conexión propia del dispositivo. Un dispositivo UDP no envía nada, así que sus tags no se pueden escribir.

Ejemplo: una báscula por RS-232

Un indicador al estilo de la salida continua de Toledo envía, muchas veces por segundo, un STX, tres bytes de estado, seis dígitos de peso, seis de tara, un CR y un byte de suma de verificación. En la estación:

1. Agregar línea en la página del driver; llámela Scale line, elija COM3, deje Baudios en 9600 y elija 7E1 como Formato serie, y después Activar la línea.
2. Agregar dispositivo en la línea; llámelo Scale. En la tarjeta Mensajes deje Texto con escapes y Terminador, ponga el Terminador en \r, el Marcador de inicio en \x02 y el Tiempo máximo sin mensaje (s) en 10, para que un cable suelto se vea como comunicación perdida.
3. En la tarjeta Suma de verificación elija Complemento a dos de la suma de 7 bits (Toledo), Bytes en bruto y Después del terminador, con las dos cuentas de bytes excluidos en 0.
4. Agregar tag; llámelo Weight, Double, de solo lectura. En la tarjeta Fuente elija Escucha, Todos los mensajes y Posición fija, con Primer carácter 5 y Longitud 6: el STX es el carácter 1, los tres bytes de estado van del 2 al 4, el peso del 5 al 10.
5. Los dígitos no llevan punto decimal, así que la etapa Escala del tag lo coloca, por ejemplo un factor de 0,01 para un indicador ajustado a dos decimales.

Un agente hace lo mismo con tres llamadas de herramienta:

serial_line_upsert driver=GenericSerialTcp name="Scale line" serialPort=COM3 baudRate=9600 serialFormat=7E1
device_upsert driver=GenericSerialTcp name=Scale transport=SerialLine serialLineId=<id> messageEnd=Terminator terminator=\r startMarker=\x02 checksum=SumTwosComplement7Bit checksumFormat=Raw checksumPlacement=AfterEnd silenceTimeoutSeconds=10
tag_upsert device=Scale name=Weight opcUaType=Double tagMode=Listen valueExtraction=FixedPosition valueStart=5 valueLength=6

Ejemplo: un lector de códigos de barras por TCP

Un lector de códigos de barras con puerto Ethernet envía un código por línea, y solo cuando lee uno:

1. Agregar dispositivo en la página del driver; llámelo Reader, deje Cliente TCP e indique Host o IP 192.168.0.40 y Puerto 2001.
2. En la tarjeta Mensajes deje Texto con escapes, Terminador \r\n y Tiempo máximo sin mensaje (s) en 0: un lector que no envía nada durante una hora no está fallando. Deje Ninguno en la tarjeta Suma de verificación.
3. Agregar tag; llámelo Code, String, de solo lectura. En la tarjeta Fuente elija Escucha, Todos los mensajes y El mensaje completo.

Lo mismo con las herramientas del agente:

device_upsert driver=GenericSerialTcp name=Reader transport=TcpClient host=192.168.0.40 port=2001 messageEnd=Terminator terminator=\r\n
tag_upsert device=Reader name=Code opcUaType=String tagMode=Listen valueExtraction=WholeMessage

driver_capabilities describe este driver en genericSerialTcp, con estos dos ejemplos, y serial_line_upsert crea una línea de este driver con driver=GenericSerialTcp; las demás herramientas están en Las herramientas, área por área.

Límites que conviene conocer

• No se descubre nada: no hay protocolo para preguntar a un equipo así qué es o qué contiene.
• Una trama binaria que anuncia su propia longitud en una cabecera no se lee; un mensaje termina con un terminador, una longitud fija, un silencio o un datagrama.
• La suma de verificación solo se comprueba: no se agrega ninguna a lo que envía la estación.
• Un tag saca un valor de un mensaje, como texto leído según su tipo; los números empaquetados como enteros o coma flotante binarios dentro del mensaje no se decodifican.
• Un dispositivo UDP solo escucha: no envía solicitudes ni acepta escrituras.
• Un dispositivo no se puede mover entre una línea serie y la red, ni a otra línea: créelo donde le corresponde y elimine el antiguo.