LVOOP vs GOOP

I've recently started toying around with incorporating LVOOP into my larger LabVIEW programs.
I have seen the terms LVOOP and GOOP thrown around, but I'm not entirely sure I understand the difference.
This is my understanding, please let me know if I am incorrect, or missing something.
Both terms refer to using LabVIEW in an object oriented fashion.
In both types of programming, you can create a class.
Using this class, you can create both objects and methods of the class.
The main difference would be how information stored/passed.
In LVOOP, the actual objects are being passed around,
whereas in GOOP, references to the objects are being passed, rather than the actual object.
Is this correct? Are there more differences?
Spoiler (Highlight to read)
I have a feeling Ben is going to jump into this discussion at some point
I have a feeling Ben is going to jump into this discussion at some point
Cory K
Solved!
Go to Solution.

LVOOP is native to LV.
GOOP was Edevo implementation of OOP that was implemented with the cooperation of NI.
They both allow implementing OOP in LV.
I have studied GOOP but never used it becuase of how it was implemented, using references. Acces to the private data was allowed using a Core that was a kind of uber-AE capable of string anything. This implementation restricted developer rom amaking changes to the Core and as a result, we limited to using what the core exposed which were COPIES of the dat in the Core. The COPIES part is what kept me out of the GOOP since my applications simply can not tolerate buffer copies.
The big plus for GOOP was it supported UML and could gen classes based on the UML or gen the UML from the classes (to a limited extent at least).
I believe it is no longer being developed (but I may be wrong there).
LVOOP has no knwolege of UML. It is very efficient provided i don't stupid stuff. It is also very flexible.
With the morder versions of LVOOP and the introduction of the DVR (data value ref) LVOOP can now pass refs to access instance of class data.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

Similar Messages

Getting very large application with LVOOP

Hello to everybody
I'm programming a quite large application using LVOOP. The application will later be split in several dll's which are called by a C++ main program, so instead of having a large 6MB executable I expected to have a few smaller dll's up to a size of 1MB. Using a "by reference approach" using objects stored in queues everything seems to work, however I noticed that as soon as an exported VI is a member of class the resulting dll will compile all the other members of the class and include that code in the dll. So even an empty(!) VI exported to a dll will have a size of about 4MB. If I drag the VI out of the class the VI still has somehow the class information stored inside the VI and the resulting size of the dll will be the same. I'm wondering if anybody can confirm this strange behaviour (?). Since the application must be transmitted over slow analog modem lines the application size matters and I might be forced to recode my application using GOOP, something I basically want to avoid. Also compiling takes a very long time.
Alex

Hi Alex,
this seems to be normal behavier, all members of a class will be included in the dll. In addition you have to take care about your parameters, LabVIEW objects can only be processed inside the dll. Classes cannot be transfered as output parameter to your C/C++ development environment, using conventioal datatypes as parameter is possible.
regards,
Nikolai

Arm goop password

Hi,
I just installed the LabVIEW Embedded for ARM evaluation kit with the LM3S8962.
A basic project will compile and download perfectly. (Amazing how well this works!)
However, as I'm primarily a SW dev, I am a firm believer in GOOP and other OO technologies. I can create the class and call it in the main VI, but when I go to compile the project, the compiler asks me for the password to a deeply embedded VI (which I do not have) and, after failing to validate or canceling, LabVIEW will just disappear.
If I create and use a native LVOOP class, it'll compile and run, however pass-by-value is simply not an option.
Test Cases:
1) Naked Main VI: compiles, runs OK
2) Main VI calling protected VI: will not compile if VI remains locked ('cancel' button or invalid password entered) and will sometimes CTD
3) Main VI calling LVOOP class: comples, runs OK
4) Main VI calling GOOP class: CTD after OK/Cancel in password dialog
Versions:
Windows XP 32bit Professional SP3
LabVIEW 2009 9.0f1 Evaluation
Endevo GDS 3.51
This really looks like an issue with password-protected VIs.
Has anyone seen this sort of problem before?
Thanks,
Tony
P.S. Will try to attach to another post since the forums keeps giving me an error when posting with attachment...

I apologize for double-posting.. (I search and read forums much more than I post to forums..)
The correct thread can be located at:
http://forums.ni.com/ni/board/message?board.id=420&thread.id=1784

Performance issues with GOOP

I would like to use GOOP in my next application development. Does anyone know if there is known performance issues I should be aware of?

That is a great question. I found a couple of other threads in the LabVIEW forum which address performance issues with GOOP:
http://sine.ni.com/niforum/niforum?forumDU=http://forums.ni.com/ni/board/message?board.id=170&message.id=30132&requireLogin=False
http://sine.ni.com/niforum/niforum?forumDU=http://forums.ni.com/ni/board/message?board.id=170&message.id=30132&requireLogin=False

GOOP and two controls due to lack of space

Hello All
I have to less space on my screen while designing the private data for GOOP class. I tried to use TAB control only as a page selector, but LV says that I can not have another control and I have to delete it.
It there any elegant way to have a lot of private data distributed somehow on the screen. Maybe I can encapsulate them somehow.
As far as I can see, the GOOP private data is a user defined control entirelly encapsulated into CLUSTER.
Tab-control and cluster can not cope. I need Tab only for convinance (visibility), but I can not use it.
What to do? Whow fit large amount of data nicelly in limmited screen space.
thans in advance
Pawel

Hi Pawel,
I am not quite clear on what problem you are having. I think it's that you don't have enough room to place all of your controls on the Front Panel of your VI? I am not sure why you had trouble with the Tab control. I built a quick example of one to see if it works on your machine.
Also, if you are wanting to build an object, then a cluster is the best way to go. If certain members are private, you can make them invisible by right-clicking on them and select Advanced>>Hide Indicator. Let me know if there's something else you're looking for.
J.R. Allen
Attachments:
Tab_Example.vi ‏22 KB

How to install and use labview goop wizard in labview 7.0 or 6.1

is there any tool kit for implementing my application using goop concepts

yeah,
have you tried the information available from the NI site? Just type: +GOOP into the search field and you will get lots of information, tutorials, etc.
here's the search results for the search mentioned above (http://search.ni.com/query.html?col=alldocs&qs=-languagetype%3Anonenglish+-contenttype%3acommunitydiscussions&layout=default&qt=%2BGOOP)

Named GOOP Objects

I've tried to do some GOOP in LV 6.02 and I wanted to use Named objects/instances.
It is fairly easy to set the name of an object, but then if I want to read the name of the
object later on, how do I do that?
The private functions "Get Data" and "Get Data to Modify" only return the Data from the Object repository, not the name.
Of course I can in addition call the Object repository using the input method "Get Statistics", but is this the only way to get hold of the name?
I don't want the statistics, I only want the Data and the name in one go.
And I also don't want to store the name as part of the Data as what could be another solution.
GOOP 1.0

Hello,
This is a very late reply so it is probably not relevant for you but here we go any way.
The GetObjectStatus returns the object name from an object reference. But the object data has to be read out separately so it does not fulfill your requirement of data and name in one call. To do better you have to make your own version of GetAtributes to make it return the obj name.
I am a bit curious about how you use the named objects sine you have this need. The way I have used named objects I only use the name to get the ref and after that I don't care about the name any more.
Jan

How To Use GOOP and The VI Server?

I created several VIs that work together to display images on a remote
computer using a VI server. To make it easier to use I turned the several
VIs into methods in a GOOP class. This works fine to display the images on a
local machine.
I then added more methods which call the existing methods via a VI server.
This version will not run, even when the VI server is the local machine.
The error it returns is "Object not valid." This comes from the object
repository method that GOOP created automatically. I'm passing what appears
to be a valid object reference, it seems that the object repository doesn't
recognize it as valid. Of course the object repository is password protected
and so I cant delve any deeper.
Has anyone
used a GOOP object over a VI server successfully? Is this even
possible?
TIA,
Don

You must be very careful because objects and refnums created on one instance
of LabVIEW are local to that instance only. Objects created on one machine
with the object repository are unknown to the other object repository
running on the remote machine. You must pass the whole object data from one
machine to the other, not only the refnum.
Jean-Pierre Drolet
"Don Brocha" a écrit dans le message news:
1_er5.467$[email protected]..
> I created several VIs that work together to display images on a remote
> computer using a VI server. To make it easier to use I turned the several
> VIs into methods in a GOOP class. This works fine to display the images on
a
> local machine.
>
> I then added more methods which call the existin
g methods via a VI server.
> This version will not run, even when the VI server is the local machine.
>
> The error it returns is "Object not valid." This comes from the object
> repository method that GOOP created automatically. I'm passing what
appears
> to be a valid object reference, it seems that the object repository
doesn't
> recognize it as valid. Of course the object repository is password
protected
> and so I cant delve any deeper.
>
> Has anyone used a GOOP object over a VI server successfully? Is this even
> possible?
>
> TIA,
>
> Don
>
>
>

LVOOP design question on factory style

Hi,
I'm not sure how to do what I want to do, but essentially I'm trying to support a (slowly) evolving custom TDMS data structure. I was thinking that surely classes and inhertiance (overrides) would be perfect for this. For example, I have a data visualization tool that I've developed. Every so often, (3 times in 4 years) the internal structure of the TDMS data files have been modified (added new stuff, changed some formatting etc.) and I'm trying to make such changes be less of a PITA when maintaining my visualization code, which would need to be able to load/read files from any 'author generation'. If my base parent class has all the methods my visulaizer currently needs, I was picturing coding the tdms reads as methods using the parent class made for dynamic overrides, then if/when things change, create a child of the parent who extends and overrides the base methods as required?
I picture having a 'launcher' helper.vi (see screen below) that takes a (TDMS) file path as the input, then starting with the parent class (basic and generic tdms operations as methods in the class, tdms reference as class data) gets the 'author' version from the TDMS file, passes that to a case structure (factory-style) which then spawns the correct child. Now, because I feel I shouldn't have to close the tdms reference in the parent class and create a brand new child class, I attempt to cast 'To more Specific Class' to case/cast the already started parent class object to become the appropriate 'child', but I get an error 1448 and the description is sadly not meaningful to me.
Now, what I want to acheive may best be done in a different way and/or the way I tried to acheive it may not make sense in LVOOP, this is my FIRST attempt at leveraging inhertiance, so feel free to propose alternate ways to go about this..
Below is a screenshot showing a mock-up gist of what I intended, and a (bastardized) attempt at UML'ey describing the above ramble as a class dependency figure (created with www.draw.io, attached both as xml and picture).
QFang
CLD LabVIEW 7.1 to 2013
Attachments:
class inheritance and factory.png ‏53 KB
tdms class diagram.png ‏49 KB
TDMS Class Diagram (3).zip ‏3 KB

The only question in this reply/post is: where should the factory helper.vi 'live'? (scope?) -It can't be 'inside' the parent class since it uses children, and it shouldn't be in a child either, since then it would need to move with every new child? Thinking re-use library / VIPM module, should I put my classes and this helper VI in a LabVIEW library??
The rest of the post is a 'journal of discovery' since the process of writing this reply/post helped me realize several basic (and in hindsight obvious) things. I'm posting the 'journey' in case someone else finds it helpful! The below text is 'chronological' as I evolved and experimented, except *bold comments* that I went back and entered my take on the issue/question/problem after (hopefully) figuring things out! (Thanks drjdpowell for providing the answer to something I didn't know was my question in your first reply!)
Journal of self-discovery of LVOOP basics:
Forgive me for I must surely be missing something that is likely in numerous documents and posts elsewhere, but shouldn't a child object wire be able to use a parent method (didn't need to over-ride) and go on from that parent method to a child method (now I need to do something child specific)? *-Yes, but only if the class is guaranteed at compile time to be of type 'child' or inherited from 'child'!*
In the simple setup below, I have a factory helper.vi that opens a tdms, reads the author property then creates an object of the appropriate type/generation in a case structure. This all worked well until I tried adding a child method inbetween two parent methods.
Writing this post, it occurs to me that this (above) can't work, because the case structure class output could be either a parent or a child (dynamic) and this is indeterminate at compile time! As such, half (in my simple example facotry of two classes) of the factory cases would not be able to 'do some child stuff'. If 'some child stuff' was an over-ride of a parent method, I would still be fine, since the code could run 'that' method on any generation, so now my question becomes:
How do I case/add child specific code 'in-line' with generic code? -> enter lesson learned from what I was incorrectly trying to do in my opening post: use a 'to more specific class' to test the object wire!
Obviously in a real-world use-case, you probably wouldn't do 'child stuff' (or parent 'close' for that matter) inside the factory. Since the factory helper is part of the parent class library, we can add future children and update this helper/factory without breaking code that depends on the 'parent out' object from the factory because those 'legacy' users will only use parent methods and children methods that it needed when it was first created.
Now I'm a giant step closer to something I could use in my data visualization program, albeit it's a bit different than what I had envisioned/hoped for. Basically if a new child generation requires brand new methods as opposed to overriding existing (parent) methods, I would need to test the object wire and add those new method's similar to how I did 'some child stuff' in image above, but if the only thing that changes is behind the scenes stuff and the methods from past generations are still 'logical'. For example, a 'return processed data' method may know that in version 1.0 of tdms, processed data was always in a group called 'A', but for some reason, later on it is in a tdms group 'B', I can override that method for that generation, and my visualization code would only need to be recompiled with the new class libraries, no block diagram changes requried as the original 'return processed data' method would be dynamically overriden!
I feel just a bit smarter now! -I hope my 'journal' might help others down the path of (obvious?) discoveries! I think I will keep coming back to this thread as I try to further architect and develop this class hiearchy and share thoughts and progress and obstacles along the way. Kudo's if you read and are interested in more like this!
QFang
CLD LabVIEW 7.1 to 2013

Exception handling in GOOP

Does anyone know if it is possible to generate exceptions in GOOP,
just like in other OO languages?
Also: are there any other ways to incorporate exception handling in LabVIEW?
Thanks!

> Does anyone know if it is possible to generate exceptions in GOOP,
> just like in other OO languages?
> Also: are there any other ways to incorporate exception handling in LabVIEW?
If you are looking for a good way of handling errors, then I'd encourage you
to look at using Error I/O. It is basically a technique for throwing errors
forward, and catching them downstream. This avoids problems with parallelism
and determining vales for downstream signals. If you have ideas about what
you would like to see, please suggest them.
Greg McKaskle

Constant wait cursor when editing with LVOOP

I've searched around several times for any mention of this problem but have never found anything. It continues to drive me crazy so I figure I'd ask about it.
I have a decently sized project utilizing about 25 LVOOP classes in the hierarchy. Whenever I edit a VI within a class, every change I make causes a wait cursor for about a second or 2. This is not a long time, but when I'm in the middle of making something and trying to edit a VI rapidly, it gets extremely annoying to be blocked every couple seconds as I place, move, and wire objects.
I assume this has to do with compiling the VI, any callers, and doing something with the class, but is it common to block input while this takes place? Is there any remedy for this?
I'm developing on a 1 yr old Xeon system with a 10k rpm drive and 12GB of ram, it's definitely not an issue with my computer being slow.
Thanks

I am working on a large LVOOP project with 30 lvclasses. The only time I get the wait cursor is when I edit the type defs and select Apply Changes. I do not notice any delays when editing the VI's whether they are methods or plain old utilities.
In my hierarchy, I created inheritance by having lvlibs which also contain lvclasses. Most methods now access the superclass (well, that's what I call it.. the cluster that contains all classes).
Do you have access to another PC which has LV installed? If so, do you get the same behavior?

LVOOP Class Mutation

Hi, I am just starting out with LVOOP. I've read the main knowledge-base articles, had a small amount of training (on the Advanced Architectures course) and have had a play with my own classes.
I now want to use OOP for a test system, so I created a class with lots of standard data types, DBLs, arrays of DBLs, Int32s, etc. I created a load of accessor VIs and some manipulation VIs and that was fine.
Then I decided to change the name of a member in the private data control (.ctl) from "Voltage Range" to "Voltage Spread" as this is more descriptive for me. Having used clusters many times before I expected that the bundle names would simply update automatically. This is not the case. Having done some searching it would appear that this is all about class mutation. I can see why LabVIEW would want to monitor changes to the private data control but I want all my VIs to refer to the latest version of the .ctl file.
I have had a search online about this but now I am more confused than when I started as there appears to be no simple "right-click and select Update" type command.
Any help much appreciated. By the way, I am using LabVIEW 8.5.
Certified LabVIEW Architect
Solved!
Go to Solution.

I had a very small audio class project that works. I copied it, changed a member lable and it did not ripple through. I am also seeing black lines around my object wires for no apparent reason.
From what I can read this is something to do with default values, but I cannot find out how to fix it or what the implications are.
I doubt NI would be interested in my call as I'm using 8.5 and I'm not on any form of Software Support Programme. Maybe when I have some money to my name!
Thanks for your help
Malcolm
Certified LabVIEW Architect

LVOOP Observer

Hello LV-developer
I started to learn LVOOP and need some help understanding overriding VIs. Actually I imlemented 4 classes:
Core (dispatcher)
Client (ancestor class for all clients)
Q_Client (inherits from Client calss)
Topic (not really implemented now)
I have problems understanding Override VIs. I implemented a Client Send.vi in class Client. This vi will be overridden from Client Send.vis of each child class. Please look on my imlementation and say me if I right understand it and implemented good/bad.
Thank you, Eugen
P.S. please look at first on Core Start.vi
LabVIEW Portal
Attachments:
Observer.zip ‏162 KB

Eugen,
i cannot tell you, if the approach you are choosing is good or bad in terms of "how fast and easy" you will add LVOOP to your publish/subscriber.
But from taking a second look into your example-project, it looks ok for me.
I hope that you already know about the differences of LV OOP and "traditional OOP". If not, you will definetly be interested in the following links:
LV OOP FAQ
LV OOP: Decisions behind the Design
hope this helps,
Norbert
[Edit] There is some feedback for LV OOP already given to NI esp. for the mechanism of inheritance since it only gives you the possibility to add functionality before and after the inherited code. But i have no information about the status of this in regard of further developement of LV OOP.
Message Edited by Norbert B on 07-14-2008 06:38 AM
Message Edited by Norbert B on 07-14-2008 06:40 AM
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

LVOOP technique for passing classes down to subVIs

Hello LVOOP experts,
A quick question regarding performance of LVOOP. I finally got around to implementing something non-trivial with LV classes, just for fun though.
If my architecture consists of a state machine, with a typedef'ed shift-registered cluster (containing all my core classes) being passed around the main loop and into subVIs, is there a performance penalty if the classes contain lots of data?
My question arises from my only passing knowledge of how LV classes work. As they are byvalue, does this mean ALL the data gets copied/moved between every state, and into every subvi? Or is the compiler smart enough to know that if I am passing the main cluster into a subVI it doesn't necessarily need to make a copy of the data unless I am forking it or something.
Fictional example, one of the classes is a data storage and has 1M DBL values in it, is this going to cause lots of memory allocation? (If so then its better probably to not store the data directly in the class, rather have a queue or some other byref storage, right?)
Comments appreciated :-)
n
nrp
CLA

nrp wrote:
Mark Yedinak wrote:
My understanding is that LVOOP objects are passed by value. So you would indeed take a hit if you are passing large objects around.
Thats as much as I suspected, thanks for the confirmation.
My big problem is I have not seen a reference implementation of how to do it right. I sure wish NI would provide some intermediate example rather than dog/cat or car/truck.
The closest I have seen in DfGrays Xylophone set of tutorials, but then he complicates things by using a singleton type approach (dequeue --> use object --> requeue) and a strange (to me) architecture with lots of registered events and an event structure as one of the cases of the main state machine loop.
Does anybody have a non-trivial, but freely distributable example of doing classes the right way? I know there are probably a dozen or so ways of doing it right, but there must be some common ground.
I spent the weekend mucking about and have something which I will present once I have tidied it up a bit.
But the overhead is probably negligible for non-storage type classes, i.e. the classes that define the
HI Mark and Neal (?)
The Pass by value story is starting to shape as a misnomer (sp? bad name).
1) If I do a Show buffer allocations when a class wire splits, the buffer does not show-up under clusters of array but rather as a scalar.
2) You can type cast the class ref as a U32 and you get a number.
3) When using Dynamic Dispatching you have to have the class control and indicator on the icon connector, so all of the requirements are present for the sub-VI (method) to work in-place using the bufer that was pointed to by the caller.
So passing the data in a class is about the same as when working with clusters. If LV can avoid the copy it will.
But where you will take a hit...
When we fork a class wire there is a buffer allocated. Too many splits could cause problems. As long as we string together lines of VLOOP methods, they should use the same buffer.
BTW:
I did have to do a re-write of one of my early LVOOP projects because I was splitting a class with a Image data in it. The re-wire skipped using the class and just passed the image data (via a queue between threads).
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

MY LVOOP solution to CLD- Security System

Hi All,
Today , I gave a shot at the security system example from CLD. I did it using LVOOP. Do leave your comments on the code. (I havent done much documentation. Also, I have given the flexibility to the program to log file in any format, as per extension entered by user. The code has been written in a hurry, so pls ignore any cleanups of BD remaining ).
Thanks in advance!
-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
"What you think today is what you live tomorrow"
Attachments:
Test_Security.zip ‏100 KB

Pretty good all in all, some comments though.
They like comments and descriptions in controls and indicators, points are deducted for not having this.
They also like block diagram constants to be labelled (again points off for not doing this).
Your error cluster is not handled too well, if there is an error in any of the states it will just propogate through continuously, probably not what you want. I think the app is supposed to stop on error (cant remember exactly).
The Array local variable in the "get status" state is unnecessary, you could just move the control outside, into the while loop. Locals are generally discouraged.
In the "get status" I would not recommend hiding the index display of the string array you are passing on. At first glance it seems the same state is being queued regardless!
You are not closing the file reference.
One thing to note, my CLD was a lot longer than the pratice examples (a lot!, and I code quite quickly).
Good effort though!
nrp
CLA

LVOOP vs GOOP

Similar Messages

Maybe you are looking for