How to nest polymorphic VI's

[Ben_Manthey]

Is it possible to nest polymorphic VI's, or can somebody suggest alternate ways of achieving my goals.

I have several VI's written that communicate over a serial port to my device under test. I have combined them into a user selectable polymorphic VI. See the left column of my picture. I also have a very similar set of VI's that communicate with my device under test over Ethernet. I have also combined them into a user selectable polymorphic VI. (middle column). 

I can also make polymorphic VI's that automatically choose based on whether they are given a serial port or an IP Address. These are shown as the rows on my picture. 

I would like to combine these two ideas into one, as shown by the lower right corner of my picture. The user would select the 'function' they want and theat would then select the appropiate VI based on communication type.

Is there any way to make this work?

[tst]

You can make nested menus inside a single polyVI (see the DAQmx read/write VIs for an example). If memory serves, you do this by using a colon in the VI name inside the polyVI to indicate a new level in the menu (e.g. Serial: Open), but I'm sure the help covers this.

[Mark_Yedinak]

You may consider using LVOOP and define a communication class. Use dynamic dispath to call the appropriate method for your interface.

[Ben_Manthey]

I was hoping to abstract the difference between Serial and TCP away from the user so they just choose a function and the polymorphic vi picks the right communication type for them.

Thanks,

[tst · Accepted solution]

If you only want serial and TCP, then I would consider using VISA for the TCP calls instead of the TCP primitives. That way the code will be the same and I believe the difference will be only in how you build the VISA resource name.

If that doesn't work for you, then Mark's suggestion is good, but you should be aware that OO has a learning curve and it's relatively easy (certainly in the beginning) to make design decisions which you will regret later.

[Mark_Yedinak]

The LVOOP option does abstract everything from the user. The only method which is specific to the interface is the configuration. Everything else the user sees is generic communication activities such as read or write.

[Ben_Manthey]

Thanks everybody. I'm going to use the VISA session suggestion. It allows me to keep the abstraction without the added complexity of OOP.