About Graphical Object Oriented Programming (GOOP) in LabVIEW
GOOP®, Graphical Object Oriented Programming, is a method and addition to LabVIEW developed in close cooperation with National Instruments. GOOP enables Object Oriented test system design in LabVIEW. By using GOOP your test systems will be better designed and much easier to maintain and change in the future. GOOP is an Endevo trademark.
Benefits
- Scalable – The code controlling one instrument can easily control many instruments by creating several objects.
- Extendable – By utilizing inheritance new functionality can be added without modifying existing code.
- Modifiable – Use classes to achieve a good system structure. Each class having its own responsibility.
- Testable – Test each class standalone before integrating them.
- Easy-to-use components! – Using object oriented code is easy and requires no knowledge about object orientation.
- Reusable – Use classes to create a common code base in your development.
National Instruments has Released Object Oriented Programming in LabVIEW 8.20!
In LabVIEW version 8.20 you now have native support for object oriented programming. Having OO support in LabVIEW opens up great design possibilities. This is something Endevo has been promoting and used for more than 10 years.
Endevo tools - Embracing the LabVIEW Object Oriented Programming Support
The Endevo tools allows developers to leverage the native OO support and the project environment. Adding features like code generation from UML for both native OO and GOOP 3, and the GOOP Development Suite allowing custom class templates based also on native classes.
What does National Instruments Object Oriented Programming support look like?
It provides full object oriented support: classes, inheritance and dynamic dispatch VIs (corresponds to Endevo GOOP®2 virtual methods).
The main difference compared to Endevo’s GOOP support is that NI provides objects by-value. You can think of a native class as a "glorified cluster". The wire will actually contain the object, as compared to Endevo GOOP where the wire contains a reference to the object. If you have a native object in a wire and the wire forks you will get a new copy of the object. If you wire the same native object into two loops you will get two objects and the loops cannot communicate through the object as you are used to with Endevo’s GOOP.
GOOP and Native OO
Endevo is convinced that although the object oriented support released by NI is very useful it is not complete. There are many situations where you actually need objects by-reference (GOOP). Examples of situations where you may prefer the by-reference model includes: when modelling resources (like instruments and files etc.), and also when modelling protocols, graphs and tree-structures the reference model make a lot of sense. Also in any situation you need to control when objects get created, the by-reference model is natural.
Therefore we continue not only supporting but also developing new versions of our tools. We will ensure code already created by Endevo will continue to run on future LabVIEW versions as we have done in the past.
Coming Releases
Keep monitoring Trial page to ensure you don't miss any new releases of the GOOP Development Suite.