Labview Proyect Documentation

[benzewin]

Hello,
I would like to know a good Documnetacion of a project in Labview that is recently implemented to be able to base some example and complete the existing documentation in the project of my company.

I hope you can help me.

Thanks

[Bob_Schor]

I'm a great believer in Documentation, preferably begun no later than when you start to develop your LabVIEW code (best, of course, is before you begin any coding).  I strongly recommend two useful tools:

• A good Document/Word-processing system that you like to use and feel comfortable using.  It should be able to allow you to create lists, tables, insert figures, create captions (for tables and figures), and produce PDFs (so your readers will not need any special-purpose software to read the documentation).
• A good screen-capture-and-anotation program, useful for including images of Block Diagrams, Front Panels, hardware configurations, etc.

Think about how you want to organize your Documentation.  I usually start by Describing the Problem or Task, which might also involve a description of the Hardware or Third-Party Software that needs to be incorporated.  There should also be a section discussing Requirements that the Project needs to meet.

What Design Decisions need to be made?  What are the considerations that dictate how you make them?  The Reader should be able to see the logic behind your choices -- he or she might not agree with them (we all have our prejudices), but your logic should be clear.  An example from a recent Document of mine was my description of the Folder/File Structure I employed for the Data Files -- I chose a simple hierarchical Folder Format that had a short Unique Name, a 3-digit numeric suffix for each set of data collected under this Name, with individual Stations (there were up to 24 simultaneous tests being run having an additional 2-digit suffix for the Folder where the specific Station files were stored, leading to a path of the form

\\<Server>\BSTest-002\BSTest-002-03\BSTest-002-03.hedr for the "Header" file for the third Station, second Run of Experiment BSTest).  As you can see, I often use my own unique 4-letter Extensions to distinguish the various "flavors" of data files.  This makes creating subsequent Analysis or Data Processing routines to deal with the Data able to easily find the files that they need once they are pointed at the root of the File Structure hierarchy.

The best advice, however, is Start Documenting Early, and Document Often.  I would say that you should spend at least 20% of your effort (if not more!) in producing Documentation, and definitely should do it as or before you are creating the LabVIEW code.

Bob Schor

[benzewin]

Thank you very much, Mr. Schor, for your response.

We commission a program with labview to a vendor and the problem is that it is a complex program programmed with calses and with 1500 VIs. The issue is that I do not have any documentation of the program. The Vis are not complex but when I get to know by myself the operation of the program as a whole I find that I am in a jungle.

I wanted to know what I should need to be able to try to be autonomous and carry out my proposed modifications without having an associated cost.

I know that knowing the program and acquiring that level will take time but what I want is to know what information it takes to get to that level in documentation mode

[Bob_Schor]

When I started learning LabVIEW, I was in almost the same situation.  I inherited a complex Real-Time routine with 160 TypeDefs, 625 VIs, and 12 LLB (containing numerous VIs and Typedefs).  None of the VIs or Types were documented.  Many of the larger ones had block diagrams that took up to 20 screens to visualize.  And it didn't work all that well.

I was tasked with maintaining it, fixing the features that "didn't quite work", and possibly "making it better".  What I did was to "Start Over", re-designing the entire Project.  I should say that the original code was written in LabVIEW 7.0, which preceded DAQmx and the LabVIEW Project environment, but both were available by the time I began my redesign.

Documentation was a key part of the redesign process.  So was using Version Control (TortoiseSVN) and writing test routines as I went.  The final product involved about 880 VIs (there were three Support Libraries to handle three slightly-different Versions, depending on the hardware being used) and 150 TypeDefs, with nothing hidden in LLBs.  Every VI was documented, and the entire Project was the subject of numerous (10 Word and 32 LaTeX) White Papers, many developed before or during the Coding Process.

This was definitely not an easy process, but it was much quicker and far more productive than attempting to "patch" and repair the design flaws of the original system (we accidentally "did that experiment" -- a talented BME student was using a version of the original code in another lab, and, working together, we "improved" (and documented as we went) some of the sub-systems, but it was still riddled with flaws and barely maintainable).

Bob Schor