Can I call 32-bit subVIs from 64-bit VI (or vica versa) in LV 2011?

[BradNC]

Howdy--

I realize my question probably stems from my limited understanding of LV's underlying architecture, but it arises as I am planning for the following scenario in my lab:

(1) The system will consist of a 64-bit PC running 64-bit Windows 7 (Professional) with 24 GB of RAM.  One or more cRIO devices will be attached as needed.

(2) All LabView software will be written and executed on the 64-bit machine (excepting that operating on the cRIO devices).

(3) At certain times within an overall automated test sequence, a high speed digitizer will be required to stream ~10 GB of data to memory, analyze it, and write the results to disk (hence the need for 64-bit).

(4) At this point I cannot say for sure what, if any, of the various Add-ons and Toolkits available might prove to be useful for us (hence the desire for 32-bit compatibility).

Naively, the above points suggest one of two overall approaches to writing my control and measurement routines:

(a) Write everything in 32-bit LV, with some specialized call to a 64-bit subVI where needed.

(b) Write everything in 64-bit LV, with specialized calls to 32-bit subVIs where needed for compatibility reasons.

So, are either (a) or (b) possible, and if so, are there reasons to prefer one approach over the other?  Any pointers, or links to relevant reading, would be much appreciated.

Thanks all for your time, and have a great day.

[smercurio_fc]

A 32-bit app cannot load a 64-bit DLL into its process space, and a 64-bit app cannot load a 32-bit into its process space. At least not directly. You need a special interface layer to do so. See here: http://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

So, the bottom line is that if you're going to be using 64-bit OS and 64-bit LabVIEW, unless you want to diddle with IPC, you will need to make sure that everything else you need to touch is 64-bit.

[BradNC]

Hmmm, well, that does look a little hairy, but I'll definitely keep it in mind as I look at how to proceed.  Am I write that this amounts to roughly the same thing as using a LV Shared Variable between two concurrently running VIs?  I suppose if that's the case, I could always use the System Exec VI in combination with a Shared Variable to roughly (very roughly) emulate a subVI call if necessary.

Thanks a bunch for the reply and the good link.

[smercurio_fc]

I'm not sure I understand what you are asking. You said "this amounts to roughly the same thing as using a LV Shared Variable between two concurrently running VIs". What is "this"?

[crewex]

I thought b was possible.....

[dkfire]

Just to be clear, are we talking about dll or pure vi's ?

There are as difference. VI's are code, and only code, every time you run a vi in LabVIEW, the development system will compile the vi to be able to run it. A vi is not locked to 32 or 64 bit, like a c file ( text file ) is not locked to 32 or 64 bit. 

But when you compile the vi to a exe or dll file, then your compiled program get locked to 32 or 64 bit, depending on what you compiled it on. 

smercurio_fc correct me if i'm wrong. 

What is, by the way, "some specialized call to a 64-bit subVI" ?

[smercurio_fc · Accepted solution]

That's correct, and is a better phrasing of what I was saying. Essentially, once you've compiled the app you're done - you've set the bitness. I assumed the OP was talking about the VIs call external DLLs, but it's not entirely clear.

[tst]

---

@dkfire wrote:

VI's are code, and only code, every time you run a vi in LabVIEW, the development system will compile the vi to be able to run it.

---

There is an important point which needs to be made here. VIs are NOT only code. They consist of both the diagram and the machine code. These days the machine code can be saved outside the VI file (and as time goes on this will probably become the default), but VIs are still compiled individually.

This doesn't really matter much if you're building a monolithic application or if you're building DLLs, because that should force the machine code to be saved as part of the file, but it does matter if you try to load and run a VI file directly from an executable.

[BradNC]

Thanks all for your replies...you've helped me understand the issue a little better.  With that, I think I can clarify my original question with a few points of context:

--I used the term "Write" in my original post, where I should have said "Compile" for the VIs I will be creating.  That was particularly poor wording in this case (sorry).

--I'm an intermediate level LV user writing VIs for experimental control and DAQ in a lab I work in.  I've never messed with DLLs, and probably won't need to for now.

--The need for a large addressable memory space for a particular digitizer is forcing the 64/32 bit issue on me for the first time.  I'm building all new VIs from scratch here, and while planning to work entirely in 64-bit LV makes integrating the digitizer with other routines simple, it cuts me off from what currently seems to be LV's native supported architecture (32-bit, where all the add-ons, etc. can be used).

My original question (perhaps also not worded well), and vague statements about "some specialized call...", point to the issue I'm trying to understand here, which is:

--What are my options (if any), for interacting with 32 or 64 bit LV VI's where necessary if my overall application is compiled in the other architecture (64 or 32 bit)?--

If I'm reading everyone right, the answer seems to that there are no real good options, but I want to make sure I understand the issue correctly before I start writing new code.

Thanks again to everyone for your time.

[Jesse_D]

Hi bcro, 

Most of the labview drivers have native support for 64bit. It sounds like you can install both 32 bit and 64 bit on the same machine, then program your fpga in 32 bit and read your data in 64 bit labview.

If you start needing more features you can just open your 64bit project in 32 bit and continue working, but at this point you knock your accessible ram down to 3 gbtes max.