OPC DA 2 cheat sheet in .NET
The other day I had to tinker with setting up a call to a remote server using the OPC DA 2.05a protocol, and this information would be very useful if I knew it in advance.
In the general case, OPC is a set of open protocols that regulate the interaction between various automation objects, such as SCADA systems, for example. OPC DA (Data Access) is one of these protocols, it provides data exchange with devices or software components. In my case, according to this protocol, it was necessary to periodically collect data from the SCADA system. And the most important thing is that OPC DA works on the basis of COM technology, so that interaction with the OPC server is essentially reduced to interaction with the COM server.
They are called OPC .NET API 2.00 Redistributable - they cannot be downloaded just like that, you need to be a "membrane" (= register and enter some money). In the same place and OPC Core Components on which this library depends. On the rutreker, you can find both. In general, it is not entirely clear why to get a library from the Opc Foundation - a company that promotes an “open standard” - you have to pay something.
What can I say about this library. There is no documentation for it anywhere, and the API is not built in the best way (for example, there are several interfaces and classes with the same name, but in different namespaces, it is terribly inconvenient, you constantly need to go to the Object Browser and see which class is needed) However, the functionality is full - you can do anything you like, which can only be done with OPC servers. By the way, for convenience, I drove the assemblies with a reflector and worked with the source code - all problems of decompilation, by happy coincidence, arose in other protocols (OPC AE, OPC HDA) and I simply threw them away as unnecessary. I can send a solution, if anyone is interested, write.
')
Paid components (and very expensive). I downloaded the Evaluation version - the installer, which demanded a password (!), But the password came by mail. The most useful component in this set is test clients for OPC — winforms applications that allow you to try to connect and see what is inside the OPC server. I did not look at the libraries themselves, they are obfuscated and they have a time limit of half an hour, then the program must be restarted. But I fumbled with the test client for a long time, since I had a 64bit system, and the test client build, as it turned out, was built under Target Platform = AnyCPU, and in 32bit Windows it was launched as a 32bit application (and everything worked as it should), and in 64bit one - as 64bit. That led to an error in the COM interop code like "CLSID is not registered". And I thought that I had something wrong configured and killed 2 days for digging into secpol.msc, dcomcnfg and compmgmt.msc. By a lucky chance, I guessed to start the client from another car and everything became clear. Using ILDASM and a Hex editor, I determined the TargetPlatform flag offset (from the beginning of the CLR Header), added the second bit 32BITREQUIRED, and it all worked. Conclusion - if COM Interop is not working for you, first check the platform for compliance. By the way, the client was also obfuscated (using SmartAssembly), and its CLR Header was located at the end.
The library from the enthusiast on codeproject.com. I can not say anything, but it was her code that was used by my predecessor, who implemented local interaction with the OPC server. Judging by what is written in the article, it is intended for local interaction. Pluses - available sources, test client availability, no dependencies.
In principle, there is nothing difficult about this if you have had experience with COM / DCOM applications. And for those who, like me, do not really understand these technologies, I can recommend writing code, looking at the decompiled source of the library from the OPC Foundation. In fact, to interact with the OPC server, all you need to do is interop on the required interfaces, get them and pull methods.
- The test client does not connect with an RPC server error is not available - check the availability of ports, port number 135 at a minimum (primary DCOM port).
- Access Denied - will have to tinker with setting up both the server and the client. See the links below.
- CLSID is not registered - check if you have Core Components installed, perhaps there are not enough of them. Or, check the Target Platform of the interop assembly. Maybe there AnyCPU should be x86.
- CoCreateInstanceEx returns a valid COM object, but when casted to COM interfaces, Access Denied (0x80070001) falls out. I spent half a day with this problem. This thing happens when you need to specify a user and password to access the server. You call CoCreateInstanceEx by filling in a SERVER_INFO before this, and you get a reference to the object. However, the following QueryInterface calls do not save the access parameters that you specified when getting the object, and this results in Access Denied. The solution is to call the magic function CoInitializeSecurity, which sets default security parameters for COM calls. Code:
When calling this function, an error RPC_E_TOO_LATE may occur. This error usually occurs because of the Visual Studio host process, which implicitly calls CoInitializeSecurity on startup. To solve the problem, simply disable the use of the host process in the project settings.
On this issue there are several links with useful information:
How people with stackoverflow helped myself figure it out
Ready interop functions with remarks
Mayrosoft offers from developers on this issue.
OPC Training Institute - a site with many well-designed articles that help in case of problems. For example, how to configure DCOM, what possible causes of an RPC error server is not available and so on. Requires registration, registration is free.
Tutorials on DCOM configuration - another 1 well-designed tutorial for tuning.
1. What is OPC DA and in particular OPC DA 2.05a
In the general case, OPC is a set of open protocols that regulate the interaction between various automation objects, such as SCADA systems, for example. OPC DA (Data Access) is one of these protocols, it provides data exchange with devices or software components. In my case, according to this protocol, it was necessary to periodically collect data from the SCADA system. And the most important thing is that OPC DA works on the basis of COM technology, so that interaction with the OPC server is essentially reduced to interaction with the COM server.
2. What are the libraries
Binaries from Opc Foundation
They are called OPC .NET API 2.00 Redistributable - they cannot be downloaded just like that, you need to be a "membrane" (= register and enter some money). In the same place and OPC Core Components on which this library depends. On the rutreker, you can find both. In general, it is not entirely clear why to get a library from the Opc Foundation - a company that promotes an “open standard” - you have to pay something.
What can I say about this library. There is no documentation for it anywhere, and the API is not built in the best way (for example, there are several interfaces and classes with the same name, but in different namespaces, it is terribly inconvenient, you constantly need to go to the Object Browser and see which class is needed) However, the functionality is full - you can do anything you like, which can only be done with OPC servers. By the way, for convenience, I drove the assemblies with a reflector and worked with the source code - all problems of decompilation, by happy coincidence, arose in other protocols (OPC AE, OPC HDA) and I simply threw them away as unnecessary. I can send a solution, if anyone is interested, write.
')
Components from Advasol
Paid components (and very expensive). I downloaded the Evaluation version - the installer, which demanded a password (!), But the password came by mail. The most useful component in this set is test clients for OPC — winforms applications that allow you to try to connect and see what is inside the OPC server. I did not look at the libraries themselves, they are obfuscated and they have a time limit of half an hour, then the program must be restarted. But I fumbled with the test client for a long time, since I had a 64bit system, and the test client build, as it turned out, was built under Target Platform = AnyCPU, and in 32bit Windows it was launched as a 32bit application (and everything worked as it should), and in 64bit one - as 64bit. That led to an error in the COM interop code like "CLSID is not registered". And I thought that I had something wrong configured and killed 2 days for digging into secpol.msc, dcomcnfg and compmgmt.msc. By a lucky chance, I guessed to start the client from another car and everything became clear. Using ILDASM and a Hex editor, I determined the TargetPlatform flag offset (from the beginning of the CLR Header), added the second bit 32BITREQUIRED, and it all worked. Conclusion - if COM Interop is not working for you, first check the platform for compliance. By the way, the client was also obfuscated (using SmartAssembly), and its CLR Header was located at the end.
OPCDOTNET library
The library from the enthusiast on codeproject.com. I can not say anything, but it was her code that was used by my predecessor, who implemented local interaction with the OPC server. Judging by what is written in the article, it is intended for local interaction. Pluses - available sources, test client availability, no dependencies.
3. Can I write code without using libraries?
In principle, there is nothing difficult about this if you have had experience with COM / DCOM applications. And for those who, like me, do not really understand these technologies, I can recommend writing code, looking at the decompiled source of the library from the OPC Foundation. In fact, to interact with the OPC server, all you need to do is interop on the required interfaces, get them and pull methods.
4. Problems
- The test client does not connect with an RPC server error is not available - check the availability of ports, port number 135 at a minimum (primary DCOM port).
- Access Denied - will have to tinker with setting up both the server and the client. See the links below.
- CLSID is not registered - check if you have Core Components installed, perhaps there are not enough of them. Or, check the Target Platform of the interop assembly. Maybe there AnyCPU should be x86.
- CoCreateInstanceEx returns a valid COM object, but when casted to COM interfaces, Access Denied (0x80070001) falls out. I spent half a day with this problem. This thing happens when you need to specify a user and password to access the server. You call CoCreateInstanceEx by filling in a SERVER_INFO before this, and you get a reference to the object. However, the following QueryInterface calls do not save the access parameters that you specified when getting the object, and this results in Access Denied. The solution is to call the magic function CoInitializeSecurity, which sets default security parameters for COM calls. Code:
[DllImport("ole32.dll")] private static extern int CoInitializeSecurity(IntPtr pSecDesc, int cAuthSvc, SOLE_AUTHENTICATION_SERVICE[] asAuthSvc, IntPtr pReserved1, uint dwAuthnLevel, uint dwImpLevel, IntPtr pAuthList, uint dwCapabilities, IntPtr pReserved3); public static void InitializeSecurity() { int errorCode = CoInitializeSecurity(IntPtr.Zero, -1, null, IntPtr.Zero, 1, 2, IntPtr.Zero, 0, IntPtr.Zero); if (errorCode != 0) { throw new ExternalException("CoInitializeSecurity: " + GetSystemMessage(errorCode), errorCode); } } When calling this function, an error RPC_E_TOO_LATE may occur. This error usually occurs because of the Visual Studio host process, which implicitly calls CoInitializeSecurity on startup. To solve the problem, simply disable the use of the host process in the project settings.
On this issue there are several links with useful information:
How people with stackoverflow helped myself figure it out
Ready interop functions with remarks
Mayrosoft offers from developers on this issue.
5. Related Links
OPC Training Institute - a site with many well-designed articles that help in case of problems. For example, how to configure DCOM, what possible causes of an RPC error server is not available and so on. Requires registration, registration is free.
Tutorials on DCOM configuration - another 1 well-designed tutorial for tuning.
Source: https://habr.com/ru/post/132780/
All Articles