template classes or interfaces for equipment

[Gsonnenf]

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

[tst]

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.

As for the Java-like interfaces, maybe this will help.

[Karunya_R]

Greg,

I will create a product suggestion for you on shipping LabVIEW with templates. There is a LabVIEW shipping example that explains how to create objects by reference.
 

[Gsonnenf]

>>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

[tst]

As I said, I don't have any practical experience with LVOOP (I use 7.0, which didn't have it), so I can't comment on the details.

I seem to remember that there used to be an issue where LabVIEW needed to load the entire class tree into memory so that it would know which VIs it can call to override methods in parent classes, so that might be a problem for you. I don't know if this was changed.

As for your other thread, 8.2 was the first version which introduced LVOOP, so some things were probably buggy there. I would suggest going over the forum at LAVA to see what people have already done, as you should be able to find some interesting stuff. Similarly, searching for "LVOOP" here should probably also yield some results.

[Gsonnenf]

Hello,

I had already looked at LAVA prior to posting the previous thread and found interesting content but nothing relevent to this specific issue. I welcome anyone with LVOOP to contribute their thoughts to this thread.

Greg Sonnenfeld