What prevents a 32-bit developed vi or project (lvproj) containing many such vis from opening in a side-by-side 64-bit LabVIEW environment?

[altenbach]

---

@*3d0g wrote:
But now what about clicking the project or a file that is in the project, but from outside the project?  If I'm understanding you, it matters not as long as "Separate compiled code" was checked when whatever it is was created. 

---

No, it does not matter either way, even if the compiled code is stored inside the VI. That's why you can open your VI even on mac or Linux and LabVIEW will just recompile and replace that part without ever touching the diagram source code. The problem with that is that source control system will notice that all Vis have changed, leading to unnecessary updates.

The option to "separate compiled code" solves that source control problem. Unless you make real edits, the VI is considered unchanged because the compiled code is now stored externally (separately for each version and bitness) and if it gets lost, it will just be regenerated.

If you constantly switch between 32bit and 64bit for the same projects (why-oh-why-oh-why???), maintaining these separate caches behind the scenes is an huge advantage, because existing Vis will open quickly in both environment. If the compiled code is internal to the VI, everything needs to be recompiled every time you open in a different system, which can be slow when opening.

Either way is safe! I would strongly recommend not to run 64bit and 32bit LabVIEW at the same time.

[BertMcMahan]

---

@*3d0g wrote:

So, presently I'm seeing in the project that "Separate compiled code from new files" is checked.  If I'm understanding you, what you've said, with this checked at the creation of the project, either the project or any vi in the project is safe from accidently opening in the 64-bit environment LabVIEW.  Correct?

You have to set that option for each file, not just for the project.

[billko]

---

@BertMcMahan wrote:

---

@*3d0g wrote:

So, presently I'm seeing in the project that "Separate compiled code from new files" is checked.  If I'm understanding you, what you've said, with this checked at the creation of the project, either the project or any vi in the project is safe from accidently opening in the 64-bit environment LabVIEW.  Correct?

You have to set that option for each file, not just for the project.

---

For each file already in the project before you change the setting - usually accomplished through a dialog in the project properties.  For new files, it should be automatically set.

[JimB.]

---

@*3d0g wrote:

---

---

I didn't mean to quote all the above.  I'll get it eventually.  At least it isn't a huge post.

Yeah, the forum software here is pretty terrible. I more often have to open the HTML view and edit the markup here than on any other since the early 2000s. Multi-quoting is absolutely a pain.

---

@*3d0g wrote:

---

So, presently I'm seeing in the project that "Separate compiled code from new files" is checked.  If I'm understanding you, what you've said, with this checked at the creation of the project, either the project or any vi in the project is safe from accidently opening in the 64-bit environment LabVIEW.  Correct?

---

Incorrect. There is nothing at all that prevents that. What it does do is make everything contained in the VI agnostic of the operating environment. If you enable that option then the VI only contains source code. It has no bitness.

Are you familiar with text based programming at all? What is the bitness of this application?

main( ) {
        printf("hello, world");
}

That's a trick question. Nothing there indicates a bitness. The bitness of the compiled code will depend on your compiler settings. LabVIEW VIs work similarly if you turn on the option to separate compiled code. With that setting turned on, the VI is neither 32-bit nor 64-bit.

If you do not turn on that option then the VI also has compiled machine code embedded in it. That compiled code will have a specific bitness. If you create one in 32-bit and then open it in 64-bit then it will recompiled itself. The good news as that doesn't ruin the VI. When you open it in 32-bit again it will just trigger another recompilation. A number of things can retrigger recompilation actually, and you will find using that option to greatly reduce the number of times LabVIEW will prompt you to save a file that you didn't actually change anything in. I think most users turn it on if for no other reason than it plays much nicer with SCC systems.

Now, of course this is talking about the VI itself. There is no damage done by saving it in the wrong environment. Running it in the wrong environment? That mostly won't matter, but can be an issue. The most common issue will be if you are depending on a driver or DLL that is not the correct bitness. This also does not damage the VI in any way, but can generate errors while running it.

---

@*3d0g wrote:

But now what about clicking the project or a file that is in the project, but from outside the project?  If I'm understanding you, it matters not as long as "Separate compiled code" was checked when whatever it is was created.  This is your answer to me.  Or is this not correct for what you're saying?

What happens when you click on the file from outside of the project is, mostly, outside of LabVIEW's control... for the most part. It is determined by Windows' file type association. 32-bit and 64-bit LabVIEW are indeed different applications, so the project or VI will open in whichever one Windows decides to open it in. Typically, this will be whichever you last used.

If you, for whatever reason, have concern for opening the project in the correct environment, then opening the file from within the correct environment is your easiest solution.

Maybe it would help to understand why you are worried about it? What are you paranoid about happening specifically?

[*3d0g]

---

@BertMcMahan wrote:

---

@*3d0g wrote:

So, presently I'm seeing in the project that "Separate compiled code from new files" is checked.  If I'm understanding you, what you've said, with this checked at the creation of the project, either the project or any vi in the project is safe from accidently opening in the 64-bit environment LabVIEW.  Correct?

You have to set that option for each file, not just for the project.

---

rats! and I spelled accidentally wrong, too.

[*3d0g]

---

@JimB. wrote:

---

@*3d0g wrote:

---

---

I didn't mean to quote all the above.  I'll get it eventually.  At least it isn't a huge post.

Yeah, the forum software here is pretty terrible. I more often have to open the HTML view and edit the markup here than on any other since the early 2000s. Multi-quoting is absolutely a pain.

---

@*3d0g wrote:

---

So, presently I'm seeing in the project that "Separate compiled code from new files" is checked.  If I'm understanding you, what you've said, with this checked at the creation of the project, either the project or any vi in the project is safe from accidently opening in the 64-bit environment LabVIEW.  Correct?

---

Incorrect. There is nothing at all that prevents that. What it does do is make everything contained in the VI agnostic of the operating environment. If you enable that option then the VI only contains source code. It has no bitness.

Are you familiar with text based programming at all? What is the bitness of this application?

main( ) {
        printf("hello, world");
}

That's a trick question. Nothing there indicates a bitness. The bitness of the compiled code will depend on your compiler settings. LabVIEW VIs work similarly if you turn on the option to separate compiled code. With that setting turned on, the VI is neither 32-bit nor 64-bit.

If you do not turn on that option then the VI also has compiled machine code embedded in it. That compiled code will have a specific bitness. If you create one in 32-bit and then open it in 64-bit then it will recompiled itself. The good news as that doesn't ruin the VI. When you open it in 32-bit again it will just trigger another recompilation. A number of things can retrigger recompilation actually, and you will find using that option to greatly reduce the number of times LabVIEW will prompt you to save a file that you didn't actually change anything in. I think most users turn it on if for no other reason than it plays much nicer with SCC systems.

Now, of course this is talking about the VI itself. There is no damage done by saving it in the wrong environment. Running it in the wrong environment? That mostly won't matter, but can be an issue. The most common issue will be if you are depending on a driver or DLL that is not the correct bitness. This also does not damage the VI in any way, but can generate errors while running it.

---

@*3d0g wrote:

But now what about clicking the project or a file that is in the project, but from outside the project?  If I'm understanding you, it matters not as long as "Separate compiled code" was checked when whatever it is was created.  This is your answer to me.  Or is this not correct for what you're saying?

What happens when you click on the file from outside of the project is, mostly, outside of LabVIEW's control... for the most part. It is determined by Windows' file type association. 32-bit and 64-bit LabVIEW are indeed different applications, so the project or VI will open in whichever one Windows decides to open it in. Typically, this will be whichever you last used.

If you, for whatever reason, have concern for opening the project in the correct environment, then opening the file from within the correct environment is your easiest solution.

Maybe it would help to understand why you are worried about it? What are you paranoid about happening specifically?

---

haven't figured it out yet. 😞

What am I paranoid about?  Well, LabVIEW has this annoying habit of wanting to upgrade if ever you ignorantly give it a chance. 

The way things work on my side of things, a driving vi was written many many moons ago, and that is just how things are done.  This vi has relatively recently been modified to handle multiple versions of LabVIEW.  (LabVIEW 2012, 2018, 2022, 2023 ad infinitum)  A user clicks the product id they wish to test and then, based on their particular LabVIEW installation, the appropriate (yep, changing here) TestStand sequence for that particularly chosen test runs.  The TestStand sequence embeds the path to the called vi at each step of the test.  (Steps are 99.999% LabVIEW, no other language.)   If for some reason LabVIEW opens the vi in the wrong bitness (I hate that word -- there is a proper term for it, but I can't remember it!) I don't think the outcome will be as desired, always: the TestStand sequence runs properly; vis run properly; and the user has a pleasant experience running their test with no mystery LabVIEW or TestStand crashes, possibly with useful pop-ups, AND I don't get called to go fix it.  (32-bit vs 64-bit drivers also come to mind, for all that hardware needed for those tests...)  That last one is crucial for getting things accomplished on time as an engineer.

That's what I'm paranoid about.  I didn't write LabVIEW nor Windows, be it XP, Win7, Win8, Win10, Win 11, WinAdInfinitum.  How can I force the vi to open in the correct environment, always?  That's what I want to know.  There will not be the convenience (aka pita) of opening the environment and then opening the desired project or vi, a two-step algorithm.  No, it'll be one step: run TestStand sequence X.seq.

Hopefully this answered your question.  Great post by the way!  Thanks!

[*3d0g]

This is a little outside the scope of the question, but it's my thread...

Have you ever had the 64-bit LabVIEW environment open, copied a section of a vi, say a state machine (the outer while-loop of), to the clipboard, and then went to 32-bit LabVIEW and pasted into a vi, there?  What happens?

You get an image, and since it's an image you only see the case of the state machine you were viewing at the time of the copy to the clipboard.

LabVIEW 32-bit doesn't even try to actually handle the 64-bit vi block diagram.  It just turns it into an image of the real thing.  I'm betting there are LabVIEW gurus here who can drill down into this action.  I'm just a user and discovered it one day.  I liked what I did while working in 64-bit and said, "self, let's use this in that other 32-bit-based thing."  I learned, nope, that won't work.  I finally did a crazy snip-tool thing to grab the state machine cases and just rebuilt the state machine in the 32-bit environment; yep, it worked, but I had to recreate it all, state machine and then case-by-case.

Like I said, that interruption question was a little off track, but...

[*3d0g]

One other thing to that last, and maybe this was the cause, the state machine did contain Call Library Function Nodes.  Therefore, dlls were involved.  Maybe LabVIEW saw that and just aborted via image creation.  Granted both sides of the situation were calling the same dll, but maybe LabVIEW just saw the CLFN's in the cases and just said no.  Whatever it was I got an image of the real thing, not the real thing.

[rolfk]

You miss one thing about the clipboard. LabVIEW has an internal clipboard, when you copy LabVIEW code to the clipboard, LabVIEW stores the binary structure to that internal clipboard and an image, but only copies the image to the external Windows clipboard. Before LabVIEW 64-bit that was no issue because the binary structure is highly version specific so even if it had copied the binary structure too, there would not have been any other LabVIEW process which could have done anything with it and for other LabVIEW versions the clipboard access would have had to be improved to detect that there is a different version in the clipboard, convert it to the current version on the fly with all the potential problems of missing functions and subVIs. Lot of trouble for a very limited use case as most LabVIEW users find one version more than intimidating enough.

64-bit LabVIEW changed that a little as you can have both versions running along each other and they could share VI code over the clipboard but that is a substantial development effort that would have delayed the release of 64-bit LabVIEW further so it was not done. And with the 32-bit version of LabVIEW on the nomination to be discontinued soon, that effort won’t be implemented now for sure!

[pincpanter]

---

@*3d0g  ha scritto:

I finally did a crazy snip-tool thing to grab the state machine cases and just rebuilt the state machine in the 32-bit environment; yep, it worked, but I had to recreate it all, state machine and then case-by-case.

---

Actually there is no need to recreate. Just open the very same vi in the 32-bit LabVIEW. You want to keep the two code bases separate? Then make a copy of the vi (or more probably the vi hierarchy, using Save as...).