Jump to content

LabVOOP


Recommended Posts

Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

Get a good book on OOP in general. OOP is so large a paradigm shift that it's hard if not impossible to fully comprehend by just looking trough a few examples. I like "Thinking in C++" books by Bruce Eckel, but they are specifically about object oriented programming in C++. However the emphasis is on the mind set required for object oriented programming in general. The books guide trough different OOP concepts starting from the most simple ones and going to steadily to more complicated ones. There is a similar book on Java, namely "Thinking in Java" by Eckel as well which I haven't read and therefore cannot comment on.

Link to comment
Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

thanks

Dan

I feel your pain. :) I was in the same boat until recently, and even now, I'm not much further along.

There are at least three issues here:

- There is the concept of OOP in general.

- There is the implementation of OOP in LabVIEW (At least two flavours)

- The concept of how the G paradigm fits in with OOP

In a nutshell, OOP provides enforced mechanisms to encapsulate and restrict access to areas of code. Interface points are written which operate on the protected code via methods and properties. A second key point is the concept of inheritance and classes. There's more to it, but that's all I'm going to say about OOP because I'm sure no expert, and there are lots of articles on the Web.

Third parties have implemented a form of OOP in LabVIEW and it is referred to as GOOP. The product is offered by Endevo (www.endevo.se). An overview of OOP, GOOP and early version of GOOP is available on the National Instruments website here.

As of LV 8.20, NI has implemented OOP which is usually referred to as LVOOP.

A notable difference between the two G implementations is that GOOP operates "by reference" and LVOOP operates "by data". LVOOP tries hard to provide GOOP features while still maintaining the dataflow paradigm.

Personally, I have heard OOP hyped for so long and so often, that I had trouble "getting it". It does have some useful features but there a more than a few people out there that are asking the question "Has OOP delivered on all the promises?" and OOP definitely has its detractors. (No flames please :) ).

For my money, OPP has a long way to go to beat sliced bread.

This is just my own $.02.

Hope it helps.

Cheers!

Link to comment

Dan,

For the last day or so I've been trying to wrap my head around how LV implements OOP. The examples included with LV weren't cutting it for me. Then I came across a NI Week presentation with example code while browsing the NI web site. I understood this example code better than any of the examples included with LV. Maybe it can help you too.

http://secure.niweek.com/published/I80_Geh...resentation.zip

Have fun with it.

Link to comment
Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

thanks

Dan

I suggest you read that entire link and all the links included in it. It also includes the examples that BigBadWally talked about.

LabVIEW Object-Oriented Programming FAQ

Link to comment
  • 2 months later...
Does anyone have a simple OOP implementation they could send me to take a look at .... i have gone through the examples etc... and for whatever reason i dont think i am "getting it"....

thanks

Dan

Dan,

I too am (roughly) in the same boat as you, so my help may not be optimal but since I understand how you feel I will include it anyway, even though it may not seem very elegant.

Im just an engineer not a software programmer, using LabVIEW since version 1.0 but never had time to get too serious with it. I would throw together some code for a prototype instrument developed "in house" and when it gave the result we wanted I was done with it. No formal studying no pHD in computer science. Typical old dog newcomer. Never learned to go further with it.

Personally My biggest challenge was to understand the mechanics of how LabVIEW implements inheritance. I agree good books must be studied to understand OO concepts but then... after this is done how to implement these in LabVIEW 8.2?

It is one thing to understand the concepts of abstraction, specialization and encapsulation but quite another to "see the mechanics" of how these concepts are implemented in LabVIEW 8.2. I would critique NI for not supplying more meaningful example code to look over and study. Sometimes an idiot like myself needs to see 3 or 4 examples from varying

perspectives (and comments everywhere ) to begin "getting it". Dont forget LV was developed primarily for guys like me who for one reason or another are not computer science professionals.

I've been studying the mechanics of how LabVIEW implements inheritance for quite some time now. BTW the LAVA forum posts are quite advanced and are filled with tremendously useful information!

These guys are the "Top Guns" in the industry and I am quite greatful they are willing to "show off" their talents.

I do not believe there is a better place to study LabVIEW OOP in all its flavors then right here at this FORUM.

it is not however, for the weary of heart. It is taking me some time, studying and reasoning, to begin understanding how all of this is supposed to work IN LabVIEW 8.2 but I am beginning to "get it", thanks to LAVA.

I agree the supplied help, (while adequate once an understanding is already achieved) does little to show some of the finer points that are absolutely pivotal to understanding the "mechanics" of how LabVIEW implements inheritance.

For example, The concept of "dynamic dispatching" and the "over ride" node is not mentioned as much as I think it should in the help documentation for newcomers and old dogs. Also, I see no way to determine if a VI has dynamic dispatching terminals except to open it and look at the terminals. A clue would be to see that many VI's have the exact same name, etc etc but the point to make here is the following:

Sometimes you need to just see ALL the code executing in one place before your eyes.

In the beginning I found the following technique helpful to me. Your milage may vary.

Open the supplied Automobile exapple in the help documentation.

Open all the VIs front panels and block diagrams. Change all the FP Icons to show the terminals then reduce the FP as much as possible so it takes only a small portion of the block diagram underneath. Try to get every block diagram reduced enough so that ALL of them are visible in the desktop. Save each as you change it. (You most likely will want to return to this several times until you "get it".) When all are positioned pretty much as in the supplied picture save it all then put all of them in execution highlighting then run the main VI and watch how the data moves.

With this aproach I was able at least to begin "seeing the mechanics" of how LabVIEW implements inheritance and encapsulation. Because I am an old dog it was necessary for me to "see" ALL the code in one place executing again and again.

I agree a reasonably simplified example would do a lot but several showing the same behavior from different perspectives would be far better. This is one thing that NI seldom does.

The shapes example (especially the presentation) is very good.

Download File:post-2402-1169313605.zip

Link to comment
I wouldn't be so hard on yourself there John - you're certainly throwing around advanced terms like a pro! :)

Howbeit your comment is most greatly appreciated most gracious crelf 'San'.

You are only too kind. :)

Been studying all of the examples provided by all of you guys here.

It's amazing (at least to me) how much utterly high quality stuff is in here!

(I know I know I already love LAVA ;)

Link to comment

Your suggestion about the Automobile example is an excellent one worth implementing.

It is one thing to understand the concepts of abstraction, specialization and encapsulation but quite another to "see the mechanics" of how these concepts are implemented in LabVIEW 8.2. I would critique NI for not supplying more meaningful example code to look over and study. Sometimes an idiot like myself needs to see 3 or 4 examples from varying perspectives (and comments everywhere ) to begin "getting it".

I take it then that the Board Testing example that ships with LV wasn't helpful. I know it has flaws, but it's the best anyone has been able to do to highlight the changes that OO brings to code. Any ideas for improving it?

Dont forget LV was developed primarily for guys like me who for one reason or another are not computer science professionals.

*ahem* May I direct you to the opening paragraph of this ...

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.