PLC → Historian (Modbus)¶

La frontera donde el sistema toca la máquina. Es la primera del camino y la única que depende de hardware que el equipo no controla.

Dos cosas conviene tener claras antes de cualquier detalle: es de solo lectura —el sistema nunca le escribe al PLC, y eso es una decisión registrada en SYS-ADR-007, no una casualidad— y nunca se ejecutó contra un PLC real.

Cómo se lee cada variable¶

Son 18 variables, y el tipo declarado determina de qué espacio de direcciones del PLC sale:

Que los booleanos salgan de un espacio distinto importa para leer el mapa: la dirección 0 de una bobina y la dirección 0 de un registro no son el mismo lugar. No hay colisión entre estado, que es una bobina, y el resto.

Dos campos de la configuración se leen mal con frecuencia, así que vale decir qué hacen:

El orden de palabra se declara solo en las once float32, que son las únicas donde influye. Está bien resuelto y vale notarlo, porque es el detalle que más suele estar de más.

El mapa de registros¶

Las direcciones están espaciadas de diez en diez, y no se solapan —importa, porque cada float32 ocupa dos registros—, con una sola excepción:

Dos variables más merecen una nota: la hora y la fecha vienen empaquetadas en un entero —hora como HHMM y fecha como DDMM—, sin año. No son marcas de tiempo utilizables: la marca de tiempo real de cada medición la pone el historian al leer.

El ciclo de lectura¶

flowchart TD
    A[Inicio del ciclo] --> B[Siguiente variable]
    B --> C{¿La lectura lanza error?}
    C -->|no| D{¿Devolvió un valor?}
    C -->|sí| E[Reintenta: hasta 3 veces,<br/>esperando 5 s entre intentos]
    E --> C
    D -->|sí| F{¿Tiene entrada en el catálogo?}
    D -->|no| G[Calidad BAD, solo al log.<br/>Sin reintento]
    F -->|sí| H[Escribe el punto]
    F -->|no| I[Se descarta, solo un aviso al log]
    H --> J{¿Quedan variables?}
    G --> J
    I --> J
    J -->|sí| B
    J -->|no| K[Espera el intervalo y repite]

El intervalo por defecto es 1 segundo, y las 18 variables se recorren en serie. De ahí salen tres comportamientos que no son evidentes leyendo la configuración:

1 · Un PLC que falla secuestra el ciclo entero¶

Los reintentos esperan 5 segundos y son hasta 3 por variable. Con las 18 fallando, un ciclo de ~1 segundo pasa a unos 4 minutos y medio, y las variables sanas quedan esperando detrás de las que fallan. Está analizado en calidad y resiliencia.

2 · No todas las fallas reintentan¶

El reintento se dispara solo si la lectura lanza una excepción. Si el PLC responde algo que no trae datos utilizables, la lectura no lanza nada: devuelve vacío, se marca la calidad como mala y se pasa a la siguiente sin reintentar.

Es una asimetría llamativa: el caso más barato de reintentar es el único que no reintenta, y el más caro reintenta tres veces esperando cinco segundos.

3 · La calidad del dato no sale del log¶

Cada lectura produce un indicador de calidad, y no se escribe con el punto: no es etiqueta ni campo. Queda en el registro de texto del proceso.

La consecuencia está del otro lado de todo el camino: el dashboard no puede distinguir una medición de un hueco. Ver flujo de datos.

Qué hace falta para conectar un PLC real¶

En orden, y el segundo es el que más fácil se pasa por alto:

1. Apuntar el historian al PLC en lugar del simulador. Es una variable de entorno.

2. Confirmar el orden de palabra de los float32. Si el PLC entrega las dos palabras invertidas —algo muy común—, hay que cambiarlo, y acá hay un problema:

   El orden de palabra invertido está implementado mal

   Con el orden invertido, un valor que debería ser 1.5 sale como 6.9e-41.

   Hoy no afecta a nada, porque las 18 variables usan el orden directo. Pero es justamente la perilla que habría que mover al conectar un PLC con palabras invertidas, y el resultado no es un error: es un número absurdo, muy cerca de cero, que el resto del sistema acepta y almacena como si fuera una medición.

   Es una línea de corrección, y conviene hacerla antes de la primera conexión, no durante.

3. Verificar el mapa de direcciones contra la documentación del PLC, incluido el caso de peso y pesoBruto.

4. Decidir si hace falta escala. Hoy no hay ninguna, y si el PLC entrega enteros escalados —décimas de kilo, por ejemplo— las mediciones van a estar mal por un factor constante, que es el tipo de error más difícil de notar.

Qué no puede decir esta página¶

• Si el mapa de registros coincide con el PLC de la máquina. El único contraste disponible es el simulador, y el simulador salió del mismo mapa.
• El modelo ni la marca del PLC, ni si hay más de uno. No está en ningún repositorio.
• Si peso y pesoBruto son la misma cosa en la máquina.
• Con qué frecuencia el PLC actualiza sus propios registros. Leer cada un segundo no garantiza un valor nuevo por segundo.

Dónde está implementado¶

El contrato vive en el repositorio del historian, que es de un autor externo. Los archivos que lo fijan:

• Las 18 variables, sus direcciones, tipos y orden de palabra: src/historian/tags.yaml
• Función Modbus por tipo, identificador de esclavo y aplicación de la escala: src/historian/modbus_reader.py
• Valores por defecto de la configuración, incluido que la escala es opcional y nunca se declara: src/historian/models.py y src/historian/tag_loader.py
• Conversión de registros a valores, y el defecto del orden invertido: src/historian/parsers.py
• Intervalo, recorrido en serie, política de reintentos, destino del indicador de calidad y descarte por falta de entrada en el catálogo: src/historian/main.py
• Mapa de direcciones del simulador, con la dirección compartida declarada a propósito: src/historian/mock_modbus.py
• El empaquetado y el CI fijando el simulador: docker-compose.yml y .github/workflows/ci.yml

Relacionado¶

• Catálogo de variables — qué hace el sistema con estas 18 variables después de leerlas
• Flujo de datos — el camino completo, de este PLC al dashboard
• SYS-ADR-007 — sistema de monitoreo, no de control: por qué nunca se le escribe al PLC