> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreflux.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Industrial Routes Overview
> Connect your Coreflux broker to PLCs, industrial controllers, and automation systems using industrial protocol routes
## Why Industrial Routes?
Bridge the gap between your PLCs and MQTT without custom middleware. Read sensor data, write setpoints, and integrate industrial equipment into your IoT pipeline—using a single, consistent configuration pattern across all supported protocols.
## Industrial Protocol Integration
Industrial routes enable direct communication between your Coreflux MQTT broker and industrial automation equipment. Read data from PLCs, write setpoints, and bridge the gap between IT and OT systems - all through standardized LoT (Language of Things) syntax.
**Like a translator at an international meeting.** Industrial routes speak both PLC (Modbus, S7, OPC UA) and MQTT—so your broker can read sensor data and send commands without custom glue code.
## Supported Protocols
Industry-standard protocol for PLCs and industrial devices over Ethernet.
RS-232/RS-485 serial communication with Modbus RTU devices.
Native S7 protocol for Siemens S7-200/300/400/1200/1500 PLCs.
Unified Architecture for cross-platform industrial communication.
TwinCAT ADS protocol for Beckhoff PLCs with AutoDiscovery support.
ControlLogix, CompactLogix, and other Rockwell Automation PLCs.
CIP-based communication for Allen-Bradley and compatible devices.
Omron FINS protocol for CJ/CS/CP series PLCs.
***
## Protocol Comparison
| Protocol | Transport | Use Case | Vendor |
| ------------- | ---------- | ------------------------------- | ------------ |
| Modbus TCP | TCP/IP | Universal PLC communication | Multi-vendor |
| Modbus Serial | RS-232/485 | Legacy devices, long distances | Multi-vendor |
| Siemens S7 | TCP/IP | Siemens automation systems | Siemens |
| OPC UA | TCP/IP | Cross-platform, secure IIoT | Multi-vendor |
| ADS | TCP/IP | Beckhoff TwinCAT systems | Beckhoff |
| Allen-Bradley | TCP/IP | Rockwell Automation | Rockwell |
| EtherNet/IP | TCP/IP | CIP devices, explicit messaging | Multi-vendor |
| FINS | TCP/UDP | Omron PLCs | Omron |
***
## Common Architecture
All industrial routes share a common architecture with three key components:
```mermaid theme={null}
graph LR
subgraph broker [Coreflux Broker]
Route[Industrial Route]
Tags[TAG Definitions]
Mapping[MAPPING Config]
end
subgraph plc [PLC / Controller]
Registers[Registers/Variables]
end
subgraph mqtt [MQTT Topics]
Pub[Published Data]
Sub[Write Commands]
end
Route --> Tags
Tags --> Mapping
Mapping -->|Poll| Registers
Registers -->|Read| Pub
Sub -->|Write| Registers
```
### 1. Connection Configuration
Each protocol has specific connection parameters:
```lot theme={null}
ADD _CONFIG
WITH HOST "192.168.1.100"
WITH PORT 502
// Protocol-specific options...
```
### 2. MAPPING with Polling
**MAPPING Definition**
A **MAPPING** is a scheduled, continuous polling operation that automatically reads data from industrial devices (PLCs, Modbus devices, etc.) at regular intervals and publishes the values to MQTT topics.
* **Polls:** industrial device at regular intervals (`EVERY`)
* **Reads:** multiple data points (TAGs) in a single operation
* **Publishes:** each TAG value to its own MQTT topic
In LoT, you define a MAPPING like this:
```lot theme={null}
ADD MAPPING SensorGroup
WITH EVERY 500 MILLISECONDS
ADD TAG Temperature
// TAG config...
ADD TAG Pressure
// TAG config...
```
#### Common MAPPING-level fields
These fields are available at the MAPPING level across all industrial protocols:
Base MQTT topic for publishing tag data. Each TAG publishes to `{SOURCE_TOPIC}/{TAG_NAME}`.
Polling interval (e.g. `500 MILLISECONDS`, `1 SECOND`).
***
### 3. TAG Definitions
**TAG Definition**
A **TAG** is an individual data point within a MAPPING that represents a specific variable or register in an industrial device.
* **Identifies:** a specific memory address in the device
* **Transforms:** raw value using scaling, offset, and engineering units
* **Publishes:** to a dedicated MQTT topic
* **Monitors:** changes using deadband filtering
- **Data transformation:** Scaling, offset, min/max validation
- **Change detection:** Deadband to filter noise
- **Formatting:** Publish as JSON or raw value
In LoT, you define a TAG like this:
```lot theme={null}
ADD TAG Temperature
WITH ADDRESS "100"
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/temperature"
WITH SCALING 0.1
WITH UNIT "°C"
```
#### Common TAG Parameters
These parameters are available across all industrial protocols:
Protocol-specific address (register number, variable path, NodeId, etc.).
Address type varies by protocol (e.g., HOLDING\_REGISTER, DATABLOCK, SYMBOL).
Data type for the value. Common types: `BOOL`, `INT16`, `UINT16`, `INT32`, `UINT32`, `FLOAT`, `DOUBLE`, `STRING`.
Topic where PLC values are published. Subscribe here to receive sensor data.
Topic to send write commands. Publish a value here to write it to the PLC (requires WRITABLE true).
Multiplier applied to raw value. Formula: `published_value = (raw_value * SCALING) + OFFSET`. Default: 1.0.
Value added after scaling. Default: 0.0.
Number of decimal places in published value. Default: 2.
Minimum allowed value. Values below this are filtered out.
Maximum allowed value. Values above this are filtered out.
Minimum change required to publish a new value. Reduces network traffic for slowly changing values. Default: 0.0.
Output format: `VALUE_ONLY` (just the value) or `JSON` (structured object with metadata). Default: VALUE\_ONLY.
Engineering unit for documentation and JSON output (e.g., °C, bar, RPM).
Human-readable description of the TAG.
Allow writing to this TAG via DESTINATION\_TOPIC. Default: false.
Byte order for multi-byte values: `BIGENDIAN` or `LITTLEENDIAN`. Default: BIGENDIAN.
Word order for 32-bit values: `BIGENDIAN` or `LITTLEENDIAN`. Default: BIGENDIAN.
***
### 4. SOURCE\_TOPIC Configuration
There are two ways to configure where TAG values are published. Use group-level when you want consistent topic structure across all TAGs in a MAPPING; use individual TAG when you need custom paths per sensor (e.g., different namespaces for temperature vs pressure).
Define `SOURCE_TOPIC` at the MAPPING level. Each TAG automatically publishes to `{SOURCE_TOPIC}/{TAG_NAME}`.
```lot theme={null}
ADD MAPPING ProductionLine
WITH SOURCE_TOPIC "factory/line1"
WITH EVERY 1 SECOND
ADD TAG Temperature
WITH ADDRESS "100"
WITH DATA_TYPE "FLOAT"
ADD TAG Pressure
WITH ADDRESS "102"
WITH DATA_TYPE "FLOAT"
```
**Result:** Temperature publishes to `factory/line1/Temperature`; Pressure publishes to `factory/line1/Pressure`.
Define `SOURCE_TOPIC` at each TAG level for custom topic structure.
```lot theme={null}
ADD MAPPING ProductionLine
WITH EVERY 1 SECOND
ADD TAG Temperature
WITH SOURCE_TOPIC "sensors/temp/line1"
WITH ADDRESS "100"
WITH DATA_TYPE "FLOAT"
ADD TAG Pressure
WITH SOURCE_TOPIC "sensors/pressure/line1"
WITH ADDRESS "102"
WITH DATA_TYPE "FLOAT"
```
**Result:** Temperature publishes to `sensors/temp/line1`; Pressure publishes to `sensors/pressure/line1`.
***
### 5. EVENT (On-Demand Operations)
Understanding on-demand operations in routes.
**EVENT Definition**
An **EVENT** is an on-demand operation that waits for messages on an MQTT topic, executes a specific action when triggered, and publishes the results back to another MQTT topic.
Use EVENT when you need on-demand reads or writes (triggered by a message); use MAPPING for continuous polling. Syntax varies by protocol—see the protocol-specific docs (e.g., [Modbus TCP](./modbus-tcp#event-based-operations)) for details.
In LoT, you define an EVENT like this:
```lot theme={null}
ADD EVENT ReadOnDemand
WITH SOURCE_TOPIC "plc/commands/read"
WITH DESTINATION_TOPIC "plc/responses/read"
WITH QUERY ""
```
#### Common EVENT Parameters
These parameters are available across all industrial protocols for EVENT definitions:
MQTT topic where the EVENT listens for trigger messages. Publish a message here to execute the operation.
MQTT topic where the EVENT publishes the result of the operation.
Protocol-specific specification of the operation (read or write) and its parameters. Uses LoT object syntax. See each protocol's documentation for supported operations.
### When to Use MAPPING vs EVENT
Use the right acquisition pattern for the job:
| | MAPPING (Cyclic) | EVENT (On-Demand) |
| --------------- | ---------------------------------------- | ------------------------------------------------ |
| **Trigger** | Automatic, on a timer (`WITH EVERY`) | Manual, via an MQTT message to SOURCE\_TOPIC |
| **Direction** | Reads from device, publishes to MQTT | Reads or writes on command, publishes result |
| **Best for** | Dashboards, alarms, continuous telemetry | Operator commands, diagnostics, recipe downloads |
| **Data volume** | Constant stream at defined interval | Only when requested |
Most real-world routes combine both patterns: MAPPING for continuous monitoring and EVENT for on-demand operations within the same `DEFINE ROUTE`.
***
## Basic Example Pattern
### Cyclic Only
This minimal pattern works across all industrial protocols for continuous data acquisition:
```lot theme={null}
DEFINE ROUTE MyPLCConnection WITH TYPE
ADD _CONFIG
WITH HOST "192.168.1.100"
// Connection parameters...
ADD MAPPING CriticalSensors
WITH EVERY 100 MILLISECONDS
ADD TAG Temperature
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/temperature"
ADD TAG Pressure
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/pressure"
ADD MAPPING SlowChangingData
WITH EVERY 5 SECONDS
ADD TAG ProductCount
WITH ADDRESS ""
WITH DATA_TYPE "INT32"
WITH SOURCE_TOPIC "plc/production/count"
```
### Combined (Cyclic + On-Demand)
A production route typically combines MAPPING for continuous monitoring with EVENT for on-demand operations. Publish a message to the EVENT's SOURCE\_TOPIC to trigger a one-shot read or write, and receive the result on the DESTINATION\_TOPIC:
```lot theme={null}
DEFINE ROUTE MyPLCConnection WITH TYPE
ADD _CONFIG
WITH HOST "192.168.1.100"
// Connection parameters...
// Continuous monitoring — polls every 500ms
ADD MAPPING ProcessSensors
WITH EVERY 500 MILLISECONDS
ADD TAG Temperature
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/temperature"
ADD TAG Pressure
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/pressure"
// On-demand read — triggered by publishing to SOURCE_TOPIC
ADD EVENT ReadRegister
WITH SOURCE_TOPIC "plc/commands/read"
WITH DESTINATION_TOPIC "plc/responses/read"
WITH QUERY "{operation: READ, address: , data_type: FLOAT}"
// On-demand write — triggered by publishing to SOURCE_TOPIC
ADD EVENT WriteSetpoint
WITH SOURCE_TOPIC "plc/commands/write"
WITH DESTINATION_TOPIC "plc/responses/write"
WITH QUERY "{operation: WRITE, address: , value: 0}"
```
***
## Advanced Example Pattern
When you need engineering-unit conversion, noise filtering, range validation, or bidirectional control, add transformation and publishing parameters to your TAGs. This pattern builds on the basic structure above to unlock the full power of industrial routes.
### Scaled and Filtered Monitoring
Apply scaling and offset to convert raw PLC register values into meaningful engineering units, and use deadband to suppress noise:
```lot theme={null}
DEFINE ROUTE AdvancedPLCConnection WITH TYPE
ADD _CONFIG
WITH HOST "192.168.1.100"
// Connection parameters...
ADD MAPPING ProcessMonitoring
WITH EVERY 500 MILLISECONDS
ADD TAG Temperature
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/temperature"
// Value transformation — raw 245 becomes (245 * 0.1) + (-40) = -15.5
WITH SCALING 0.1
WITH OFFSET -40
WITH UNIT "°C"
// Noise filtering — only publish when change exceeds 0.5
WITH DEADBAND 0.5
// Range validation — discard values outside physical limits
WITH MIN_VALUE -20
WITH MAX_VALUE 150
// Precision — publish with 1 decimal place
WITH DECIMAL_PLACES 1
// Structured output — includes unit, description, and timestamp
WITH PUBLISH_MODE "JSON"
ADD TAG Pressure
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/sensors/pressure"
WITH SCALING 0.01
WITH UNIT "bar"
WITH DEADBAND 0.1
```
### Writable Setpoints with Validation
Enable bidirectional control by marking TAGs as writable. Published values on the DESTINATION\_TOPIC are written to the PLC, with MIN/MAX enforcing safe limits:
```lot theme={null}
ADD MAPPING Setpoints
WITH EVERY 1 SECOND
ADD TAG TemperatureSetpoint
WITH ADDRESS ""
WITH DATA_TYPE "FLOAT"
WITH SOURCE_TOPIC "plc/setpoints/temperature"
// Bidirectional — publish to DESTINATION_TOPIC to write a value
WITH WRITABLE "true"
WITH DESTINATION_TOPIC "plc/setpoints/temperature/write"
WITH UNIT "°C"
// Safety limits — reject values outside the safe operating range
WITH MIN_VALUE 0
WITH MAX_VALUE 100
```
***
## Best Practices
Group TAGs by update frequency:
* **Fast (50-100ms)**: Safety signals, real-time control
* **Medium (500ms-1s)**: Process values, sensor readings
* **Slow (5-30s)**: Configuration, counters, status
```lot theme={null}
ADD MAPPING FastLoop
WITH EVERY 100 MILLISECONDS
// Critical TAGs only
ADD MAPPING SlowLoop
WITH EVERY 5 SECONDS
// Non-critical TAGs
```
Reduce network traffic for slowly changing values:
```lot theme={null}
ADD TAG Temperature
WITH DEADBAND 0.5 // Only publish if change > 0.5
```
Transform raw PLC values to engineering units in the route:
```lot theme={null}
ADD TAG Temperature
WITH SCALING 0.1 // Raw 245 becomes 24.5
WITH OFFSET -40 // Apply offset if needed
WITH UNIT "°C"
```
Include metadata in published messages:
```lot theme={null}
ADD TAG Temperature
WITH PUBLISH_MODE "JSON"
WITH UNIT "°C"
WITH DESCRIPTION "Main reactor temperature"
```
Output:
```json theme={null}
{
"value": 24.5,
"unit": "°C",
"description": "Main reactor temperature",
"timestamp": "2024-01-15T10:30:00Z"
}
```
Only enable WRITABLE for TAGs that need it, and use specific topics:
```lot theme={null}
ADD TAG Setpoint
WITH WRITABLE "true"
WITH DESTINATION_TOPIC "plc/setpoints/temperature/write"
WITH MIN_VALUE 0
WITH MAX_VALUE 100
```
***
## Next Steps
Choose the protocol that matches your equipment:
Start with the most common industrial protocol.
Connect to Siemens PLCs directly.