FPGA Compile servers are again down....

[Intaris]

This seems to be happening with some regularity in the last couple of years.

Being in Europe, some hours before the folk in Austin wake up turns into half a day of being unable to compile FPGA code. Well, yes, local compile is available, but that's not a great alternative.

I think we really need to start looking into setting up our own compile farm.

[Intaris]

BTW, turns out the servers were NOT down, it was a LabVIEW IDE problem.... my colleague ran into the same issue today, tried to restart LabVIEW, was told the project file was corrupt (No idea why) and after reverting the project, the server connection worked.

This is a new error I haven't seen in LV 2015 or 2019.

[Ettepet]

---

@Intaris wrote:

BTW, turns out the servers were NOT down, it was a LabVIEW IDE problem.... my colleague ran into the same issue today, tried to restart LabVIEW, was told the project file was corrupt (No idea why) and after reverting the project, the server connection worked.

This is a new error I haven't seen in LV 2015 or 2019.

---

Which Labview version are you using?  In general it is advised not to switch to newer versions of Labview unless required.  [One reason to switch of course is to not fall too far behind.]

We were on Labview 2018 (which is somewhat 'old'), and decided to switch to the latest version.  I encountered various problems in both Labview 2024Q3 and Labview 2025Q1, which gave us pauze.

It seems a number of bugs have been slipping in to Labview in recent times which are not being reported.  Maybe because of all the people with older, more-complex software sticking to older Labview versions. 🙂

The bugs I discovered involved a soft-lock when using "Create SubVI" (LV2024Q3, 32-bit); and opening a project-file automatically causes it to want to save changes to various back-ground files (LV2025Q1, 32-bit).  We are currently deciding what to do, as one of my colleagues would rather stick to Labview 2018, because the change to a more recent Labview version is not a high priority.

[Intaris]

Using predominantly LV 2022 at the moment. We've been using it for 2 years now, generally OK but yeah, some bugs present.

I had been using 2015 for a long time with some 2019 sprinkled in. There, every time I got an error message from the FPGA compile server, it was the server (although now that I write that, I don't know if we didn't maybe have something similar but never realised).

I have an idea on the Idea exchange for a LTS version of LabVIEW which has (which seems like a terrible decision to me) declined.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LTS-Long-term-support-vewrsion-of-LabVIEW/idi-p/10941...

[Ettepet]

---

@Intaris wrote:

Using predominantly LV 2022 at the moment. We've been using it for 2 years now, generally OK but yeah, some bugs present.

I had been using 2015 for a long time with some 2019 sprinkled in. There, every time I got an error message from the FPGA compile server, it was the server (although now that I write that, I don't know if we didn't maybe have something similar but never realised).

I have an idea on the Idea exchange for a LTS version of LabVIEW which has (which seems like a terrible decision to me) declined.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/LTS-Long-term-support-vewrsion-of-LabVIEW/idi-p/10941...

---

I went from Labview 8.6 to LV2011, to LV2013, skipped LV2015 (too many obvious bugs - in my use-case) and landed on LV2018SP1.  The latter has served us well.

I agree on the LTS idea, or some sort of (general) open-source for Labview.  Such things enable long-term stability and the possibility of growth.  Maybe a sort of localized Labview version could be established around equipment, just like with visual basic around Excel and the like.  A way to make your freshly acquired NI equipment do spectacular things, where full-blown integration and usage would require a more global Labview programming license.  Not sure if the effort would still pay-off in the current climate though.

All the best with your FPGA compilation issues, as I do not have first-hand experience with that.