In 2023 Should I be using LabVIEW 32bit or 64bit.

[wiebe@CARYA]

It can't be easy for them...

Going all 64 bit will be a lot cheaper to maintain. Getting there will (has) costs a lot though...

The business\management\financial situation doesn't help.

It seems they have been 'cherry picking' the migration, removing the obstacles to move to 64 bit one by one. There's not much left, but once they 'switch', they have to deliver and fix the things everybody forgot about. So it seems they officially recommend 32 bit, hoping to spot the showstopper before they make it definite.

LINX needs to migrate, it feels like a pretty important part of the community edition(not sure it is though). Now RT has migrated, I don't see good reasons not to support it for 64 bit (except yet another budget is needed)..IMO, It should have been migrated before the community edition release, because back then, 64 bit was already the unofficial recommendation. It seemed wrong to me to onboard people with software that didn't age well that obviously...

[crossrulz]

---

@Terry_ALE wrote:

2018 was the first LabVIEW FPGA for 64-bit version.

---

Real-Time and FPGA have had LabVIEW 64-bit support for many years.  It was the cRIO support that finally came around (2022 Q4) that has me going with 64-bit.  I'm now in the process of moving from 2019 32-bit to 2023Q3 64-bit (had to wait for a project to finish before starting the process).  I have one .Net library in my reuse library that I'm not sure if it will handle 64-bit (I have not dug into it yet, it just now entered my mind).  That is my only real concern with the migration at the moment.

[RTSLVU]

I still use 32 bit because one of the toolkits I need is not available for 64 bit.

Other than that I don't think it matters what bitness you use unless your program actually needs to access over 4GB of RAM.

[wiebe@CARYA]

---

@RTSLVU wrote:

I still use 32 bit because one of the toolkits I need is not available for 64 bit.

---

So, which toolkit?

---

@RTSLVU wrote:

Other than that I don't think it matters what bitness you use unless your program actually needs to access over 4GB of RAM.

---

That, and you'd be up to date... You won't be using any emulation layer. 32 bit support will stop at some point.

[alexderjuengere]

---

wiebe@CARYA wrote:

32 bit and 64 bit should be able to run (be installed) side by side...

---

I used labview 2020 64 bit and labview 2019 32bit installed one the same computer for quite some time

you can't open a 64bit.vi in labview 32 - but a 32bit.vi doesnt have this issue in labview 64 bit

we decided to move from 32bit 64bit when IMAQ and IMAQdx were fully supported

[wiebe@CARYA]

---

@alexderjuengere wrote:

---

wiebe@CARYA wrote:

32 bit and 64 bit should be able to run (be installed) side by side...

---

I used labview 2020 64 bit and labview 2019 32bit installed one the same computer for quite some time

you can't open a 64bit.vi in labview 32 - but a 32bit.vi doesnt have this issue in labview 64 bit

---

You should be able to open a LV20 64 bit VI in LV20 32 bit and vice versa. It shouldn't even mark the Vi as changed (iff separate compiled code is on). I actually seen this work like that for LV20 64\32 bit. Of course API calls and conditional disabled structures can change. 

Could the problem here be that it's LV20 vs LV19?

[alexderjuengere]

---

wiebe@CARYA wrote:

You should be able to open a LV20 64 bit VI in LV20 32 bit and vice versa. It shouldn't even mark the Vi as changed (iff separate compiled code is on). I actually seen this work like that for LV20 64\32 bit. Of course API calls and conditional disabled structures can change. 

Could the problem here be that it's LV20 vs LV19?

---

Probably! 

If I remember correctly, I never installed LabView 2020 32 bit along labview 64 bit

[RTSLVU]

---

wiebe@CARYA wrote:

---

@RTSLVU wrote:

I still use 32 bit because one of the toolkits I need is not available for 64 bit.

---

So, which toolkit?

---

---

The old NI-CAN toolkit and XLR8 come to mind right off the top of my head.

---

wiebe@CARYA wrote:

---

---

@RTSLVU wrote:

Other than that I don't think it matters what bitness you use unless your program actually needs to access over 4GB of RAM.

---

That, and you'd be up to date... You won't be using any emulation layer. 32 bit support will stop at some point.

---

Experience has taught me not to fix things that are not broken.

[wiebe@CARYA]

---

@RTSLVU wrote:

---

wiebe@CARYA wrote:

---

---

@RTSLVU wrote:

Other than that I don't think it matters what bitness you use unless your program actually needs to access over 4GB of RAM.

---

That, and you'd be up to date... You won't be using any emulation layer. 32 bit support will stop at some point.

---

Experience has taught me not to fix things that are not broken.

---

But that's a grey area.

You could argue running a 32 bit app on a 64 bit OS is broken. Not broken to failure, but less than perfect nonetheless.

You could argue it will break completely in the near future and anticipate on that. 

I'd consider this an upgrade. If an app is not broken, running just fine in LV7, an upgrade might not be a bad idea despite not being broken.

It broke for me in LV13. I don't read in my entire (0..nnn GB) files, but I do cache data to some extend. As there's no enforced limit to the number of simultainiously opened files, it was easier to go 64 bit (and actually have no physical limit as well) than to program a limit based on available memory. An it worked effortlessly.

Not sure why I'm arguing for 64 bit. I don't have 64 bit stock 🤣...

[RTSLVU]

---

wiebe@CARYA wrote:

---

@RTSLVU wrote:

---

wiebe@CARYA wrote:

---

---

@RTSLVU wrote:

Other than that I don't think it matters what bitness you use unless your program actually needs to access over 4GB of RAM.

---

That, and you'd be up to date... You won't be using any emulation layer. 32 bit support will stop at some point.

---

Experience has taught me not to fix things that are not broken.

---

But that's a grey area.

It seems black and white to me. If the program runs exactly as intended then it is not broken. Regardless of any OS tricks that are going on.

In fact if the OS changed and the program stopped working as indented, then the I would say OS is broken and freeze my target computers on the last version of the OS that was not broken.

Case in point: I support eight ATE systems in our lab that use an instrument whose drivers are not compatible with Windows 11. The driver is not just pre-fab LabVIEW vi's that use VISA and SCPI commands, every VI uses a call to a DLL. The manufacturer has obsoleted that instrument and has no plans on updating the driver. Equivalent replacement instruments will cost a couple hundred thousand dollars, not counting my time updating the program for the new instruments.

From my point of view Windows 11 is broken not our currently working ATE systems.

So even though our IT department is pushing Windows 11 (So we all have the latest and greatest OS) I have frozen all of our ATE's and my company laptop on Windows 10.