Template classes or interfaces for equipment

Question

Hello,
I am creating an experiment design pattern using Labviews object orientated functions. I'd like to say I'm very happy that labview incorporated object orientation and am looking forward to them implementing additional important object orientation features such as purely virtual classes (Interfaces) that can help get around the single inheritance issues for use in design patterns.
Anyhow my question is, does LabView currently have an object oriented template (i.e. purely dynamic VI structure) for equipment such as function generators and oscopes? I know they have a normal template with a project view, but this doesn't allow the flexibility of a java style interface.
Secondly, if you don't currently have them, i will need to create a few anyway, and I would be keen on posting them, especially if labview had a good place to share them. An OOP labview section would be really nice.
Greg Sonnenfeld

Answer 1

>>I don't have any practical experience with
LVOOP, so I'm not sure how much its by-value design is appropriate for
creating instrument drivers. That said, you should have a look through
the LAVA forums' OOP forum (it also has a code repository section you can post actual tools to). Additionally, NI has their new DevZone community area, where you can post code.
While the pass-by value design has some draw backs, it still allows for the very valuable usage of design patterns in development.
Consider an application that needs to use a Digital Multimeter (DMM used for simplicity). Labview currently has a standard VI template for the development of drivers for a DMM. So most vendors will implement VI's with the same VI prototype. With functions such as:
VisaAddress initialize(VisaAddress visa);
VisaAddress:Float getVoltage(Visa Address visa);
Consider a software where the type of digital multimeter is not know until runtime, or the same code will be run at multiple sites on different equipment, or a program that maybe use several different types of multimeters depending on the preference of the user.
Instead of developing our code with a specific VI library, we instead develop the DMM portion of the code using an interface ( A purely dynamic VI with no implementation or perhaps linked to a virtual device). We will call this class "DigitalMultimeterI".This code could then be run without throwning errors when no equipment attached. Furher more, it could allow for a unit test of the code to ensure functionality without needing a device.
Case 1
Now it would be time to link our equipment to our code. We simply find a vendor implementation (a class that inherits the interface and overides all of its dynamic VIs) of the class DigitalMultimeterI, we'll call the DigitalMultimeterVendor, and wire it to the port that accepts a DigitalMultimeterI class.  Labview recognizes to call the VI that is associated with the DigitalMultimeterVendor class where ever a DigitalMultimeter VI is placed.
Case 2
Consider an extension of the previous case, where two different DMM brands are being used.  During runtime, a user is given the option to choose between 2 different DMMs. If both DMMs drivers are implementation of the DigitalMultimeterInterface class, the code can uses a simple switch case statement to determine which object to pass into the experiment logic. No additional programming is needed.
Case 3
Consider a piece of code that may be used at multiple physical locations between many collaborators. A core skilled labview designer can create all the experiment logic using interfaces and distribute the code to multiple sites. The recipient scientists or engineers at these sites can then choose an appropriate implementation of the Equipment Interface class to fit the equipment at their laboratory with little knowledge of labview. In fact, by dynamically loading an equipment implementation object at runtime, perhaps by using a call by file path method, the recipient scientists or engineer may be able to use the code without ever having to do any programming. The would simply have to select an appropriate class file.
We see now, that by utilizing interfaces and design pattern in our experiment logic, we have created an "agile" framework that embodies the principles of component orientation. Such design methodologies enable developers to significantly improve code re-usage, reduce development time, decrease debugging time with unit test, allow easier multiuser development and increase end user satisfaction. All of which will increase the value of the Labview software and likely reduce the work load on Labview support engineers.
-Greg Sonnenfeld