- This topic has 2 replies, 2 voices, and was last updated 1 year, 2 months ago by
.
-
Posts
-
In cases where
1. In a development environment where the IP Port or Subnet settings differ from production environment, but OPC setting are identical.
2. When the Communicator, Remote OPC UA server and Admin app are on different boxes and different networks, have different accessibility to each other.
I think it helpful to provide a
Test Server URLtextbox on Admin App’sOPC UA Propertieswindow. allowing the user to
set the address for Communicator in originalServer URLtextbox as usual,
in the meanwhile pulling nodes from theTest Server URLserver for configuration, without uploading thisTest Server URLto Communicator.I never felt such is necessary for Modbus. The difference lies in the fact that the OPC properties window is a preview and click based process, which requires connection. I don’t mean this is a drawback, but makes an independent Test URL valuable when connectivity differs.
The other possible approach we use in DrvOpcClassic.
A user can download the structure of the OPC tags to an XML file using a utility. Then open that XML file by a driver UI instead of connecting to an OPC server. May be this approach is straightforward and easy for understanding.For example, a customer can send you an XML file containing OPC nodes. Then an engineer can use it in his office.
In my case I am not worried by the offline issue, since without connection to the RS instance, SA also can’t connect, to me there’s nothing to config. If I am offered connectivity to the remote RS box, I can port forward the remote OPC UA addr+port to a local port for SA to connect through the RS box, it’s just the address will not be the same.
In the case of running a dotnet tool on an existing OPC servers, if that box has restrictions, quirky settings or very old OS, things might not necessarily go easier.
- You must be logged in to reply to this topic.