Language: English

PLC Bridge

Your controller, talking to your Vorne boards.

One service on the plant network sits between the PLC and every Vorne XL board. The controller reads live counts, state, and OEE, and can start jobs, set down reasons, run changeovers, and inject counts, without anyone standing at a terminal.

Get a demo Read the user guide

What it is

One bridge, six protocols, no program rewrite.

Your PLC only ever talks to the bridge, and the bridge talks to every board. There is no add-on instruction to import and no vendor block to install: your integrator creates tags with the names and types we hand over, and the bridge reads and writes them like any other client.

  • Live job, part, shift, count, state, and OEE values from every board
  • Commands the other way: start a job, set a down reason, run a changeover, start a shift
  • Count and reject injection, reject reasons, team changes, and comments
  • Quality on every value, so a held reading is never mistaken for a fresh one
  • Commands persisted and replayed in order when a board is unreachable
  • V1 and V2 board differences hidden from the controller

Protocols

However your controller prefers to talk.

EtherNet/IP

Allen-Bradley controllers. Every value lands in a named controller tag, and a request and acknowledgement pair carries each command back the other way. Controller-scope base tags only: no add-on instruction, no UDT, no rung.

OPC UA

The bridge runs a server that any client can browse, read, and write, so a SCADA package limited to plain tag reads and writes is enough. Anonymous clients read; writing a command needs an account.

Modbus TCP

One fixed register map, served either way round: the bridge listens and your PLC polls it, or the bridge connects out and mirrors the map into a controller that can only be a server itself.

MQTT Sparkplug B

Births, data on change, and death through the last will, on the standard topic layout, so a Sparkplug host discovers the bridge with no configuration. Commands arrive as DCMD and NCMD.

SLMP / MC Protocol

Native Mitsubishi. The bridge reads and writes MELSEC device memory directly over SLMP on the CPU's built-in Ethernet port, so an iQ-R or iQ-F needs no Modbus gateway and no protocol conversion in the program.

Beckhoff ADS

Native TwinCAT. The bridge addresses TwinCAT variables by symbol name over ADS, so values land in the PLC's own variables rather than in a mapped register block. ADS is part of the TwinCAT runtime; it needs an ADS route between the bridge and the controller.

Unified namespace

Or straight onto your broker.

If the plant's data layer is a broker rather than a controller, the bridge joins it as an edge node. Point it at your broker, name the group, the edge node, and the board it serves, and every board's live production state arrives on the standard Sparkplug topics. There is no tag map to build: leave the rename map empty and every point publishes under its own name.

  • Sparkplug B on the standard topic layout, so a host like Ignition, HiveMQ, or Chariot discovers the bridge with nothing to configure
  • Your naming, not ours. The group and the edge node name are configuration, so the bridge lands where your namespace says it belongs
  • Births carry the whole model, and a host that connects late asks for a rebirth and gets the current value of every point
  • Quality travels with every value, so a held reading is never mistaken for a fresh one, and a value the board never gave stays null instead of becoming a zero
  • Commands come back the other way: a host writes a command metric, and the bridge starts a job, sets a down reason, runs a changeover, or injects counts on the board
  • Not a Sparkplug shop? A plain JSON topic mode publishes the same model under your own prefix, deliberately off the Sparkplug topics, so a host never meets a payload it cannot decode

One thing to be clear about: the bridge publishes. It is not your broker, and it does not subscribe to your other producers.

Vendor and model

It knows which controller it is talking to.

Vendor and model differences are handled rather than ignored.

Identity the protocol carries

Where the protocol carries reliable identity the bridge reads it and configures itself: CIP identity on an Allen-Bradley controller, the model the CPU reports over SLMP on a MELSEC, the device info the TwinCAT runtime returns over ADS.

Where you name the model

Where the protocol carries no identity - Modbus TCP is the plain case, a register is a register - you name the vendor and model and the bridge loads that profile instead.

What a profile carries

  • The vendor's own data types, and its own spelling of them

    so a BOOL, a STRING and a DINT mean what that family means, written the way its tooling writes them.

  • Arrays and structures, including how a structure is laid out on the wire

    so a multi-element value is not split or padded the wrong way.

  • Byte and word order

    so a 32-bit value is not read back halved and swapped.

  • Rate and batch limits

    how many points in one request, and how often the controller will answer.

  • Register and device maps

    so an address means the same thing at both ends.

  • Setup and licensing

    what has to be enabled, routed or licensed before the controller answers at all.

Controllers

Which controllers that means.

We speak protocols and you buy a brand, so here is the translation.

Rockwell Automation, Allen-Bradley

EtherNet/IP

ControlLogix, CompactLogix and Micro800. Values land in named controller tags and commands come back out of them. Controller-scope base tags only: no add-on instruction, no UDT, no rung. The bridge reads the controller's CIP identity and applies that family's profile - tag browse, string handling and name limits differ between a Logix controller and a Micro800, and the profile is where that difference lives.

Siemens

Modbus TCP

S7-1200 and S7-1500, over the CPU's own PROFINET interface. MB_CLIENT polls the bridge; MB_SERVER takes the bridge's writes. Siemens states neither instruction needs additional hardware. Modbus carries no identity, so the model is named in the configuration and its profile brings the register map and the word order with it.

Mitsubishi Electric

SLMP / MC Protocol

MELSEC iQ-R and iQ-F, on the CPU's built-in Ethernet port. The bridge reads and writes device memory directly, with no Modbus gateway in between. It asks the CPU which model it is and loads that profile; the iQ-R and iQ-F device ranges are not the same. Modbus TCP remains available on the iQ-F if a site prefers it.

Omron

Modbus TCP

NJ and NX series, from the CPU's built-in Ethernet port with the ModbusTCPRead, ModbusTCPWrite and ModbusTCPCmd instructions. Nothing to add to the rack. Name the model and the profile does the rest.

Schneider Electric

Modbus TCP

Modicon M241, M251 and M580. The Modbus client and server ship in the controller firmware, so there is nothing to install: the program polls the bridge by calling READ_VAR, or the embedded server takes the bridge's writes.

Beckhoff

ADS

TwinCAT 3, addressed by symbol name over ADS. The bridge reads the runtime's device info and applies the TwinCAT profile. ADS needs an ADS route between the bridge and the controller. OPC UA (TF6100) and Modbus TCP (TF6250) remain available and are licensed TwinCAT functions; ADS is part of the runtime.

One number to settle with your integrator. Modbus TCP runs either way round, and the direction where the bridge writes into the controller rather than being polled needs 6239 contiguous holding registers the controller can both read and write. That is a Modbus-only condition. It applies to Siemens, Schneider and Omron, and to Mitsubishi or Beckhoff only if you take their secondary Modbus route rather than SLMP or ADS. Omron documents the master function, so on an NJ or NX the controller does the polling.

Two things this list is not. EtherNet/IP here means Allen-Bradley CIP tag access, so an EtherNet/IP port on another maker's controller does not reach the bridge that way. And the bridge runs the OPC UA server, so the controller side has to be an OPC UA client: a PLC that offers its own OPC UA server is facing the other way. Your SCADA or historian is usually the OPC UA client on a line. Sparkplug B: the bridge is the edge node and the other side is a Sparkplug host application, not a controller function.

Not on this list? Almost every controller in a plant can be one end of Modbus TCP. Tell us the make and model and we will say which surface it would use and what your integrator would have to build.

Resources

Learn more about PLC Bridge

User Guide

For the plant and whoever runs the service: what the bridge does and does not do, how it is deployed, what the configuration declares, what healthy means, and what happens to a command while a board is down.

Read the guide →

Integrator Guide

For the PLC programmer or system integrator: the tag model, the Vorne Access Control requirement, the tag list to create, and the protocol mappings.

Read the integrator guide →

Interactive Brochure

The full PLC Bridge overview: features, benefits, and where it fits in the suite.

View brochure → (opens in a new tab)

Printable PDF

The same brochure, opened straight into your print dialog to save as a PDF.

Print to PDF → (opens in a new tab)

Put production data on the controller.

Tell us which controller and which protocol, and we will walk through the tags it would read, the commands it could send, and what your integrator has to build.

Get a demo Read the integrator guide