How big is a big LabVIEW project?

[cebailey]

Of course this question does not have a single or simple answer, but, what is your impression of how big a big project is in LabVIEW?

"Project" here is meant in ordinary English and not in its special LabVIEW organizational tool sense.

Is there some number of VIs that, to you, starts to sound "big"? Some number of bytes for the stored VIs that make up a project? Some length of time it takes to write? The number of people contributing? The size of the resulting executable(s)? Some other measure of the scale of the thing?

What are the largest things you have done or seen done with LabVIEW, and how do you find yourself quantifying the size in your own mind when you think about it?

Thanks to anybody willing to take a stab at this question, poorly defined though it may be!

[Ben]

Yes I agree the term "big LABVIEW project" is relative.

I simply watch the count of VIs to judge if a project is large. The time required to develop or the number of developers does not play a part in my minds eye since 6 developers completing a project in 1 month vs 1 developer doing it in 6 months seems the same.

Prior to the introduction LVOOP, when one of my project grew to more than 700 VIs, is when I started thinking of it as "big", with my largest pre-LVOOP being about 1400 VIs.

Now that I have been working with LVOOP that number has been bumped to 1000 VIs.

The largest project I recall hearing about was 3000 VIs (using LVOOP, not developed by me).

So... what prompts the question?

Curious,

Ben

[Andrey_Dmitriev]

> Now that I have been working with LVOOP that number has been bumped to 1000 VIs.

Ben, is your LVOOP project bigger or smaller that "functionally same" non-LVOOP project? 

Andrey.

[Ben]

---

Andrey Dmitriev wrote:

> Now that I have been working with LVOOP that number has been bumped to 1000 VIs.

Ben, is your LVOOP project bigger or smaller that "functionally same" non-LVOOP project? 

Andrey.

---

My gut feel is that 700 non-LVOOP = 1000 LVOOP

The difference is all of the accessor VIs required to work with the various attributes of the classes. In non-LVOOP I'd just use Bundle and UnBundle by names nodes. The protection scheme built into LVOOP requires I use accessors instead. Don't let that scare you! LVOOP will automatically generate accessor VIs for you.

So what are your numbers?

Still curious,

Ben

[Andrey_Dmitriev]

> My gut feel is that 700 non-LVOOP = 1000 LVOOP 

Just started with LVOOP and see the same proportion - LVOOP project approx 50% bigger than same non-LVOOP project. But development speed the same (or a little bit fater), because lot of things are "auto generated".

For me projects up to 100-200 SubVIs are small, 100-200 to 500-700 - "medium" and 500-700+ - big (for LVOOP these numbers should be increased a little bit).

Also this depends from the content. For machine control applications most of sub VIs are "pure logic" VIs, but for image processing some VIs contained complicated math algorithms, so I can spend more days just for few VIs. Depends from the complexity point of view 100-200 SubVIs project can be more complicated than 500-700 SubVIs, so we can't set "splitter point" here. But I agree with you, that LVGOOP projects with 1000+ SubVIs are big.

Right now I working on the relative big modular project which contained totally approx 2000 SubVIs (60 MB code) splitted to 150 libraries. Together with other files (*.ctl, *.lvlib, etc) approx 3000 files / 100MB sources.

Andrey.

[smercurio_fc]

This subject has been brought up before several times, and you may want to perform a search to see previous discussions.

Personally, I think metrics such as "number of VIs", or "number of bytes", or "number of lines" are pointless (no offense meant, Ben ) as they rarely, if ever, provide any inkling to a project. I could just as well write a simple "project" with 1 VI that's about 300 MB, or 300 VIs each of 1 MB. Which is the larger project? In my mind, a project is as big as it needs to be to accomplish the task. Critiques can be made on coding style and architecture, both of which directly affect the number of VIs and the size of the VIs. For example, let's say you dictate that state machines are the architecture that shall be used. Well, that in turn dictates how many VIs you will have since state machines usually require support VIs. What about error handling? Logging? Modularity requirements? Documentation requirements (each of those characters you type takes up space )? etc... etc...

The way I structure my code I usually end up with lots of VIs, but a highly modular system that's easy to understand. If people consider 700 VIs a big project, then what's one that is over 2000? Super-sized? The one I have right now is getting close to 3000. Hold the fries, please.

I don't use LVOOP since I think the LabVIEW implementation is clumsy compared to "regular" OO in more traditional text-based languages. I've tried many times to implement LVOOP, but I keep hitting walls and I'd rather not spend my time trying to fight code, thank you very much. On the other side I also have a C# program I wrote that's fairly complex, and totally OO. I found writing OO in C# way easier and less frustrating than in LabVIEW, but maybe that's just me. 

Message Edited by smercurio_fc on 11-12-2008 09:24 AM

[Ben]

---

smercurio_fc wrote:

This subject has been brought up before several times, and you may want to perform a search to see previous discussions.

Personally, I think metrics such as "number of VIs", or "number of bytes", or "number of lines" are pointless (no offense meant, Ben ) as they rarely, if ever, provide any inkling to a project. I could just as well write a simple "project" with 1 VI that's about 300 MB, or 300 VIs each of 1 MB. Which is the larger project? In my mind, a project is as big as it needs to be to accomplish the task. Critiques can be made on coding style and architecture, both of which directly affect the number of VIs and the size of the VIs. For example, let's say you dictate that state machines are the architecture that shall be used. Well, that in turn dictates how many VIs you will have since state machines usually require support VIs. What about error handling? Logging? Modularity requirements? Documentation requirements (each of those characters you type takes up space )? etc... etc...

The way I structure my code I usually end up with lots of VIs, but a highly modular system that's easy to understand. If people consider 700 VIs a big project, then what's one that is over 2000? Super-sized? The one I have right now is getting close to 3000. Hold the fries, please.

I don't use LVOOP since I think the LabVIEW implementation is clumsy compared to "regular" OO in more traditional text-based languages. I've tried many times to implement LVOOP, but I keep hitting walls and I'd rather not spend my time trying to fight code, thank you very much. On the other side I also have a C# program I wrote that's fairly complex, and totally OO. I found writing OO in C# way easier and less frustrating than in LabVIEW, but maybe that's just me. 

Message Edited by smercurio_fc on 11-12-2008 09:24 AM

---

1) So what is YOUR criteria for a Big project?

2) What issues did you run into with LVOOP? My issue was how to develop Active Objects since they are not supported directly and I had to "roll-my-own" version.

Ben

[cebailey]

Thank you, this is a useful perspective - got a lot of replies in just a few minutes and am curious about further posts.

I am working on my first LabVIEW project (other than little experiments that were just for learning). It's at 179 VIs totaling 18 MB. Another programmer has worked on a few parts of this, too. I am completely agnostic on the question of whether I've made too many or to few VIs, whether they're too big or too small, and how convoluted my logical thinking and my turning it into code is. It has been messier than I anticipated and I'd like to better understand why.

Different strategies look better or worse as a project grows. How much is stictly dataflow, how much starts using locals, or globals? How many things are passed by references, how typical are property and invoke nodes? At some point gathering all the errors got impractical and my local LV mentor suggested using a queue to manage them, in throw-and-catch or producer-consumer fashion - great stuff.

First things get passed around on wires, then more things wouldn't fit and got bundled unnamed into clusters, which of course quickly turns into a nightmare, so they got redone bundled by name. Changing these clusters was unweildy so they got customized into strict typedefs. Soon there was a supercluster containing a bunch of these clusters.

Every new value that the project needs can be a wire, or a displayed object, and when I add it I wonder if I will wind up referencing it from other VIs, so should I put it into my clusters, or put a reference to it in there, or make it a global, or some combination of these, or what? Start simple and keep going back to make it more general and versatile, or maybe make a big fuss at the start and be done with it?

Will this next VI work the way I want on the first try or after fiddling? Or only after I carefully define a tester VI that calls it and develop the two together? Is my work too interconnected, so that testing a VI in isolation is really difficult, and I wind up trying to debug it as a component in the whole shebang? When something doesn't work right, how far back should I go to fix it?

So, these are all the things that any new LV programmer must wrestle with, I guess, and as I do so the wrestling seems to be defined by how big and complicated the whole project is, however that's defined. It's like doing an experiment. Walking into a strange room and trying to turn on the lights is a tiny experiment, and it happens almost without planning and analysis. But bigger experiments need more time thinking up front, and maybe need more subexperiments. I'm a scientist who also programs, not a professional programmer. My other programming experience is text based, where I have a better sense of how quickly or thoughtfully to tackle things to hit a sweet spot. I'm trying to get more of that sense in the LV world.

Anyway, thanks for all these excellent posts!

[cebailey]

>Personally, I think metrics such as "number of VIs", or "number of bytes", or "number of lines" are pointless [...] In my mind, a project is as big as it needs to be to accomplish the task.

I have to agree there is some truth to this. But there is also some sense we have of the size of any project we start, programming or otherwise. I think we use this sense whenever we take on a project. There's a continuum from replacing a light bulb all the way up through building a house and beyond. So, maybe they're not pointless, just imperfect. There must be some kind of feeling for it. If somebody came to you with a well defined need, somehow, you'd be able to say something about how soon you can give them a solution, right? What does one use to decide where to start and what to anticipate?

[Andrey_Dmitriev]

Hi,

I will recommend to read this document:

LabVIEW Development Guidelines

and take a look here:

Style Guidelines

and here:

LabVIEW Style Checklist

then here:

Rules to Wire By -- Part I

Rules to Wire By -- Part II

this also not bad:

12 Steps to better code

personally I will recommend

- do not make block diagram bigger that your monitor

- do not use sequences if not necessary 

- always use 4x4 connector pane if possible

- use error in / out

- wire (i mean - dataflow) from left to right (first thinking - second wiring)

- make readable icons for SubVIs

- use source code control

this list can be continued, of course - see links above.

Finally, the only your experience will say - what you doing wrong and what is good...

good luck,

Andrey.

Message Edited by Andrey Dmitriev on 11-12-2008 05:57 PM