Please comment on my large program structure.

[Yamaeda]

You need to be logged in to spread Kudos around. 🙂

/Y

[rex1030]

I am not a LabVIEW legend like most of those who have posted here before me, but I would like to offer my humble advice. I majored in computer engineering and they dont teach LabVIEW at that university. I have coded in pascal, c, c++, and java which are all text based languages and getting the job here I had to learn labview from scratch. I was immediately put on a large project working with one other collegue who was learning labview at the same time. The code we wrote on that first project was bascially one big while loop spanning in multiple screens in every direction. It worked sort of, but debugging, upgrading, or changing anything was an absolute nightmare. Anyone who has ever come behind us to attempt to change anything... cant. I look back at that code now and I don't know whether to cry or laugh. My point is I can tell you first hand that I have gone from there, to using a lot of subVIs and good overall program architecture and its not just better, it's easier. Using a state-machine architecture, event-structures, producer-consumer loops, and lots of subVIs will help you code faster and your programs work better.

Reasons to use more subVIS:

1.Its easier to read and find what you are looking for immediately in your code.

2. It allows you to organize subVIs into physical folders on disk, sorted by function. This improves reusablitly so if you spent an hour making a subvi to do a function you can use it again later in the same or different projects as well.

3. Debugging. Putting functions into subvi's allows you to test the subvi independently of the rest of your program and confirm it is working as designed before moving on. Also, when your program throws an error, the subvi that had the problem is listed! Basically it goes right to where the bug is. This drastically reduces the amount of time you spend debugging because you aren't hunting all over your program to find and fix a bug.

4. Modular code allows you to use better program architectures. It makes it easier to use event-structures, state machine architecture, and producer-consumer loops because you can control data flow easier and you have room to add or change functionality without breaking wires and risking breaking your code. Because you are free to use better architecture, your programs literally work better.

You would be interested in studying about "state machine" architecture, producer consumer loops, and event structures. There are great articles and labview code examples on each of these topics.

You are on the right track. I looked at my massive program block diagram and said the same thing as you, "there has to be a better way to do this." There is. It takes a little getting used to but the benefits are almost immeasurable for someone coding a lot.

rex

[Ben]

---

@rex1030 wrote:

...

You are on the right track. I looked at my massive program block diagram and said the same thing as you, "there has to be a better way to do this." There is. It takes a little getting used to but the benefits are almost immeasurable for someone coding a lot.

rex

---

Hi Rex,

The positive spin about that first app that you (and I in my own way) wrote is that it gives us a strong motivation to do it right and never do that again.

Ben

[F._Schubert]

As we are going to share the stories from our beginnings in LV programming, here is one of mine:

I wasn't really a noob any more, with about 1 year of professional work experience (and some more years of LV experience). It was my first project were the equipement was off-site, so I was traveling (by train) forth and back to test and release my latest code. I have a really old laptop, so little screen resolution. Then I watched a webcast (or other document), where an NI engineer was telling: If you really want to force yourself to write 'good' code, use a 640x480 (?) resolution.

Yoo, I did that. Event driven queued message handlers, 3 of them with a central queue based 'manager' (it get's the messages from each of the 3 displays on a single queue and sends messages to each of them on 3 queues). It's not really scalable, but there never was a request too add a complete new view to it, it (the architecture) really fit's is purpose. And I must admit that I never wrote a better-suited piece since then (due to a demand for faster products and a design shift for better scalability; just counting 'big' production-code not a small tool).

As a side note: 3 month after delivering the 'final' version, it stopped working. Guess what: I was using a global!

Please try and analyze the 640x480 resolution concept. It's actually not a limitation of your screen, but of your brain (remember: there is no spoon). You can very fast grip 3 pieces, but you slow down when it's 10 ('many') pieces.

Felix

[Ben]

---

@f. Schubert wrote:

...

Please try and analyze the 640x480 resolution concept. It's actually not a limitation of your screen, but of your brain (remember: there is no spoon). You can very fast grip 3 pieces, but you slow down when it's 10 ('many') pieces.

Felix

---

Don't understand the spoon reference but the rest inspires me.

I used to work with one of the old LV experts (published in LTR remeber that?) that spoke of 8 to 12 objects on a diagram.

12, a dozen is a special number because (no I will not resort to the Old Testement) but but because a 3 X 4 matrix (12 elements) can be spotted at a glance when counting (objects are often sold by the dozen). There are exceptions but most people can quickly ID a group of three or four elements without resorting to counting.

I have carried that message with me as I code and there seems to be validity in keeping the number of operators small to ensure understanding.

But that is just one way of looking at a diagram.

THere is also the aspect of presentation. Many operators can be on a diagram and if the presentation is right. Now at the risk of "showing my dirty underwear" I offer this image as an example.

\

In that diagram you see more than a dozen objects and judging by the scrool bar, there may be as many as 50 objects on that diagram.

Just my morning thoughts,

Ben