13.1 Do not write any code for OPC failure recovery
As described in FAILURE RECOVERY, problems in communications with target OPC server are automatically recognized, and the component performs the recovery automatically. Attempts to duplicate this functionality in your code will interfere with this mechanism and won’t work.
It is fine (and indeed, suggested) to catch the errors and handle them appropriately. But the error handling should not include attempts to remedy the situation.
And the referred chapter:
12.12 Failure Recovery
The OPC communication may fail in various ways, or the OPC client may get disconnected from the OPC server. Here are some examples of such situations:
• With OPC Classic, the OPC server may not be registered on the target machine – permanently, or even temporarily, when a new version is being installed.
• With OPC UA, the OPC server may not be running or registered with the discovery service on the target machine – permanently, or even temporarily, when a new version is being installed.
• The (DCOM, TCP, Web service or other) communication to the remote computer breaks due to unplugged network cable.
• The remote computer running the OPC server is shut down, or restarted, e.g. for security update.
• The configuration of the OPC server is changed, and the OPC information (item in OPC Classic, node and attribute in OPC UA) referred to by the OPC clients no longer exists. Later, the configuration could be changed again and the OPC item may reappear.
• The OPC server indicates a serious failure to the OPC client.
• The OPC Classic server asks its clients to disconnect, e.g. for internal reconfiguration.
QuickOPC handles all these situations, and many others, gracefully. Your application receives an error indication, and the component internally enters a “wait” period, which may be different for different types of problems. The same operation is not reattempted during the wait period; this approach is necessary to prevent system overload under error conditions. After the wait period elapses, QuickOPC will retry the operation, if still needed at that time.
All this logic happens completely behind the scenes, without need to write a single line of code in your application. QuickOPC maintains information about the state it has created inside the OPC server, and re-creates this state when the OPC server is disconnected and then reconnected. In OPC Classic, objects like OPC groups and OPC items are restored to their original state after a failure. In OPC UA, objects like OPC subscriptions and OPC monitored items are restored to their original state after a failure.
Even if you are using the subscriptions to OPC items (in OPC Classic) or to monitored items (in OPC UA) or events, QuickOPC creates illusion of their perseverance. The subscriptions outlive any failures; you do not have to (and indeed, you should not) unsubscribe and then subscribe again in case of error. After you receive event notification which indicates a problem, simply stay subscribed, and the values will start coming in again at some future point.
Second: "Setting a pointer to NULL" may or may not be correct, it depends on the kind of pointer you are using, and whether you have other pointers to the same thing. Simply setting a regular pointer to NULL does nothing to EasyOPC, the component wouldn't even know about it. What is needed is that all references to it are released (using the IUnknown::Release() method), this is a general COM rule. How this is achieved - the component does not care. If, for example, you are using smart pointers and using them correctly, then yes, setting them all to NULL would be the right way of disposing the object.
Third: It is recommended that you explicitly unsubscribe, before disposing of the component. You can use EasyDAClient.UnsubscribeAllItems(), or EasyAEClient.UnsubscribeAllEvents().
But we have encountered another problem (do not know if we should create a new topic).... if the OPC Server shutsdown, for some reason, we try to cleaup the connection to the OPC server by unsubscribing both our DA and AE subscriptions and make unadvise.
After that the OPCDA and OPCAE pointers are set to NULL. When we try to reconnect to the OPC Server we sometimes hangs in the SubscribeMultipleItems (OPC DA) or in the SubscribeEvents methods. More often the SubscribeEvents method. The only alternative is to shutdown our OPC Client and restart it, then everthing works ok. Have you encountered this kind of problems before?
What is the correct way to unsubscribe an AE/DA subscription? Could that be a problem when we try to recreate the OPC Connection and subscriptions?
I have downloaded version 5.31. As I understand it I do not have to worry about the .Net Framework version? The production system is running 3.5 and the customer will not change it until the production system is upgraded, but since I am using the COM interface it is not an issue.
How do I recieve a 30-day trail license? Can you send one to my mailadress? Is it posssbile to run the licenese on several machines since it is a redundant system with two OPC client machines?
We have had similar issue, but not directly related or "triggerable" by connectivity losses.
The trial gives valid data for 30 minutes since the process (EASYOPCL.EXE in your case I believe) starts; after that, it gives an error instead. We can give you say 30 day evaluation license that has no limitation other than the absolute end date, - let me know if you need it then.
Have you come across this type of error in earlier versions? I forgot to tell you that it is a Windows 2008 R2 64 bit machine that is running the OPC Client and server.
I will try to rebuild the application with the new version. If I download the new SKD from the download section does it work 30 minutes before I have to restart my application or is it 30 days?
My suggestion is that you rebuild your application with the latest version, and re-test. If it resolves the problem, I will get you an extra good deal on the version upgrade, not the usual 50% of the new license price. If switching to the newest version does not resolve the problem, we will be in better position to troubleshoot further (although not an easy position either, unless we can reproduce it here).
I have created an application that uses both the COM-DA and Com-AE sdks from you. The application connects to the OPC Server locally ie on the same machine, and creates a DA subscription on approx 7000 items.
When the machine experience network loss due to switch breakdown (we simply unplug the cable) sometimes my application crashes and generate the following entry in the event log: (It might be that the OPC Server behaves badly, but I do not want my application to crash).
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Your version of the easyopcl.exe is 5.11.355.2.
This is happening in an production environment so debug is not an option. I have tried to log the exection but can not find anything to go on. Do you have any suggestions?
Update: Both Microsoft Visual C++ 2005 Redistributable 8.0.61001 and
Microsoft Visual C++ 2010 x64 Redistributable 10.0.30319 are installed on the computer.