Using LVOOP/FGV/Polymorphic VIs to make portable code

[Dyskresiac]

Hi all. 

I've been using LabVIEW a lot since 8.6 (using 2015 now though) and I'm finding myself reinventing the wheel a lot.  The more comfortable I get with LabVIEW, the more I start looking into how get the job "done right" versus just getting the job "done."  Unfortunately I cannot access LabVIEW on my networked machine, so screencaps aren't possible.  So here's my scenario (simplified down a bit):

=============================================================

My Situation

=============================================================

Let's say I have 6 Setups:

-Varying numbers of Relays, AI, AO, DIO, etc.  

-Each Setup can be PXI w/ MXI, PXI w/ Internal Controller, cDAQ, or cRIO w/Network Streams. 

For the sake of simplicity, let's act like the front panel for all 6 systems contains:
-An array of Boolean Controls for the Relays
-A Multiplot for the AI

-An array of Cluster [ Boolean (DIO Output), Boolean (DIO Input) ]

=============================================================

What I do now

=============================================================

For each of these systems, I have a "System_XX_Relay"  "System_XX_AI" and "System_XX_DIO"  vi, where XX is unique for each system.

For each Relay in the system, I manually hard-code map each Boolean Button to its SPECIFIC Relay (IE: Power on NI XXXX Slot 1, Relay 0.)

For each AI in the system, I manually hard-code map each line on the graph to an AI (IE: PowerMonitor on NI XXXX, Slot 1, Ch 0 )

For each DIO in the system, I manually hard-code map each item on the cluster to a line on its SPECIFIC DIO card (IE: Start Test on NI XXXX, Slot 2, DIO 3.)

If I copy System_XX_Relay from  1A to 1C, it won't work.  It's looking for a card that isn't there, and it isn't using Network Streams.   Etc.

=============================================================

What I WANT to do

=============================================================

1) Universal UI and "Host" Program between all 6 devices.
2) Reads in .xml to map Controls/Indicators to its respective interface

3) Uses updatable Libraries for each singal type with an identical interface in "Host."
4) Allows libraries to be updated across all Setups even if they aren't using the new modules

----  Ex:  Relay V1.0 may only provide support for 2 Relay Cards.  If I have a system that needs a new Relay Card, I can update to Relay V1.1 then I can deploy V1.1 to my existing systems even if they aren't using the new devices

=============================================================

Why I want to do it

=============================================================

1) Portablility, obviously.  But Portability with traceable CM.

2) Reduce production time for the next device/setup combination.

=============================================================

Where I've made it thus far

=============================================================

My first thought is to use LVOOP. 

1) Have a Library containing a Class of "Relay" which will contain Daughter Classes for each Type/Topography I support and translate the agnostic input (say, String) to the appropriate driver.

2) Have a plaform-agnostic "Control" Program that will use the Methods of the Classes to control the hardware

3) Have a platform-agnostic "Mapping" Routine that will use the Methods of the Classes to map Front Panel objects to their respective hardware

(future)

4) Implement a "Record" feature using a FGV within the Method calls.

5) Implement a "Playback" feature that will use the Recording to Automate a Recording.

=============================================================

Where I need help

=============================================================

Still with me?  You're awesome.  Gold star.

1) Will this accomplish what I want?  Am I headed in the right direction?
2) If I support a device that isn't present on the system, will it be runnable so long as I don't use that daughter device's Methods?

3) Would xml be the best program-external way to configure device mapping?  I've never used LVM, should I try using that instead?

(future)

4 & 5)  Is there a way this can be added after-the-fact allowing my V1.x "Control" program to use the V2.x class libraries just without Recording/Playback feature WITHOUT any changes to "Control.vi"?

ALL) Are there any NI courses that covers this kind of instrumentation and higher level architecture program design?

WOW.  That was a marathon, but thank you for reading this.  Any help would be greatly appreciated.  If clarification is needed let me know and I'll.... draw something up in MS Paint or something.  (I hate not having LV on my networked machines.)

[tst]

I'll admit to not reading your post thoroughly, as it was more than I feel like handling at the moment, so I'll be somewhat general:

1. First, I would suggest not reinventing the wheel yourself unless you feel confident about how you approach it or have other good reasons for it. Take for example this document and the various related components it links to - http://www.ni.com/example/30328/en/
   This should give you something for abstracting IO. I don't know how good it is, but it might work for you or give you other directions of what to search for ("HAL" would also be a relevant search term).
2. You might also find relevant content on the LAVA forums or here - https://decibel.ni.com/content/groups/large-labview-application-development
3. Also search for the CLA summit videos posted by Mark Balla on LAVA, as they are usually high quality and some of them discuss various abstraction and distribution strategies, which I believe are relevant for what you want.
4. I believe NI does have various advanced courses, although I have no idea what they include. Their course offering should be easy enough to find.
5. I don't see anything impossible offhand, although keep in mind that having things which are dynamic can be tricky, particularly if you're talking about deployed executables. If you want the stuff to be really independent there you're talking about plugin architectures, which come with a host of issues.

[Intaris]

It sounds approximately right at first glance.

Obviously, when instantiating your specific relay objects, yous string input should not only select the driver but also the specific hardware address so that you only need to maintain a single class for all relays of a single type.  Same for the AI and others.

So:

1) Yeah, should definitely be doable

2) Depends.  If the driver depends on a driver which whose absence will break any methods, then you at least need to have the driver installed.  this is only a problem if the class in question is hard-linked to your program (factory method via object constants for example).

3) Personal preference.  Go with whatever you're comfortable with.  This is perhaps the least important part of the design.  To be even smarter, wrap the save and load routines in a class of its own so that you can change it at a whim's notice if need be.

4&5) I dunno, it depends on your Control.vi.  Without change is probably not doable.  Your objects need to come from somewhere..... Unless you wrap your concrete VIs around the new objects.

Shane