VI as a reusable subpanel component with multiple instances

[mellguth]

Hi,

Background information: we try to design a Labview project library for customer of our detectors, where we provide several control panels that the customer can integrate flexibly in a parent VI. For instance, one of the control panels offers buttons for initializing and deinitializing the hardware, starting a measurement and an indicator that tells you when the measurement is finished. A customer can integrate the front panel of this VI in his own VI by using the Labview subpanel component. I have set up an example where this works nicely. You cannot use the connector pane of the sub-VI, because it is not synchronously called, but runs in parallel and lives as long as the parent VI. So, the communication with the parent VI happens through a named queue (or two named queues if you need bidirectional communication).

My concern is: What if a customer had two detectors and would like to integrate two instances of this control panel in his parent VI? First of all, I'm not sure whether there is a way to have two instances from the same .vi file loaded and running in parallel with each of them having their own data. But more importantly, there is the problem with the named queue. Can this only work by cloning the .vi files and changing the cloned .vi to use a different queue name? Or is there a way to pass a queue reference from the parent VI, into the sub-VI? I mean, conceptually, even if you cannot use the outputs of a long-lived sub-VI running in parallel to your parent VI, you should still be able to pass in some initial configuration data when you start it, right?

In short: Can I dynamically open more than one subVI off the same .vi file, use them in subpanels, and still pass different initialization data into each subVI instance from the block diagram of the parent VI --- not using named queues, global variables, or any mechanism that would be visible to any other VI, but instead something that can be wired to each of the VI instances separately?

[JÞB]

Let me state this opinion clearly.

Do not do that!  Create an Instrumnt Driver PnP (Project style)!  Your soft front panel (SFP) belongs in the lvproj Example folder outside the Driver lvlib.  See the Instrument Driver Developer Resources in the IDN Network.

Now I will address some meat for your SFP launching as Clone Instances by Asynchronous Call By Reference (ACBR).  Each Clone gets a unique VI Clone Name property that is determined when it is populated into the Clone pool.  That String property is available from the ACBR(Fire and Foget) VI Ref Out terminal to the caller and,  from This VI in the Clone instance.  The property is very handy for naming object refs like Queues, Notifiers, Timed Loops, User Events and whatnot.

[JÞB]

See here for Driver development guidelines 

If you need expert help with this development I'll negotiate offline.

[mellguth]

Thank you for pointing me to the Instrumnt Driver PnP, i will have a look into it. Inspite of a few years of programming experience in some common languages I just started one week ago with Labview and am currently trying to arrive at a minimal starting point (up to now, we just offered a wrapper *.dll + header files with simplified function signatures for Labview to customers), with pressing time constraints, so I have to quickly discover just the things that are needed instead of having the luxury of collecting a broad overview of Labview. I assume your advice of not doing "that" was referring to the project library in contrast to the Instrument Driver PnP (?).

Thank you furthermore for pointing me to the ACBR. Combined with a typed reference, this node does actually offer the input connectors of the connector pane, so this is precisely what I was missing before (I started from the Labview example that lets you switch between 3 different graphs in a subpanel, and this example used a different type of node to launch the VI). With the input connectors accessible, it seems even possible to pass an unnamed queue reference into the child VI that will only be accessible by parent and child.

[JÞB]

Hmmmmmm.....

---

@mellguth wrote:

... (up to now, we just offered a wrapper *.dll + header files with simplified function signatures for Labview to customers),...

---

Oh, is that a blue USB Dongle?  Yeah, that sounds like a driver I wrote before for a previous client that wouldn't share the LabVIEW Driver IP with the device manufacturer. 

And, since you do have the dll an header you can user the C import wizard to create wrappers for each exposed file prototype.  The wizard drops each call on its own Block Diagram with a Call Library Function node (CLFN) and, the wires the arguments with, optionally, the error cluster to the connector pane for you.  It's a good starting point to build your driver!  Then you simply organize the lvlib by Init, Configure Action/ Status and Utility (Make any Low Level folders needed or declare private scope as desired) and add it to the lvproj with examples, documentation and any custom error definitions.