8.1.1 Development contexts
Many supervision applications include the OPC client function as standard. However, in the case of specific requirements, it is possible to develop one's own OPC client oneself, using the
development tool of one's choice. This section is intended solely to supply the basic information required by developers
Developments can be classified in two main categories: Developments using the custom interface.
This interface can be used with languages of the C/C++ type. Its use requires complete knowledge of the OPC Data Access specification, OPC mechanisms in general and OLE/COM mechanisms.
Developments undertaken using the Automation DLL.
This interface is more specifically intended for fast development tools such as VB, Delphi, offices tools, etc. It in fact constitutes an additional automation layer of the custom interface useable in languages of the C/C++ type. Its use requires complete knowledge of the Data Access Automation Interface specification and of OPC mechanisms in general. This DLL is not supplied in the package. If required, the Automation DLL sources can be obtained from the OPC foundation
8.1.2 ProgID and CLSID
The OPC server is identified using its ProgID (program identifier) and its CLSID (class identifier), recorded in the registers database of the machine during installation.
Woodhead
Woodhead
The CLSID is the single and universal identifier of the server and it is independent of its version. The ProgID is a string of characters translated from the CLSID using the registers database. It constitutes a legible synonym of the CLSID.
ProgID: Woodhead.PfbOpcServer
CLSID: {283618B5-8349-11D0-8F82-0080C85344A1}
8.1.3 Developing a client in C and C++
The OPC server is based on specifications 2.05a and 3.0 of the OPC foundation. It supports access through the OPC custom Interface.
The aim of this documentation is not to replace the specification published by the OPC foundation. The latter describes in detail the different interfaces and the role of the methods they expose. The purpose of this section is to describe particular features relating to the development of an OPC client in C++ with this OPC server in particular.
8.1.3.1 Creation of an OPCServer object
The OPC server is identified using its ProgID (program identifier) and its CLSID (class identifier), recorded in the registers database of the machine during installation.
The CLSID is the single and universal identifier of the server and it is independent of its version. The ProgID is a string of characters translated from the CLSID using the registers database. It constitutes a legible synonym of the CLSID.
ProgID: Woodhead.PfbOpcServer
CLSID: {283618B5-8349-11D0-8F82-0080C85344A1} To instance the OPC server, the client application must:
1 – Initialise the COM library
2 – Obtain the CLSID from the OPC server from the ProgID 3 – Create an OPCServer object
4 – Call one or more functions of the OPCServer object 5 – Release the interfaces used.
This is an example of code undertaking the above stages (for the sake of code legibility error cases are not handled):
//Stage 1: Initialise the COM library HRESULT hr;
hr = CoInitialize(NULL);
//Stage 2: Obtain the CLSID from the ProgID CLSID clsid;
hr = CLSIDFromProgID((L" Woodhead.PfbOpcServer "),&clsid); //Stage 3: Create the OPCServer object and obtain the first interface (here IOPCServer)
IOPCServer* pServer;
hr = CoCreateInstance(clsid,NULL,
CLSCTX_LOCAL_SERVER,IID_OPCServer,(void**)&pServer); //Stage 4: Call one of the functions of the interface. …
pServer->GetStatus(…); …
Woodhead
Woodhead
pServer->Release(); UnInitialize();
8.1.3.2 Creation of an OPCGroup object
A group is created by the client using a call to the method AddGroup of the interface IOPCServer of the object OPCServer. The latter notably contains the following parameters:
Name Description
szName Name of group. If it is not supplied, the server generates a unique one (in the
form New_Group_x , where x is an incremental number).
dwRequestedUpdateRate Refreshment period requested by the client. The period actually accepted by
the server will be returned in the return parameter
dwRequestedUpdateRate.
dwLCID This parameter is not used.
pPourcentDeadBand This parameter allows return of the variable with a strong variation (see
"Group management")
8.1.3.3 Managing items
Items are created by the client using a call to the method AddItem of the interface IOPCItemMgt of the object OPCGroup. Each item symbolises a connection to a physical variable. In fact the client describes the variable which interests it by means of a OPCITEMDEF structure.
The fields of this structure are as follows:
Name Description
szAccessPath Not actually used by the OPC server. If this field is used its content will be
concatenated to that of the item (szItemID) to form the name of the item
szItemID String of characters referencing the item.
bActive indicates the state of activation of the item at the time of its creation.
hClient Reference handle of point for the client.
dwBlobSize the "blob" mechanism is not used by the OPC server.
pblob the "blob" mechanism is not used by the OPC server.
vtRequestedDataTyp e
Type of variant requested by the client. The value VT_EMPTY designates the default type (decided by the server).
Woodhead
Woodhead
Notes
When a new item is added to a group using the method AddItems, the OPC server automatically determines the canonical type of the variable and returns it in the field vtCanonicalalDataType of the structure
OPCITEMRESULT.
If there is no specific requirement, it is thus recommended that the client application should always pass the value VT_EMPTY in the field
vtRequestedDataType, thus allowing the server to determine itself the
type of the variable .