data transfer from LV built exe to VI

[Hornless.Rhino]

Hi All,

Hopefully you smart people can help me out a bit.

I need to send some data (I32 arrays) from a 32bit version of LabVIEW to a 64bit version of LabVIEW.

I can't just do everything together as I'm using a combination of 32bit and 64bit dlls. The 64bit dll is necessary, and I don't have the skills to convert the 32bit dll to 64bit, as despite the code being available, its used to simplify access to other dlls, and the multiple levels of header files are doing my head in.

After looking at the options available, I thought network streaming would be the best.

This works, but I don't want the end user to have to open 2 different versions of LabVIEW simultaneously, so I though I could build an exe to do the streaming.

Looking at a previous thread (http://forums.ni.com/t5/LabVIEW/Network-streaming-stand-alone-application/m-p/3202933 ) I got exe to exe communication working, but I can't nut out how to get exe to vi communication working.

So I guess firstly, is it possible to network stream from an exe to a vi? and secondly, is there a better way?

The data won't be coming in particularly fast (about messages per second, and only a few hundred bytes of data each time), but it needs to be lossless transmission. It will also all be on the same computer.

Any suggestions?

[Sam_Sharp]

Yes, you can use network streams between an executable and a VI - it's based on TCP so it isn't dependent on the application scope (e.g. executable, development environment). I didn't know about the nuances regarding the endpoint URLs that are mentioned in the thread.

Network streams seems like a sensible way to go but there are other ways: Implement your own TCP protocol, use something like the AMC message library or look at an interprocess communication broker (e.g. MQ? ZeroMQ? etc.) - I think some of them have LabVIEW interfaces.

Shame you can't get the 32-bit DLLs to 64-bit...one of the (seeming many, for few upsides) downsides of using LabVIEW 64-bit. It means you have to have another instance of the run-time engine in memory which I would be wanting to avoid if I could but it seems like you don't have a lot of choice.

[PatrickLye]

I've never tried what you're talking about, but another option would be to install an instance Microsoft SQL Server Express and communicate through it. It is pretty simple to set up lossless communications with the right tables, but this if you can't get something else to work. I would think there is something much better available...

[Hooovahh]

Another option (that I hadn't fully explorered) is to use ActiveX.  In a built application you can output a TLB file which can be used in Windows to register similar to a DLL.  There is an option in the Application Builder for this.  Then other applications can open ActiveX references to your built EXE, then you can get and set control values of a running VI in that EXE.

[Hornless.Rhino]

---

@Sam_Sharp wrote:

Shame you can't get the 32-bit DLLs to 64-bit...one of the (seeming many, for few upsides) downsides of using LabVIEW 64-bit. It means you have to have another instance of the run-time engine in memory which I would be wanting to avoid if I could but it seems like you don't have a lot of choice.

---

Yep. Essentially I'm using the LabVIEW wrapper for wpcap which is from 2006. I can get the actual pcap dlls (which LV does like), but I have no idea to to use the LabVIEW library functions.

I definitely want to avoid have the two runtimes open if possible.

[Sam_Sharp]

Hang on, so what do you have in 64-bit LabVIEW that you don't have in 32-bit LabVIEW? The VIs (that wrap the DLL) or the DLL itself?

If your difficulty is using the Call Library Function node, then maybe we can help you with that? If you have the 64-bit VIs and the 32-bit DLL, you should be able to modify the VIs to work with the 32-bit DLL in LabVIEW 32-bit...

[Hornless.Rhino]

---

@Sam_Sharp wrote:

Hang on, so what do you have in 64-bit LabVIEW that you don't have in 32-bit LabVIEW? The VIs (that wrap the DLL) or the DLL itself?

If your difficulty is using the Call Library Function node, then maybe we can help you with that? If you have the 64-bit VIs and the 32-bit DLL, you should be able to modify the VIs to work with the 32-bit DLL in LabVIEW 32-bit...

---

Essentially I have a 64bit dll that I must use (no other option).

Luckily I've found a different set of dlls that I'm now using instead of the 32bit dlls, so everything should run nice in the 64bit version of LabVIEW without worrying about transferring data at all.