software engineering with LV

[differentstrokes]

We are going though a Test Standardization effort at my workplace. LV architecture and Test Data Management are our major concerns. I wanted to know if you guys had some examples illustrating different LV architectures in action and if there were more presentations like NI's Design pattern doc i.e. on software engineering with LV.

If could you point me to the right resources, I would appreciate it.

[dhuff]

I would highly recommend read the book "A Software Engineering Approach to LabVIEW" by Jon Conway & Steve Watts ISBN 0-13-009365-3 as a primer.

<http://vig.prenhall.com:8081/catalog/academic/product/0,1144,0130093653,00.html>

There are lots of good and different LabVIEW books out there, here is a link to an old list:

<http://www.warwicktech.freeserve.co.uk/labviewbooks.html>

While you are starting this effort, you might want to start looking at a few major issues you should at least think about such as:

1. Not every VI can be written to be reuseable, but how do you want to share or reuse VI's?

2. Are you trying to use these VI's with other software? (TestStand, LabVIEW RT/FPGA, LabWindows CVI, HP-VEE, etc.)

3. What type of source code control are you using? (You should be definitely looking at using source code control if you have more than 1 user using the same VI's

4. How are you going to share them, over a network or server, seperate copies, etc.

5. Which Labview Versions will you support? 6.1,7.0,7.1,....

Keep in mid that each company will have slightly different ideas and practices, you need to try it until you find something that works for you

[hviewlabs]

We are sure our LabHSM toolkit will be of great interest for anybody interested in advanced LabVIEW architectures. LabHSM is a professionally designed toolkit that allows creating complex event-driven LabVIEW application as an easily maintainable collection of asynchronously communicating active objects ( actors ) based on a universal Hierarchical State Machine ( HSM or statechart ) template. The LabHSM toolkit enables the programmer to work on a higher level of abstraction and utilize agile software development methodologies combining design and coding in one highly flexible process. It is available for free unlimited trial period download at http://labhsm.com.

[yao]

The LabHSM  toolkit enables the programmer to work on a higher level of abstraction and utilize agile software development methodologies combining design and coding in one highly flexible process. It is available for free unlimited trial period download at http://labhsm.com.

3636[/snapback]

Is there any function limited of the LabHSM toolkit trial version :question:

[hviewlabs]

Is there any function limited of the LabHSM toolkit trial version  :question:

3637[/snapback]

Not really, except the nag screens and inability to create working VIs from the template unless their names start with "Demo_". Watch for a new version coming soon, which will automatically create and delete Actions cases on the block diagram as they are created and deleted in the LabHSM Editor.

[hviewlabs]

Is there any function limited of the LabHSM toolkit trial version  :question:

3637[/snapback]

The latest demo version (1.1) also limits the maximum number of states, events and actions in one HSM VI.

[PaulG.]

We are going though a Test Standardization effort at my workplace. LV architecture and Test Data Management are our major concerns. I wanted to know if you guys had some examples illustrating different LV architectures in action and if there were more presentations like NI's Design pattern doc i.e. on software engineering with LV.

If could you point me to the right resources, I would appreciate it.

Speaking from experience: I don't think you need to spend a lot of time and money coming up with documentation methods for your LV programs. I would highly recommend adopting a "state machine" as a standard LV program design for all top-level vi's and 2nd-level sub-vi's. 99% of anything you want to do in LV can be accomplished in a state machine, and they are inherently self-documenting. Simply mandate as "policy" all programmers utilize state machines and that all sub-vi labels are "visible". Also, mandate as policy all enum state machine controls will be strict type def's. When you "print entire documentation" of the "master" vi and all subsequent sub-vi's and controls you have a sufficient and basic documentation package. I have an application that contains over 600 vi's. It was written utilizing a state machine in the primary and high-level sup vi's and was documented in this way. It's very easy to pick up where someone else left off when making changes. I inherited the first revision (1.0a) and the only trouble I had making revisions was when a previous programmer didn't utilize these basic guidelines and I had no idea what he was doing. I've had to rewrite just about everything he did into this format. But now I'm at "1.9". 2.0 will be perfect and easily sold to ISO or anyone else who requires documentation. And if I get hit by a truck tomorrow the next guy could step right in and cover for me.