Rewriting a LabVIEW Program from Scratch

[dpg1]

Hi all,

For the past 5 months or so I've been writing a LabVIEW program. When I started, I was a complete newcomer, having never programmed anything before, learning how to use something in LabVIEW when I needed it. Also, as time has gone by, more and more requirements have become evident. As a result of this, the code is ugly, badly organised, the program loads slowly and is a nightmare to maintain. Because of all these things, I've decided the best thing is to start again, from scratch.

I'm posting here simply for advice. What hints and tips would you give me for this? How should I go about it? It's hard to motivate myself to do, because it feels like a step backwards, repeating stuff I've already done.

Any help is appreciated,

Thanks in advance,

David

[nathand]

Instead of re-writing the entire thing from scratch, you might find it easier to start by rewriting small portions of your code into subVIs, then integrating those new subVIs into the existing application.  It will make it easier for you to test as you go along and work on it incrementally.  After a while you should find that most of the key functions have been rewritten, and then you can take those reusable subVIs, drop them into a new project and you'll be most of the way there.

[JÞB]

David,

In This Thread I lamented when cought in a similar situation that required a code rewrite.  Several interesting tips showed up and some HOW NOTs  to avoid.

One thing to keep in mind is that you are not "rewriting" you are writing "new".

From my experience I have learned to take the following approach:

• Examine the archetecture-  is it suitable? what would make it better?
• Spell out the top three to five (or ten if you need)  "problems" and make generalizations about them (e.g. Too many Globals or Cluttered diagrams)
• "Modularaillaize" your concept (UI interaction, Data Acq, File generation etc...)

At this point, And no sooner, you can generate a potential preliminary design document.  List the modules and major components of the software and start to dig in.

Copy and paste as desired- but avoid re-using any sub-vi that you don't feel is "bullet-proof."   Intentionally write quality code.

• Write descriptions for your vi's and include inputs and outputs by name in your discriptions
• Write shell code (a vi with its icon, correct connector pane, Controls, indicators and its vi info but no wires)
• Put it together- and fill in the shells.
• Pat yourself on the back for writing a great piece of code
• cash your paycheck and move on.

 
Great Post

[Ben]

---

Jeff Bohrer wrote: 

...

Great Post

---

Mega-Dittos to you Jeff!

Ben

[Nihil]

advices like these and more you can find at "The LabVIEW Stylebook" by Blume (prentice hall) 

had the book recomended to me, and it does have very good information and methodology to use. (i'm still reading it)

see ya. 

[Mark_Yedinak]

Even more important than the excellent suggestions that Jeff gave you would be to define the requirements of the application. When defining the requirements don't allow yourself to get caught up in the "how" aspects of the application but focus on the "what". The requirements should not be concerned with how you will implement the system, what architecture you will use or specifics of how the user interface will look exactly. The better you define the requirements of what you need to implement the better off you will be in making decisions about the architecture of the system, what components or algorithms will be reusable, what data you need to collect, what reports will be required, etc. Choosing the architecture before you know what to do is not the best approach. You may find yourself forcing your solution into the wrong architecture rather than picking the architecture that will fulfill your requirements.

If you define the requirements you will be more able to estimate the effort. You will know when you are complete. You will have a better chance of providing a system that will do everything you need and can make intelligent decisions regarding how things will be implemented so you can maximize reuse and end up with a maintainable system.

Requirements should always be written to encompass a single item. They should be unambiguous. And most importantly they should be testable. If you can't write a simple test to verify the requirement your requirement is not written well enough.

Example:

Bad requirement: The system shall be easy to use. (This is not testable. It is not discrete.)

Good requirement: The system shall allow the user to enter a voltage threshold.

To refine this requirement you would have additional requirements such as:

The maximum voltage shall be 10.

The minimum voltage shall be -10.

The default value for the voltage shall be +5.

The biggest mistake most folks make is to jump in developing something without a clear definition of what must be developed.

[nitad54448]

hi

it also happened to  me (I am not a programmer, I am doing this mostly for fun !)when wires were everywhere and a guy who is pretending to teach labview told me that I can remove wires and put local variables 🙂 

then after the local variables period (I should call this period as Neanderthalensis Labvieweres NotSoSapiensis ..) I learned by myself, mostly from this forum, that there are other ways...Then I was in the period of Shift Registers

So, if I am allowed to make suggestions : take a look at templates mainly Producer Cosummer/ Master Slave and State Machine. I am using a lot the notifier and I am in the period of Clusterozaurus Rex. Finally look at Action Engine which is my greatest discovery after the state machine (look at "race conditions " in ben's signature ! thanks again ben) and now I am using everywhere, even if it's not that necessary, just to be sure to master it properly !

Regards

N

Message Edited by nitad54448 on 03-09-2010 03:08 PM

[dpg1]

Thanks for the great posts guys! I think I'm going to print out this thread and stick it up on my desk wall! It's comforting to know that I'm not the only person going through this frustrating problem!

[dpg1]

---

nitad54448 wrote:

hi

it also happened to  me (I am not a programmer, I am doing this mostly for fun !)when wires were everywhere and a guy who is pretending to teach labview told me that I can remove wires and put local variables 🙂 

then after the local variables period (I should call this period as Neanderthalensis Labvieweres NotSoSapiensis ..) I learned by myself, mostly from this forum, that there are other ways...Then I was in the period of Shift Registers

So, if I am allowed to make suggestions : take a look at templates mainly Producer Cosummer/ Master Slave and State Machine. I am using a lot the notifier and I am in the period of Clusterozaurus Rex. Finally look at Action Engine which is my greatest discovery after the state machine (look at "race conditions " in ben's signature ! thanks again ben) and now I am using everywhere, even if it's not that necessary, just to be sure to master it properly !

Regards

N

Message Edited by nitad54448 on 03-09-2010 03:08 PM

---

Quick question - where can I read about the action engine? I've just been reading about producer consumer architechture and it looks very useful for my application!

Thanks

[Mathan]

---

dpg1 wrote:

Quick question - where can I read about the action engine?

---

Ben - Community Nugget 4/08/2007 Action Engines

Give Ben a lot of Kudos for this.