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.