building large programs in labview

[dsavir]

Hi,

We have a LV program that numbers 100s of VIs. It was written in a "patches" method: A basic program was written, then the customers wanted a new feature and a "patch" was added, and then another, etc. The result is... a horrendous program, that is almost impossible to update without changing everything.

We are now changing our hardware and want to rewrite the software as well. Now there are a lot more tools then there were. Do any of you have any tips on how to design it and what tools to use? We have a lot of features, a lot of variables, and everything is subject to change.

The tips I have seen so far:

1) Plan in advance (but how do I plan in advance for changes I don't know yet?)

2) use typedefs

3) do NOT use globals - use action engines or queues

4) split the program into modules by functionality (what if many modules need to use the same basic function? won't that cause a problem? How best to pass data between modules?)

Do you have any other ideas?

Some requirements:

- a wizard (as we have lots of options, a user wanting to perform a simple function usually gets confused)

- Memory efficient (the current program gets hung up on memory). I have read up on managing large data sets in labview, I am just not sure how to incorporate it in a large program.

              to ALWAYS have in and out pins of an array in a subvi so it won't copy?

              to allocate in advance and adjust the size of arrays in blocks?

              use queues and not arrays?

- we scan images of size up to 5000x5000  16 bit pixels, 16 channels. How best to store such data?

Any ideas and tips would be welcome!!!

Danielle

[Harold_Timmis]

depending on the project you may want to use a state machine to make you application more efficent whether it be a test executive state machine, Sequence state Machine, queue state Machine.....

[muks]

Hi Danielle,

Welcome to the other face of labVIEW.I will tell you one similar case where I was involved. I was using lv 7.0 then and a program written in 6.0 has to read and modified. The code was almost impossible to be understood. It was a really heavily wired vi with some 80-85 subvis. Frankly it took me almost a day to figure out where should I begin from. It was definetly not enjoyable. There were hundreds of global variable and once u click it the list will load for some 30-40secs. 

Dont touch the master vi. It is the only thing with you to buy some time. Get the input and output. Dont think about optimizing the speed . Build your subvi Independently. Try inserting it after knowing your input and output. Test it and extinguish the fire momentarily. 

Now go back to our tried and tested method of pencil and paper. Divide the whole project to individual modules. divide them further into sub-modules and concentrate on them alone. LABEL each and every submodule. Save a copy of your vis with a daily note. 

Imagine a worser scenario. If you have been given a code of say 50,000 lines to begin with..............

[muks]

---

Plan in advance (but how do I plan in advance for changes I don't know yet?)

---

This always happens. If there are no revisions in your code then you are coding for your own company... Keep a revision control and document the changes along with a date.

[Ben]

---

dsavir wrote:

Hi,

We have a LV program that numbers 100s of VIs. It was written in a "patches" method: A basic program was written, then the customers wanted a new feature and a "patch" was added, and then another, etc. The result is... a horrendous program, that is almost impossible to update without changing everything.

We are now changing our hardware and want to rewrite the software as well. Now there are a lot more tools then there were. Do any of you have any tips on how to design it and what tools to use? We have a lot of features, a lot of variables, and everything is subject to change.

The tips I have seen so far:

1) Plan in advance (but how do I plan in advance for changes I don't know yet?)

2) use typedefs

3) do NOT use globals - use action engines or queues

4) split the program into modules by functionality (what if many modules need to use the same basic function? won't that cause a problem? How best to pass data between modules?)

Do you have any other ideas?

Some requirements:

- a wizard (as we have lots of options, a user wanting to perform a simple function usually gets confused)

- Memory efficient (the current program gets hung up on memory). I have read up on managing large data sets in labview, I am just not sure how to incorporate it in a large program.

              to ALWAYS have in and out pins of an array in a subvi so it won't copy?

              to allocate in advance and adjust the size of arrays in blocks?

              use queues and not arrays?

- we scan images of size up to 5000x5000  16 bit pixels, 16 channels. How best to store such data?

Any ideas and tips would be welcome!!!

Danielle

---

I have been impressed with LVOOP and its ability to allow modifications after the fact. Its dynamic dispatching allows us to deploy an application today that can utilize feature developed tomorow.

1) Find a domain expert that really knows the area addressed by the app. Pick their brain about "crazy ideas" they may have. Ask "stupid questions" like "So do you think they will want to run this backwards or inside out?  Think about what they could ask that could cause you trouble. If they rule it out, document it so you have justification for not including that option (then include support for it any way, they will change their mind latter anyway )

2) LVOOP is really a more powwerful version of type defs. If you can make the paradigm shift, do it.

4) UML really helps to break things up. If developed using LVOOP the smae "blcoks" can be used for similar classes, with dynamic dispatching deciding when to invoke the "special" versions as dicatated by the class.

Regarding performance:

This tag along with its associtated tags contain a collection of links that I have put together to let anyone that is interested in LabVIEW Performance to become an expert. Please review those links and study the suggestions made there.

Just trying to help,

Ben

[JÞB]

---

muks wrote:

---

Plan in advance (but how do I plan in advance for changes I don't know yet?)

---

This always happens. If there are no revisions in your code then you are coding for your own company... Keep a revision control and document the changes along with a date.

---

A very common question!  any good programmer will tell you that changes will happen and you must plan for them.  The how it the tricky part.  LabVIEW can do just about anything so plan for anything.  Suppose you have a function that well call "Get Reading"  depending on certain options or conditions this could be just about anything but, we know (at the most abstract level) it will have an input that describes the reading to take and an output that represents the reading.  So, let the caller of this function decide which revision of what vi to launch. 

Abstraction and cohesion are the keys to good maintainable code.  Read up on the subjects and PRACTICE with simpler projects to develop a coding style that  makes sense for your ultimate goal.  Try the CLD exercizes and preparation materials!  these will help focus your view on code modulrarity and design.  Then you will be able to adapt your thinking and experience to a larger scale proble.

It seems far too common that developers forget that scale is a huge factor.  A simple vi can be developed quickly has few interactions and is easy to follow so when we start out we commonly ignore the documentation (both within the vi and on paper) and develop working code and BAD habits at the same time.   You HAVE to intentionally break the habit of shooting (coding) from the hip and relearn coding by intention.  You CANNOT learn it in one shot so start small and master the basic skills of documenting and then coding.

Good luck!  Great post!  

[JÞB]

---

Ben wrote:

---

Think about what they could ask that could cause you trouble. If they rule it out, document it so you have justification for not including that option (then include support for it any way, they will change their mind latter anyway )

Ben

---

Kudos!  No more need saith I

[dsavir]

Thanks, all of you!

Ben, thanks for the tags and advice. I thought of OOP but it looks so unintuitive ... een though I like OOP in other programming languages. I'll give it a shot. But what is UML?

Harold, how do I use state machines in Labview? Is it a design recommendation or an actual tool? How would it work, a VI for each state? How does that fit with modular design (if it is supposed to)?

Thanks again!

Danielle

[Ben]

UML = Unified Modeling Language ( See Wiki here  )

It is a loose set of semi-standard diagrams that let us define the parts of an application. The diagrams function as tools to let us represent the beaviour and interactions of system components.

By analyzing an applications requirements at a "high-level" we can identify the "modules" and refine how they will be be implemented and allow us to plan for changes. I have not completed reading it but I think it is Craig Larman's "An Introduction to UML and Patterns" book where I learned most of the little I know about UML. THe part I really like is that the diagrams of UML are tools in a tool-box that I can pull out when they are handy but if I don't have a need to for one of them I can ignore it. Most of the time I can draw the line at the "System Sequence Diagrams" (see wiki) that detail a "straight line" flow of execution.

Ben

[DFGray]

Here is a link to a presentation I did on large applications a long time ago.  The basic ideas have not changed much.  It gives an example of a queue driven state machine.  I would not recommend using the data repositories it uses.  I would recommend action engines or single-element queues.  As Ben mentioned, LabVOOP objects are also very useful, especially if wrapped in a good data repository.  The easiest way I know to do this is create your LabVOOP object, then use the single-element queue to hold only the object reference.  Check the object reference out by dequeueing.  Check it in by enqueueing.  Single-element queues are a natural for this, since a dequeue automatically locks the object.  Putting the object back on the queue unlocks it.

To give you some encouragement, I was in your position about four years ago.  I had a piece of code consisting of a couple hundred VIs that had been hacked on by about six programmers over five years (and I was one of those programmers).  It was a mess.  It could not be modified without breaking something.  I refactored it in about two weeks.  I reused most of the original code by putting it into subVIs.  The main change was to the overall program structure.  Instead of a complex, custom set of loops and case statements, I changed it to a simple array-based task handler (the code was executing a predefined set of commands, which could change from run to run).  I now had one loop and one case statement, and I could easily add more tasks by adding another case to the case statement.  The code is now over 500 VIs and is still easy to modify.  It can be done.

Good luck.