SPI-MODBridge
Modbus equipment onto the platform, unchanged.
SPI-MODBridge connects Modbus RTU and TCP equipment to SPIDEX. Registers are mapped once and exposed as normalised telemetry, so downstream systems see measurements rather than register addresses.
Why it exists
Modbus is everywhere and carries almost no meaning on its own. Every integration re-derives the same register maps by hand, and that knowledge stays trapped in whichever project produced it.
- ·Modbus RTU and TCP polling
- ·Register-to-measurement mapping
- ·Normalised telemetry output
- ·Local rules on mapped values
- ·Reusable device profiles
On the RS485 segment or Ethernet network alongside the equipment being read.
Security- · Distinct device identity
- · Authenticated platform connection
- · Encrypted transport
- · Signed firmware images
- · Access-controlled remote sessions
How it fits the stack
The Modbus profile is a C3F module, so a mapping written once is reusable on any device that runs the framework.
About C3FMappings are deployed as versioned configuration and can be updated remotely.
About SPIEngineHardware detail
Published values are confirmed. Anything hardware-dependent that has not been verified by engineering is marked rather than estimated.
- Protocol support
- Modbus RTU, Modbus TCP
- Device framework
- C3F
- Polling interval
- Configurable
- Power input
- Pending verification
- Mounting
- Pending verification
- Operating temperature
- Pending verification
Highlighted entries are hardware-dependent values awaiting engineering confirmation. They are published only once verified — ask for the current datasheet during evaluation.
Where it is applied
Energy meters
Drives and motor controllers
PLC-adjacent monitoring
Building services plant
Evaluating SPI-MODBridge?
Ask for the current datasheet, lead time and integration detail. Anything not yet verified will be identified as such.