LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application built with LabVIEW can't find ni_opcua_client.dll

Well, aside from the legal issues about copying VI's from a Toolkit which has deployment license costs, there is a technical issue too.

 

Please note, my LabVIEW DSC experiences are mostly from LabVIEW 7.1 days, so I do not claim to know all the details of the current LabVIEW DSC implementation, however below is a reasonable assumption based on what I know about OPC UA in general.

 

While previous versions of OPC were build on top of OLE/ActiveX, which made it more or less impossible to use that technology on non-Windows systems, OPC UA (unified architecture) is build on web technologies and therefore is independent of a specific platform to run on. However most OPC UA implementations are still done in C(++), partly because the reference design from the OPC Foundation is done that way, and as such a specific implementation is still specific to a certain platform it was compiled for. So your LabVIEW VIs are only really wrappers for the DLL that implement the OPC UA functionality. A DLL however is compiled for a certain platform (ie. 32-bit or 64-bit Windows) and can't be copied to any other platform. So OPC UA, unlike the earlier OPC is platform independent in its technologies it uses, but a specific compiled implementation is still only executable on the platform it was compiled for.

 

Theoretically if the entire OPC UA implementation was done in LabVIEW, then one could simply copy it from any LabVIEW platform to any other LabVIEW platform but that has a lot of implications.

- For one everything the OPC UA architecture consists of would have to be reimplemented from scratch in LabVIEW, without the possibility to reuse large parts of the reference design

- Any improvement by the OPC Foundation to that reference design would have to be identified in the source code and ported over to the LabVIEW implementation

 

These two points alone are a huge undertakings, which would most likely prevent any manager to commit resources for. And the implemention in LabVIEW might have some issues with performance, since certain things are simply more easily doable in a low level language like C than in a high level language like LabVIEW, which wants to take all the hassle about memory management and much more out of the programmers hand, at the cost of higher memory usage and because of that also lower performance for low level details like massive parallel network protocol implementations.

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 18
(1,882 Views)

Thank you guys for the replies. 

 

Well, of course I will stay on the legal side. I don't think my client will appreciate it if the system I'm delivering to them has licensing issues 🙂

 

Anyway, I guess I'm out of luck then. The main and core program will be in 64-bit and there will be a small 32-bit program running in the background to handle the communication. By the way, is there a better, easier and more efficient way to communicate between 32 & 64 bit program than using TCP/IP? What are the options that I have? Can I used shared variables? I don't have access to LabVIEW at the moment to test.

 

Please advice.

 

 

0 Kudos
Message 12 of 18
(1,859 Views)

So, it is impossible to connect to OPC servers using LabVIew 2013 64bit?

0 Kudos
Message 13 of 18
(1,789 Views)

Certainly not impossible, but not as convinient than installing LabVIEW DSC and configuring some variables. There are several ActiveX and mainly .Net based OPC UA interfaces from third party providers that you can interface to from LabVIEW with a little work.

Rolf Kalbermatter
My Blog
0 Kudos
Message 14 of 18
(1,780 Views)

I ended up doing two piece of programs, one in 32-bit and the other in 64-bit. The communication via the two is done via shared variables. It works and didn't take too much of the expected time - maybe, compared to using third party OPC clients. It will be awesome if some of the DSC components to work in 64-bit - for instance, the event-triggered shared variables (vs. polling).

0 Kudos
Message 15 of 18
(1,765 Views)

@Shazlan wrote:

I ended up doing two piece of programs, one in 32-bit and the other in 64-bit. The communication via the two is done via shared variables. It works and didn't take too much of the expected time - maybe, compared to using third party OPC clients. It will be awesome if some of the DSC components to work in 64-bit - for instance, the event-triggered shared variables (vs. polling).


Curious.  Was a there a reason why you needed to use LabVIEW 64 bit?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 16 of 18
(1,755 Views)

The application that needs to communicate via OPC is also performing various memory intensive operations (vision, motion, data processing).

0 Kudos
Message 17 of 18
(1,739 Views)

Now I see why you split the thing in two.  That's pretty sly.  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 18 of 18
(1,728 Views)