LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to document a labview project

Hi, I 'm involved a labview programming project. After I have finished all my VIs. I need to document them, so that the next person who will take over me, know how the VIs work. how am I going to do that? Can anyone suggest some good URL or can upload some sample reports? Thanks...
0 Kudos
Message 1 of 7
(4,896 Views)
I can suggest to use "Show VI info" - you can invoke it by Ctrl+I, or by
"Windows" -> "Show VI info". If you want to document parts of the program
you can right click the program part and open "Description".

Victor

"cpu" wrote in message
news:50650000000800000065310000-1005954886000@exchange.ni.com...
> Hi, I 'm involved a labview programming project. After I have finished
> all my VIs. I need to document them, so that the next person who will
> take over me, know how the VIs work. how am I going to do that? Can
> anyone suggest some good URL or can upload some sample reports?
> Thanks...
0 Kudos
Message 2 of 7
(4,896 Views)
"BROWSE - Show Hierarchy"? That show what vi's call what.
On Sun, 18 Nov 2001 20:52:12 -0800 (PST), cpu wrote:

>Hi, I 'm involved a labview programming project. After I have finished
>all my VIs. I need to document them, so that the next person who will
>take over me, know how the VIs work. how am I going to do that? Can
>anyone suggest some good URL or can upload some sample reports?
>Thanks...
0 Kudos
Message 3 of 7
(4,896 Views)
Hi CPU,
on NI site you can find this "LabVIEW Development Guidelines" [http://www.ni.com/pdf/manuals/321393c.pdf] and chapter 5 is all you need as a start point. The rest of it is useful too.
Good Luck!
Message 4 of 7
(4,896 Views)
cpu,

I try to include the following info in every VI/subvi:
1. General: (VI name, Version #, Date coded, Author).
2. Description: (paragraph that summarizes its overall functionality).
3. Specifics: (detailed sub paragraphs that specify unique or complex code).
4. Misc: (data type input/outputs, unique conditions for the vi to work, limitations, etc.).

Now, the way I input this info is 3 steps:
1. On the block diagram, I use yellow text boxes to label overall code phases or code subset names (e.g. Initiation phase, run phase, terminal phase, etc.), and light-blue text boxes representing the specific details (what the code is doing). I put these boxes right next to the code its pointing to. The colors just let it show easily.
2. After making s
ure those comments are good, I copy them onto the VI's documentation property field.
3. I also have a separate document (Word, etc.) that provides general overview of the entire project and refers to the VI's printed documentation for details on each VI (which is already documented).

This is how I do it (in an nutshell). It takes extra time, but always worth it. Also, there are topics relating for coding standards, etc., that will provide more ideas.
The main thing with documenting your code is to be sure you do it - one way or another. How you do it should also be consistent across all projects and their VIs.

Doug
Message 5 of 7
(4,896 Views)
Document??

like in the past for Fortran code you need not document - the code is
obvious!!

Tom


"Doug (CapeFl)" wrote:

> cpu,
>
> I try to include the following info in every VI/subvi:
> 1. General: (VI name, Version #, Date coded, Author).
> 2. Description: (paragraph that summarizes its overall functionality).
> 3. Specifics: (detailed sub paragraphs that specify unique or complex
> code).
> 4. Misc: (data type input/outputs, unique conditions for the vi to
> work, limitations, etc.).
>
> Now, the way I input this info is 3 steps:
> 1. On the block diagram, I use yellow text boxes to label overall
> code phases or code subset names (e.g. Initiation phase, run phase,
> terminal phase, etc.), and light-blue text boxes representing the
> specific details (wh
at the code is doing). I put these boxes right
> next to the code its pointing to. The colors just let it show easily.
> 2. After making sure those comments are good, I copy them onto the
> VI's documentation property field.
> 3. I also have a separate document (Word, etc.) that provides general
> overview of the entire project and refers to the VI's printed
> documentation for details on each VI (which is already documented).
>
> This is how I do it (in an nutshell). It takes extra time, but always
> worth it. Also, there are topics relating for coding standards, etc.,
> that will provide more ideas.
> The main thing with documenting your code is to be sure you do it -
> one way or another. How you do it should also be consistent across
> all projects and their VIs.
>
> Doug
0 Kudos
Message 6 of 7
(4,896 Views)
"tom" wrote in message
news:3BFF019F.D64A7960@NOSPAM.yahoo.com...
> Document??
>
> like in the past for Fortran code you need not document - the code is
> obvious!!

Well, it should be...


Labview programmers should always strive for simple to understand code.
Simple almost always wins over elegant. If you find a situation where
coding absolutely requires complexity, then put some notes right on the
diagram explaining what is being done.

0 Kudos
Message 7 of 7
(4,896 Views)