Rapid SCADA’s classic OPC driver requires the OPC server and Communicator to run on the same PC. This is a driver constraint introduced to avoid network DCOM problems. For a remote OPC endpoint, use the OPC UA driver, or place Communicator beside the classic OPC server and send data onward to ScadaServer.
Identify the OPC Architecture
| Connection path | Supported decision | Key constraint |
|---|---|---|
| Classic OPC server to Communicator | Install both on the same PC | The classic OPC driver does not support a remote OPC server |
| OPC UA server to Communicator | Connect to another host | The OPC UA driver supports remote hosts |
| Local Communicator to remote ScadaServer | Use this when the classic OPC server cannot move | Communicator configuration remains local |
Resolve the Remote Classic OPC Constraint
- Confirm whether the data source exposes classic OPC or OPC UA. Do not troubleshoot remote DCOM as though the classic Rapid SCADA driver supports that architecture.
- If the source is classic OPC, install Communicator on the same PC as the OPC server.
- Configure that local Communicator to transfer collected data to ScadaServer on the remote machine.
- If the source supports OPC UA, use the OPC UA driver and configure the remote host connection.
For large tag sets, configuration through the XML file can be more practical than configuring each item through the user interface. The evidence does not identify specific XML elements, filenames, or connection parameters, so retain the identifiers generated by the installed configuration tools.
Diagnose Two-Client Connection Failures
A reported symptom is that the first SCADA client receives data while the second client enters an error state. The available evidence does not establish the root cause. A domain-user configuration was suspected, but it was not verified; an OPC server client-count restriction or incorrect access configuration also remained possible.
Separate this symptom from the Rapid SCADA same-PC rule. First verify whether the OPC server permits multiple simultaneous clients, then compare the security and access settings used by both clients. Testing on a non-domain PC can isolate domain-account effects, but a successful or failed test should be treated as diagnostic evidence rather than proof of a general OPC limitation.
Evaluate Gateway Workarounds Carefully
An OPC DA-to-Modbus TCP bridge was identified as a possible workaround, but the reported implementation could drop all data when one signal stopped responding. Treat gateway behavior as product-specific and verify loss-of-signal isolation before deployment. An OPC DA-to-OPC UA gateway is another architectural option to investigate, but the evidence does not confirm a particular gateway product or its behavior.
FAQ
Can Rapid SCADA Communicator connect to a classic OPC server on another PC?
No. The classic OPC driver requires the OPC server and Communicator to be installed on the same PC because of network DCOM reliability problems.
How do I connect Rapid SCADA to an OPC server on a remote host?
Use the OPC UA driver when the source supports OPC UA. Otherwise, run Communicator locally beside the classic OPC server and transfer the collected data to ScadaServer on the remote machine.
Why does only the first OPC client receive data?
The evidence does not confirm one cause. Check whether the OPC server limits simultaneous clients, compare both clients’ security settings, and use a non-domain test PC to determine whether domain-account configuration contributes to the failure.
