LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to build a big application with no difficulty? Smaller is easier than big one.

I have learnt a lot of building smaller programs but then I start to build large applicatiosn, I run into lot of errors or unstable running. How do I incorporate small programs into big ones so that each small can co-exist with other small ones? For eg, I build an small program to select and display and then run the test based on the selection?
0 Kudos
Message 1 of 5
(2,972 Views)
This is (IMHO) a fundamental question in computer programming.

The discussion quickly enters into areas of Architecture, Development processes and so on. Since I'm not actually a trained Programmer (I'm a learned Programmer) I don't know what these all really mean.

In my experience, it's important to know what you want to have at the end of your work before starting to write the smaller pieces. You need to know HOW, WHERE and WHEN the parts should work together. Then you can start thinking about the best way to do it.

Make sure you keep functions grouped logically. Try to keep "variables" local, so that they don't need to be passed around all over the place (Filenames for example). This will lower the risk of closing a file in onepart of the program
, while trying to write to it in another part - thus causing a problem. Keep all writing to a single file in a single place. (for example).

I've started linking programm "parts" together using Queues, as this gives automatically a clean cut between the components, forcing you at the beginning to define the interface. It's also easier to debug, because the amount of "crossover" between components is reduced to a minimum.

Having said all this, I'll leave the way for other, more experienced "architects" to answer.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 5
(2,972 Views)
I agree with Shane.

I also am a graduate of the school of hard knocks.

At first your question "How to build a big application with no difficulty?" may sound like a contradiction but it is not.

I suggest you contact the closest CLA (Certified LabVIEW Architect, NO I am not a CLA!) in your area and ask them for some assistance.

I am not suggesting that you you just contract with them to do the work (although that would qualify as easy). Ask for them to advise on architectures or help with the design devlopement.

The issues you mentioned are the normal result of bottom up programming. Its sorta like inventing all of your tools for your workshop before you decide if it is going to be a wood shop or a metal shop.

Top down design would start with the big
picture/core functionality and then determine what are the challenges and what tools will be required. After that an architecture is assembled that address the requirements and challenges.

It is no shame to call on an experienced guide when doing this type of work. You can think of devlopers as explorers charting paths to new technological teritories. And staying with that analogy, even the greatest of explorers in history did not hesitate to utilize the assistace of local guides when avialable.

If you can afford a consultant, then I suggest you utilize this exchange to help. Keep your questions brief but to the point. Supply graphic aides when appropriate and we may be able to pull off a "group think" to get you were you need to go.

Done rambling for now,

Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 5
(2,972 Views)
What kind of errors are you seeing? What do you mean by "stability"? Does the program actually crash?

There are actually two quite different issues involved:

(1) Code design, maintenance and management:
Shane and Ben already gave excellent answers for that.

(2) Code performance and stability:
From your question, it seems you are struggling with errors and stability. This could indicate fundamental flaws in your programming approaches that prevent peaceful code coexistence as soon as a few modules are running concurrently.

Some mistakes I've seen:
-- Every module is "King of the world", polling for e.g. parameter changes as fast as they possibly can. Each tries to consume 100% of the CPU doing basically nothing. Example, looking at one of your ealier works HERE:

You have two FOR loops that have no data dependency, thus both run in paralell. The first loop is timed and occurs at a nice peaceful pace. The second loop runs as fast as it can, consuming all CPU, mostly reading the same value over and over and over again, each time re-doing what it just did.

-- Race conditions where several parts of the program read and write to e.g. globals and locals and the sequence of events is unpredicatable, e.g. one parts tries to read a varable before the other part wrote to it, one part is writing and another part is erasing at the same time, etc.
Strictly limit the use of local and global variables, they have limited purpose in the UI part but should not be used to shuffle data between different parts of the programs (as you did in the above quoted example),stick to wires whenever possible. Dataflow is a powerful concept. Breaking the dataflow makes the code unpredictable.

A well designed LabVIEW program has no size limits. There are huge projects with hundreds of subVIs that run without any problems.

I'd be happy to look at your code an scan for some common mistakes.
0 Kudos
Message 4 of 5
(2,972 Views)
Hi Shane, Ben n Altenbach

Thank you for sharing your valuable experience and lessons with me.

I have heard about top-down and bottom up programming and done subvi before. Just that I have never done a big program before and I encounter the problem initally.

But with good examples to learn, I will not have any problem building the big program.

Sure will ask you for help if I ever met any problem.

Thanks
Clement
0 Kudos
Message 5 of 5
(2,972 Views)