OPC Classic Development Toolkits
Licensing Model of the OPC Classic Development Toolkits
The installation package of Softing's OPC Toolkit V4.4x may be downloaded and used freely by anyone. By default, the installer will install and set up the base demo package. This may be used for OPC application development. The base demo package contains a fully functional OPC Toolkit core (OTB.dll, OTBx64.dll), which will run in demo mode, unless a proper license is activated. The only limitation the demo mode contains is a 90 minutes run time limitation. After exceeding 90 minutes of runtime, the OPC Toolkit will stop working and a message box notifying the user will pop up.
The Toolkit contains 6 components and each of these components can be activated individually, by providing the proper license key:
- OPC Server DA - Data Access Specification V1.0a, V2.05 and V3.0
- OPC Server XML-DA - XML Data Access Specification V1.01
- OPC Server AE - Alarms and Events Specification V1.10
- OPC Client DA - Data Access Specification V1.0a, V2.05 and V3.0
- OPC Client XML-DA - XML Data Access Specification V1.01
- OPC Client AE - Alarms and Events Specification V1.10
There are 3 licensing models available for the Toolkit components mentioned above:
- Run Time License
- Binary License
- Source Code License
Note: For each licensing model Softing provides a different key type and the key will not work for another licensing model.
Note: The licensing modes described above are completely independent of each other.
Note: It is not possible to use different licensing models at the same time. I. e. it is not possible to activate different components using different licensing models.
Run Time License:
A Run Time License cancels the 90 minutes limitation of the OPC Toolkit core, by means of Softing's License Manager (Softing's License Manager must be installed in order to be able to activate the components using this license model). This license may be required for the pre-production phases of development - e.g. load and endurance testing and for deployment. The OPC application that has been developed must be deployed together with the Softing's License Manager and a Runtime License key in order to use this licensing model. This type of license is bound to a specific PC and cannot be transferred to another PC.
Using the license model requires that the license key is provided by your OPC application. I. e. an activation method must be called in the OPC application, where the component that needs to be activated and the proper activation key are specified. This type of license is not bound to a specific PC and can be transferred to another PC.
Sample code in C# for DAClient:
// Activate your OPC Client license
Source Code License:
Provides full source code of the OPC Toolkit and enables the user to compile his own activation free version of the OPC Toolkit Core. Activation of the Source Code License key must be done within the Softing License Manager. On activation the source code for the activated components/features will be installed/extracted on your machine. A detailed description of how to enable the source code license can be found in the Toolkit documentation under "Compiling the OPC Toolkit core" article.
Note: Updating an existing OPC development project with a patch will cause OTBcfg.h and OTB.cpp to be overwritten, so license activation will have to be done again.
Note: It is possible to activate several components at the same time. The code for the purchased components will be merged into an OPC Toolkit containing all the licensed features/functionalities. E.g. it is possible to have a Toolkit core that has Server DA, Server AE and Server XML-DA functionalities.
Error message: Could not load file or assembly "OpcRcw.Dx"
This error message is caused by missing or incorrectly installed OPC core components (OpcRcw is a class of the core components).
To solve the problem, please uninstall the OPC core components (if they are already installed) and then reinstall them.
The installer can be found in the /Retail/OPC folder on our installation DVDs or as a download on the website of the OPC Foundation under → Resources → Samples/Code → Classic → Core Components (https://opcfoundation.org/developer-tools/developer-kits-classic/core-components/).
The server developed using the OPC Toolkit is launched more than once
The server developed using the OPC Toolkit is launched more than once (e.g. by the Explorer and additionally by an OPC client).
This is a common DCOM problem. The OPC server is launched by different users (User / System). You can solve the problem by editing this server setting under Start / DCOM Settings. If the OPC Server is installed as a service, you can also edit the setting by selecting Control Panel → Services → Properties of the server → Launch the service as “This user.” In this case, the user has to be assigned a password.
Developed programs indicate “Demo Mode” although the OPC Toolkit has been activated
You need to enter the DesigntimeKey (Binary Key) in the source code (“Activate” method). Please have a look at one of the provided samples that demonstrate how to invoke this method.
I want to debug, but the debug DLLs (xxxd.dll) are missing
If you want to debug into the OPC Toolkit, you will need the debug DLLs (xxxd.dll), which are not included with the Toolkit:
- Tbcvs20xxd.dll (for c++)
- TBNxx.dll (for .NET, here without “d”)
Softing supplies only the release versions of the DLLs because the debug DLLs need to be created by the developers themselves. For this purpose, the Toolkit folder provides the appropriate projects, which you can open and compile in the desired version.
To debug, both DLLs used (API + core) need to be loaded into your project in the debug versions.
Results in the otbd.dll. This is the OPC Toolbox core.
Results in the TBCVS20xxd.dll. This is the C++ API.
Results in the TBNxx.dll. This is the .Net API.
Please also have a look at the help topic “Installation → Compiling the OPC Toolbox Core” and read the FAQ “What settings do I need for debugging the OPC Toolkit?”
What settings do I need for debugging the OPC Toolkit?
- You need to compile the OPC Toolkit yourself (see help topic “Installation -> Compiling the OPC Toolbox Core”).
- For .NET:
- Uncomment the “otbud.dll” in the “OTBFunctions.cs” file.
- In the .NET project, check the “Enable unmanaged code debugging” check box.
- TBN and OTB both have to be debug versions.
- For C++:
- In the Project Linker -> input -> specify the debug dll (otbd.dll).
- TBC and OTB have to have the same version (debug).
- Open the process explorer and check whether the correct DLLs are loaded.
The installed OPC server is invisible to OPC clients
You have developed an OPC server and installed it on a different computer. Now OPC clients cannot see this OPC server.
- The OPC core components have to be installed on the target computer, as well. Please open the task manager and check if the “OpcEnum.exe” process is running. If it isn't, you can download these components from www.opcfoundation.org and install them.
- The OPC server has to be registered on the target machine:
- Check whether the DCOM settings have been correctly configured. Please ask for our DCOM brochure or use our EasyConnect software that helps you avoid DCOM problems.
- The OPC server has to be launched by the correct user.
If the OPC server is registered as a service, the user under whose account the OPC server is started as a service still has to be configured. (Control Panel -> Administration Tools -> Services -> MyServer -> Properties -> Log On tab. Here, change the settings from “Local System account” to “This account”, select the user and assign a password.)
Error code: “0x80004002 (E_NOINTERFACE)” when calling DaSession.write or DaSession.Read
The “0x80004002 (E_NOINTERFACE)” error code is output if DaSession.write or DaSession.Read is called.
Read / Write operations on a session are only possible if the OPC server you are using supports the OPC Specification DA3. The above error code indicates that your server might only support DA2. In this case, please use only Subscription.read / Subscription.write or Item.read / Item.write.
When starting .NET projects on 64-bit systems, an error message appears
When a project is started on a 64-bit system, an error message like the following is displayed:
Failed to load TBN40.dll.
This problem is caused by a project setting in VisualStudio (Project settings -> Build -> Platform Target). If it is set to “AnyCPU” on a 64-bit system, the 64-bit version will be loaded. This will lead to an error because the Toolkit only supports 32 bits. Please change the setting to “x86” and recompile the project. In addition, open the API project (c:\Program files\Softing\OPCToolbox\V43x\Windows\NET\src\OPCToolboxNET_VS20xx.csproj), check the setting and, if required, compile all the versions of the API DLLs (Batch Build).
Installers created in VisualStudio do not work as they should
The project runs without problems on the development computer, but does not work when installed on a different computer.
The installation of an OPC project generally requires 2 DLLs from the Toolkit (TBx.dll and OTBx.dll), see online help under “Installation -> Installation of the created OPC-Application.”
If an installation is generated in VisualStudio, VisualStudio automatically detects the dependence on the TBx.dll, but unfortunately does not detect the dependence on the OTBx.dll, which depends on the TBx.dll.
Therefore, this DLL has to be manually added to the installation project.
Project does not accept DesignTimeKey (Binary Key) any longer
The project runs without problems on the development computer, but fails to detect the license (shuts down automatically or runs only 90 minutes) when installed on a different computer.
Occurs after updates to the Toolbox (4.2x -> 4.3x as well 4.xx -> 4.4x). As the OTxx.dll is not detected automatically during generation, it has to be manually added to the installation. When the Toolkit is then updated, this DLL needs to be changed. Please check that all the DLLs of the installation use the correct versions of the two DLLs.
The Demo Client subscriptions can connect to a remote Server, but the OPC Client project cannot
An OPC Client application created with the Toolkit cannot connect subscriptions and items to an OPC server, but the Demo Client can connect and the cyclic data exchange works without any problems.
In the majority of cases, this problem is caused by the DCOM security settings. Preferably, they should be checked and corrected first. The subscriptions mechanism requires the server to create DCOM call-back connections in the client, therefore the client have DCOM setting configured to accept the remote access.
The difference in behaviour between the two applications lies in the existence in the Demo Client of a special fall-back mechanism that allows the client to actively poll the server’s items when the subscription failed. This poll is done using OPC session read requests at regular interval defined as subscription’s update rate. Because of this the transparent behaviour, one can draw the wrong conclusion that the subscription based cyclic data exchange work fine and no DCOM security issue exists.
The developed OPC Server doesn’t terminate
You have created an OPC Server using the Softing OPC Toolkit. The developed OPC Server can be started by the OPC client but the Server does not exit when the Client closes the connection.
To terminate the OPC Server, you have to implement the method OpcServer::Shutdown in your code. The shutdown event is triggered by the Toolkit when the last OPC client disconnects. Inside that method you have to implement the code, which closes your application.
Installation of the OPC Application on a target machine
Please read the following application note:
Communication with Rockwell OPC Servers fails
The Softing OPC Toolkit Classic SDK/CDK V4.4x support principally all OPC Data Access Specifications: V1.0a, V2.05 and V3.0
Please note: some of the Toolkit methods (such as DaSession..::..Read, DaSession..::..Write) may be used only for the servers that support XML-DA or DA V3.0. For the servers that support only DA V2.0 or below, the method returns an error code indicating that the operation is not supported. In this case the Read / Write method of the DaSubscription class should be used.
This example shows how to synchronously browse a Data Access Server's address space. The example can be used for browsing the Data Access servers that support Data Access V2.0 or less as well as the ones that support XML-DA V1.0 OPC specification. To support interoperability, a workaround that hides erroneous behaviour of servers created with the Rockwell Toolkit can be activated. Therefore, the ForceBrowseUp property (.NET) / setForceBrowseUp() method (C++) has to be set to (.NET) / called with (C++) "true" before each call of the browse method.
This example shows how a client can inform itself of OPC servers that support Data Access or Alarms and Events Specifications and are located on the local computer or on other remote computers. The found servers will be grouped accordingly to the OPC specification they support. (DA_V1.0, DA_V2.0, DA_V3.0 or AE_V1.0) For each found server the following information will be given:
- the server's description
- the server's CLSID
- the server's ProgID
- the server's version independent ProgID
Selecting a server will determine its URL to be displayed in the TextBox control from the bottom of the page. The operations are executed synchronously.
How to enable the Toolkit traces
The trace files are used by the Toolkit to log debugging purposes messages.
The tracing mechanism can be enabled through the EnableTracing method on the Application Object. For e.g.
The OPC Toolkit distinguishes 4 trace levels:
For each level, you can specify the trace output that is to be written.
The specified file name ( here “Trace.txt”) is basis for forming trace file names. Trace outputs are written alternately to two files. These are called "Basis"_currentA.log and "Basis"_currentB.log. Once the maximum size has been reached for one file, the other file is used.
If trace backup files are configured then instead of being overwritten when the server is restarted, old trace files are stored as backup copies until this number is reached. The backup copies are stored in the same directory as the "Basis"_currentA/B.log files and are named "Basis"_backup#X.log, where X = 1 .. number of log copies.
Advanced DCOM settings are necessary from the version 4.4x
The OPC Security has been changed in the latest version of the Softing OPC Toolkit V4.4x and it effects all operations. Please read the "Installation" -> "DCOM Configuration" chapter from the Toolkit Documentation for better understanding the new workgroup/domain-enabled DCOM security scheme.
Given the new security settings, connections to different domain/workgroup are not allowed by Microsoft Windows DCOM unless CoInitializeEx and CoInitializeSecurity are issued in the customer application before initializing the Toolkit (so that the DCOM security is already initialized when the Toolkit initializes).
These DCOM security settings are however not part of our scope since the DCOM is a service of the Microsoft Windows operating system.
The developed OPC Server restarts automatically when an OPC Client is connected to it.
The OPC Classic uses DCOM as base communication technology between the OPC Clients and OPC Servers.
DCOM has a special functionality that enables the OPC Clients to verify if the Server's process is already started and if so to just connect to the already started process.
If the process is not started, the Client will just start the OPC Server in a new process. This mechanism is independent on the OPC technology. In order to change this behaviour, the user needs to tune the DCOM settings of the PC.
The reported behaviour is valid, and is actually the intended behaviour in many automation use cases.
- OPC Client connects to an OPC Server
- the client has a reconnection mechanism activated that detects when the connection is broken and will just reattempt a connection
- Server shuts down (gracefully)
- Client detects the connection break and will trigger the reconnection mechanism (attempts a session)
- Server gets started by the DCOM intrinsic mechanisms described above
If you want to keep the server stopped, you must make sure that there is no instance of a client attempting to reconnect (like described in the above mechanism). There is no straight forward mechanism that prevents the server to be started via DCOM from a Client.
OPC Server shuts down when there is no OPC Client connected.
Normally this is the expected behavior of a server when it was started by a client via DCOM.
If this is not desired, you can change the implementation of the handleShutdownRequest() callback so that the process running the OPC Server is not terminated.
In our Console example application I would just leave the implementation of handleShutdownRequest() empty. E.g.:
long API_CALL handleShutdownRequest(void)
} // end HandleShutdownRequest
This callback is triggered by the toolkit to inform the application that no clients are connected anymore. The active action of shutting down the OPC server is done by the application though.
Server's address space elements creation performance optimization
In order to improve the performance of managing the address space elements within a server, especially the user can choose the following setting.
This will change the internal method of storing the address space from lists to maps.
The benefit is that the access to the elements is faster, but the disadvantage is that the order of the elements cannot be controlled by the user. For the user this means that when browsing the address space the order of the items is different than the order of definition of the elements and the client needs to sort this out.
Server redundancy mechanism
The Softing OPC Toolkit does not have implemented a server redundancy mechanism (warm/cold/hot).
However, it provides the required means for detecting the communication failure condition and its flexibility allows fast switching of the active session, should the server be redundancy prepared. In the case the server does not offer more than one interface, the connection monitor will reconnect the objects automatically.
You only have to implement the "handleStateChangeCompleted" (C++ callback) or "StateChangeCompleted" (.NET event) and take the appropriate actions when such a callback or an event is triggered by the Toolkit CORE with the new State being disconnected.
Depending on the situation, we recommend either create two different trees of sessions-subscriptions-items at startup, activate one and connect the other (warm redundancy). When the active session would fail, then activate the other session (if it`s not the case for both to be down) and use it as required. When the first session recovers, then park it in the deep connected state.
There is very much flexibility in the Toolkit and it allows you to implement various standard/custom redundancy mechanisms.