Configuring Interfaces
Overview
Section titled “Overview”An interface is one configured connection to one endpoint: an OPC UA server, an S7 PLC, an MQTT broker, a robot controller. Each enabled interface runs independently, reconnects on its own and can be changed while the gateway keeps running.
A signal maps a protocol address to a name, a direction and a type. Signal names are the contract with the 3D model — the viewer binds by name, so a signal called Conveyor1_Running in the gateway meets the component that expects Conveyor1_Running in the model.
Everything on this page is configured in the CONNECT panel of realvirtual WEB. The same operations exist as a REST API if you prefer to script them.
Creating an interface
Section titled “Creating an interface”- Open the CONNECT panel and add an interface.
- Pick the type. The dialog then asks only for the parameters that type actually needs — see supported protocols.
- Save.
The gateway starts the interface immediately. There is no restart, and other interfaces are not touched.
| State | Meaning |
|---|---|
| Connected | The connection is up and signals are being exchanged |
| Connecting | A connection attempt is running |
| Error | The last attempt failed; the reason is on the card. Reconnect follows a growing backoff of 1, 2, 4, 8, 15 and 30 seconds |
For the listener-style interfaces — Modbus server, shared memory — Connected means the gateway is published and accepting attachments, not that a particular remote client is currently attached.
Update cycle
Section titled “Update cycle”Update cycle sets how often a polling interface reads its signals, in milliseconds. Event-driven protocols — MQTT, ctrlX, Keba, and TwinCAT in notification mode — deliver changes when they happen and use the cycle only as a keep-alive.
Values reach the browser on a fixed 10 ms tick, and only what changed is sent.
Adding signals
Section titled “Adding signals”Signals reach a configuration in three ways, depending on what the controller offers:
Browse
Section titled “Browse”For protocols that can be browsed — OPC UA, MQTT, ctrlX, TwinCAT, EtherNet/IP, Keba, Festo — the Browse button runs a discovery on the live connection and lists what it finds. Select the signals you want, assign the direction, and bind. The bound signals are registered immediately and persisted to the interface.
Discovery always runs on a separate short-lived connection, so browsing never disturbs the running exchange.
Import a tag table
Section titled “Import a tag table”A tag table exported from the engineering tool is imported in the browser and pushed to the gateway. This is the usual path for a Siemens process image and for controllers with hundreds of tags.
Enter manually
Section titled “Enter manually”For protocols without a browse mechanism — S7, Modbus client and server, FANUC, Denso, ABB RobotStudio — signals are entered by hand. The dialog knows what each protocol expects: it shows the right address label, examples and data types, and it validates the address with the same parser the interface itself uses at connect time.
Where the address already implies a direction — an S7 area letter, a FANUC signal prefix — the dialog prefills it.
Signal direction
Section titled “Signal direction”Direction follows the PLC convention, exactly as in Unity. It is expressed from the controller’s point of view, not the browser’s:
| Type | Who writes | Who reads | Typical use |
|---|---|---|---|
| PLCInputBool / Int / Float | realvirtual (viewer, simulation) | the PLC | Sensor state, part present, axis feedback |
| PLCOutputBool / Int / Float | the PLC | realvirtual (viewer) | Motor on, valve command, setpoint, lamp |
Read it as the PLC’s terminal strip: a PLC input is something the field — here: the digital twin — supplies. A PLC output is something the PLC drives and the twin shows.
The value chip carries the direction and the current value, so a frozen signal is visible without opening anything.
Write access to the controller
Section titled “Write access to the controller”Every interface has an Allow web to PLC switch, and it is off by default.
While it is off, values written from the browser are accepted into the gateway and visible in the HMI, but they are not passed on to the real controller. This makes a monitoring installation safe by construction: an operator can click anything in the HMI without reaching the machine.
Turn it on deliberately, per interface, when the HMI is supposed to command the machine.
Changing and removing signals
Section titled “Changing and removing signals”Configuration changes are applied by hot-reload: the affected interface restarts with the new configuration while everything else keeps running.
Renamed or deleted signals disappear from the signal list and from the browser stream right away — an old name never lingers until the next gateway restart. A removal triggers one full resynchronisation so every connected browser agrees on the new set.
Signal issues
Section titled “Signal issues”Signals the gateway knows it can never decode are reported per interface and shown as a badge on the interface card:
| Issue | Meaning |
|---|---|
| Address parse error | The address could not be understood. The signal stays registered but never updates |
| Out of bounds | The address points outside the received data — typically a process image that is shorter than the tag table expects. It clears by itself once the payload fits |
Profiles
Section titled “Profiles”A profile is a named snapshot of all interfaces and bridges, including per-signal historian recording. Profiles live in the viewer’s CONNECT settings: until the live configuration is saved there, the selector shows unsaved live configuration; Save turns it into a named profile. Switching — in the settings or from the tray menu — hot-reloads the interfaces without restarting the gateway.
A profile can be bound to a model. When that model becomes active, its profile activates with it, so a model always runs with the configuration it belongs to. Use profiles for a gateway that serves more than one machine or that alternates between a real controller and a simulation.
Moving signals between interfaces
Section titled “Moving signals between interfaces”Two mechanisms move values without a PLC in the loop:
- Mirroring copies all signals of a source interface into an output interface — MQTT or shared memory — keeping the names. Use it to republish a PLC’s signals to an MQTT broker.
- Mapping connects one signal to one signal of any other interface, with an explicit rule for type conversion. Feedback loops are detected and broken.
See also
Section titled “See also”- Supported protocols — parameters and address formats per protocol
- First connection — the shortest path to live values
- REST and WebSocket API — the same operations for scripts