Blog entry on Polymorphic Action Engines

[LAVA 1.0 Content]

I have written a little note on some recent work on Polymorphic Action Engines,

Please keep discussion with the Blog post.

Ton

[Mark Balla]

QUOTE (Ton @ Dec 11 2008, 01:42 PM)

I have written a little note on some recent work on http://forums.lavag.org/blog/tonsplans/index.php?showentry=193' target="_blank">Polymorphic Action Engines,

Please keep discussion with the Blog post.

Ton

I wrote a responce but in the future if you want to have a dicussion on a topic why not keep in in the discussion fourm. More members are likely to see it and give feedback.

[Jim Kring]

Hi Ton,

I think that we should position the discussion topic as:

Is a Polymorphic VI a good mechanism to conveniently access the members of a "library" (set of related) of VIs?

The main problem that this technique solves is that there is no easy way in LabVIEW (without using palettes) to access the other members of a library from an existing member (or reference/lvobject) on the block diagram. For example, Property Nodes and Invoke Nodes provide quick access to a menu of available properties and methods of various "objects" -- we need something similar for lvlibs, where we can quickly access other members.

So, what are the pros and cons of using the PolyVI in this way?

Pros

• Can use the poly selector terminal
  
• Can show instance icons
  
• Nice menu structure that can be used to group related functions
  
• All VIs must have the same connector pane pattern. (This is a "pro" if you like to enforce that all VIs must use the 4-2-2-4, or other, pattern. See "con" below)
  

Cons:

• All VIs must have the same connector pane pattern. (This is a "con" if you use different patterns for different VIs. See "pro" above.)
  
• It is not an expected/standard (yet) use of poly VIs
  

Can anyone else think of other pros and cons, or have comments on the ones that I listed?

Of course, this technique involves using a LabVIEW feature in a way it was not intended, but this wouldn't be the first example of overcoming a major LabVIEW limitation through creative use of other features. I'm starting to think that if we educate the LabVIEW community on this clever use of polyVIs that it might be a very useful tool.

Another side note is that polymorphic VIs are actually just a work-around for two major limitations in LabVIEW:

1. run-time (true) polymorphism (such as that which was finally made available in LVOOP)
   
2. "anything" (undefined) datatype/control (that can be used to propagate wire data type, at edit-time, from a subVI's conpane terminals to polymorphic inputs of primitive functions and inputs of subVIs with undefined inputs).
   

So, there's really no reason (aside from the name "Polymorphic VI") that polymorphic VIs should be used only for edit-time switching between psuedo-polymorphic VIs. The polymorphic VIs is really just a convenient editing tool that allows the user switch between an organized set of VIs at edit-time, which is what we're trying to do, here.

:2cents:

-Jim

PS - great idea, Ton!

[Aristos Queue]

QUOTE (Jim Kring @ Dec 12 2008, 01:23 PM)

Cons:

The poly VI brings all of its subVIs into memory with it, so if you drop a single VI, all the member VIs load. A couple of us in R&D have worked for years to remove this limitation, but no success yet -- too many aspects of polyVIs break when you don't load all the instances (how do you make sure all the conpanes match, for example).

[PJM_labview]

I can see this as being useful if you do not have a palette for all your wrapper members. If you do have a palette, LV give you very quick access to all the member of the same palette (see screenshot) and I do not see any advantage to wrap everything in a polymorphic VI (neither do I see any inconvenient to have a palette with a "lot" of items). Additionally, in my opinion, maintaining polymorphic VI is a pain (this is a cumbersome process).

So, I will add another con:

• Maintaining polymorphic VI is a pain.
  

[vugie]

As it is still not clear where to continue the discussion, I cross-post my two cents here:

For some time I use AE based on variant with named attributes. Just to limit constantly number of get/set methods and shift registers in main VI. With such approach I have only one variant variable in main VI and one method for set and one for get. I provide name of the variable to these methods with string constant and check whether attribute exist inside get method. The disadvatage is that I have to unflatten variant to proper type after getting and this takes a place. What I'm thinkig of to solve that problem is to create XNode which would serve as universal get method adapting type of its output basing on input string and type definitions stored i.e. as a named constant in main VI.

Unfortunatelly I have to find some time to deep into XNodes...

And for my type of AE wrapping all other methods in polymorphic VI is definitely a good idea...

QUOTE

Is a Polymorphic VI a good mechanism to conveniently access the members of a "library" (set of related) of VIs?

...but strictly for AE, not so generally. Why? Because usually there are only few methods other than get and set (at least in my AEs) and they are all designed to be used, so loading all of them to memory at once is not a con (BTW bad to hear that Aristos, that means a lot of unnecessary functions are being loaded into memory in my programs - a lot of analitycal functions in LV are polymorphic. I have to think about using their instances directly). 90% of my VIs use 4-2-2-4 pattern so for me this limitation is not a con. So with such approach I'll have only 3 items on AE palette (and I use only one AE per application, see above) - I can keep such a small pallette permanently open, even on my laptop.

The only con I can think of is instance selector - it takes too much place.

[Mark Balla]

QUOTE (PJM_labview @ Dec 12 2008, 02:47 PM)

So, I will add another con:

• Maintaining polymorphic VI is a pain.
  

I agree this is a definite con.

Does anyone know of a way scripting or otherwise that can programmatically add and remove vis from a polymorphic.vi

If we could come up with a tool to do this it would minimize the problem.

[Mark Balla]

It looks like most of the work has already been done.

http://forums.lavag.org/create-Polymorphic...cally-t822.html