Problems writing values to OPC server using OPC Foundation Classic Core Components .NET API

[banksey255]

I am using LabVIEW 64-bit and trying to interface with an OPC Server using the OPC Foundation Classic Core Components .NET API (I have not identified any other suitable approaches: LabVIEW 64-bit DataSocket doesn't support OPC, developing a 32-bit LabVIEW application to act as an intermediary has proven not that trivial to make robust, lots of other options involve cost, etc). I can read values from the OPC server without issue. The problem is that when I try to write values, despite no error being reported, I can see that the OPC server values don't update, and my attempts to isolate the problem have contradictory findings. That is, I downloaded Matrikon OPC Simulation Server, which apparently is widely used by developers to test their OPC clients, and when I use it to test my LabVIEW code, I find I can read and write values without problems, suggesting my LabVIEW code is ok. However, when I use MatrikonOPC Explorer or LabVIEW 32-bit DataSocket to interface with the OPC server, they are both able to write values without problems, suggesting my LabVIEW code is at fault.

I have attached my LabVIEW code. The code is a bit of a mess as I am testing different approaches and am using a disable structure to switch between alternative methods. Can anyone see what might be causing my problem?

OPC Foundation have paywalled their classic .NET API sample client source code and there seems to be a near complete lack of documentation on their .NET API. What I have implemented is based on porting the code found at the following websites:

https://iotgarage.blogspot.com/2021/02/sample-opc-client-using-opc-net-api.html

https://www.youtube.com/watch?v=yp6dUjQ7Vso

As a follow up question, if I don't wire .NET references returned by .NET invoke nodes, is LabVIEW smart enough to know to close those references, or do I have to wire them to close reference to explicitly close them to avoid memory leaks? (I know I am not closing many references at the moment).

Many thanks.

[Andrey_Dmitriev]

Just one initial question before you will proceed to the hard debugging session - why do not use Data Socket instead:

UPDATE: Ah, sorry, "LabVIEW 64-bit DataSocket doesn't support OPC", now I see.

[Andrey_Dmitriev]

Hi, its me again.

Last weekend, I was very curious about OPC support in LabVIEW x64. It could be interesting for me as well because of some potential "retrofit" upgrades ahead, where the LabVIEW-based SCADA system should be upgraded to x64, but keep the old OPC connectivity without migration to OPC UA.Anyway, I checked your .NET solution with the NI OPC Server and it works, both for reading and writing, so the issue could be with your particular server. I just cleaned it up a little bit:

But I don't like .net - based solution for some reasons and looking for alternative. One more or less acceptable implementation was found here: an open source OPC DA Client SDK/ToolKit written in C++, support both 32 bit and 64 bit.

I forked this repository, recompiled with latest Visual Studio and added very simple wrapper for LabVIEW (using DLL import wizard, very quick and very very dirty, because I haven't much time at weekend). From LabVIEW point of view it looks like this and works as well:

Attached the project (also on the GitHub), which may be will be helpful for you or for someone else (it is far far away from "production quality", but feel free to use it as starting point, if needed). In addition, C++ - based solution may be helpful for troubleshooting for deep low level debug. LabVIEW sources saved as LV2018, all DLLs and redists are included.

Andrey.

[banksey255]

Thanks for testing it, Andrey. You may be right that it is an error with the OPC server, yet it is strange that other OPC clients appeared to interface with it error free, which makes me wonder what they do differently.

Ultimately, the software that ran the OPC server had several other errors, and we were left will little choice but to develop a solution to the extent necessary to correct them, which inherently bypassed the OPC server.