I find there are many ways to communicate between PC and S7 PLC by Ethernet.

But I don't know the basic difference between these ways.

Whether all of these ways use OPC technology?
Whether all of these ways only need a common Ethernet card?

 

I usually don't recommend OPC for a small installations as it's my personal feeling that it's not worth the extra management and effort.

However, if you have a large number of devices using many different native protocols it can be well worth doing just so all your HMI software only has to deal with OPC.

In the end your choice of communication methods will depend largely on the HMI software you plan to use on the PC to display the data (wonderware, etc).

If you use Ethernet to connect the S7 to a PC then all you need is an Ethernet Port or card in the S7 (this is usually specialized equipment) and a standard Ethernet card in the PC.

If the HMI software supports the S7 protocol natively via either a serial port or Ethernet then you're probably better off using the software's native drivers. Of course this has both advantages and disadvantages as compared to OPC.

An OPC server like KEPServer is really a protocol translator which will scan the S7 PLC in it's native protocol and re-present the data via the OPC protocol.

OPC has the following advantages:

1. For serial port connected devices, multiple clients can access the data simultaneously

2. Most PC HMI software supports the OPC protocol

3. If you're dealing with multiple devices using protocols it's great to be able to "normalize" them into one OPC protocol which the HMI supports.

OPC also has some disadvantages:

1. There is an additional layer of complexity added to the data flow / configuration

2. Not all of the native protocol's functionality is usually available via OPC. For just "point" data that's fine, but record oriented data usually isn't easily accessible via OPC.

3. OPC server to OPC client communication can leak memory over wide area networks. This is due to design issues with the Microsoft COM/DCOM protocol on which OPC is built. DCOM security configuration on the PC's can also be a real pain. This is not a concern if the client & server are on the same PC.

4. The most common OPC spec OPC-DA uses DCOM which is not firewall friendly. OPC software Vendors will sell you software to help, but that's usually a pain to manage. There are later OPC XML-DA specs which use XML and are firewall friendly but most HMI vendors don't support those specs yet.

 

libnodave and rllib don't use OPC technology.
They are OpenSource software and run on Linux/Windows at least.
libnodave is in ANSI-C
rllib is in C++
Both only need a common Ethernet card.

rllib is part of a HMI SCADA package
http://pvbrowser.org

 

What "extra management and effort" for OPC are you referring to? Setting up DCOM security is a matter of methodically following the instructions by the vendor. From there on it is only point and click to the data. No programming, no data mapping. Could it be easier than OPC?

I agree OPC adds another layer, but it is invisible to the user. In fact, OPC usually hides several underlying layers of complexity and making
configuration easier.

Yes. With OPC 1.0 and 2.0 complex data structures have not been supported so it has always been broken down into its individual elements, however, the data has been accessible. With OPC 3.0 complex data structures will be supported, but it is not yet implemented in many servers and clients.

DCOM configuration is about following the instructions step by step. What is the DCOM memory leak problem you are alluding to? I've used OPC in many applications for nearly ten years. I have seen a fair share of memory leaks,
but not in DCOM.

The need for running OPC type of data through a firewall is small. OPC deals with live data which is of no interest beyond the control system. At the business they are usually interested in periodic reports compiled from logged data. Anyway, ICONICS Genesis32 is a client with native support for XML-DA. They also provide a XML-DA wrapper for COM servers.

To learn OPC and other automation software technologies take a look at the book "Software for Automation: Architecture, Integration, and Security". http://www.isa.org/autosoftware

Jonas Berge
SMAR
===========
[email protected]
www.smar.com
Learn fieldbus and Ethernet at your own pace: www.isa.org/fieldbuses
Learn OPC and automation software at your own pace: www.isa.org/autosoftware