Anyone have any "lessons learned" from changing from 32-bit to 64-bit LabVIEW?

[Kyle97330]

At my company (midsize team, 4 devs) we have been using 32-bit LabVIEW for quite a long time.

Just recently we have started to consider switching to 64-bit.  We have a couple of large applications that have had "out of memory" problems (one during build, one during runtime) and while we were able to make some code changes and such to keep them in the limits for now, it will be difficult to keep developing these without spending a disproportionate amount of time trying to limit their memory footprints.  (Note:  Am not asking for suggestions on this here.  We have plenty of those, they're just time-consuming and problematic to implement on these applications).

I also don't need any links to NI pages.  I have already found and reviewed the following:

NI Product Compatibility for Microsoft Windows 10 

LabVIEW 32-Bit vs. 64-Bit Development Environments FAQ 

LabVIEW 32-Bit and 64-Bit Compatibility 

We make only limited use of NI products and toolkits apart from LabVIEW itself, and all of those are supported in 64 bit.

So we've come up with the following "plan" to proceed and I'm hoping that anyone else who made the transition from 32 bit to 64 bit can contribute anything based on their experience.

• Our company is currently running LabVIEW 2021 32-bit.
  • In that environment, we will ensure that we have the "Separate compiled code from source file" checked on all code
  • Also make sure that all environments have "Separate compiled code from new files" also checked in the configuration
• Install LabVIEW 2021 64-bit on one PC in parallel with 2021 32-bit.
• On that PC, develop a "pilot" program using 64-bit exclusively.
  • I have a project coming up in Q1 2025 that fits the bill nicely (moderate complexity, only one station, no legacy equipment). 
  • If there are any issues with "bit-ness" attempt to resolve them with the use of conditional disable structures rather than branching the code.
• If all goes well, then Q2 2025 or so, we will convert to LabVIEW 2024 64-bit as our primary development environment, supplanting 2021 32-bit
  • While LabVIEW 2025 might be out at this time, using 2024 will allow us to continue use of 2021 in parallel since all NI support software simultaneously supports the last 3 years of releases as well as its current year.
• If we discover a few exceptions that don't work with LabVIEW 64-bit, those programs will be left in 32-bit and on some workstations we will maintain LabVIEW 2024 32-bit for them.
• If we discover that many things don't work in 64-bit, we will either drop 64-bit completely or only use it for the very few applications that need it, moving just to 2024 32-bit.

The only thing I know for sure could be an issue is 3rd-party binary interfaces.  I expect all VISA, TCP/IP, and so on to work just fine but there may be some hardware that uses DLLs or ActiveX that will either need updates or just stop working.

Has anyone else done this sort of a change and has any tips on how to manage it?

[RTSLVU]

Just make sure any third party toolkits and drivers that use a DLL are 64 bit LabVIEW compatible.

[Gregory]

I recently used 64-bit for an application and the most annoying thing was getting all the DLL calls to work. If you name your DLLs according to their pattern (e.g. MyDLL32.dll and MyDLL64.dll) then you should be able to use a wildcard and LabVIEW should find the correct one (MyDLL*.dll). But, LabVIEW (2016) struggled a lot with this and this often resulted in broken DLL calls.

Since I just had a handful of DLL calls I mostly used conditional disables to get around this. This results in broken code during the build, but checking "enable debugging" allowed me to build executables successfully.

[BertMcMahan]

The only issue I've had is with the Report Generation Toolkit, which was a little finnicky during conversions IIRC. I think there was an invoke node or two that I had to right click and relink, but it wasn't a big deal, and it was several years ago so it's probably not an issue anymore.

[Steffen01]

seems to be a bit faster as well.

Most of features are now supported in 64 bit as well, I run a cRIO, started in LV2015. Back then had to opt for 32 bit for all the drivers, RT engine, FPGA compiler etc. Now all this exists in 64 bit as well.

Plus you will struggle to find 32 bit dlls these days. I am wrestling with one supplier software, it does not give me the option to force to install 32 bit. It will always install a 64 bit dll, unless I find some 32 bit computer somewhere.

In other words. sooner or later you have to make the plunge

[crossrulz]

I will say that NI has a goal of eliminating LabVIEW 32-bit. There is no timeline on this. But it is a goal. My assumption at the moment is that NI is watching for a release when a critical mass of users are using 64-bit over the 32-bit option. That is when the clock will begin. And this is a good thing. It would allow NI to simplify their code base by eliminating bitness branches.

Earlier this year, I started porting my framework from 2019 32-bit to 2024 64-bit (initially using 2024Q1, now using Q3). I have had only 2 issues. One was procedural on my end as I had to be more careful with my PPL usage (32-bit PPLs are not compatible with LabVIEW 64-bit). The fix here was simply to rebuild the PPLs in the proper order and not getting ahead of myself. The other issue was due to a .NET library I was using apparently completely changed the API in a newer release. I haven't pursued this any further than identifying the issue as I don't have an immediate need for it. I'll eventually get to it.

With all of that said, I encourage people to move to 64-bit. The toolkits and drivers are all but caught up, cRIO drivers being the one I was waiting for. As I stated, NI going looking to only have 64-bit. Now is a great time to do the move.

[Kyle97330]

Thanks for all the notes.  One of the two "big applications" I mentioned does use PPLs  (though it's one that one of the other devs is the owner of) so that's good to keep in mind.

We don't use the RGT or cRIOs, so those don't apply to us, but we do have some internal company DLLs.  They've been in use for a number of years as-is so I don't know about renaming them with a "32" if they need rebuilding for 64 bit, as they are shared with people who do not use LabVIEW as well.

[Darren]

LabVIEW code that calls 32-bit DLLs is the most common issue I've seen when upgrading to LabVIEW 64-bit. Teams I've worked with have either (1) re-built the DLLs to be 64-bit, or (2) found an alternative to calling the DLL at all.

LabVIEW code that calls PPLs built with 32-bit LabVIEW is the second most common issue.

LabVIEW code that uses NI hardware that doesn't include support for 64-bit LabVIEW is the third most common issue.

If you can handle those three, you should be fine. The RGT method relinking described upthread has to do with Office version differences, not LabVIEW bitness.

[tst]

---

@Gregory wrote:

I recently used 64-bit for an application and the most annoying thing was getting all the DLL calls to work. If you name your DLLs according to their pattern (e.g. MyDLL32.dll and MyDLL64.dll) then you should be able to use a wildcard and LabVIEW should find the correct one (MyDLL*.dll). But, LabVIEW (2016) struggled a lot with this and this often resulted in broken DLL calls.

Since I just had a handful of DLL calls I mostly used conditional disables to get around this. This results in broken code during the build, but checking "enable debugging" allowed me to build executables successfully.

---

Another option for this is to configure the CLFNs to accept a path to the DLL and then build that path dynamically based on the bitness of LV. This lets you support both bitnesses and I don't remember seeing issues with this (although you do also have to account for LV vs. EXE).

[rolfk]

All the advice so far is sound and useful. We are now getting into the situation finally where 64-bit is the new standard for most software. And many do not provide 32-bit options already now. Except of course if you need to use a software driver that is already a few years old and the manufacturer of the hardware is not interested to support it anymore because they have a new and much better product now.

Then you can get into the situation that you should have 64-bit for one driver and 32-bit for another and there are no other options for either. One possibility would then be to have two separate applications that communicate over network with each other. Less than ideal but the only workable solution safe from throwing away the old hardware and buying the new and shiny one (or reverse engineer the old driver and reimplement it fully in LabVIEW 😁, my favorite one if time allows it).