02-10-2014 02:58 AM - edited 02-10-2014 03:09 AM
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.
02-14-2014 04:11 AM
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.
10-06-2014 12:33 PM
So, it is impossible to connect to OPC servers using LabVIew 2013 64bit?
10-06-2014 01:40 PM
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.
10-06-2014 07:09 PM
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).
10-06-2014 09:12 PM
@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?
10-07-2014 05:31 AM
The application that needs to communicate via OPC is also performing various memory intensive operations (vision, motion, data processing).
10-07-2014 06:33 AM
Now I see why you split the thing in two. That's pretty sly. 🙂