Documentation Tools for LabVIEW

[Mike Ashe]

Hi all,

We're here in this topic to discuss everyones favorite engineering activity, as it applies to LabVIEW.

That's right, you guessed it, it's ...... (drum roll please)

Documentation of your completed project !

Oh I can here the cheers now, the excitement out there in reader land. Okay, maybe not. As a matter of fact most of us would rather watch paint dry than do documentation. But it is a part of being professional on a project, and since in truth we all probably hate it, and would like to get through it as quickly as possible so we can get one to the next design and coding project ... well I looked through the forums and did not find a topic dedicated to tools, tips, techniques, code snippets, etc that will help us do documentation of LabVIEW.

Along those lines I also think the community needs some really innovative tools, and relatively inexpensive tools to help with docs, ranging from free, open source, to reasonably priced tools that cost.

Now that I've opened the subject, I'll let others chime in for a while, then I hope to be finished with cleaning up a couple of small tools here that I use regularly. They do not do thewhole job, but they help.

:thumbup:

[Chris Davis]

You have brought up a good topic. I'm sad to say that I don't have any dedicated tools for this work. My most recent trip down this path, I ended up using the HTML page generation of code and creating a ~15 page software maintenance document on the code structure, as it was when I finished the project. This was coupled with the acceptance / installation test document, the users manual, work instructions for the end user.

I typically place a free label on the block diagram, the front panel, and in the VI properties containing the same information on the project, author, and subroutine name, as well as a description of what the subroutine is supposed to do. In my last project I made sure that all indicators and controls had descriptions that matched thier purpose. That was a lot of work!

Perhaps if there was a tool that would gather all of the control and indicator descriptions into one place to be edited and reloaded into thier respective subroutines (and saved back out).

I'll be watching this topic with interest.

Chris

[Irene_he]

Perhaps if there was a tool that would gather all of the control and indicator descriptions into one place to be edited and reloaded into thier respective subroutines (and saved back out).

I'll be watching this topic with interest.

Chris

Yes you can do it with vi server. Load all vis you want to document into memory, then get all vis in memory with vi server, open references to those vis (using a for loop with index) and get all controls' descriptions of each vi and save them into a text file with proper formating for easy read back and decode later. That way you can edit the text and read back to assign to each controls using the vi server technique again.

Thanks.

Irene

[crelf]

<Shameless Commercial Plug>

There is such a tool available: The VISTA Documentation Manager and Documentation Generator - check out the links on the left side of the page. I have the luxury (and it is a luxury) of working for V I Engineering, so I get to use these tools (and more) internally for free, but even if I worked somewhere else, I would still certainly use these tools. From our website:

VI Documentation Manager

Quickly edits VI descriptions, controls and indicators. Improves productivity when documenting VI

[WMassey]

Perhaps if there was a tool that would gather all of the control and indicator descriptions into one place to be edited and reloaded into their respective subroutines (and saved back out).

Attached is tool that I built for selectively moving Tips & Descriptions from one VI to another. It also allowed me to edit them along the way and do a spell check. It might provide you with the basis (or at least inspiration) for building the tool you suggest. (LV v7.1.1 & OpenG required)

Download File:post-2800-1142695660.zip

[LAVA 1.0 Content]

<Shameless Commercial Plug>

There is such a tool available: The VISTA Documentation Manager and Documentation Generator - check out the links on the left side of the page. I have the luxury (and it is a luxury) of working for V I Engineering, so I get to use these tools (and more) internally for free, but even if I worked somewhere else, I would still certainly use these tools. From our website:

<Shameless Commercial Endorsement> :2cents:

I have been using these tools for a few years, I would not say that knowing I have these tools makes me excited about documenting my code . However, when forced to document these tools certainly make it less painfull.

[crelf]

I have been using these tools for a few years, I would not say that knowing I have these tools makes me excited about documenting my code . However, when forced to document these tools certainly make it less painfull.

I can't say I know any software engineer that is ever excited about documenting code - we usually just wanna write more code

[Mike Ashe]

Okay, we have our first commercial tool(s) and first freebie utility. Aside from their functionality, the VISTA tool gets points for being relatively affordable and the Copy Tips utility gets points for reuse of OpenG code.

Great opening moves guys, anybody else?

[Jim Kring]

The documentation for the Dictionary library of the OpenG toolkit is generated dynamically. Show the context help for one of the library members and then click on the online help link to open the HTML help in your browser. For extra fun, click on the example links.

[didierj]

I usually try to make parts of the documentation before and while I wire.

As I usually base my projects on openGoop and state machines the docs that usually have to be created before are:

- state diagram

- class hierarchy (maybe better "class diagram", since openGoop doesn't know inheritance so far)

- use cases

- if needed sequence charts for special parts of the code that might get complicated to understand

Most important is to keep these documents updated while working on the code.

...but as I'm just human, many tools and parts of the code are done in a "quick-and-dirty" manner that lacks of any documentation. :thumbdown:

Didier

[Jeffrey Habets]

The documentation for the Dictionary library of the OpenG toolkit is generated dynamically. Show the context help for one of the library members and then click on the online help link to open the HTML help in your browser. For extra fun, click on the example links.

This is pretty cool... :thumbup:

For me personally, I'd leave out the Error in and out. We all know what they do and they just clutter up the documentation page. (Wish NI would do this too..) And maybe some nice headers for grouping inputs and outputs.

[Mike Ashe]

The documentation for the Dictionary library of the OpenG toolkit is generated dynamically. Show the context help for one of the library members and then click on the online help link to open the HTML help in your browser. For extra fun, click on the example links.

I seem to be having a minor problem. When I did that Firefox reported that it could not find page <filename> and I noticed that the name ended in ht not htm. So I tried it again, except that the more help button does not even press now. Any ideas?

[Jim Kring]

I seem to be having a minor problem. When I did that Firefox reported that it could not find page <filename> and I noticed that the name ended in ht not htm. So I tried it again, except that the more help button does not even press now. Any ideas?

Mike: I've seen this, too. I don't know whether to blame LabVIEW, FireFox, or Windows. The problem seems to come and go. Does it work for you in LabVIEW 8.0?

This is pretty cool... :thumbup:

For me personally, I'd leave out the Error in and out. We all know what they do and they just clutter up the documentation page. (Wish NI would do this too..) And maybe some nice headers for grouping inputs and outputs.

Jeffrey: That's a great idea. Those error clusters take up a lot of valuable space. It might take a =bit of work to exclude these controls, since I am just delegating the task of generating the input/output control/indicator documentation to some built-in functions.

[Mike Ashe]

Mike: I've seen this, too. I don't know whether to blame LabVIEW, FireFox, or Windows. The problem seems to come and go. Does it work for you in LabVIEW 8.0?

You would have to ask that. I don't want to admit how long it had been since I had updated Commander & my packages to the latest versions. This was in 7.1 I suppose I should be honest and admit that I haven't installed on 8.0 yet, so I guess this will give me my excuse...