LabVIEW
LabVIEW communication to a 3rd party software
Solved!
@themadgreek wrote:
Hi Paolo,
I checked that in the first place, Maestro works just fine. I am not sure what exactly is why LabVIEW does not want to communicate with the device. I will try the code you shared in a 32 bit LabVIEW and see if it works.
---------------
themadgreek
If the AX doesn't load, there's no change (0.00000%) it will communicate.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
If the com object is compiled (I think, like .NET, it doesn't need to be), a 32 bit object wouldn't work on a 64 bit LabVIEW. And vice versa.
"Despite Microsoft's previous efforts to make ActiveX cross-platform, most ActiveX controls will not work on all platforms,"
It's more complicated than this. ActiveX is based on (D)COM and a COM component is compiled binary code for a specific CPU architecture.
But the D in DCOM stands for distributed which means that a component can be invoked out of process, and even on a different computer. The parameter transfer is then done through COM marshalling either through pipes or TCP/IP streams. It's another RPC scheme in fact just like CORBA and several others.
The component is then loaded in a proxy process and method invocation is done through this COM marshalling. So far so good. In order to do that DCOM does all kinds of very nasty hooking into a processes main message loop (that is the main window message queue for a process, in the case of LabVIEW also the so called root loop and UI thread). Basically when a component is invoked out of process the call site marshals the data into a stream, passes it to this DCOM interceptor which sends it to the remote site and then waits until the response returns and then hands that off to the callsite. This works fairly well if a number of conditions are met:
- The component needs to be marked as being able to be out of process invokable. This is something the component developer needs to do and guarantee, the calling process (LabVIEW here can not do anything about that).
- The component needs to be registered accordingly in the registry for DCOM to be able to invoke it like that. In the case of 32-bit to 64-bit out of process invocation and vice versa it needs to be registered accordingly in both modes.
- DCOM security configuration is a nightmare to understand. They tried to implement tight security but made it so complicated and obscure that there is almost nobody who understands how it works. Considering that it was developed almost 30 years ago it is safe to assume that much of its security would be probably breachable by nowadays technology if anybody would still understand how it works. Its main security nowadays is most likely that it is so obscure and complicated that nobody bothers about it anymore.
- The calling application needs to serve the main message loop continuously for the DCOM marshalling to work. This means if you lock up the UI thread in LabVIEW in some way all goes bad.
The problem is that most ActiveX components are not marked multithreading safe but so called apartement threading safe as that is much easier to implement. It means that the component does not care in which thread it is executed as long as it is always the same thread. It basically means that it is not multithreading safe. The only thread in LabVIEW that can guarantee that is the UI thread and now you can see that there is a potential lockup problem here.
But it seldom gets even there. Almost no ActiveX component developer bothers to add the necessary registry keys to allow his component to be invoked out of process. It's simply to much hassle and more often than not a sure way to cause a lot of additional support calls. Even the Microsoft Office components are normally not registered like that in the system.
So while ActiveX in theory would allow to invoke a 32-bit component from a 64-bit process and vice versa, it is almost never supported by the component installer. I have experimented with registering some ActiveX components such that cross architecture invocation is possible but it is a total hassle and unless the component really is programmed and compiled to be safe to be invoked as out of process, it is a very brittle way of trying to do things.
.Net chooses a very different approach to reach architecture independent execution. While .Net assemblies can contain native compiled code and that makes them only invokable from a process with the same architecture, many .Net assemblies nowadays only contain .Net IL (Intermediate Language) code. This is the .Net bytecode that is machine architecture independent. It is a sort precompiled code but needs to be further compiled on execution through the CLR usually using JIT (Just in time) compilation where the code is compiled on first execution into the actual target architecture code. It is in a way something in between real compilation and interpretation and the same thing that is for instance also used in Java, Lua and Python. The similarity with Java isn't accidental, .Net was originally mostly a Java clone since Microsoft and Sun Microsystems didn't get along very well and Microsoft saw the potential that Java had.
@rolfk wrote:
wiebe@CARYA wrote:
If the com object is compiled (I think, like .NET, it doesn't need to be), a 32 bit object wouldn't work on a 64 bit LabVIEW. And vice versa.
"Despite Microsoft's previous efforts to make ActiveX cross-platform, most ActiveX controls will not work on all platforms,"
It's more complicated than this.
I knew that 😊. Not the details though. Glad I didn't even try to figure it out.
IIRC, often the problem with AX objects not loading was that they need to be registered, with regSvr32 filename.dll?
wiebe@CARYA wrote:
@rolfk wrote:
wiebe@CARYA wrote:
If the com object is compiled (I think, like .NET, it doesn't need to be), a 32 bit object wouldn't work on a 64 bit LabVIEW. And vice versa.
"Despite Microsoft's previous efforts to make ActiveX cross-platform, most ActiveX controls will not work on all platforms,"
It's more complicated than this.
I knew that 😊. Not the details though. Glad I didn't even try to figure it out.
IIRC, often the problem with AX objects not loading was that they need to be registered, with regSvr32 filename.dll?
WEll, that's what the installer for that object is for. It should put the ActiveX object and all its supporting libraries and documents in the (by the developer designated space on disk) perform component registration and be done with. If you just copy the component to another computer then yes it needs to be registered manually since the registry is the sole means for ActiveX to locate and instantiate objects.
But running regsvr32.exe is often not enough. It simply invokes the exported DLLRegisterServer() function from the component DLL, nothing more really. You could do that with a LabVIEW Call Library Node too. But that function typically simply registers the DLLs own location in the registry together with any other needed registry keys to tell COM/DCOM how to load the DLL when an application calls CoGetClassObject().
If the DLL depends on anything else such as other DLLs they of course need to be installed (and possibly registered) too.
It works but you need to use an ActiveX Container:
Then insert in the container the UMCBI Connection Control V2 as already explained.
This control does not need an Automation Open, just wire it to the Address property node.
EDIT: Address is not the IP address, rather the instrument number given by the MCB Configuration program; in this example is 1:
