# Omron

> Conecte PLC Omron, los controladores CJ, CS y CP por dirección de memoria sobre FINS (UDP, TCP o Host Link en una línea serie) y los NJ, NX y NY por nombre de variable sobre EtherNet/IP; los ajustes FINS, las formas de dirección, los tipos de dato, las lecturas, las escrituras y el descubrimiento.

El driver **Omron** habla con los PLC Omron en cualquiera de sus dos lenguajes, elegido por
dispositivo. Un controlador CJ, CS o CP, y un NJ o NX configurado en modo de memoria CJ, se lee
por FINS a partir de la dirección de memoria, escrita como la escribe el software de
programación de Omron: `D100`, `W0.01`, `CIO100.05`. Un controlador NJ, NX o NY se lee sobre
EtherNet/IP por el nombre de una variable que publica en la red, como `Level` o `Motor.Speed`.
Una misma estación lee los dos tipos lado a lado bajo el mismo driver. Agregue un dispositivo
bajo el driver Omron en el [Connector](connector) y elija su **Protocolo**; el panel muestra solo
los campos que usa ese protocolo.

## Protocolos {#protocols}

| Protocolo | Controladores | Los tags se direccionan por | Puerto |
| --- | --- | --- | --- |
| **FINS** | CJ1, CJ2, CS1, CP1 y los demás controladores CJ, CS y CP con puerto o unidad Ethernet; un NJ o NX en modo de memoria CJ | **Dirección de memoria**, como `D100` o `W0.01` | 9600 de forma predeterminada |
| **Tags NJ/NX por nombre** | Controladores NJ, NX y NY, como NJ501, NJ301, NJ101, NX1P2, NX102, NX502, NX701 y NY5 | **Nombre de variable**, como `Level` o `Motor.Speed` | ninguno: EtherNet/IP contesta en su puerto estándar, el 44818 |

FINS es el valor predeterminado, y un dispositivo nuevo arranca en él. El protocolo es un ajuste
del dispositivo, así que un CJ2 y un NX1P2 quedan bajo el mismo driver, cada uno leído en su
propio lenguaje. Cambiar el protocolo conserva los ajustes FINS como se dejaron, para cuando FINS
regrese, y cada tag del dispositivo pasa a leer su dirección en el protocolo nuevo: su **Tipo de
dato** se acomoda a uno que la dirección admite ahí, y una dirección que el protocolo nuevo no
puede leer queda marcada en la página del tag hasta que se corrija.

## Conexión {#connection}

| Campo | Significado | Valor inicial |
| --- | --- | --- |
| **Host o IP** | Dirección IP o nombre de host del puerto o la unidad Ethernet del PLC. | vacío |
| **Protocolo** | **FINS** o **Tags NJ/NX por nombre**. La línea de abajo dice qué lee el protocolo vigente: "Áreas de memoria de los controladores CJ, CS y CP, y de un NJ/NX en modo de memoria CJ." o "Variables que un controlador NJ, NX o NY publica en la red, leídas por nombre sobre EtherNet/IP." | FINS |
| **Puerto** | Solo FINS: el puerto en el que el PLC contesta a FINS, el mismo por UDP y por TCP, de 1 a 65535. Un campo vacío muestra 9600 en gris y al dispositivo se le marca por él. Un dispositivo leído por nombre de tag no tiene campo de puerto. | 9600 |
| **Intervalo de sondeo (ms)** | Periodo de lectura de todo el dispositivo para los tags que no lo reemplazan. | 1,000 |

El encabezado del dispositivo muestra el endpoint armado. Un dispositivo FINS escribe en
él todos sus ajustes, con un nodo 0 que significa automático, por ejemplo
`omron://192.168.250.1:9600?protocol=fins&transport=udp&network=0&node=0&unit=0&source=0&timeoutMs=2000`.
Un dispositivo leído por nombre de tag nombra solo su host y su protocolo, `omron://192.168.250.1?protocol=njnx`.
Cada tag puede fijar su propio **Intervalo de sondeo (ms)**; un valor 0 en el tag regresa al
intervalo del dispositivo.

## Preparar el controlador {#prepare-the-controller}

Un controlador NJ, NX o NY leído por nombre de tag solo sirve las variables globales que publica en
la red. Publicar es un atributo de cada variable, que se fija en Sysmac Studio y se transfiere al
controlador. Un controlador leído por FINS no necesita ese ajuste.

| Ajuste | Dónde en Sysmac Studio | Sin él |
| --- | --- | --- |
| **Network Publish** en **Publish Only** (o Input u Output para una variable que también usa un enlace de datos de tags), en cada variable global que la estación lee o escribe | **Programming > Data > Global Variables**, la columna **Network Publish** de la variable. Transfiera el proyecto al controlador (**Controller > Synchronize**). | El controlador contesta que no sirve ninguna variable con ese nombre, exactamente como para un nombre que no existe. El tag se lee con mala calidad, y los demás tags del dispositivo se siguen leyendo. |

Una variable de un programa, una variable local, no se puede publicar: declárela entre las
variables globales, o cópiela a una variable global en el programa.

Cuando el controlador contesta que no sirve ninguna variable con el nombre de un tag, la página del
dispositivo nombra la variable y los tags que la leen, con las dos causas (un nombre que no existe,
o una variable que no está publicada) y estos pasos, en un aviso que desaparece solo en cuanto la
variable se lee; la página del propio tag lleva el mismo aviso. El diario técnico y el agente leen
los mismos pasos.

## La tarjeta FINS {#the-fins-card}

Un dispositivo leído por FINS lleva una tarjeta **FINS** debajo de su tarjeta Conexión: por dónde
viajan sus peticiones, a quién van dirigidas y cuánto espera cada una su respuesta. Un dispositivo
leído por nombre de tag no tiene esa tarjeta.

| Campo | Significado | Valor inicial |
| --- | --- | --- |
| **Protocolo de transporte** | **UDP**: "Un datagrama por petición, respondido al puerto del que salió: el valor predeterminado de los puertos Ethernet de Omron." **TCP**: "Una conexión, en la que el controlador asigna a esta estación su nodo FINS." | UDP |
| **Red** | "La red FINS del controlador: 0 para la red de esta estación, de 1 a 127 a través de las tablas de enrutamiento de los controladores." | 0 |
| **Nodo del controlador** | El nodo FINS del PLC, de 1 a 254. Vacío, la casilla muestra "Automático": por UDP, el último número de la dirección IP del PLC (un PLC en `192.168.250.1` es el nodo 1); por TCP, el nodo que el PLC anuncia cuando se abre la conexión. | Automático |
| **Unidad** | "La unidad del controlador que responde: 0 para la unidad CPU." Hasta 255. | 0 |
| **Nodo de la estación** | Solo UDP: el nodo FINS de esta estación, de 1 a 254. Vacío, la casilla muestra "Automático": el último número de la dirección IP de esta estación en la red por la que llega al PLC. Por TCP la casilla no se dibuja, porque el PLC asigna el nodo en la conexión. | Automático |
| **Tiempo de espera de respuesta (ms)** | "Cuánto espera una petición FINS su respuesta." De 100 a 60,000. | 2,000 |

Un número fuera de su rango se rechaza debajo de la casilla, por ejemplo "Ingrese un número entre 0 y 127.",
y la casilla regresa al valor vigente. Pasar el transporte a TCP conserva el nodo de la estación
capturado para UDP, que el dispositivo ya no usa.

## Host Link en una línea serie {#host-link-on-a-serial-line}

Un controlador CP1E, CP1L, CP1H, CJ o CS que solo tiene puerto serie (RS-232C, o RS-485 y RS-422A mediante una tarjeta opcional o un convertidor) se lee por FINS sobre Host Link, a través de una línea serie del driver Omron: un puerto COM que comparten hasta 32 controladores, cada uno respondiendo a su propio número de unidad. Agregue la línea con **Agregar línea** en la tabla Líneas serie de la página del driver y ponga su **Puerto serie**, sus **Baudios** y su **Formato serie** en lo que tienen configurado los puertos serie de los controladores (el resto de la página de la línea está en [Líneas serie](connector-lines)), habilítela y luego agregue cada controlador con **Agregar dispositivo** en la página de la línea.

| Ajuste | Dónde | Valor |
| --- | --- | --- |
| Modo del puerto | El PLC Setup del controlador, para el puerto serie al que va conectada la línea | Host Link |
| Baudios y formato | La línea | Como estén configurados los puertos de los controladores; un puerto Host Link sale de fábrica con 9600 baudios y `7E2` |
| **ID de unidad** | La tarjeta Conexión del dispositivo, junto a **Línea serie · fija** | El número de unidad Host Link del controlador, de 0 a 31, como lo fija su PLC Setup. Un dispositivo nuevo toma el primer número libre de la línea; se rechaza un número que ya tiene otro controlador de la línea |
| **Tiempo de espera de respuesta (ms)** | La tarjeta FINS del dispositivo | De 100 a 60,000; 2,000 |

Un dispositivo en una línea se lee por FINS para siempre: no tiene campo **Protocolo**, **Host o IP** ni **Puerto**, y su tarjeta FINS muestra solo "FINS sobre Host Link en esta línea serie, hacia el controlador cuyo número de unidad (configurado para su puerto serie en el PLC Setup) es el ID de unidad de arriba." y el **Tiempo de espera de respuesta (ms)**, porque la petición va a la unidad CPU del controlador al que se dirige el bus y ningún campo de red aplica. Nunca pasa a la red, ni un dispositivo de red pasa a una línea. Sus tags se direccionan igual que por la red (`D100`, `W0.01`), y su endpoint nombra la línea y la unidad, por ejemplo `omron://serial/<line id>/COM5/9600/7E2?protocol=fins&transport=hostlink&hostLinkUnit=0&timeoutMs=2000`.

| En una línea serie | Qué pasa |
| --- | --- |
| Varios controladores en una línea | Una petición y su respuesta a la vez para toda la línea; la respuesta de otra unidad, o el ruido, se ignora |
| Un controlador que no responde dentro de su tiempo de espera | Ese dispositivo se reconecta; los otros controladores de la línea siguen leyendo |
| El controlador toma la trama como dañada y responde un código de fin Host Link, como `13 (FCS error)` | El dispositivo se reconecta |
| El puerto falla, por ejemplo cuando se desconecta el adaptador | Todos los dispositivos de la línea se reconectan; el puerto se vuelve a abrir tras una pausa de 1 segundo, que se duplica hasta un minuto |
| Un tag de texto | Como máximo 534 caracteres, lo que lleva una trama Host Link |

El escaneo no busca en una línea serie: agregue cada controlador por su número de unidad.

## El direccionamiento {#addressing}

Un tag se direcciona con una casilla de su tarjeta Fuente, cuyo nombre sale del protocolo del
dispositivo: **Dirección de memoria** por FINS, **Nombre de variable** en un dispositivo leído
por nombre de tag, con la pista del protocolo abajo. Una dirección que el driver no puede leer se
rechaza en la página del tag ahí donde se escribe, con el motivo. La línea de solo lectura
**Dirección de origen (bus)** de la tarjeta Fuente muestra la dirección que recibe el driver.

### Direcciones de memoria (FINS) {#memory-addresses-fins}

Una dirección de memoria se forma con las letras del área, el número de palabra en decimal y,
para un solo bit, un punto y el bit, de 00 a 15. Las letras no distinguen mayúsculas de
minúsculas, y también se leen las grafías antiguas.

| Área | Ejemplos | Palabras | También se escribe |
| --- | --- | --- | --- |
| CIO | `CIO100`, `CIO100.05`, `100.05` | 0 a 6143 | un número solo, que es una dirección CIO |
| Trabajo (W) | `W0`, `W0.01` | 0 a 511 | `WR` |
| Retención (H) | `H10`, `H10.00` | 0 a 1535 | `HR` |
| Auxiliar (A) | `A100`, `A100.03` | 0 a 1471 | `AR` |
| Memoria de datos (D) | `D100`, `D100.15` | 0 a 32767 | `DM` |
| Memoria de datos extendida (E) | `E0_100`, `EA_0`, `E18_0` | 0 a 32767 | el banco en hexadecimal, de 0 a 18, entre la E y el guion bajo |

Cada área tiene como límite la mayor que tenga algún controlador CJ, CS o CP (un CJ2 tiene 1,536
palabras de retención y bancos de memoria extendida hasta el 18). Una palabra o un banco que un
controlador más chico no tiene es respuesta del propio PLC, un error en la primera lectura del tag
(vea [Lectura](#reading)). Lo que la página del tag rechaza ahí donde se escribe:

| Usted escribe | La página del tag dice |
| --- | --- |
| Algo que no es un área, una palabra y un bit, como `X100` o `D100.` | "Una dirección de memoria FINS es el área, la palabra y, para un bit, un punto y el bit, por ejemplo D100, W0.01, CIO100.05, H10, A100 o E0_100." |
| Una palabra más allá del final de su área, como `D40000` o `W512` | "Esa palabra está más allá de la última palabra de su área en cualquier controlador CJ, CS o CP." |
| Un bit más allá del 15, como `W0.16` | "El bit de una palabra va de 00 a 15." |
| Un banco más allá del 18, como `E19_0` | "Los bancos de la memoria extendida se numeran de 0 a 18 en hexadecimal." |

La dirección de bus es la dirección en su única grafía, con el bit en dos cifras: `100.5` viaja
como `CIO100.05` y `DM100` como `D100`. Un tag de texto agrega después de un `?` los caracteres
que ocupa, así que un texto de 16 caracteres en D200 viaja como `D200?16`.

### Nombres de variable (NJ/NX) {#variable-names-njnx}

Un controlador NJ, NX o NY se lee por el nombre de una variable global que publica en la red, que
en Sysmac Studio es una variable cuyo atributo Network Publish es Publish Only, Input u Output
(consulte [Preparar el controlador](#prepare-the-controller)). Una variable que el controlador no
publica no se puede leer por nombre. Un nombre se escribe con
letras ASCII, dígitos y guiones bajos, sin empezar nunca con un dígito, con un punto antes del
miembro de una estructura y un índice entre corchetes: `Level`, `Motor.Speed`, `Temps[3]`,
`Grid[1,2]`. Cualquier otra forma se rechaza en la página del tag: "Un nombre de variable se escribe con letras, dígitos y guiones bajos, sin empezar con un dígito, con un punto antes de un miembro y un índice entre corchetes, por ejemplo Level, Motor.Speed o Temps[3]."
Un nombre en otra escritura, que Sysmac Studio permite, se rechaza igual, porque la petición
EtherNet/IP no lo puede llevar.

El controlador enlista sus variables de una forma que este driver no lee, así que cada tag de un
dispositivo leído por nombre de tag se captura a mano. Si el controlador publica un nombre es
respuesta suya, dada en la primera lectura del tag. No hay campo de desplazamiento: un miembro o un
elemento se nombra por sí mismo, y un elemento de un arreglo BOOL se lee por su propio nombre,
como `Flags[5]`. La dirección de bus es el nombre seguido de `?0`, por ejemplo `Motor.Speed?0`.

## Los tipos de dato {#data-types}

Por FINS, el **Tipo de dato** que se ofrece sigue a la dirección:

| La dirección nombra | Tipo de dato | Qué se lee |
| --- | --- | --- |
| Un bit, como `W0.01` | Boolean | Solo ese bit. |
| Una palabra, como `D100` | Int16 o UInt16 | La palabra. |
| Una palabra y la siguiente | Int32, UInt32 o Float | Dos palabras, la palabra baja en la dirección y la alta después, como guardan una palabra doble las propias instrucciones de Omron. La última palabra de un área no arranca ningún par, así que solo ofrece Int16, UInt16 y String. |
| Una palabra y las siguientes, como texto | String | La **Longitud (caracteres, en blanco = 16)** que declara el tag, de 1 a 1998 caracteres, dos por palabra, con el primero en el byte alto. El texto termina en su primer NUL. En una línea serie, de 1 a 534 caracteres. |

Escribir una dirección que no admite el tipo del tag cambia el tipo por el que la dirección lee de
forma más natural: un Boolean para un bit, un Int16 para una palabra. Un tipo que la dirección no
admite se rechaza con los que sí admite, por ejemplo "La dirección D100 se lee como uno de estos tipos de dato: Int16, UInt16, Int32, UInt32, Float, String."
No hay opción de orden de bytes ni de palabras: FINS guarda cada palabra con el byte alto primero,
y el driver se encarga de eso.

Un dispositivo leído por nombre de tag ofrece todos los tipos atómicos de su controlador:

| Tipo de dato | Tipo de la variable en Sysmac Studio |
| --- | --- |
| Boolean | BOOL |
| SByte | SINT |
| Byte | USINT |
| Int16 | INT |
| UInt16 | UINT |
| Int32 | DINT |
| UInt32 | UDINT |
| Int64 | LINT |
| UInt64 | ULINT |
| Float | REAL |
| Double | LREAL |

Una variable WORD se lee como UInt16 y una DWORD como UInt32. Las variables STRING no se leen, y
String no se ofrece. Un tipo fuera de la lista se rechaza con ella: "Una variable de un controlador NJ/NX se lee como uno de estos tipos de dato: Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Float, Double."

## Lectura {#reading}

Por FINS, el dispositivo mantiene una conversación con su PLC y manda una petición a la vez, cada
tag una lectura de área de memoria de sus palabras, y solo toma como respuesta la que trae el
número de esa misma petición, así que una respuesta atrasada nunca se lee como la de la siguiente.
Antes de leer cualquier tag, el PLC tiene que contestar a una lectura de datos del controlador,
con cualquier código de fin; el modelo que nombra se escribe en el diario técnico. Lo que contesta
el PLC decide después qué pasa con cada lectura:

| El PLC contesta | La lectura |
| --- | --- |
| Terminación normal | El valor. |
| Un código de fin sobre el punto, como una dirección que el PLC no tiene | Ese tag se queda sin valor, y su error nombra el código y su significado en el manual de Omron, por ejemplo `end code 0x1103 (address range error)`. Todos los demás tags del dispositivo siguen leyendo. |
| Un código de fin sobre el camino hasta el PLC (0x01xx, 0x02xx, 0x03xx, 0x05xx), un nodo intermedio que agotó su tiempo en el camino, o nada dentro del **Tiempo de espera de respuesta (ms)** | El dispositivo se vuelve a conectar, y sus tags fallan en sus lecturas hasta que el PLC conteste otra vez. La política de cada tag para [un dispositivo que no contestó](connector-value-pipeline#the-device-did-not-answer) decide lo que muestra. |

Un dispositivo leído por nombre de tag se verifica preguntando al controlador por una variable que
ningún programa declara: la respuesta del controlador de que ese nombre no existe es una respuesta
del controlador. Sus peticiones pasan por el mismo código EtherNet/IP que las del driver
[Rockwell EtherNet/IP](driver-rockwell), y vencen a los 10 segundos.

## Las escrituras {#writes}

Los tags cuyo **Acceso** es Lectura y escritura o Solo escritura se pueden escribir; un tag nuevo
arranca como Solo lectura. Una escritura espera su turno en la cola del dispositivo junto con las
lecturas, y manda el valor que se pidió y nada más:

| El tag lee | Qué manda la escritura |
| --- | --- |
| Un bit FINS (`W0.01`) | Solo ese bit: el PLC lo cambia en su lugar y deja los demás bits de la palabra como están. |
| Una palabra o palabra doble FINS | El valor completo, en la dirección y, para dos palabras, en la palabra siguiente. |
| Un texto FINS | Toda la longitud declarada, con el texto adelante y NUL atrás, para que no se lea después de él nada de un texto anterior más largo. Un texto que no cabe en la longitud se rechaza, nunca se recorta. |
| Una variable NJ/NX | El valor, a esa variable por su nombre; un elemento de un arreglo BOOL como ese BOOL solo. |

| El PLC contesta a una escritura FINS con | La escritura |
| --- | --- |
| Terminación normal | Entregada. |
| Un código de fin que la rechaza | Rechazada, y el motivo nombra el código y su significado, por ejemplo `end code 0x2101 (read-only)`. |
| Nada dentro del **Tiempo de espera de respuesta (ms)**, o un nodo intermedio que agotó su tiempo en el camino (0x0205) | Sin respuesta. |

Una escritura FINS cuyo valor no cabe en el tipo del tag se rechaza antes de mandar nada.

## El descubrimiento {#discovery}

La página del driver Omron lleva una tarjeta **Alcance del escaneo** con una casilla opcional, "Dirección del controlador para un sondeo FINS, por ejemplo 192.168.250.1 (vacío = solo NJ/NX por difusión)".
Descubrir hace entonces hasta dos preguntas, una después de la otra:

| Pregunta | Cuándo | Qué ofrece |
| --- | --- | --- |
| Una lectura de datos del controlador por FINS y UDP, con todos los nodos automáticos, mandada al PLC de la casilla: una dirección IP o un nombre, con `:port` cuando el PLC contesta a FINS en otro puerto que no sea el 9600. La línea de avance dice "Pidiendo a 192.168.250.1 que se identifique sobre FINS…". | Solo cuando la casilla trae una dirección. | El PLC, como un dispositivo FINS con el nombre del modelo con el que contesta, en `omron://<host>:<port>?protocol=fins&transport=udp&network=0&node=0&unit=0&source=0&timeoutMs=2000`. Un PLC que no contesta nada no ofrece nada. |
| La petición de identidad EtherNet/IP, por difusión en todas las redes en las que está esta computadora. La línea de avance las nombra: "Buscando controladores Omron NJ/NX en 192.168.0.255…". | Siempre. El escaneo escucha hasta que pasan 5 segundos sin respuesta nueva. | Cada controlador NJ, NX o NY que contesta, como un dispositivo leído por nombre de tag, con el nombre de su producto (un NX1P2, por ejemplo). Un acoplador de E/S NX, cuyo nombre de producto empieza con `NX-`, no guarda variables y se pasa por alto, igual que cualquier otro producto Omron. |

Ninguna de las dos preguntas encuentra tags: un PLC FINS no publica una lista de sus direcciones,
y un NJ/NX enlista sus variables de una forma que el driver no lee, así que cada candidato muestra "No se reportó ningún tag. Agregue el dispositivo para configurar sus tags en el editor."
Lo que haya en la casilla que no sea un host se rechaza debajo, y Descubrir se pone en gris: "Un escaneo Omron pide al controlador escrito aquí que se identifique sobre FINS: su dirección IP o su nombre, con el puerto si hace falta (por ejemplo 192.168.250.1 o 192.168.250.1:9600). Déjelo vacío para buscar solo controladores NJ/NX por difusión."
Un controlador en una red en la que esta computadora no está no contesta a la difusión; agréguelo a
mano. El escaneo de Rockwell EtherNet/IP oye la misma difusión y le deja todos los controladores
Omron a este. El resto del comportamiento del escaneo está en [Descubrimiento](connector-discovery).

## Herramientas del agente {#agent-tools}

`driver_capabilities` describe este driver bajo `omron`: sus dos protocolos, cada uno con los
campos de dispositivo, las formas de dirección y los tipos de dato que acepta, los transportes y
los rangos FINS, las escrituras y el descubrimiento. `device_upsert driver=Omron` acepta
`omronProtocol` (`Fins` o `NjNx`) y, por FINS, `finsTransport` (`Udp` o `Tcp`), `finsNetwork`,
`finsNode` (0 para automático), `finsUnit`, `finsSourceNode` (solo UDP, 0 para automático) y
`finsResponseTimeoutMs`; un dispositivo leído por nombre de tag no acepta puerto ni campos FINS.
`tag_upsert` acepta la dirección de memoria o el nombre de variable como `address`, el tipo como
`opcUaType` (si se omite, un bit toma Boolean y una palabra Int16) y la longitud de un texto FINS
como `wireQuantity`. `device_discover driver=Omron` corre el escaneo, con `target` para el sondeo
FINS. Un CJ2 leído por UDP y un NX1P2 leído por nombre de tag:

```
device_upsert driver=Omron name=Press host=192.168.250.1 omronProtocol=Fins finsTransport=Udp
tag_upsert device=Press name=Level address=D100 opcUaType=Float
device_upsert driver=Omron name=Filler host=192.168.250.2 omronProtocol=NjNx
tag_upsert device=Filler name=Speed address=Motor.Speed opcUaType=Float
```

Un controlador en una línea serie cuelga de una línea de este driver: `serial_line_upsert driver=Omron` crea la línea, y `device_upsert driver=Omron serialLineId=<id>` agrega el controlador por Host Link (`finsTransport=HostLink`, que la línea implica) con `unitId`, su número de unidad de 0 a 31 (si se omite, el primero libre), y `finsResponseTimeoutMs`; ahí se rechazan los campos de red. Un CP1L en la unidad 0 en COM5:

```
serial_line_upsert driver=Omron name=HostLink serialPort=COM5 baudRate=9600 serialFormat=7E2
device_upsert driver=Omron name=Mixer serialLineId=<the line's id> unitId=0
tag_upsert device=Mixer name=Level address=D100 opcUaType=Int16
```

Las demás herramientas están en [Herramientas del agente](agent-tools).

## Límites que conviene conocer {#limits-worth-knowing}

- Un controlador que solo habla los comandos Host Link más antiguos del modo C, como un CPM1, un CPM2, un CQM1 o un C200HS, no se lee, ni en una [línea serie](#host-link-on-a-serial-line) ni a través de un convertidor: el driver solo envía comandos FINS.
- Los temporizadores y contadores no se ofrecen por FINS: su valor actual se guarda en BCD o en
  binario según cómo esté configurado el PLC, y nada en una respuesta FINS dice cuál. Lea ese valor
  a través de una palabra a la que el programa lo copie.
- Las variables de un controlador NJ/NX nunca se enlistan, ni en la página del tag ni en un
  escaneo: cada nombre se captura.
- Un dispositivo leído por nombre de tag lee un valor atómico por tag. No se leen las variables
  STRING, una estructura completa ni un arreglo completo; un miembro o un elemento se lee por su
  nombre.
- El driver manda tres comandos FINS y ninguno más: lectura de área de memoria, escritura de área
  de memoria y lectura de datos del controlador. Nunca cambia el modo de operación del PLC, su
  reloj ni su programa.

## Bueno saber {#good-to-know}

- Por UDP, la estación manda cada petición desde un puerto propio y el PLC contesta a ese puerto,
  que es como vienen configurados de forma predeterminada los puertos Ethernet de Omron. Una unidad
  Ethernet configurada con la conversión de direcciones estática contesta al puerto 9600 de la
  estación, donde el driver no escucha: lea ese PLC por TCP.
- Una red FINS distinta de 0 se alcanza mediante las tablas de enrutamiento configuradas en los
  PLC; la estación no enruta nada por su cuenta.
- A un controlador NJ/NX se le pregunta primero por la ruta CIP `1,0` y, cuando esa no obtiene
  respuesta, por 18 seguido de la propia dirección IP del controlador, como `18,192.168.250.1`; la
  ruta que contestó se prueba primero la siguiente vez. No hay campo de ruta.
- Cada tag FINS es una petición propia, y un dispositivo manda una a la vez, así que el tiempo de
  una ronda de lecturas crece con el número de sus tags.