Thought Experiment: Variable Number of Parallel Time Dependent Systems

Question

Hi all, 
I'm just going through a thought experiment before beginning a new major project and am trying to figure out the best way this code could work. We have a new project coming up that is going to be based out a single computer, this computer is then going to control a number of identical iterations of measurement devices, at present the number is 20 but this could change depending on mechanical failure etc during trials. All of these devices need to be running at the same time and are relatively time dependent, each device has to:
Record measurement data at 1Hz (0.05s Active Time)
Respond to inputs and undertake longer tasks (0.5s Active Time). Inputs occur at random intervals greater then ~10s
As all of these systems must run in parrallel I am looking at the number of different ways LV handles the parallel instances to try and determine a reasonable design pattern before beginning anything. The current ways that I am looking at it are:
Standard Multiple VI parallelization
Build a SubVI, place multiple instance in block-diagram, run.
Pros:
Simple, Build a Sub-VI that can run the device plop X instances.
Cons:
Scalability, Not able to easily change number of instances without re-editing code, rebuilding moving etc.
State Machine parrallelization
Build a state machine for the Device, run X instances in a parrallelized For Loop, for all longer tasks run start them and then check progress each time you come back into the state machine.
Pros:
Programmatically scalable
Standard State Machine Architecture.
Cons:
Less control over long tasks
More complex programming and control.
I am looking forward to what the community has to say, I have a feeling I should probably be looking at OOP for this but I have never done any in LV before and I am a little worried how long the learning curve on that would add to the project without resulting in a much improved outcome.
Let me know your thoughts on the best way to continue.

Answer 1

As Mike said, you can launch multiple instances of a reentrant VI similar to launching a single instance of a VI - it's all in how you get your reference / what your reference actually is.
If you use the Open VI Reference function with a parameter of 0x80 or 0x100 on a preallocated clone reentrant VI, a clone is allocated and the reference is a reference to that clone of the VI (you can check this in testing using a property node and checking the name, which will have the clone number after a colon, and/or Is Clone VI).  At that point, anything that you do with that reference is being done to that clone.
What I did recently for a similar design was defined my class (or just a cluster if not using OOP) to have all of the information to define a single identity - TCP connection ID, queue refs, etc., and the reference to a clone.  A constructor would be called like a "regular" SubVI to create everything it needed, including allocating a clone for itself to run in, and return a Data Value Reference to the resulting object (cluster).  A launcher could then be used that would take the clone reference and Start Asynchronous Call on it, passing into one of its controls the DVR to the object.  Now the clone is running and has everything that it needs to identify itself and operate, including responding to connections like you might have for displaying detailed information about one process all on its own, and my main application still holds onto the reference to the object so that it can do things like be a common server to give new clients the list of TCP ports that each clone is available at.
As for some items in the original post:
  An object oriented approach is usually great for managing these kinds of designs.  If you have knowledge of object oriented design and just aren't familiar with LabVIEW's OOP support, then the learning curve should be very shallow, but it is a good idea to start with a small project or a single module first.  You don't want to be in the, "It's supposed to work this way, but I've never actually done it, and that coercian dot on a child being passed into a parent terminal is making me nervous..." boat for a critical project, even when it does work how you think its supposed to.
  I believe that the Actor Framework (which requires LabVIEW OOP to work with) is made for this type of stuff.
  I must say, I hadn't ever considered or seen using a parallel-enabled for loop with a SubVI in it to do this kind of thing, and I thought it was a cool idea.