GOOP

[PauloM]

Hello,

Although I've programmed in LabVIEW for some time now, I never had the chance to try the GOOP way of programming.

In the beginning, my applications were quite small, so the "normal" way of programming was enough to make them and keep them structured and maintainable.

With time they are becoming bigger, more complicated, and I think that now is time to dedicate some time to this approach. I heard some goop things about it and having some knowledge of OOP languages, I believe that this is realy the way I want to go, at least for big projects from now on.

I downloaded the OPEN GOOP wizard and installed it.

What I want to know is if there is documentation explaining the concept - how to do OOP in LabVIEW!!! Design good practices... In some words - Where/How to start.

Thanks for the help,

Ragards,

Paulo

[PJM_labview]

Hello,

Although I've programmed in LabVIEW for some time now, I never had the chance to try the GOOP way of programming.

In the beginning, my applications were quite small, so the "normal" way of programming was enough to make them and keep them structured and maintainable.

With time they are becoming bigger, more complicated, and I think that now is time to dedicate some time to this approach. I heard some goop things about it and having some knowledge of OOP languages, I believe that this is realy the way I want to go, at least for big projects from now on.

I downloaded the OPEN GOOP wizard and installed it.

What I want to know is if there is documentation explaining the concept - how to do OOP in LabVIEW!!! Design good practices... In some words - Where/How to start.

Thanks for the help,

Ragards,

Paulo

3674[/snapback]

Hi Paulo,

There are some documents and examples on the old Old OpenG website. Search the OpenG meeting Archive for more docs.

Also, there is one example in this forum using OpenGoop (look for Didierj posting).

Cheers

PJM

[jeffwass]

What I want to know is if there is documentation explaining the concept - how to do OOP in LabVIEW!!! Design good practices... In some words - Where/How to start.

Hi Paulo, I just had several paragraphs of a response, and my browser just lost it. argh.

I started using OpenGOOP a few weeks ago and I'll let you know about my experiences with it. Overall - I find it pretty useful and it does provide an efficient and useful programming interface in the right situations (eg, I use OpenGOOP for device drivers). But I've found the documentation to be pretty horrendous (this is not unexpected since it's Open Source Software and thus entirely dependent upon the time of volunteer programmers). On the other hand, though, I find the software-side of OpenGOOP to be pretty good. I basically learned OpenGOOP using the three examples linked from the OpenG website, but this was VERY frustrating to learn from. First of all, several examples used an older version of OpenG, and when trying to load these examples I had to go manually to the various OpenG functions and point them to the right path explicitly. This was VERY annoying, especially in the largest of the 3 examples. The other annoyance is that there was little consistency between the three examples. Some broke the class directory into various subdirectories, some didn't, etc.

The biggest gotcha for me when starting was figuring out that when you change the class data type, you have to go through the "CLASSNAME/Core/CLASSNAME Object Data Store VI Ref Type.vi" and right-click the VI Refnum control->Select VI Server Class->Browse and then link to the "CLASSNAME/Core/CLASSNAME Object Data Store.vi" file. This wasn't documented anywhere, and really REALLY annoyed me, to the point that I almost abandoned using OpenGOOP entirely. However, once I figured this out I've been okay.

Although it's gotten so annoying trying to re-do this every time that I've since made my class data type a variant, and then throw all relevent parameters into attributes. [i've actually found that using the attributes of variants is more useful than the data of the variant themselves.]

Anyway, I've been successfully using OpenGOOP after this, but I still don't know if I'm doing it right. I wouldn't be surprised if some of the OpenGOOP developers would laugh out loud if they saw how I use OpenGOOP in my VI's, but due to the lack of decent instructions I've eventually kind of hobbled some understanding.

This is what I do when using it. I make a new class, decide what data type I'll use, and then change the VI reference as noted above. Then I make two directories in the parent class directory, named Public and Private. I then copy the four template .vit's from the Templates directory to the public directory, renaming them as .vi's. (I have no idea if this is how one is supposed to use them, but that's what I do). I try to keep my design such that I'll only call routines in the Public directory from outside the class. Private are just for bookkeeping and calculations within the class. I put all cluster and enum typedefs into the Data Structures directory. Lately I've been using a bunch of pop-up windows for configuring constructors in various ways, so I've tended to put these into a Utilities directory.

I then work on making the constructor and destructor first, and then eventually add the various other routines to add/read/modify data of the class. All public routines are based on those four template vi's.

One annoying thing is that if one of my external VI's receives the reference to a class, the control always says "Template", so if I have two different OpenGOOP classes, I cannot tell which is which (except through the label).

I also haven't found out how to do inheritence, and instead I've had to do a bunch of programming gymnastics to get around this. For example, the motivation to use OpenGOOP was for the device drivers of my Test Executive. Each driver will have associated with it a enum indicating what device it is (GPIB, Serial, VISA), configuration data for the appropriate communication channel (eg Address and Mode for GPIB), a reference to vi file that gives the actual calls, etc. This would be the perfect opportunity for subclassing. For example, GPIB instruments would use different communicating VI's than RS232 instruments, so there would be alot of common methods but a few specific methods between the instrumetns. I wanted to have a GPIB and Serial subclass that would inherent from my Instrument class, but never figured out how to make this work. So instead I keep various other definitions and handle the class differently depending on how it's defined.

I would love to hear how you are making out w/ OpenGOOP, since I've just started a few weeks ago myself. I'm also very curious if anybody knows how to address the various problems I've mentioned previously (how to really use the templates, inheritance, etc).

[atk_nut]

Have you tried the GOOP wizard from NI? Is it different than what you are doing?

I just tried it myself for the first time and it seems to work pretty well.

[PJM_labview]

This is what I do when using it.  I make a new class, decide what data type I'll use, and then change the VI reference as noted above.  Then I make two directories in the parent class directory, named Public and Private.  I then copy the four template .vit's from the Templates directory to the public directory, renaming them as .vi's.  (I have no idea if this is how one is supposed to use them, but that's what I do).  I try to keep my design such that I'll only call routines in the Public directory from outside the class.  Private are just for bookkeeping and calculations within the class.  I put all cluster and enum typedefs into the Data Structures directory.  Lately I've been using a bunch of pop-up windows for configuring constructors in various ways, so I've tended to put these into a Utilities directory.

Keeping the private and public data separated is a very good practise. :thumbup:

You can usually keep the templates in the template directory and just double click on them to instanciate it when you need to create a new vis that read/write the data (then you save the instance under which ever name you which).

I then work on making the constructor and destructor first, and then eventually add the various other routines to add/read/modify data of the class.  All public routines are based on those four template vi's.

Good

One annoying thing is that if one of my external VI's receives the reference to a class, the control always says "Template", so if I have two different OpenGOOP classes, I cannot tell which is which (except through the label).

You should actually edit the enum (that say template) to replace the text by your class name (ex:my class).

You can also edit the control to replace it by a nice picture (look at the configuration file VIs palette and its refnum to see what I mean).

I also haven't found out how to do inheritence, and instead I've had to do a bunch of programming gymnastics to get around this.  For example, the motivation to use OpenGOOP was for the device drivers of my Test Executive.  Each driver will have associated with it a enum indicating what device it is (GPIB, Serial, VISA), configuration data for the appropriate communication channel (eg Address and Mode for GPIB), a reference to vi file that gives the actual calls, etc.  This would be the perfect opportunity for subclassing.  For example, GPIB instruments would use different communicating VI's than RS232 instruments, so there would be alot of common methods but a few specific methods between the instrumetns.  I wanted to have a GPIB and Serial subclass that would inherent from my Instrument class, but never figured out how to make this work.  So instead I keep various other definitions and handle the class differently depending on how it's defined.

There is an OpenGoop which has inheritance and virtual method on the OpenG.org (old tiki website), but if you think the doc is bad on the "regular" toolkit I will advise no trying it.

Basically, to be more user friendly, the OpenGoop need a better doc and more wizards to make managing classes easier.

Attached is an utility that add a banner on selected VIs in a class; it's a modify version of one that is found on the old Openg.or website.

PJM

Download File:post-121-1106795192.zip

[Mark Balla]

The biggest gotcha for me when starting was figuring out that when you change the class data type, you have to go through the "CLASSNAME/Core/CLASSNAME Object Data Store VI Ref Type.vi" and right-click the  VI Refnum control->Select VI Server Class->Browse and then link to the "CLASSNAME/Core/CLASSNAME Object Data Store.vi" file.  This wasn't documented anywhere, and really REALLY annoyed me, to the point that I almost abandoned using OpenGOOP entirely.  However, once I figured this out I've been okay. 

3679[/snapback]

Originally when Open Goop came out the data cluster was flattened to a string before it was sent to the data store. So the VI Ref type (connector pane)was the same for all data (refs,string and error clusters) and the link would never need to be changed. Flattening and reconstructing the data every time you read or changed the data created a lot of wasted cpu cycles. I ran into a problem where I had image references inside my object data and converting them to a string caused huge memory leaks. The documentation probably was written before the data as a cluster was put into the data store.

But there is a fix without having to manually relink all of the vi refs

Jim Kring help me with this solution.

First find the VI Refnum inside the Data store VI Ref Type.vi and make it a strict type def.

Then use the following code to relink the vi ref to the data store.

You still have to run the code every time the data is change but it is easier that doing it manually.

Although it's gotten so annoying trying to re-do this every time that I've since made my class data type a variant, and then throw all relevent parameters into attributes.  [i've actually found that using the attributes of variants is more useful than the data of the variant themselves.]

Anyway, I've been successfully using OpenGOOP after this, but I still don't know if I'm doing it right.  I wouldn't be surprised if some of the OpenGOOP developers would laugh out loud if they saw how I use OpenGOOP in my VI's, but due to the lack of decent instructions I've eventually kind of hobbled some understanding.

3679[/snapback]

I would be interested in seeing an example of using variant attributes as data storage. So I'll show you my Goop template folder if I can see yours.

My template is a moderate modification of the Goop template. I like to use colors to signify my classed instead of headers. I also use graphics in my references for a little added cool factor. The main thing I do that Open Goop doesn't is check for valid references every time I read and write.

In the upper left corner of the MAIN BD is the relinker. I you change your data open this vi and run it and all should be fixed.

Download File:post-584-1106806839.zip

[Mark Balla]

You should actually edit the enum (that say template) to replace the text by your class name (ex:my class).

PJM

3681[/snapback]

Would there be a way to do this automatically through scripting?

[PJM_labview]

Would there be a way to do this automatically through scripting?

3684[/snapback]

Now that you mentioned it, I realized this is quite eazy to program and does not need scripting (see attached VI). It would probably be usefull to run this VI during the class creation.

Programatically changing the image in the enum... That would be nice if it could be done with scripting (I have not tried it, but I have a feeling it might not be possible).

PJM

Download File:post-121-1106843047.vi

[Jim Kring]

I started using OpenGOOP a few weeks ago and I'll let you know about my experiences with it...  [snip]

3679[/snapback]

Wow. That is great feedback!

We, at OpenG, try very had to make useful, well-documented tools. But, unless users demonstrate that they are using a specific tool and have a need for more features and better documentation, it is very easy for the developers to simply move on to the next exciting project. We really do listen and want to make your experience with OpenG tools better.

Please get involved in the process by sending us your feedback and feature requests. OpenG has recently made its discussion and support forums a whole lot more user friendly. OpenGOOP related discussions currently belong in the Packages Forums.

Regards,

-Jim

[eaolson]

But there is a fix without having to manually relink all of the vi refs

Jim Kring help me with this solution.

First find the VI Refnum inside the Data store VI Ref Type.vi and make it a strict type def.

Then use the following code to relink the vi ref to the data store.

You still have to run the code every time the data is change but it is easier that doing it manually.

I realize that this is a new reply to an old thread, but I'm just starting to work with OpenGOOP and found this behavior to be annoying as well. But in trying to use the solution that mballa suggested, I can't seem to get a "Make Strict Reference" method from the VIRef invoke node. I've checked in 7.0, 7.1, 8.0, and even 5 (don't seem to have 6 anywhere around here), and it doesn't seem to be present in any of them. Was this specific to version 6, or am I looking in the wrong place?

[Mark Balla]

I can't seem to get a "Make Strict Reference" method from the VIRef invoke node.

I was not aware of it until your question but the "Make Strict Reference" method is aparently a scripting function.

For version 7.1 This is what you see if you don't have scripting enabled.

And this is what will show up if you enable scripting.

To enable scripting go to this post

If you are not interested in scripting then just copy the method from the template and paste it into your code.

I currently don't use this version of Goop any more. I have moved to a que based version. I have posted a possible core replacement to the original OpenG version here

Hope this helps