LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dr. Damien's Development - Running Top Level VIs II - SubPanel Use


Daklu wrote:

battler. wrote:

I am quite experienced with LV but have no idea about LV classes and OOP.


I'll second Damien's suggestion to learn OOP.  I started using LVOOP about 2 years ago and haven't looked back.  Very few people who take the time to learn OOP go back to to the structured programming (data and procedures--or "traditional" LV programming) regardless of the language used.

 

There are, however, a few caveats:

...Be prepared for longer load times, especially in large applications.  When a LV class is loaded it loads all the classes member vis.  If your app is completely OO, that means everything gets loaded.  When you combine that behavior with more vis, the result is that you have time to visit the forums while waiting for your app to load.  (That's been my experience at least.)  We have a large app that takes 5-8 minutes to load in LV8.6.

  • ...So jump aboard, drink the kool-aid, and enjoy the process of learning a new programming paradigm.

I am far behind Daklu in my trip down the LVOOPid path and I can confirm everything that he said.

 

One note re:load times

 

My monster LVOOP project took many minutes to load on my old laptop (single core 1G CPU) running LV 8.6. THe same project loads in seconds using my new laptop running LV 2009 on top of Windows 7 (8 cores with 8 Gig of memory). I am sure the new machine helps but I believe LV 2009 is better with the load times.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 31 of 35
(1,994 Views)

Some philosophical thinking about LVOOP, so open some decent wine before reading this.

 

Thesis 1: Dimensions

Inheritance and dynamic dispatch add more dimensions.

 

Preface: Fractional dimensions. If you look at a tree like structure, you clearly see that the degrees of freedom are more than 1 dimension (like an array), but less than a complete 2D surface. So I will refer to these as 1.x dimensions (something between 1D and 2D). I just can't finde the recource I got this mathematical concept for reference and to narrow the number further down (like between 1.2 and 1.7).

 

* We have a 2D block diagram space (as opposed to text languages where only one dimension is available).

* SubVis offer another 1.x dimension (like functions/procedures).

* the genealogy of classes (it's a tree) introduce another 1.x dimension

 

So without OOP we just have between 2 to 4 dimensions; With OOP we havebetween 3 to 6 dimensions. So the advanced programmer is moving in an averaged 4.5 dimensional code. Cool! Geeky!

The correct metrics are a bit difficult, as we are not having trees.

* The block diagram space is limited by the direction of the wires. This makes it a kind of uni-directional graph. No circular wiring allowed.

* Hierarchy of SubVis: again its not just a tree, but a uni-directional graph.

* OOP inheritance. This seems like a real tree. Sadly we don't get the extra 0.2 dimensions as they have in other languages by 'interfaces' and 'multi-inheritance'.

So wellcome in the LV-multiverse, only the string-theoristsoffer you more space.

 

Postscript:

I have no idea if recursion gives a higher dimensionality. And I think that organizing our projects in tree like structures (file system, LV-project) are not adding to the dimensionality, but they are only views of it.

 

Thesis 2: Projections

Because a computer screen is only 2D, we need to project the 4.5D space onto 2 or less dimensions.

 

* This is the case where we physically locate the code in the file system (the file system knows nothing about the 'hyperlinks' of the code)

* Same goes for the project explorer

* The hierarchy window

* Any uml diagrams we draw during developement

 

So what we clearly miss is a native inheritance view of our classes.

 

Thesis 3:Texture in the multiverse

We have several tools to impose some texture on the multi-dimensional space of our code

 

* The structures palette (they only operate in the 1.x space of the block diagram, but the tunnels are only propagated further, once all have received data)

* SubVis, yeah, the SubVi boundary.

* folders in the file system, reaching as far as cross-project reusable repositories.

* lvlib's, not only keeping Vis together in the (2009) hierarchy window, the project explorer, but also guarding the 'private' VIs.

* Action Engines: I use AE's without an unitialzed shift register (the functional global feature), they are just there to keep some code together.

* classes: superior to my AE approach, as they feature the dimensions of inheritance.

 

Conclusion:

* We need more tools (projections) to navigate the multiverse as we expand it's dimensionality.

* 'Code-bloat' (refering to Daklus post) is just to give the multiverse more structure.

* Refill the wine-glass.

 :robottongue:

 

Felix

Message 32 of 35
(1,971 Views)

F. Schubert wrote:

Some philosophical thinking about LVOOP, so open some decent wine before reading this.

...

So what we clearly miss is a native inheritance view of our classes.

 

...

* Refill the wine-glass.

 :robottongue:

 

Felix


Agreed!

 

You did not mention the Class hiarchy which does give us another view.

 

Class_Hiarchy.PNG 

 

At one time I started to write a 3-D VI hierachy screen but stopped sice the 3D picture control was limited.

 

In words...

 

Top level VI is at the top.

Sub-VIs aranged about the base of a cone with top level at apex.

Sub-VIs with sub-VIs get their own cone but the apex fits into its slot in its parent cone.

Common sub-VI appear in the cylinder who's postion and diameter are defined by by where they would be if not a common sub-VI.

Put VI Icon on each face of a cube to represent the VI.

 

Viewed from the side it would a lot like our current hiardht screen.

From the top yet another view.

 

So Iagree we can usre handle more ways of looking at our code.

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 33 of 35
(1,963 Views)

Having at least Ben as an audience, I go on with the story. But propably I should post this discussion at lava for more responses.

 

Preface: The concept of views was introduced later in the philosophical pondering. It was needed as explanation why the file system doen't add to the fractional dimensinality. I borrowed it from uml, which I think shows some great philosophical minds at work on the very foundation of the concept.

 

Thesis 2b: Borrow from uml

Requesting new views for LV code, we do not need to start from the scratch but can look at the big bundle of various views describing software: uml. Brainstorming some ideas:

* it would nice to have uml class diagrams with embedded LV icons, with all the rich features to draw 'aggregation', reference and so forth.

* even more fance a double-click would bring us to the VI/lvclass.

-> both are mere implementation issues.

* use sequence diagrams to model 'communication' between various VI's

* I don't know yet how the various types of uml 'arrows' might correspond to LV code (queues, user events, ...)

-> this is actually conceptional new, so it would introduce a new view!

 

Felix

0 Kudos
Message 34 of 35
(1,927 Views)

F. Schubert wrote:

Preface: Fractional dimensions. If you look at a tree like structure, you clearly see that the degrees of freedom are more than 1 dimension (like an array), but less than a complete 2D surface. So I will refer to these as 1.x dimensions (something between 1D and 2D). I just can't finde the recource I got this mathematical concept for reference and to narrow the number further down (like between 1.2 and 1.7).


If you find the reference, please post a link.  I've never thought of code in these terms and I'd like to read more about it.

0 Kudos
Message 35 of 35
(1,870 Views)