Overview
Native protocols and OPC communication are two methods for enabling device communication in industrial automation systems. This page explores the benefits of using native protocol interfaces with PLCs, including which include higher performance, cost reduction, and improved field maintenance and deployment.
On this page:
Table of Contents maxLevel 3
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 parallel execution (multi-threading) available in the Device Module allows optimized configuration not available in most OPC servers.
Extended Functionality
thought By connecting through the Native Drivers, an additional set of functionality is functionalities will be available,. For instance, for ControlLogix and CodeSys, we can execute discovery methods that goes go beyond what would be available using a third-party supplied OPC gateway to 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...
| Page Tree | ||||
|---|---|---|---|---|
|