Page History

Comparison: Native Protocols vs OPC ThirdParty Tools

What are the benefits of supplying native protocols protocol interfaces to PLCs , instead of just use using an OPC client and rely relying on an external OPC server to get the datedata?

Some PLCs are using use OPC UA as their native built-in protocol; certainly, certainly this question does apply applies to them , but as well as to other equipments equipment using proprietary protocols. 

There are many scenarios when where the native driver is more beneficial. Let us explore some of them:

Higher Performance

Instead of a direct connection, invariably adding Adding one more application in the middle, instead of having a direct connection, will cause additional lag time. Further, the AccessTypes and the ability of parles execution parallel execution (multi-threading) available in the Device Module allows optimized configuration not available in most OPC servers.

Extended Functionality

By connecting through the Native Drivers, an additional set of functionalities will be available. For instance, for ControlLogix and CodeSys, we can execute discovery methods that go beyond what would be available using a third-party supplied OPC gateway for those devices.

Cost Reduction

Most of the native drivers are included at no charge. The exceptions when When there is a cost, it is typically quite much smaller than the cost of the OPC server cost.

The OPC server still needs to use the Native Protocol Addresses

One misleading argument to use for using OPC is to hide that it hides the PLC address from the configuration. The reason it this is misleading is that you need to use the native PLC address to setup set up the configuration of the OPC server anyway; you are just duplicated duplicating the work loadworkload.  

The exception here is if the OPC Server server is already installed and serving multiple applications. In this case, the connection using the OPC Client client to the centralized OPC server is recommended.

Another good option is to leverage the OPC Server server included in the Module device module for the Edge application. In this case, the project connects with to the field device with using the native protocol , while still enabling its OPC Server server functionality, so allowing other applications can to use the built-in OPC Server server in the FrameworX platform to access the data. 

Easier Field Maintenance and Deployment 

As explained on in the previous item, if the OPC Server was server is not in its place, adding one more "middle-man" is just stressing only complicates the deployment and maintenance procedures.

Improved technical

support  

Two points for potential failure or misconfigurations, and along with two independent suppliers, typically do not compare with a single environment and centralized support.

In this section...