How big is a big LabVIEW project?

[Intaris]

Another data point.

Out project contains nearly 5000 VIs (All non-NI).  Vast majority non-LVOOP but not all VIs active (Test VIs etc.).

I would certainly classify it as a large project.

Shane.

[Current_93]

Андрей, это вы один все эти проекты (https://www.gemeasurement.com/) разработали за год? 

[joshua.l.guthrie2.civ]

I'm curious the thoughts of doing a "large" project not in OOP?

Granted, NI's implementation of OOP in LabVIEW leave a fair amount to be desired, but I couldn't imagine organizing my code w/o it.  So those w/ projects let's say 1000+ VIs, how many are NOT using OOP?  Why?  And what tools/tricks do you use?

I kind 'a have a hate-hate relationship with OOP in LabVIEW (especially manipulating large objects by reference), but it's the tool that I have.

Also, along the same lines, I can't imagine being w/o the abilities to separate my code in packed libraries.  But I've found that my packed libraries tend to live better in separate projects (dependency resolution and name spacing issues).

[Yamaeda]

---

@joshua.l.guthrie2.civ wrote:

I'm curious the thoughts of doing a "large" project not in OOP?

Granted, NI's implementation of OOP in LabVIEW leave a fair amount to be desired, but I couldn't imagine organizing my code w/o it.  So those w/ projects let's say 1000+ VIs, how many are NOT using OOP?  Why?  And what tools/tricks do you use?

I kind 'a have a hate-hate relationship with OOP in LabVIEW (especially manipulating large objects by reference), but it's the tool that I have.

Also, along the same lines, I can't imagine being w/o the abilities to separate my code in packed libraries.  But I've found that my packed libraries tend to live better in separate projects (dependency resolution and name spacing issues).

---

8 year old thread, but Folders and Libraries goes a long way. 🙂 OOP can be very good, but it's not the be all, end all of design.

[Intaris]

---

@Yamaeda wrote:

---

---

8 year old thread, but Folders and Libraries goes a long way. 🙂 OOP can be very good, but it's not the be all, end all of design.

---

Unless you make a mess of implementing OOP, then it can definitely be the end-all of the design 🤡

[Elijah_K]

Recently worked with a customer that has a 40,000 VI project spanning >400 *.lvproj files, which is developed and maintained by around 50 LabVIEW programmers. It's 100% OOP and specifically, Actor Framework.

We're working with them to help optimize the build processes, specifically their usage of PPLs for a componentized build process.

I'd say this represents the larger end of the spectrum!

[joshua.l.guthrie2.civ]

---

@Elijah_K wrote:

Recently worked with a customer that has a 40,000 VI project spanning >400 *.lvproj files, which is developed and maintained by around 50 LabVIEW programmers. It's 100% OOP and specifically, Actor Framework.

We're working with them to help optimize the build processes, specifically their usage of PPLs for a componentized build process.

I'd say this represents the larger end of the spectrum!

---

LOL, and I complain about my 45-minute compile times.  I can't imagine!

Is there a decent tool to map PPL dependencies other than opening up the projects?  I'm currently mapping what PPL depends on what PPL by hand.  A graphical representation would be awesome.   I get the feeling I'm missing something obvious.

I've gone as far as writing a VI that compiles by iterating though all the build specs (when I feel the need to do a "make clean" and build the whole project), but with a decent visualization tool, I could probably do parallel compiles on different machines (hardware).

[rolfk]

I used in the past MGI Solution Explorer to manage this kind of projects. Each class had its own project for each platform (32-bit Windows, 64-bit Windows, NI Linux RT) and build the according PPL to a common build path that was symlinked to the actual platform specific binary artifact path. Other projects and their classes referred to the PPLs through that same build path. Before starting development for a platform there was a shell script symlinking the common build path to the correct platform path. If you forget to do that you learn very quickly when you open a specific class project as you get tons of linking errors and if you save at this point you better have an actual repository version you can restore too, because the project is hosed real good and manual restoration is the only other way and very painful.

The MGI Solution Explorer allows to setup scripts that invoke each project Build Specification and build things up from the bottom up. Another powerful tool is the Solution Builder which can analyze a class hierarchy in a project and build each lvlib into it’s own PPL in the right order and relink higher level lvlibs to their newly build PPL dependencies on the fly. But when that became available we had already setup the Solution Explorer system and nobody felt like risking to use yet another tool. Also initial tests showed that the Solution Builder wasn’t quite ready to deal with multiple different target architectures.

[StevenHowell]

Good lawd thats a lot of actors!

I think the biggest I have created was probably between 20 and 30 actor classes.