LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Software documentation/diagramming methods

I am the lead for a small software team that builds large LabVIEW applications from the ground up for internal company use. Recently, we have started formulating an easier-to-maintain architecture using advanced LabVIEW methods. We are doing fine technically, but we are having issues adequately documenting our concepts and conveying them to eachother. None of us have a computer science background, so we are ignorant of standard diagramming and documenation techniques. Are there any LabVIEW superheroes out there that could point us to some good methods, books or websites to help us? We are particularly interested in documenting event-driven producer/consumer loops, queued state machines (QSM), daemons (aka active objets) and OOP. (A million points for anyone who can help document QSMs.)

 

Thanks in advance for any help!

 

-Andy

0 Kudos
Message 1 of 8
(3,779 Views)

I wouldn't know of any "standard" techniques.  Free labels, Tip Strips, Front panel object descriptions, VI descriptions are some the tools you have available to you.  As far as how you want to use them, I couldn't find a resource that discusses that.  Perhaps you could take a look at some examples posted on the community, like this, and see how others are documenting code.

 

 

Tejinder Gill
National Instruments
Applications Engineer
Visit ni.com/gettingstarted for step-by-step help in setting up your system.
0 Kudos
Message 2 of 8
(3,746 Views)

I'm not particularly looking for an NI-implemented way of documenting things. We use the methods you mention above and they are great if you are trying to understand a program that is already written.

 

I'm looking for techniques to document code before you write any code. I typically start by writing diagrams on napkins to discuss concepts with my peers, but my diagrams are hit and hiss. i'm looking for standardized ways to create these diagrams or perhaps a source of some good examples. One of my colleagues mentioned the Unified Modeling Language (UML). Has anyone used UML before? would this help me out in this case?

0 Kudos
Message 3 of 8
(3,740 Views)

If you are using OOP, then UML is a way to design your code before implementation.

UML is a standard way of modeling a object program, but it can also be used for standard programs.

 

0 Kudos
Message 4 of 8
(3,723 Views)

A neat tool I would reccommend is Violet UML (Freeware), its very easy to use and runs on JAVA so it runs on anything you can throw at it. Online help is a good read with useful tips on what diagram is normalled used for what.

 

- State machines are illustrated using state diagrams

- Use case diagrams are great for showing customers

- Sequence diagrams I use alot for an easy to understand overview of how a process might/should run

 

violet.sourceforge.net/

 

Great tool 😉

:. LV2010 SP1 ... W7 .:
Message 5 of 8
(3,620 Views)

@bazookazuz wrote:

I am the lead for a small software team that builds large LabVIEW applications from the ground up for internal company use. Recently, we have started formulating an easier-to-maintain architecture using advanced LabVIEW methods. We are doing fine technically, but we are having issues adequately documenting our concepts and conveying them to eachother. None of us have a computer science background, so we are ignorant of standard diagramming and documenation techniques. Are there any LabVIEW superheroes out there that could point us to some good methods, books or websites to help us? We are particularly interested in documenting event-driven producer/consumer loops, queued state machines (QSM), daemons (aka active objets) and OOP. (A million points for anyone who can help document QSMs.)

 

Thanks in advance for any help!

 

-Andy


I am in the minority that claim that a QSM simply can not be documented! Since the transitions are highly dependent on the initial state (what is already on the stack?) it (in my minds eye) is a chaotic system!

 

Others love it but still can't document it.

 

So since I design first and code second, QSM never enter the game.

 

I have used a number of methods to document designs. This thread has a couple of examples.

 

If this link works for you, it shows another example.

 

Lately I have been teaching myself LVOOP using Craig Larman's book "An Introduction to UML ...." which does not concider LV but covers UML and OOP patterns very well.

 

So I use UML for most of my work and if all esle fails, I just make things up. Smiley Wink

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 6 of 8
(3,607 Views)

QSM: If you have a 'real' QSM where the message consumer produces 1 or even more new 'state-messages', then you have a mess that can't be documented (as Ben said). Even worse, you are using an anti-pattern that is fundamentally flawed.

There is a thread on LAVA on the problems documenting it.

 

If you have a better designe like a queued message handler (the consumer never enqueues new states) or a state machine that has a specific state to check for new messages (an idle state for the dequeue), then you should look at the Sequence diagram and the state chart diagram of uml.

 

About uml, there is also a (still active) thread on LAVA about uml tools.

 

Also, I want to promote my NI commiunity group on uml. You are invited to start a new discussion (or do whatever else you find useful for your project) concerning any specific issues you face on modelling or documenting LabVIEW code with uml.

 

Felix

Message 7 of 8
(3,573 Views)

Sounds like you are more interested in model documentation as opposed to code documentation?  That is do you want to make it easier to understand an architecture vs. understand an implementation.  UML is a nice tool for modeling but is much better at OOP and sequential programming and yes I have too tried to doc a QSM program (not a finite diagram).  Some UML techniques are useful to labview.  I would be interested to see what turns in these discussions.

Paul Falkenstein
Coleman Technologies Inc.
CLA, CPI, AIA-Vision
Labview 4.0- 2013, RT, Vision, FPGA
0 Kudos
Message 8 of 8
(3,552 Views)