OPC Massendaten DOKU v10 e

Application for Communication
Mass Data Acquisition with an OPC Client in C# based on .NET
Warranty, Liability and Support
Mass Data Acquisition with OPC
Entry-ID: 21447513
Warranty, Liability and Support

We accept no liability for information contained in this document. Any claims against us - based on whatever legal reason - resulting from the use of the examples, information, programs, engineering and performance data etc., described in this document shall be excluded. Such an exclusion shall not apply in the case of mandatory liability, e.g. under the German Product Liability Act (Produkthaftungsgesetz), in case of intent, gross negligence, or injury of life, body or health, guarantee for the quality of a product, fraudulent concealment of a deficiency or breach of a condition which goes to the root of the contract (wesentliche Vertragspflichten). However, claims arising from a breach of a condition which goes to the root of the contract shall be limited to the foreseeable damage which is intrinsic to the contract, unless caused by intent or gross negligence or based on mandatory liability for injury of life, body or health. The above provisions does not imply a change in the burden of proof to your detriment. The application examples do not purport to cover all details or variations in equipment, nor do they provide for every possible contingency. They are not customer-specific solutions. They are only intended to provide support for typical tasks. You are responsible in ensuring that the described products are correctly used. These Application Examples do not relieve you of the responsibility in safely and professionally using, installing, operating and servicing equipment. When using these Application Examples, you recognize that Siemens cannot be made liable for any damage/claims beyond the liability clause described above. We reserve the right to make changes to these Application Examples at any time without prior notice. If there are any deviations between the recommendations provided in this application example and other Siemens publications e.g. Catalogs the contents of the other documents have priority. Copyright 2005 Siemens A&D. It is not permissible to transfer or copy these Application Examples or excerpts of them without first having prior authorization from Siemens A&D in writing. For questions about this document please use the following e-mail-address: mailto:csweb@ad.siemens.de
Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e
V1.0
19.04.05
2/95
Foreword
Entry-ID: 21447513
Foreword
Objectives of the application Recording of data is an important prerequisite for saving costs during production. The energy consumption within a production process, for example, can be recorded and evaluated over an extended period of time in order to optimize the processes. OPC provides standardized interfaces for this which enable connecting Windows applications to programmable logic controllers (PLC). The application on hand illustrates a possible procedure for generating individual OPC Clients in C#, suitable for mass data recording in the automation world. In this application, a simple heating circuit is simulated with a SIMATIC S7 controller. The simulated physical parameters are cyclically sent to the OPC client as a data package, and saved to a data base by the client.
Main contents of this application The following main points are discussed in this application: Creating and application of an OPC client, which saves data of a SIMATIC S7 to a data base via ADO.NET. Three possibilities of saving data are illustrated: Saving to a Microsoft Access data base Saving to a Microsoft SQL Server data base Saving to an XML-file
Demonstration of handling COM components in .NET, especially the OPC server: Procedure for connecting to the OPC server Memory management when using COM components
Demonstration of the most important OPC DA 2.05 methods for reading SIMATIC process variables: Synchronous writing and reading Asynchronous writing Operator control and monitoring
Display of suitable software design for OPC clients Delimitation In order to delimit the scope of this application it does not contain a complete description of the .NET framework,
V1.0
19.04.05
3/95
Foreword
Entry-ID: 21447513
of C#, of ADO.NET, of Multithreading, of the OPC specification as well as deeper level COM mechanisms Therefore, basic knowledge in the area of object oriented programming, as well as in the COM field, is assumed. Further knowledge in UML (Unified Modelling Language) is an advantage. Structure of the document The documentation of this application is divided into the following main parts.
Part Application Description
Description Provides a general overview of the contents. You will learn about the components used (standard hardware and software components and the specially created software). Discusses the detailed function processes of the involved hardware and software components, the solution structures, and where sensible the concrete implementation of this application. This part is necessary if you want to learn about the interaction of the solution components, for example in order to use them as the basis for own development. This part leads you step by step through the structure, important configuration steps, commissioning and operation of the application. Here you find further information such as e.g. literature, glossary etc.
Function Principles and Program Structures
Structure, Configuration and Operation of the Application Appendix
Reference for Automation and Drives Service & Support This entry originates from the internet application portal of the A&D Service and Support. The following link takes you directly to the download page of this document. http://support.automation.siemens.com/WW/view/en/21447513
V1.0
19.04.05
4/95
Foreword
Entry-ID: 21447513
Table of Contents
Table of Contents ......................................................................................................... 5 Application Description ............................................................................................... 7 1 1.1 1.2 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Automation Task............................................................................................. 7 Overview........................................................................................................... 7 Requirements ................................................................................................... 8 Automation Solution ...................................................................................... 9 Overview of overall solution.............................................................................. 9 Software components involved....................................................................... 10 Description of the core functionality................................................................ 11 Required hardware and software components ............................................... 14 Basic Performance Data................................................................................. 16 Alternative solutions........................................................................................ 18 Prospects........................................................................................................ 20
Function Principles and Program Structures .......................................................... 22 3 3.1 3.2 3.3 3.4 3.5 3.5.1 3.5.2 3.5.3 3.6 3.6.1 3.6.2 4 4.1 4.1.1 4.1.2 4.1.3 4.2 4.2.1 4.2.2 4.2.3 4.3 4.4 General Function Mechanisms.................................................................... 22 Principal application model of the OPC DA application .................................. 22 Differences between synchronous and asynchronous read and write jobs .... 25 Dividing OPC items into OPC groups ............................................................. 29 Identifying OPC items created in an OPC client ............................................. 30 Function mechanisms of .NET and inclusion of components of the previous programming world .................................................................................... 32 Programming model of the old world .............................................................. 32 Programming model of the new world ............................................................ 33 Integration of COM components in .NET applications .................................... 35 Mechanisms of ADO.NET............................................................................... 37 Application model ADO (COM) ....................................................................... 37 Application model ADO.NET .......................................................................... 38 Function Mechanisms of this Application.................................................. 40 Logic data interface between controller and OPC client................................. 40 Connecting the process variables with visualization elements ....................... 41 Selected depiction of the process variables to be visualized.......................... 43 Data structure of the telegram ........................................................................ 46 Structure of the OPC Client ............................................................................ 48 Class diagram of the OPC Client.................................................................... 48 PersistentData class ....................................................................................... 49 DBConnector class ......................................................................................... 50 Establishing the connection to the OPC server and creating the OPC items . 53 Problem circles in generating OPC clients and solutions in this application... 55
V1.0
19.04.05
5/95
Foreword
Entry-ID: 21447513
4.4.1 4.4.2 4.4.3 4.4.4 5 6 6.1 6.2 6.3 7
Simple usage of the OPC RCW...................................................................... 55 Identification of OPC items via the respective handles................................... 56 Allocating the value of an OPC item to user-defined objects.......................... 62 Dealing with OPC server events with long processing runtime ...................... 63 Data Flow Model of this Application ........................................................... 66 Explanations on the Example Program ...................................................... 68 Installation of the OPC-DA-RCW interfaces ................................................... 68 Sequence diagrams of the OPC Client........................................................... 70 Releasing the references to the OPC server .................................................. 72 Modifications to the Example Program ...................................................... 75
Structure, Configuration and Operation of the Application ................................... 78 8 8.1 8.2 8.2.1 8.2.2 8.2.3 8.2.4 8.2.5 9 9.1 9.1.1 9.1.2 9.1.3 10 10.1 10.2 Installation and Commissioning ................................................................. 78 Installation of the hardware............................................................................. 78 Installation of the software .............................................................................. 79 Installation of STEP 7 and SIMATIC NET ...................................................... 79 Set PG/PC interface ....................................................................................... 79 Installation of the STEP7 project .................................................................... 81 Importing the XDB file to the station manager ................................................ 82 Installation of the user interface...................................................................... 84 Configuration ................................................................................................ 85 Configurations of the application .................................................................... 85 Configuring the OPC server in HWConfig ...................................................... 85 Configuring the OPC server in NetPro............................................................ 88 Check the settings .......................................................................................... 89 Operating the Application............................................................................ 91 Commissioning of the simulation .................................................................... 91 Show / delete data records stored in the data base ....................................... 92
Appendix and List of Further Literature ................................................................... 94 11 12 12.1 12.2 Glossary ........................................................................................................ 94 Literature ....................................................................................................... 95 List of further literature.................................................................................... 95 Internet links ................................................................................................... 95
V1.0
19.04.05
6/95
Application Description Automation Task

Mass Data Acquisition with OPC Entry-ID: 21447513
Application Description
Content This provides an overview of mass data recording using an OPC client. You will learn about the components used (standard hardware and software components and the specially created software). The basic performance data show how powerful this application is.
Automation Task
the automation task discussed in the documentation on hand.
Here you will find information on
1.0
Overview
Overview of the automation task The following figure gives an overview of the automation task.
Figure 30-1
Description of the Automation Task Using the example of a simulated heating circuit, large data packages are cyclically sent to an OPC client. It saves the received data to a data base.
V1.0
19.04.05
7/95
Application Description Automation Task

2.0
Requirements
Requirements for data transmission Data transmission must be a controlled and acknowledged process: Implementing a simple acknowledgement protocol (handshake) The controller only sends if no acknowledgement is expected
During transmission of a telegram, the controller buffers the recorded data Process data are transferred via the standardized OPC-DA interface: Transmission of process data to the SIMATIC NET OPC Server V6.2. via Industrial Ethernet Using the OPC-DataAccess Custom interfaces V2.05 Application of the SIMATIC NET block services (BSEND/BRECV) for telegram transmission Using SIMATIC NET variable services for controlling and visualizing the simulation Asynchronous writing of process data Implementing a structure for error handling on the client side.
Requirements for the client The OPC client not blocking during saving data to the data base; it can continue visualizing data of the controller. Connecting the data base with ADO.NET: Microsoft Access supported Microsoft SQL Server supported XML-file as data memory supported
Requirements for the development environment Universal usage of the realized class model must be possible. The latest Windows development environment must be used: Using Microsofts .NET technology Using the .NET programming language C#
V1.0
19.04.05
8/95
Application Description Automation Solution

Automation Solution
the solution selected for the automation task.
1.0
Overview of overall solution
Layout diagram The following figure displays the involved hardware components:
Figure 30-1
PG/PC A PG/PC is connected to an S7-400 controller via hub. Thereby a standard Ethernet network card, already integrated in a SIMATIC Power PG, is used. Controller On the controlling side, there is a SIMATIC S7-400 station with the CP 443-1 IT as well as a CPU 414-2DP.
V1.0
19.04.05
9/95

2.0
Software components involved

The following figure shows the involved software components:
Figure 2-2
PC/PG For visualizing, the PG/PC contains an OPC client realized with .NET. For connecting to the process , the OPC client uses the OPC Runtime Callable Wrapper (abbrev.: RCW) of the SIMATIC NET OPC-Servers V6.2. The SIMATIC NET OPC server establishes the connection to the controller via the SIMATIC NET IE SOFTNET-S7. The connection with the data base is realized with ADO.NET. Controller The controller provides the data to be saved. A program for simulating a heating circuit has been implemented for this. Created software components OPC client (developed with C#) S7 program for simulation
V1.0
19.04.05
10/95

3.0
Description of the core functionality
Overview of the user interface The application consists of a visualization user-interface with three sections:
Figure 2-3
Description of user interface

Table 2-1
Section Control / Status of the Simulation Display of first Data Record Statistics of Data Transmission
Description Controlling the simulation via Start/Stop button Display of buffer status Display of first data record of currently sent telegram OB35 frequency: Configured call frequency for OB35 This corresponds to the frequency of filling an entry into the buffer Data record size: This corresponds to the size of a measured data record Telegram size: This is the size of the sent telegram Average data throughput: This corresponds to the data throughput per second. It is a calculated value. Time for converting / saving data: Displays times for converting, analyzing and saving a telegram to the data base. These times are measured in the PC. Total / average send time: This time corresponds to the time from sending the telegram in the controller until arriving of the acknowledge signal. This time is measured in the controller.
V1.0
19.04.05
11/95

General process sequence of main functionality The following layout diagram shows the process for saving a data packages:
Figure 2-4
Explanation
Table 2-2
No. 1 2 3 4 5 6
Instructions Controller sends a data package to the PC. The OPC server receives the data package. The OPC server signals the OPC client that it has received a data package. The OPC client extracts and analyzes the telegram. The OPC client saves the net data into the selected data base. The OPC client calculates the statistics and updates the visualization.
Note The service S7 communication with the user interface BSEND is used for this. The OPC server has received a receive buffer for receiving the data package. Signaling occurs via the OnDataChange mechanism.
V1.0
19.04.05
12/95

No. 7
Instructions
Note
The OPC client signals to the controller, The handshake signal is realized with writing that the data has been saved to the data an OPC item. base. The handshake signal is written to the controller via the OPC server. The OPC client is now ready for a new data package.
Advantages of this solution The solution realized in this application has the following advantages: Creating mass data recording programs which can be adjusted to the individual requirements Avoiding cost-intensive program packages which are over-sized for a specific customer solution Largely independent of controller type, using the open OPC standards Any data base systems can be used An almost unlimited number of auxiliary programs can be integrated (e.g. Microsoft Excel)
V1.0
19.04.05
13/95

4.0
Required hardware and software components
Hardware components (SIMATIC S7)

Table 2-3
Component PS407 10A CPU 414-2DP CP 443-1 Standard hub 1 1 1 1
No.
MLFB / Order number 6ES7407-0KA01-0AA0 6ES7414-2XG04-0AB0 6GK7443-1EX11-0XE0 Depending on product
Note
Hardware components (PC)

Table 2-4
Component
No. 1 1
MLFB / Order number 6ES7711-2EA21-3LB4 Depending on product
Note Integrated in Field PG
SIMATIC Field PG Ethernet network card
Standard software components

Table 2-5
Component STEP 7 Professional Edition 2004 (incl. STEP 7 V5.3 and S7-SCL V5.3) SIMATIC NET IE SOFTNET-S7 V6.2 SP1 with: OPC-RC-Wrapper OPC-Server Microsoft Visual Studio .NET 2003 mit .NETFramework V1.1 or higher .NET Framework V1.1
No. 1
MLFB / Order number 6ES7810-5CC08-0YA5
Note Already contained in above SIMATIC Field PG. OPC-RCWrappper and OPC-Server are included free of charge Required for adaptations Required for comissioning ADO.NET is part of the .NET Framework
6GK1704-1CW62-3AA0
Depending on product
Free download at http://www.microsoft.co m/
V1.0
19.04.05
14/95

Example files and projects The following list contains all files and projects used in this example.
Table 2-6
Component 21447513_OPC_Massendaten_STEP7_v10_d.zip: STEP 7-Projekt 21447513_OPC_Massendaten_CODE_v10_d.zip: Setup program
Note The file contains the S7 simulation program as archived STEP 7 project User interface (without .NET-Framework) and source code files of the user interface This document
21447513_OPC_Massendaten_DOKU_v10_d.pdf: Documentation
V1.0
19.04.05
15/95

5.0
Basic Performance Data

This application document discusses three options for saving data: Microsoft Access Microsoft SQL Server XML file
Implications of the ADO.NET interface Using the ADO.NET interface makes accessing the different data bases nearly identical. The main difference between ADO.NET and ADO is that the relevant tables can be kept transient in the memory. Hence only a loose connection with the actual data memory (hard disk) is propagated. This should clearly increase the performance.
Nevertheless, no considerable increase in performance regarding existing ADO applications (see preceding application: http://support.automation.siemens.com/WW/view/de/7399373) was noticed for the data throughputs (up to 25 Kb/sec) measured in this application. The largest performance difference were caused by the different data bases. Test system All measured values were measured on a SIMATIC Field PG with the following data: PIII 1GHz 512MB RAM 100MBit/s network card The data base is located on the same system as the data recording program (OPC client) Frame conditions The system was operated continuously for approx. 15 hours without additional processor load. Approx. 5 kByte were sent per telegram A telegram was sent about every 2 seconds. The maximum number was 1000 data records for the Heater table and 8000 data records for the Measure table. (The number of data records in a table must be restricted as the method of saving data to an SML file, used in this application, always writes all data of a table into an XML file. Otherwise the time limit of the above 2 seconds for saving the data can not be met.)
V1.0
19.04.05
16/95

Performance data
Table 2-7: Data package size: ~5KByte
Criterion Overall telegram transmission time (*) Time for saving to data base Total time for a data package (**) Average data throughput
MS Access 200-250ms 750-950ms ~ 1sec
MS SQL Server 200-250ms 150-220ms ~ 350ms
XML(***) 200-250ms 50-1500ms ~200-1800ms
~ 5kByte/sec
~ 15kByte/sec
2.5 25kByte/sec
(*) The Overall telegram transmission time is the time for sending approx. 5kB with BSEND to the PC; this value is calculated from: Overall send time Time for converting Time for saving to DB (**) The Total time for a data package corresponds to the total of Overall telegram transmission time and Time for saving to data base. It was measured in the controller. The time difference between Sending the data and Detecting the handshake signal was calculated. (***) For the test case with XML the maximum number of data records had to be limited. The values therefore depend on the overall number of measured data already recorded at the time of measurement.
Note
The values are calculated by the application and displayed in the Statistics field (see chapter 3.0).
Interpretation of the test data It is noticeable that using an MS Access data base takes approximately 3.5 to 4 times as long as with an MS SQL Server data base for saving a complete data package to the data base. The Overall telegram transmission time for 5 kB with the test system allows for a maximum data throughput of approx. 25kB/sec. This would not include any saving of data. From a certain number of data records on, saving with XML should not be performed with the method provided by ADO.NET (more specifically: with the DataAdapter object), because this method does not only write the changed data records, but all data records to an XML file. For saving data in XML, a separate class construct should be implemented, allowing to write only the changed data records to an existing XML file. However, writing few data records to an XML file is, with regards to data throughput only, superior to every data base. This way, the maximal possible data throughput is reached with the test system ( see Table 2-7).
V1.0
19.04.05
17/95

When using the XML file it must also considered, that for large telegrams (>10kB) a partially considerable processor load is to be expected. This can become a problem when several programs are to run on the PC simultaneously. When using the SQL server, this problem will not occur due to the performant saving of large data volumes. Even so: the larger the telegram (equal data volume), the better the maximum possible data transmission time (25kB/sec) is reached.
6.0
Alternative solutions
Solution alternatives to the here introduced solution are discussed, evaluated and compared (advantages, disadvantages, ...).
Using product data collection (PDC) systems Individual systems as well as additional packages for existing visualization tools, such as SIMATIC WinBDE exist in the field of product data collection systems. The following advantages and disadvantages result:
Table 2-8
Advantages The PDC system can be parameterized Extensive evaluation of data possible such as KPIs (key performance indicators)
Disadvantages Partly, extensive and expensive software packages are required Integration into the MS-Office world not possible without difficulties
Custom interface vs. Automation interface Due to the data structures defined in the OPC specification, the OPC interface has been implemented as custom interface. In order to also be able to use OPC with programming languages not enabling Custom interface connection (VBA, VB V6.0 or older), an automation interface was implemented which depicts the more complex structures onto simpler structures. Due to the additional management required ( additional wrapper, see Glossary) a disadvantage regarding performance must be taken into account.
Note
For high-performance requirements in particular, work should exclusively be performed with the Custom interface, which in return excludes using VB 6.0 or VBA.
V1.0
19.04.05
18/95

Decision criteria for using different programming languages Due to the standardization, OPC can be used with any COM-capable programming language ( Glossary). The following table shows you the most important decision criteria which are decisive for selecting the used programming language.
Table 2-9
Criterion Custom interface Automation interface Simple implementation Error handling

Description Is it possible to use the custom interface of the OPC DA interface ? Is it possible to use the automation interface of the OPC DA interface ? How much is the language suitable for relatively simply implementing code ? How well is the language suitable for realizing professional error handling ? How well is the language suitable for developing performant OPC applications ?
Performance
Comparing different programming languages The following table compares the different programming languages using the above described criteria.
Table 2-10
Criterion Custom interface Automation interface Simple implementation Error handling Performance
VBA (MSOffice) -
VB V6.0 -
VC++
.NET-languages (managed) (with RCW) (*) (with RCW) + (**) ++ (**) + (**)
(*) ++ ++ - (**) + (**) ++ (**)
(*) should not be used (**) using the custom interface
V1.0
19.04.05
19/95

OPC under .NET and C++

Table 2-11
Criterion Implementation
Description Implementation of OPC clients in .NET hardly differs from the implementation in C++, as the COM mechanisms must still be followed. However, the implementation of a user interface with .NET is clearly faster than comparable implementation with C++. The most striking difference between .NET and C++ is probably the error handling. Instead of polling HRESULT as usual, i.e.COM returned values ( glossary), an exception handling ( Glossary) is realized. This has the following advantages: No error will be overlooked Reading code more simple Uniform error handling within the OPC client Possible introduction of error hierarchies by means of implementing some Exception classes Current measurements yielded that the performance differences in OPC matters are hardly worth mentioning. The behavior of the user interface is a different matter - here .NET is rather comparable with VB V6.0. Generally, however, the bottleneck will not be the update rate of the user interface, but the connection to the OPC server or the connection between OPC server and controller. Therefore, for OPC applications, .NET can be considered equal to VC++ V6.0.
Error handling
Code performance
7.0
Prospects
Microsoft is currently enforcing performance improvements of .NET applications. Performance boosts in this field are to be expected over the following months. In order to reduce the concrete implementation work during using OPC with .NET, the OPC foundation ( http://www.opcfoundation.org/) is currently working on simplifying the interfaces. Hereby, for example, new RCWs are implemented which make better use of the .NET possibilities. It can be assumed, that in the future the OPC interfaces for .NET will be as easy to handle as in Visual Basic V6.0. The new version of .NET-Framework comes with a new version of ADO.NET (V2.0), which will be compatible with the currently available version. ADO.NET applications developed with V1.1. are hence also functionable with Framework V2.0.
V1.0
19.04.05
20/95

Furthermore, asynchronous data access with ADO.NET V2.0 will be supported. The performance of data base updates is to be further improved by the option of using batch updates. It will also be possible to save data not only as SML file, but also as binary file.
Note
The RCW currently provided by the OPC Foundation has not been tested by Siemens AG with regard to the SIMATIC NET OPC Server V6.2 SP1.
V1.0
19.04.05
21/95
Function Principles and Program Structures General Function Mechanisms

Function Principles and Program Structures

Content Discusses the detailed function processes of the involved hardware and software components, the solution structures, and where sensible the concrete implementation of this application. Read this part if you want to know how the individual solution components interact.
General Function Mechanisms

the function mechanisms applying regarding OPC and which require particular consideration with .NET.
1.0
Principal application model of the OPC DA application

The application model of the OPC DA interface is briefly discussed now. A detailed description of the object model is available in the OPC DA specification \1\.
V1.0
19.04.05
22/95

Overview
Figure 8-1
OPC client By generating references in the client to the respective interfaces, the OPC server is informed of client access to a certain variable of the configured controller being desired. Further interfaces available via the IOPCGroupStateMgt Group(s) interface enable read and write access to these variables. The following access methods are possible: Synchronous reading / writing Asynchronous reading / writing Monitoring variables (reporting value changes)
V1.0
19.04.05
23/95

Note
Single threaded OPC clients are blocked at synchronous read / write jobs. For asynchronous read / write jobs, the OPC client remains operable (responsive). For further information see chapter 2.0.
OPC server The OPC server is the central communication unit between an OPC client and the respective controller. Via COM/DCOM mechanisms, it provides interfaces standardized towards the OPC client which allow each COM capable application to access variables of any controller. In this application the DataAccess interfaces for generating the logic connections between OPC items and process variables are decisive.
The OPC server is connected to the respective controller via the implementation of the communication protocols. Connection between OPC server and controller The values of the variables are read out via the connections configured in the OPC server using the respective protocol blocks. These connections are configured using the NetPro tool (see chapt. 2.0.0). It must be noted, that the protocol blocks are not standardized interfaces, but proprietary protocols implemented for the respective underlying controller. Reading variables from the controller Reading and updating the variables can be performed in two ways:
Table 3-1
Service Variable service
Description For variable services, one or several process variables are specified by means of absolute or symbolic addressing. Thereby, the variables to be monitored can be polled cyclically from the OPC server ( Polling, see Glossary). If the variables to be monitored are transferred to the OPC server program controlled by means of larger data blocks, then this is referred to as block service. Thereby, not the process variables themselves are addressed, but rather the data areas such as a data block. A cyclic "monitoring" of the receive buffer by the OPC server only makes sense here for receive items (e.g. "receive").
Block service
V1.0
19.04.05
24/95

Notes on the services In this application, only variable services are used. The absolute addressing only differs from the symbolic addressing by the ITEM_ID. The variable and block services are on the OPC client side only differentiated by its ITEM_ID. Here, block services only refers to the services (SEND/RECEIVE, BSEND/BRECEIVE) provided by the SIMATIC NET OPC Server V6.2.
2.0
Differences between synchronous and asynchronous read and write jobs

The differences between synchronous and asynchronous reading and writing of OPC items is discussed below. Hereby, differences between accesses to the DEVICE and the CACHE are explained in detail.
Function principle of synchronous / asynchronous read and write jobs The following image gives you an overview of the function principles of the respective calls:
Figure 3-2
V1.0
19.04.05
25/95

Explanations on the figure The figure shows the call direction (read arrows) and the resulting data flow (blue arrows). Data is exchanged between the OPC server and the controller using an Industrial Ethernet card and a CP343-1. Data exchange between OPC client and OPC server occurs as interprocess communication (here: COM). "CACHE" refers to a temporary buffer which the OPC server generates for a particular group. It contains a local image of the process variables defined for this group (which in return are managed by the group as OPC items). "DEVICE" refers to the process variables on the controller. Explanation of the processes
The following table explains the respective calls and data flows. Thereby, the following consequences are pointed out:
Table 3-2
No. 1 2
Instructions
Note
Synchronous read job on The value of the OPC item is read with the value currently the CACHE located in the CACHE. Updating the CACHE The OPC server updates the entire CACHE with the values from the DEVICE after the time period defined with requestedUpdateRate. Note: The requestedUpdateRate need not correspond to the actual update rate. Please note the update rate returned by the OPC server (revisedUpdateRate)!
OnDataChange-Event
For OPC items parameterized as "active", the OPC server has registered a data change within its CACHE. This is reported to the OPC client. Note: This mechanism is ideal for monitoring the process variables. The update rate corresponds to the actual "updateRate".
V1.0
19.04.05
26/95

Asynchronous read job to the DEVICE
The OPC client starts an asynchronous read job via the OPC group. The OPC server reads the requested process variables from the process image of the S7-CPU and delivers to the OPC client via the OnReadComplete event. it then writes the read values to its CACHE Note: The OPC client continues being operable for asynchronous calls while the respective job is processed (responsive).
Synchronous read job to the DEVICE
The value of the OPC item is read with the value currently located in the process image of the S7-CPU. Note: This access may take several seconds depending on physics, data traffic and data volume. During this time, the thread of the OPC client, which starts the synchronous read call, cannot perform any other tasks! Single threaded OPC clients are hence blocked during this time and cannot execute further operating and monitoring tasks.
Synchronous or asynchronous write job
Write jobs are only executed to the DEVICE, irrespective of whether they are synchronous or asynchronous. Note: This access may take several seconds depending on physics and data volume. If a synchronous write job has been cancelled, the same behavior as described in point 5 takes place; for an asynchronous call the OPC client behaves as described in point 4.
Access to CACHE and DEVICE The following table summarizes the operations possible to "DEVICE" and "CACHE"
Table 3-3
Operation Synchronous reading
DEVICE
CACHE
Note Reading from the CACHE requires the group and the respective item to be active.
Asynchronous reading
The OPV server reads the variable from the DEVICE. This also updates its CACHE. Write jobs are always written to the DEVICE.
Synchronous writing
V1.0
19.04.05
27/95

Asynchronous writing Monitoring (event controlled) -
Write jobs are always written to the DEVICE. Monitoring of variables is only possible using the CACHE.
Note
Apart from read and write jobs, further methods are also available (such as IOPCAsyncIO2::Refresh) which, however, were not used in this application. For further information see OPC Specification \1\.
Comparison of application cases The following table contains a comparisons of different application cases and shows the recommended procedure:
Table 3-4
Operati on
Cyclic/ Acyclic Cyclic monitoring
Data quantity Large Small Large Small Large Small
DataChangemechanism + + -
Sync * * + +
Async * * + + -
Read Acyclic Write Acyclic
(*) The OnDataChange mechanism is executed asynchronous to the CACHE
Note
Large data volumes in the range of several kilo-bytes were to be read or written with the block services, e.g. BSEND/BRCV. Hereby the SIMATIC works as active communication partner.
V1.0
19.04.05
28/95

3.0
Dividing OPC items into OPC groups

Here you learn about the criteria to be taken into consideration when dividing the OPC items to OPC groups.
Motivation of dividing OPC items As explained in chapter 2.0, certain ways of behavior result from certain call types. Now it makes sense combining process variables or OPC items with a similar operating or monitoring behavior into groups. In some cases, however, it is desirable that a process variable is to be monitored at two different locations of the OPC client (such as for example in two different pages or dialogs). Another example for this is a process variable being monitored at one location, however only being sporadically (i.e. acyclically) read at an other location.
In these cases it makes sense creating the same process variable in several groups as OPC item. Dividing process variables to OPC items and OPC groups The following figure illustrates this option with two different groups. Process variable 1 is mapped to two OPC items, which belong to two groups. This enables generating different ways of behavior for a process variable in an OPC client.
Figure 3-3
V1.0
19.04.05
29/95

4.0
Identifying OPC items created in an OPC client

In order for the process variables mapped to OPC items being read or written by an OPC client, a definite assignment of OPC items to an OPC client must exist. The concept of identifiers or handles is used here.
Handle types Two handle types are distinguished. This differentiation ensures that the OPC client as well as the OPC server can identify the respective OPC items.
Table 3-5
Type Clienthandles
Description This handle servers for identification of an OPC item within the OPC client. This handle servers for identification of an OPC item within the OPC server.
Serverhandles
Serverhandles If the call direction is from OPC client to OPC server, the OPC client must transfer the respective server handles to the OPC server. Example: write into the OPC items
Figure 3-4
V1.0
19.04.05
30/95

Clienthandles If the call direction is from OPC server to OPC client, the OPC client will receive the respective client handles from the OPC server. Example: The OPC items in the CACHE have changed OnDataChange event is triggered
Figure 3-5
the
Effects on the Client program This structure implies that an OPC client must manage the server and/or client handles depending on the application case. This way, the client handles may, for example, serve as an index of the respective OPC item in an OPC item array. The server handles should either be encapsulated in a separate server handle array or in an own OPC item management class.
V1.0
19.04.05
31/95

5.0
Function mechanisms of .NET and inclusion of components of the previous programming world
The previous as well as the latest Windows programming world will be discussed first now. Then the differences to be noted are explained. It is only a brief introduction helpful for understanding the "how to program with .NET" as well as "how to combine the new and the old world?". Further information is available in the secondary literature \2\. 1.0.0 Overview
Figure 3-6
Programming model of the old world
API The previous programming model of the Windows world builds on an Application Programmers Interface (API). The API provides a lot of Cfunctionalities for accessing the operating system resources and functionalities. Programming languages and libraries Using various programming languages with partially extensive libraries (VBRuntime, Microsoft Foundation Classes, Active Template Library) it was possible to implement Windows programs. Hereby the libraries respectively encapsulated a part of the API functions.
V1.0
19.04.05
32/95

Interacting of the languages with COM In order for the developed program components to be able to work with each other, Component Object Model (COM) by Microsoft was introduced. Using standardized interface definitions enabled establishing a "connecting glue" between the individual components. The concept of Distributed Component Object Model (DCOM) was developed in order to expand the cross-language and cross-component interaction to a cross-computer interaction.
Note
The OPC server works as COM component. OPC clients access the OPC server via COM mechanisms.
2.0.0 Overview
Programming model of the new world
Figure 3-7
API The basis of the model is Win32 API like in the previous Microsoft programming world. CLR Based on API follows the Common Language Runtime (CLR). It constitutes a runtime environment comparable with a Java Virtual Machine model. It compiles Just In Time (JIT) a type of byte code in X86 code
V1.0
19.04.05
33/95

(depending on the respective processor architecture); Microsoft speaks of IL code (Intermediate Language). Intermediate Language, Garbage Collector and unmanaged Code The advantage of the IL code is the fact that it is independent of the platform. It is also possible to execute this code on Linux (Unix) systems, if a CLR has been implemented there (i.e. http://www.mono-project.com/). The CLR does not only perform the JIT compiling of the IL code, but also the entire memory management. Similar to Java, a Garbage Collector (GC) was developed, who releases un-referenced memory areas within the CLR after an unspecified time. Code subjected to the access of the Garbage Collector is also referred to as managed Code. In order for it to be possible in certain cases to still control the release of memory areas manually, the developed code can be declared as "unmanaged". This enables protecting certain code areas or entire programs explicitly from the access of the Garbage Collector.
Base Classes Regarding the libraries of partly varying extend of the old world, Microsoft has now implemented a uniform base class library which can be accessed independently from the .NET programming language. Integrator Visual Studio .NET Visual Studio .NET (VS .NET) takes on the task of combining the different .NET languages with each other. This enables realizing .NET components in different languages. Interaction between the .NET components is possible with Visual Studio .NET without greater efforts. Mainly the easy to handle integration options within the .NET components enable a faster development.
V1.0
19.04.05
34/95

3.0.0 Overview
Integration of COM components in .NET applications
Using a COM component in a .NET application/component:

Figure 3-8
Runtime Callable Wrapper (RCW) and the relationship with the COM component Installing a COM component generated for the previous Windows world within a .Net application, requires a "wrapper", a type of mask which encapsulates all interface definitions for the .NET application. This is necessary as the previous interface definitions located in so-called IDL files (Interface Definition Language, see Glossary) are not supported by .NET. This wrapper is also referred to as Runtime Callable Wrapper (RCW). For COM components offering the automation interface, Visual Studio can generate these wrappers automatically. For COM component providing the custom interface, such wrappers must be generated manually.
Note
The differences between automation and custom interface are not discussed here in greater detail. This requires secondary literature \2\.
V1.0
19.04.05
35/95

Memory management when using COM components Memory management for .NET applications is performed by the Garbage Collector, however, COM components require an explicit memory management. Therefore, the following points must be considered for data exchange between both components:
Table 3-6
Direction .NET zu COM
Description In .NET, all variables are objects. Due to the fact that generally speaking, COM servers do not synchronize with COM clients, transfer values should be protected from the access of the Garbage Collector ("pinning" of objects). COM components deliver return values in form of COM pointers. Due to the fact that in the managed code of .NET clients such pointers do not exist, the returned values must first be saved into .NET objects. This is performed via the .NET data type "IntPtr" and methods / objects of the "System.Marshal" classes.
COM to .NET
Note
The required code is commented and contained in the respective source code files.
RCW and OPC Due to the OPC specification, OPC components offer a Custom interface, i.e. an RCW must be generated manually for performant applications. An RCW is delivered for the SIMATIC NET OPC server for the DataAccess interface V2.05, which must only be integrated into the respective Visual Studio project (further details available in chapter 1.0). If the automation interface of OPC is used with .NET, then the RCW is automatically generated by VS .NET as soon as a reference to the OPC automation interface is included into the .NET project. The resulting double encapsulation of the OPC custom interface however, may cause a reduction in performance.
Note
This application deals with the usage of the custom interface, as a performant connection is the focus of this application.
Note
The reverse application case using a .NET component as COM component is possible using a Com Callable Wrapper (CCW) This however, is not further discussed within the framework of this document, as it is not necessary for comprehension of this application.
V1.0
19.04.05
36/95

6.0
Mechanisms of ADO.NET
1.0.0 Overview
Application model ADO (COM)
Figure 3-9
Explanation
Table 3-7
No.
Object / Action
Note It is often necessary to permanently keep a Connection open. However, the number of Connections with a data base is restricted. This may cause problems, if several clients are connected with the data base. This guarantees a precise imaging of data in a data base. However, this does not enable modeling the relationships of the tables.
1 Connection establishes a connection with the data base.
A RecordSet keeps a tight connection with the data base.
10
Using the cursor, a specific data record can be accessed in the data record. A tight connection enables simple reading and modification of new data records.
11
V1.0
19.04.05
37/95

2.0.0 Overview
Application model ADO.NET
Figure 3-10
Explanation
Table 3-8
No.
Object / Action
Note Connections are only opened when required. Connection pools are created as soon as Open is called. A Close call does not delete the connection from the Connection pool
1 Connection establishes a connection with the data base.
12
Command objects mainly execute SQL statements at the data base.
V1.0
19.04.05
38/95

No. 13
Object / Action DataReader enables performant reading of a forward directed data stream from the data base.
Note DataReader can only be used for reading data from the data base. The DataAdapter corresponds with a DataSet or a DataTable. In order to execute an UpdateCommand with a DataAdapter, it must only contain one DataTable.
14
DataAdapter provides an interface to a DataSet (5) using the respective command.
15
A DataSet contains the data of the data base.
The DataSet represents the data base structure and its data in the memory of the PC. This enables a transient saving of selected data of the data base. Transfer of database datavia XML and WebServices is possible without greater problems. The DataSet object can also be used for generating or modifying relationships between DataTables. An adaptation of the data model in the transient memory is hence possible.
Note
The following points must be noted in the application model of ADO.NET: The data volume contained in the memory must be considered. If a client saves data to the data base, the other client does not necessarily notice this (due to the transient data management) Changes at the data base structure must be adjusted in the DataSet The DataSet should be resynchronized during the update in order for the data of the data base to correspond with the data in DataSet. This can be initiated with a simple parameter specification. Further information is available in the secondary literature \2\.
V1.0
19.04.05
39/95
Function Principles and Program Structures Function Mechanisms of this Application

Function Mechanisms of this Application

how the classes in the OPC client interact with each other and which tasks the most important components fulfill. The implementation of the simulation on the controller side is not discussed here in greater detail, as this is not the core focus of this application.
This chapter explains ...
Structure of the chapter First the logic data connection between controller and OPC client is illustrated. Hereby, the corresponding data structures in controller and OPC client are listed. Subsequently, the relationships within the OPC client are depicted with a class diagram, and problem circles during implementation of OPC clients are explained as well as possible solutions discussed.
1.0
Logic data interface between controller and OPC client
This chapter first deals with which process variables are connected with which visualization elements. Subsequently, the communication sequence is explained.
V1.0
19.04.05
40/95

1.0.0
Connecting the process variables with visualization elements The following table shows the allocations:
Table 15-1
Process variables Filling the alternating buffer Start/Stop: Control / Status of the Simulation
Visualization element
Display, whether Send is active (DB15):
Display of buffer status (DB25 and DB26):
Display of telegram head (DB15):
Display the data
Display of 1st header data (DB15):
Display of 1st measured data (DB15):

Note All measured data are always stored in the data base.
V1.0
19.04.05
41/95

Process variables Statistics from the controller
Visualization element
Note
All other statistics values are calculated or measured in the OPC client.
The following chapter discusses the mapping of process variables to groups and OPC items.
V1.0
19.04.05
42/95

2.0.0
Selected depiction of the process variables to be visualized As already explained in chapter 1.0, the process variables are mapped to OPC items, which in return are allocated to OPC groups.
Overview The following overview shows the overall correlations.

Figure 4-1
The areas referred to are explained below:
V1.0
19.04.05
43/95

1. Assigning the process variables to OPC groups The process variables to be visualized are here divided into 4 sections (see chapter 1.0.0). The update rate hereby serves as the structuring criterion and whether it is a block or a variable service:
Table 4-2
Group BRCV
Characteristics of variables Variable for receiving the data telegram Variables changing quickly and frequently
Updata rate High
To be monitored Yes*
OPC access method OnDataChange
Application in the OPC client Storage to data base Display in text fields Display in text fields Display in text fields
FastVisualization
High
Yes
Sync OnDataCha nge Sync OnDataCha nge
SlowVisu- Variables changing alization slowly or not at all
Low
Yes
*) The BRCVitem should always be monitored !
2. Assigning the process variables to OPC items The respective process variables are now assigned to each group.
Table 4-3
Group BRCV
Process variable This is not a process variable, but a receive buffer reserved in the OPC server by creating the OPC item. If this buffer is filled, this is reported by the OPC server via an OnDataChange event (see \2\). Status of the Send Bit (indicates whether a telegram is being sent at that moment and whether the acknowledge signal is expected) Status of the buffer Time difference between Sending the telegram and receiving the acknowledge bit Start and stop of the simulation. Display of structure length Display of call frequency of OB35
FastVisualization
SlowVisualization
V1.0
19.04.05
44/95

Addressing the process variables in SIMATIC The assignment of OPC items to process variables occurs using so-called ItemIDs. ItemIDs must be defined as data type string and must follow a given syntax. This syntax depends on used OPC server and service (variables / block service). Variable service The following applies for SIMATIC NET OPC Server V6.2 SP1: <Protocol>:[<Connection name>],<Object>,<Type>,<Startindex>,<Number> Example: A variable is accessible via the S7 connection S7 connection_1 in DB2, DBW0. Then the ItemID is: S7:[S7 connection],DB2,INT,0,1
Block service The following applies for SIMATIC NET OPC Server V6.2 SP1: <Protocol>:[<Connection name>],<Service>,<ID>,<Type><Startindex>,<Number> Example: The controller sends a data area comprising 5418 bytes via BSEND with R_ID = 1. Then the ItemID is: S7:[S7 connection],BRCV,0,B0,5418
Note
Further information available in OPC Specification / OPC Manual \1\.
3. Managing the OPC Objects This application saves all relevant data of the crated OPC items in one or several arrays.
Note
Here the Client handles serve as index of an OPC item in the array The Server handles of OPCItems are returned from the corresponding array by specifying the respective ITEM_ID. Further information on the solution selected here is available in chapter 4.0
V1.0
19.04.05
45/95

3.0.0
Data structure of the telegram
Data structure in the controller Data produced during simulation of the heating circuit are mapped to the following structures in the controller. The data structure sent by the controller always takes the form of the UDT4 TELEGRAM.
Figure 4-2
V1.0
19.04.05
46/95

Data structure in the OPC client In the OPC client, the telegram sent by the controller is converted into equivalent .NET compatible structures. The classes necessary are hereby discussed in chapter 3.0.0. The layout of the data base is depicted below:
Figure 4-3
For modeling the connection between the heating station and its measuring locations, M_idx of the Measure (measuring locations) table is a ForeignKey to the H_idx-Key of the Heater (heating station) table.
Note The telegram header is not written to the data base. The depicted data base layout has been realized for each of the data base solutions introduced in this data base solution.
V1.0
19.04.05
47/95

2.0
Structure of the OPC Client
1.0.0
Figure 4-4
Class diagram of the OPC Client
V1.0
19.04.05
48/95

Note
Only the most important relationships and attributes are depicted. Relationships with standard .NET controls or structures also necessary for this application are not depicted. This is referred to the commented source code.
Explanations to the frame colors The classes framed in red encapsulate OPC specific functionalities, which can be simple adapted and reused. These are mainly functionalities which in this application were necessary regarding the interfaces IOPCServer, IOPCGroupStateMgt and IOPCItemStateMgt, i.e. especially the data exchange via OPC-DA 2.05 (see chapter 1.0.0). The classes framed in blue serve as usable logic interface for managing OPC items as simply as possible. This particularly simplifies reading and writing of OPC items to and from user interface elements. Core class is the PCItemExtenderList (see chapter 2.0.0).
The area framed in green serves as interface for all user interface elements wishing to read or write data from OPC items using OPCItemExtender objects. The classes PersistentData and DBConnector are briefly described below.
2.0.0
PersistentData class This class represents the main dialog of the application. It has the following tasks: Distributing the OnDataChange events to the respective objects Aggregating or referencing of all objects; this occurs either directly or indirectly via lists or manager classes Control of the entire application Forwarding control data to subordinate controls and vice versa Error handling; all errors not processed in other classes, are processed by this class (try-catch).
The principle steps for OPC connection are given in chapter 3.0.
V1.0
19.04.05
49/95

3.0.0 Tasks
DBConnector class
The CBConnector class has the following tasks:

Managing the different objects for data base connection to a hash table (Access, SQL Server, XML) Unpacking and analyzing a telegram Packing the read data into .NET structures using the S7DataConverter class. Triggering the filling of DataAdapter and DataSets or DataTables encapsulated in other classes. Reporting to the user interface as soon as a telegram has been saved to the data base Measuring the time required for converting the data and for saving data to the data base
V1.0
19.04.05
50/95

Class diagram The following class diagram shows the internal structure of the class.
Figure 4-5
V1.0
19.04.05
51/95

Explanation for the class diagram

Table 4-4
Section Blue
Task The connection with one of the 3 data bases is made with exactly four objects of the DBInterface class.
Explanation Three different approaches for connecting to a data base are introduced in this application (dark red frame): Access: Using the OleDBProvider SQL Server: Using the SQLProvider XML: Using an XML file NULL: This value corresponds to the initial setting of the application no saving to a data base; the reference to the DBInterface must have the value null Due to the fact, that each of the above class has been derived from DBInterface, a secret access to each of the objects is possible. Due to the fact that the DBConnector class implements the IOPCItemControl interface it can process the telegram (see chapter 4.0) The telegram is received from the OPC server as a byte array. Due to this circumstance, as well as the fact that SIMATIC processes its data in BigEndian format, it is necessary to unpack the byte array and copy the data to the required structures. The structures used in the simulation on the controller are realized in the OPC client by the TelegramHead, MeasuredHead and MeasureData classes. Using the S7DataConverter class, the data in the byte array can now be transferred to the created .NET structures. The data are also analyzed. These classes provide the required data base connections. Furthermore, these classes implement the functionalities required for the application, such as: Adding a data record to the Heater table. The AutoIndex created by the DataTable is hereby returned, so it can be used as ForeignKey in the Measure table. ATTENTION The data record is initially only created in the DataTable, hence is not daved to the data base. Adding a data record to the Measure table ACHTUNG: The data record is initially only created in the DataTable, hence is not daved to the data base. Adding data stored in the DataTables to the data base Deleting all data from the data base Reading all data from the data base Notifying the user interface is performed with an Eventhandler BRCVOccuredEventHandler. Via the OnBRCVOccured event, this message is sent to all objects registered at the Eventhandler (here: the user interface).
Green
Interface for receiving a telegram Unpacking, packing and analyzing the telegram
Red
Dark red Provision of respective data base connection
Orange
Notifying the user interface as soon as saving to data base is completed
V1.0
19.04.05
52/95

3.0
Establishing the connection to the OPC server and creating the OPC items
Introduction The procedure for connecting an .NET-OPC clients to the OPC server as well as creating OPC items is identical to the procedure as with a C++ application. In order to exchange data between OPC client and OPC server, a "Connection must first be established. This occurs via the OPC DataAccess interface, whose objects and connections are displayed simplified and incomplete in the following figure. Objects of the OPC DataAccess interface
Figure 4-6
1
IOPCServer
2 3
IOPCItemMgt
IOPCGroupStateMgt
IOPCAsyncIO2 ISyncIO
IConnectionPointContainer
5
IConnectionPoint
Description of the graphic The OPC client performs the respective actions by pressing the respective operator buttons. The dependencies displayed in the above figure must of course be taken into account. The actions to be performed are:
Table 4-5
No. 1
Instructions Creating an instance of the "IOPCServer interface
Note This informs the OPC server that an OPC client needs to be served. Note The OPCServer object is managed by the OPCServerManagement class. All OPC objects directly required in this application by the IOPCGroupStateMgt interface are encapsulated in the OPCGroupManagement class. Note
IOPCServer provides an interface for the IOPCGroupStateMgt interface. Now one or several OPC groups must be added via this interface (IOPCGroupStateMgt). IOPCGroupStateMgt provides an interface for the IOPCItemMgt interface. The OPC items are created using this interface.
V1.0
19.04.05
53/95

No. 4
Instructions IOPCGroupStateMgt provides an interface to the IOPCAsyncIO2 interface. Making asynchronous calls requires an instance instance of this interface (IOPCAsyncIO2) to be generated. The OPC server is to inform the OPC client actively when the files asynchronously written in the controller have arrived. This requires the OPC client register at the respective interface as receiver of messages. This is performed via the "IConnectionPointContainer interface or respectively the "IConnectionPoint.
Note
Like all "active" COM components, the OPC server provides an interface to the "IConnectionPointContainer. An instance to "IConnectionPoint finally provides the active connection.
Note
If variables / OPC items must continuously be monitored, the OPC group in which the variables/OPC items are located must be switched "active". Further respective information is available in the OPC Specification \1\ . OPC items (and the respective group), which are to be read synchronously from the CACHE, must be active. Further respective information is available in the OPC Specification \1\ . Operating the user interface is introduced in chapter 10. The respective OPC functionalities used regarding an OPC group are encapsulated in the OPCGroupManagement class. It is nevertheless explicitly pointed out, that it may become necessary, to adjust this class in an own application. A general application capability of this class can not be guaranteed. Only one possible way of implementation is illustrated here. With regards to this, an OPC wrapper class for .NET will be provided which considerable simplifies the implementation of OPC clients.
V1.0
19.04.05
54/95

4.0
Problem circles in generating OPC clients and solutions in this application
Here you will find information on Problems occurring during creating of OPC clients and how to solve them will be discussed below. For the following chapter it is recommended to have the class diagram (chapter 1.0.0) available. 1.0.0 Problem How can the implementation work load for OPC clients be reduced ? The implementation work load for accessing OPC objects and their methods in .NET hardly differs from that under C++. Additionally the required resource management (memory) contains also sources for errors. Solutions realized in this application Generally the access to OPC objects by means of own classes should be encapsulated in order to provide simpler access. .NET provides an additional software architectural aid facilitating cleaning up of obsolete objects. This is the IDisposable interface, used for realizing the IDisposable #~#. Deriving the respective class from this interface guarantees a uniform mathod call, which enables releasing all obsolete resources.
Note
Simple usage of the OPC RCW
The final release of all resources is down to the .NET-Framework of the GarbageCollector. In Version V1.1 it cannot be predicted from when on a memory area marked for release is actually being released! COM resources however must always be released explicitly, as this resource is located in the unmanaged Code and the GrabageCollector has no access to it. The OPCServerManagement and OPCGroupManagement classes (blue frame in Figure 4-4) encapsulated the access to the OPC objects and its methods. Additionally these classes implement the IDIsposable interface and hence support the release of all non-required resources.
V1.0
19.04.05
55/95

Further advantages of the OPCGroupManagement class Another advantage of the OPCGroupManagement class is that it encapsulates events delivered by the OPC server. It means that the user interface need not have any contact with the OPC. It is sufficient to reference an object of the OPCGroupManagement class. If for each OPC group to be created, the user interface now manages an object of the OPCGroupManagement class, then it will already receive the results from the OPC server group selectively. I.e. not one method is called for all OnDataChange events as so far, but only the OnDataChange event for the respective group in which the value of an OPC item has changed.
Note
The source code for connecting with OPC is available in the commented sources. The sequence diagram for running the IDisposable pattern is available in chapter 3.0.
2.0.0 Problem
Identification of OPC items via the respective handles
Which structure is suitable for managing client and server handles ? As already explained in chapter 4.0, client and server handles are used for identifying OPC items. This is a quick and simple way of managing these handles:
Storing the Serverhandles in an array:

private int m_srvHndl[] = new int[4];
Creating client handles as constants:

private const int CLNTHNDL1 = 0; private const int CLNTHNDL2 = 1; private const int CLNTHNDL3 = 2;...
The following problem cases result from this "management structure":
V1.0
19.04.05
56/95

Receiving data via OnDataChange (code excerpt)

Figure 4-7
Explanation For the above method it becomes apparent very soon, that for large amounts of OPC items (e.g. several 1000 OPC items) the limits of clarity are quickly reached (switch-case instruction) and programming errors become more and more likely. Additionally it is difficult to expand the above code fragment. It must be imagined that a further OPC item must be added to the runtime. This however must already be known at the time of implementation (due to the switch-case instruction in OnDataChange).
V1.0
19.04.05
57/95

Writing an OPC item via a synchronous write command (code excerpt)

Figure 4-8
Explanation Here it becomes apparent, that the position of the server handle in the management array must for the respective action already be known at the time of implementation. If at a later development time another OPC item is added, then the code of the setResetFlagForSimulation code must be changed as the index o the server handle within the array has changed. Simple expandability can hence not be guaranteed anymore. Solutions realized in this application Encapsulating data describing an OPC item into its own class offers almost unlimited expandability. This has been realized by means of the OPCItemExtender class. All OPCItemExtender objects are saved in an object of the OPCItemExtenderList class, which in return is a specialization of the System.Collections.ArrayList class of the .NET-Framework. Conventions of the OPCItemExtender and OPCItemExtenderList objects In order for the client and server handles not to be managed separately, the following conventions must be made: The client handle of an OPC item is the index of an OPCItemExtender object within the OPCItemExtenderList object.
V1.0
19.04.05
58/95

The server handle of an OPC item is also saved in the OPCItemExtender class. There are two ways to receive an OPCItemExtender object from the OPCItemExtenderList: Index access to the list (index corresponds to the client handle) Specifying the ITEM_ID, which should always be known in the application (z.B. in form of constants, #define directives, INI files)
The Hashtable of the OPCItemExtenderList For also enabling performing the last point (accessing an OPCItemExtender object via its ITEM_ID) at over 1000 objects with acceptable performance, the OPCItemExtenderList contains a hash table which contains the ITEM_ID as keys and a reference to the respective OPCItemExtender object as value. This enables accessing any OPCItemExtender object in constant time (O(1) complexity).
Access to a particular OPCItemExtender object via the hash table The following figure schematically illustrates the above. This also enables code constructs discussed in the following blocks.
Figure 4-9
V1.0
19.04.05
59/95

Receiving data via OnDataChange (code excerpt)

Figure 4-10
Explanation The value of the delivered OPC item is written into the OPCItemExtender object via an actValue property, which is indexed over the respective client handle. It becomes apparent, that only newly added OPC items require no immediate code adaptation of the OnDataChange method. Another advantage of the here described solution is the fact, that the value of an OPC item is now available at any time, as it is stored in the respective OPCItemExtender object (which can be addressed via the known ITEM_ID).
V1.0
19.04.05
60/95

Writing an OPC item via a synchronous write command (code excerpt)

Figure 4-11
Explanation The code extract shows how the server handle for the OPC item ITEM_RESET is read from the respective OPCItemExtenderList object. Irrespective of whether further OPC items are added in the later course, the correct OPC item is always written at this point.
Note
In order to fully provide the required expandability, respective methods must of course be implemented the OPCItemExtenderList class. Only the methods necessary for this application have been implemented in this application. For example, it is not possible within this application to remove individual, already added OPC items during runtime, as the respective methods have not been implemented. With the existing class structure however, there shouldn't be any larger problems regarding expandability of the classes.
V1.0
19.04.05
61/95

3.0.0 Problem
Allocating the value of an OPC item to user-defined objects
The class structure explained in chapter 2.0.0 provides no solution to a specific problem: Which user interface element is meant to indicate the value of a certain OPC item ? At this point at the latest you are again dependent on a switch-case construct, as already illustrated in chapter 2.0.0. Often, certain user interface elements request the value to be displayed as String value, other elements require a Boolean value. At least a switch-case regarding the type of an OPC item is necessary. The next question follows, if the value of an OPC item is not to be displayed at all, but for example to be saved in a database.
In more general terms, the question is: how can a connection of any objects to values of OPC items be realized without extensive switch-case or if-thenelse constructs becoming necessary? Solutions realized in this application The answer to this questions is given by the object orientated languages: Polymorphism. The interface IOPCConnector::IOPCItemControl used in this application declares a setOPCParam(object) method (green frame in class diagram chapter 1.0.0). If now any .NET class is derived from this interface (C#-modifiers must of course be considered), then this class must implement the method of the interface. Such a class is DBConnector, for example.
Note
In this application, all classes implementing the IOPCConnector::IOPCItemControl interface have the suffix Connector.
Now let m_DBConn be an object of the DBConnector class, which can manage almost any number of data connections. If the setOPCParam method is now called by the m_DBConn object with the value of the OPC item transferred as object, then the m_DBConn object can process the transferred value as desired. The user interface needs no longer deal with this. However, as it is not desired to memorize all connector objects separately, there is polymorphism.
V1.0
19.04.05
62/95

The OPCItemExtender class contains a member private IOPCItemControl m_correspondingObject; Any object of a class which implements the IOPCConnector::IOPCItemControl object. Due to the fact that each Connector class implements this interface, any object of any Connector class can also be specified here. When calling the (still abstract) method, it is established via late-binding which object is present and the method (now concrete) corresponding to the object is called. The following code fragment of the OPCItemExtenderList class shows how simple writing of OPC item values into any Connector objects is. The actValue property of an OPCItemExtender object is hereby set in the OnDataChange method (see chapter 2.0.0 OnDataChange Code Fragment).
Figure 4-12
4.0.0 Problem
Dealing with OPC server events with long processing runtime
When processing an OnDataChange in the OPC client is taking relatively long compared with the update rate of other OPC groups, then the OPC client will not notice changes in quickly changing OPC items, as during processing the event no other events can be processed by it. The question is: How to deal with events (e.g. OnDataChange) of the OPC server, whose processing in the OPC client takes very long (several seconds)?
V1.0
19.04.05
63/95

Solutions realized in this application The only option for an OPC client to simultaneously process an event1 and receive (process) an event2, is to have the processing of event2 be performed in a separate thread, a so-called Worker Thread. Of course further problems result, which from case to case need to be analyzed (e.g. synchronization; disturbance between threads; interrupting a thread by another; prioritizing events (threads); the same event occurring faster than it being processed in the thread etc.). In this application, however, these problems hardly occur, as: there is only one event in this application, i.e. saving to data base, which may take longer only respectively one Worker Thread needs to be started the controller sends a telegram only after receiving the acknowledge bit. The acknowledge bit is only written by the OPC client when the telegram has been saved to the data base and the Worker Thread is terminated. the Synchronization is thus realized by the Communication protocol.
However, an overflow of the buffer in the controller is possible if saving to the data base takes too long (here: >2 sec.). For starting a Worker Thread, .NET provides a quite comfortable option via the IAsyncResult interface. In this application a callback object is also being used, which displays the end of the worker thread. Furthermore, a so-called Waithandle can be used to poll whether the thread has been terminated or not. The following code extract shows the procedure (file: PersistentData.cs; Region Callback methods):
Figure 4-13
Defining a delegate to determine the method to be executed:
V1.0
19.04.05
64/95

Figure 4-14
Receiving the OnDataChange from the BRCV group:
Figure 4-15
The Worker Thread was terminated:
V1.0
19.04.05
65/95
Function Principles and Program Structures Data Flow Model of this Application
Data Flow Model of this Application

how the data flow words regarding transmission of a telegram. The main focus is on the processes in the OPC client.
This chapter explains ...
Overview
Figure 33-1
Description
Table 5-1
No. 16 17
Instructions The CP is used for sending the telegram to the address configured in NetPro. The telegram is passed on to the OPC server via the corresponding driver layers.
Note
1 The controller sends a telegram with BSEND
V1.0
19.04.05
66/95
Function Principles and Program Structures Data Flow Model of this Application
No. 18 19 20
Instructions The OPC server has detected the complete reception of the telegram and informs OnDatChange of the event. The OnDataChange event is received by the OPC-RCW. The OPC-RCW for .NET passes the event on. The OPCGroupManager receives the forwarded OnDataChange event. The OPCGroupManager object reports to the user interface (PersistentData class), that an OnDataChange event has been received. The user interface starts a thread and has the received telegram processed by the method executed by the thread. Thereby the method forwards the telegram to the DBConnector object via the delivered Clienthandle. The DBConnector object informs the user interface of the telegram being unpacked, analyzed and saved into the data base. The user interface now sets the acknowledge bit via a synchronous write job via a group management object (group FastVisualization). The OPCGroupManager of the FastVisualization group forwards the job to the OPC-RCW. The OPC-RCW calls the respective method of the OPCDA interface. The job is passed on to the OPC server The write job is forwarded to the Industrial Ethernet network via the driver layers. The CP receives the telegram triggered by the driver layers and the Ethernet card. The acknowledge bit is set via the BESY of the controller. The syncWrite call is terminated. The method executed by the thread is hence terminated. The thread informs the user interface object of the thread has terminated its work. As a result, the user interface object terminates the thread.
Note
This is the OPCGroupManager object BRCV, which is managed by the BRCV group.
21
22
The user interface knows, that a telegram has been received (the event was forwarded by the BRCV group) and therefore a thread must be started.
23
24
25 26 27 28 29 30
The acknowledge bit is reset by the controller as soon as a telegram is sent.
31
V1.0
19.04.05
67/95
Function Principles and Program Structures Explanations on the Example Program

Explanations on the Example Program

<Code details of some core elements of the program, sequence diagrams, configuration instructions ...>
1.0
Installation of the OPC-DA-RCW interfaces
Here you will find information on how to integrate the SIMATIC NET OPC-DA interfaces into a .NET application.
Note
This chapter is neither an instruction manual for Visual Studio .NET nor an introduction into .NET-Framework. It only lists some relevant procedures for connecting the above components.
Prerequisites The following prerequisites must be fulfilled: SIMATIC NET V6.2 installed Visual Studio .NET started with a .NET-Windows application Installation of .NET-RC Wrapper In order to access the OPC-DA interface, a reference to OPC-DA-RCWrapper must be generated within the project. Chapter 2.0 contains a description of how the respective OPC-DA interfaces must be used.
Note
Chapter 5.0 explains and describes the necessity of an RCW.
V1.0
19.04.05
68/95

Table 6-1
No.
Instructions
Note
1 In the project you click Add reference...
32
In the following dialog you click Browse and select the files opcrcw.comn.dll and opcrcw.da.dll which are located at [SIMATICNET-installation path]\opc2\bin\ . Acknowledge with Open and then with OK.
V1.0
19.04.05
69/95

No. 33
Instructions The RC-Wrapper now appear in References.
Note
2.0
Sequence diagrams of the OPC Client
Here you will find information on the sequences running at this OPC Client. Creating OPC groups and OPC items is discussed as well as the sequence for receiving a telegram. The instructions necessary behind the illustrated sequences are available in the commented source code.
Note All code fragments have been divided into regions. All data base relevant classes are contained in the Namespace *.DB.
V1.0
19.04.05
70/95

Sequence diagram for creating OPC groups and items The following sequence diagram shows the sequence starting with the OberflchenObjekt this:
Figure 6-1
V1.0
19.04.05
71/95

Sequence diagram for receiving a telegram The sequence diagram shows the sequence for receiving a telegram. The area inside the red frame runs in a separate thread.
Figure 6-2
3.0
Releasing the references to the OPC server

This section now shows how the COM references are released.
General information In .NET it is possible to use the IDisposable pattern. As illustrated in chapter 1.0.0, the respective class implements the IDisposable interface. This provides the Dispose(void) method. When now calling the Dispose(void) method, a Dispose(true) method is performed which manually releases the reference to the released. If the method is not called (programming error), then a finalizer (Destructor) is called who calls the same Dispose(false) method. Result: The COM references are released again in any case.
V1.0
19.04.05
72/95

Note
The call of the finalizer is not deterministic, i.e. the time interval between deleting the last reference on an object and deleting the object from the memory is not fixed.
Necessity of this pattern The necessity for this procedure becomes clear when considering that COM objects cannot be detected by the GarbageCollector. They are located in the unmanaged Code section. Additionally, there are inter-dependencies between the COM objects. The COM object of the IOPCServer type, for example, must not be released while COM objects of the IOPCGroupStateMgt type are still referenced. Otherwise, the IOPCGroupStateMgt objects cannot be released (then the IOPCServer object required for this does not exist anymore). Implementation in this application
The following sequence diagram shows the procedures when the OPCClient is being closed:
V1.0
19.04.05
73/95

Figure 6-3
this m_mgtServer groupManager m_OPCCP m_OPCItem m_OPCGroupStateMgt m_OPCServer
Dispose
Dispose removeAllItemsAndGroup foreach loops over all groupmanagers
disconnectCallback Unadvise Marshal.Release(m_OPCCP)
removeItems RemoveItems
removeGroup
RemoveGroup
freeGroup Marshal.Release(m_OPCGroupStateMgt)
Marshal.Release(m_OPCServer)
V1.0
19.04.05
74/95
Function Principles and Program Structures Modifications to the Example Program

Modifications to the Example Program

how to alter the size of the telegrams to be sent.
General The simulation runs automatically on activation. In individual cases it is possible, that the send bit (DB15.DBX0.0) must either be reset via the user interface or the variable table (see chapter 10). Adjusting the telegram size The are basically two options for adjusting the telegram size:
General adjustment of the structures (see chapter 3.0.0) Adjusting the number of data records to be transferred
Prior to the adjustment, the application must be installed according to chapter 8. You need to consider the maximum block size! Consider the memory area for data blocks provided by your Y7 CPU.
Note
The table below contains a description of how to change the number of data records.
Table 7-1
No.
Instructions
Note
1 Open the project OPCMassendaten (Mass data) in the SIMATIC Manager. 34 Open the blocks UDT4, DB25, DB26, FC2 and FC5.
V1.0
19.04.05
75/95

No. 35
Instructions Now change the initial value for variable MAX_SIZE and size of the WP_DAT array in the blocks DB25 and DB26. Note: The values in both DBs must be identical Due to 1 entry consisting of 270 bytes, the maximum possible number is calculated as follows: Maximum DB size/ 270
Note
36
In UDT4 you adjust the size of the array to the now valid maximum number of data records .
37
In the FC5 block you adjust parameter Variable of the VAR_LEN FB and parameter SD_1 of the BSEND FB.
V1.0
19.04.05
76/95

No. 38
Instructions In block FC2 you adjust the parameter BEREICH of the ALT_BUFFER FB. Note: The area of the pointer is exactly 18 bytes lower than for the parameters in step 5.
Note
39
Saving and compiling all blocks. Select the menu command "Check Block consistency". Load the blocks into the automation system. Open the Visual Studio .NET solution Open the PersistentData.cs file. In the code you navigate to the regions: Constants OPCconstants: settings, item-ids etc. opcconstants for the BRCV group
Note: Possibly, the blocks DB15, OB1 and OB100 must be saved separately.
40 41 42 43
44
Change the constant ITEM_BRCV to the new required size for receiving the telegram Save the data and create the project via menu ...
The example assumes a telegram size of 8kB The generated file can now be executed.
45
V1.0
19.04.05
77/95
Structure, Configuration and Operation of the Application Installation and Commissioning

Structure, Configuration and Operation of the Application

Content This part leads you step by step through the structure, important configuration steps, commissioning and operation of the application.
Installation and Commissioning

the hardware and software to be installed and which steps are necessary for commissioning the example.
1.0
Installation of the hardware

This chapter describes the hardware and software components to be installed. The description and manuals as well as delivery information contained in the delivery scope of the respective products, should be followed in any case.
Installation of the hardware For details on the hardware components, please refer to chapter 4.0. For the hardware setup, proceed in accordance with the table below:
!
Warning
Table 8-1
Switch on the power supply after the last step only .
No.
Focus
Instructions Install the station in compliance with the diagram shown in chapter 1.0. Connect the controller with the PG. Note Instead of using a hub or a switch you can also use a cross cable for a direct connection.
1 Controller S7-400 station Industrial Ethernet
V1.0
19.04.05
78/95

2.0
Installation of the software
This chapter describes how you can put this software into operation. For a smooth operation procedure the following sequence should be kept:
Table 8-2
No. 1 47 48 49 50 Set PG/PC interface
Instructions Installation of STEP 7 and SIMATIC NET Installation of the STEP 7 project Importing the XDB file to the component configurator Installation of the user interface
The following chapters have been structured in this very sequence.
1.0.0
Installation of STEP 7 and SIMATIC NET A description of the installation procedure for STEP 7 and SIMATIC NET is not part of this documentation. The installation takes place in the familiar Windows environment and is self-explanatory.
2.0.0
Set PG/PC interface The Ethernet network card must be set as PG/PC interface.
Note
Please ensure, that the Ethernet network card has the fixed IP address 140.80.0.2 (these can be set via the network settings the TCP/IP properties). Otherwise you must adjust the STEP7 project.
Now proceed as follows:
V1.0
19.04.05
79/95

Table 8-3
No.
Instructions
Note
1 Start the SIMATIC Manager and open the dialog for creating the PG/PC interface via Options > Set PG/PC interface....
51
Set your network card as depicted. Note: In this case a NETGEAR network card was used.
52
Confirm with OK.
V1.0
19.04.05
80/95

3.0.0
Installation of the STEP7 project The STEP 7 project contains the following configuration for network cards and modules:
Table 8-4
Focus Controller PG CP 443-1
Module Ethernet network card
IP address 140.80.0.1 140.80.0.2
The subnet mask has been set to 255.255.255.0.
Note
If you wish to use other IP addresses, you must adjust the STEP 7 project accordingly.
Then proceed as follows:

Table 8-5
No.
Instructions Extract the project via the menu File > Retrieve...
Note Use the browser to search the archived project 21447513_OPC_Massendaten_STEP7_v10_d .zipand click OK to confirm Note If no S7-SCL has been installed on your PG, an error message appears during retrieving. However, you may still use the project
1 Open the SIMATIC Manager.
54
Select a directory into which the project files are to be retrieved and open the project. Open the project tree of the project.
Click AS 400 in the project tree and use PLC -> Download to download the program to the SIMATIC 400.
55 56
57
Set the SIMATIC station to RUN mode.
V1.0
19.04.05
81/95

4.0.0
Note
Importing the XDB file to the station manager The XDB file already exists in the extracted project
Table 8-6
No.
Instructions
Note
1 Open the Component configurator by doubleclicking in the toolbar.
58 59
Click Import Station Browse to your STEP 7 project and select the XDB file (available in the "XDBs" file in the project directory). Press Open.
Note
Confirm the query with Yes.
V1.0
19.04.05
82/95

No. 60
Instructions The Import Wizzard confirms that import is possible. Press OK. Close the component configurator with OK
Note
61
V1.0
19.04.05
83/95

5.0.0
Installation of the user interface
!
Warning
If you have installed an operating system older than WindowsXP SP1, you must first install the .NET-Framework Version1.1. Information available on the Microsoft Internet pages http://www.microsoft.com/
For installing the operator user interface proceed as follows:

Table 8-7
No.
Instructions
Note
1 Extract the 21447513_OPC_Massendaten_CODE_v10_d.zip file

Double-click the file Persistent_Data_ADO_XML.exe in the \Persistent_Data_ADO_XML\bin\Release folder
The data base is contained in the folder \Persistent_Data_ADO_XML \bin\Release\DB
!
Warning
In order to operate the application using an SQL server data base, either Microsoft SQL Server 2000 must be installed or MSDE (Desktop Engine of the SQL Server) be downloaded from www.microsoft.com and installed. Furthermore, the SQL data base HeatCircuit.mdf must be imported to the SQL server. Alternatively the Access data base can be imported to an SQL data base.
Uninstallation To uninstall the extracted file you simply delete it.
V1.0
19.04.05
84/95
Structure, Configuration and Operation of the Application Configuration

Configuration
Note
The following explanation on configuration only becomes necessary if you wish to make adjustments or want to know which configurations must be made prior to this application.
1.0
Configurations of the application
Main focus of this application is using OPC. There are several options for configuring the OPC server. Here, importing the SCB file delivered by STEP 7 is illustrated.
Note
You must first create the PG/PC interface according to chapter 2.0.0.
1.0.0
Table 9-1
Configuring the OPC server in HWConfig
No.
Instructions
Note
1 Create a new station of the type SIMATIC PC Station in a STEP 7 project. 3 Open the created station by The hardware configuration opens. double-clicking Configuration Add a SIMATIC NET OPC server to slot 1. This application uses the SIMATIC NET OPC server V6.1.0. Note It is located in the catalog directory:
V1.0
19.04.05
85/95

No.
Instructions Add IE General..
Note In this application a standard Ethernet network card was used. Note It is located in the catalog directory::
Open the object properties of the OPC server by double-click and change the S7 tab.
If you wish, you activate the Access Protection as well as Use Symbols (see screenshot step 5) Close the dialog and the object properties of the OPC server respectively with OK.
V1.0
19.04.05
86/95

No. 9
Instructions Open the object properties of the network card with double-click.
Note
10 11
Click on Properties.... Set the parameters as in the in the screenshot on the right. Note: If no IE network has been configured yet, you generate a new one with New... and apply the standard parameters.
12
Save and compile the hardware configuration with . Close the hardware configuration.
V1.0
19.04.05
87/95

2.0.0
Table 9-2
Configuring the OPC server in NetPro
No. 1
Instructions Open NetPro with the button. Select the OPC server.
Note
13
14
Add the new S7 connection
15
Select the CPU 414-2DP. Select S7 connection as the connection type.
16
Accept the standard parameters with Apply and OK.
V1.0
19.04.05
88/95

No. 17
Instructions The following image appears in the connection table Save and compile the configuration with .
An XCB file is created.
Note
18
19
Close NetPro.
Note
The created XDB file must be loaded to the station manager via import. Proceed analog to chapter 4.0.0.
3.0.0
Check the settings The settings can be checked with the configuration dialog for the OPC server. The following settings should be considered:
Table 9-3
No.
Instructions
Note
1 Open the configuration dialog.
20
Check the set access point S7ONLINE.
V1.0
19.04.05
89/95

No. 21
Instructions Check the set IP address for the used Ethernet card.
Note
22
Check the set protocols. Note: Activating the S7 protocol is sufficient for this application.
23
Check whether the Symbols have been loaded.
24
Close the configuration dialog box.
If one of the settings does not correspond with the displayed images, perform the preceding configuration again.
V1.0
19.04.05
90/95
Structure, Configuration and Operation of the Application Operating the Application

10
Operating the Application

the operating steps which can be performed with the user interface.
1.0
Note
Commissioning of the simulation

For an overview of the user interface see chapter 3.0.
You can make the following settings: Change the update rate for the individual groups Change the data base to which the telegrams are to be saved. For commissioning and setting the simulation proceed as follows:
Table 10-1
No.
Instructions
Note
1 Set update rates for the group: Press menu items SimulationSettings UpdateRates and set the rates in ms. Acknowledge with OK.
25
Connecting to the OPC server: Press menu items SimulationSettings Connection to OPC-Server Connect
V1.0
19.04.05
91/95

No. 26
Instructions If the Send Bit is read, reset it with SimulationSettings Control Clear send bit. Otherwise, the application cannot start!
Note
27
If you wish to save the data to a data base, select the data base type.
28
Start the simulation: Press the Start/Stop button.
2.0
Table 10-2
Show / delete data records stored in the data base
No.
Instructions
Note
1 Stop the simulation: Press the Start/Stop button and wait until the color turns red or gray. Note: The button turns gray if the OPC client is not connected with the OPC server.
V1.0
19.04.05
92/95

No. 29
Instructions Show data records: Press the menu item Show records
Note
The data records are displayed in DataGrids (please press the + icons):
30
For deleting the data records of the selected data base or deleting all data records, press Database-Settings in the corresponding menu.
V1.0
19.04.05
93/95
Appendix and List of Further Literature Glossary

Appendix and List of Further Literature

11 Glossary
COM: Component Object Model: Software model for communication between components based on a standardized interface; DCOM: Software model for communicating beyond computer boundaries based on COM: Event handler An Event handler processes occurring events or Windows messages. Exception An Exception is referred to as a exceptional situation. It can be generated either by the operating system (e.g. Division by zero) or by the user program. Exception handler An Exception handler processes occurring exceptional situation. Generally, the reaction to an error behavior and/or a message to the user are implemented here. HRESULT Return data type of COM objects. IDL Interface Definition Language: A Microsoft standard language for definition of function and parameter interfaces. Polling Term referring to (mostly cyclical) requesting of certain values or statuses. Sink interface Using the sink interface, messages between components can be sent. The sink interface is based on COM mechanisms. Windows message The standard Microsoft Windows operating systems exchange messages to notify of events, e.g. the paint event. Wrapper The term Wrapper normally refers to a class group which encapsulates other class groups for data conversion or easier handling. It can be
COM / DCOM
V1.0
19.04.05
94/95
Appendix and List of Further Literature Literature

considered a hull enclosing the wrapped classes, covering them from the outside.
12
1.0
Literature
List of further literature
This list is by no means exhaustive and only gives a selection of appropriate sources.
Table 30-1
Topic \1\
Title OPC DA 2.05a Specification bei http://www.opcfoundation.org/ mn_opc_0.pdf und mn_opc_76.pdf von SIMATIC.NET V6.2 Inside C#, Tom Archer .NET Crashkurs, Clemens Vasters, Oellers, Javidi, Jung, Freiberger, DePetrillo Microsoft .NET Framework Programmierung, Jeffrey Richter
OPC
\2\
.NET
30.0
Internet links
This list is by no means exhaustive and only gives a selection of appropriate sources.
Topic \1\ \2\ Reference to the document Siemens A&D Customer Support Title http://support.automation.siemens.com/WW/view/de/21 447513 http://support.automation.siemens.com
V1.0
19.04.05
95/95

OPC Massendaten DOKU v10 e

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OPC Massendaten DOKU v10 e

Enviado por

Direitos autorais:

Formatos disponíveis

Application for Communication

Mass Data Acquisition with an OPC Client in C# based on .NET

Warranty, Liability and Support

Mass Data Acquisition with OPC

Warranty, Liability and Support

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Mass Data Acquisition with OPC

Mass Data Acquisition with OPC

Part Application Description

Function Principles and Program Structures

Structure, Configuration and Operation of the Application Appendix

Mass Data Acquisition with OPC

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Mass Data Acquisition with OPC

4.4.1 4.4.2 4.4.3 4.4.4 5 6 6.1 6.2 6.3 7

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Task

Here you will find information on

Application Description Automation Task

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Here you will find information on

Overview of overall solution

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Software components involved

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Description of the core functionality

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Description of user interface

Application Description Automation Solution

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Required hardware and software components

Hardware components (SIMATIC S7)

Component PS407 10A CPU 414-2DP CP 443-1 Standard hub 1 1 1 1

MLFB / Order number 6ES7407-0KA01-0AA0 6ES7414-2XG04-0AB0 6GK7443-1EX11-0XE0 Depending on product

Hardware components (PC)

MLFB / Order number 6ES7711-2EA21-3LB4 Depending on product

Note Integrated in Field PG

SIMATIC Field PG Ethernet network card

Standard software components

MLFB / Order number 6ES7810-5CC08-0YA5

Free download at http://www.microsoft.co m/

Application Description Automation Solution

Component 21447513_OPC_Massendaten_STEP7_v10_d.zip: STEP 7-Projekt 21447513_OPC_Massendaten_CODE_v10_d.zip: Setup program

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Basic Performance Data

Application Description Automation Solution

MS Access 200-250ms 750-950ms ~ 1sec

MS SQL Server 200-250ms 150-220ms ~ 350ms

XML(***) 200-250ms 50-1500ms ~200-1800ms

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Copyright Siemens AG 2005 All rights reserved 21447513_OPC_Massendaten_DOKU_v10_e

Application Description Automation Solution

Criterion Custom interface Automation interface Simple implementation Error handling

(*) ++ ++ - (**) + (**) ++ (**)

(*) ++ ++ - () + () ++ (**)