wrap a vi having indicators into a stand-alone block

[Accuiti-Bob]

Hi Dennis, I am not trying to re-architect anything.  BK doesn't have the drivers for Labview or anything else.  They only provide a small computer demo program that you can use to remotely/manually control the supply.  I have written a working Labview module that controls the supply, puts up a front panel visualization of the supply, and keeps the virtual supply front panel matching that of the physical BK1687B.  I don't like the way the control is signaled to this module (globals) and I am looking for a WIRE as being more intuitive and readable means to provide the signaling.

Secondly, I have been unable to take my working module and wrap it up into a single block for re-use.  How is this unreasonable?  Can you just point me to the reference about wrapping up the whole working vi as a module with the front panel graphics bundled?  Say, see ref ... for example.

[Taki1999]

---

@Accuiti-Bob wrote:

....

Secondly, I have been unable to take my working module and wrap it up into a single block for re-use.  How is this unreasonable?  Can you just point me to the reference about wrapping up the whole working vi as a module with the front panel graphics bundled?  Say, see ref ... for example.

---

It's unreasonable because your working module was built as a custom user interface and not as a driver.

Since it was not architected as a driver, just exposing the controls and indicators as a subVI will likely not give you the interaction you need.

To get your desired behavior, you could build or find a driver that implements the commands in section 5.2.6 of the manual.

BK1687 manual with remote commands over serial

EDIT: The BK Driver Here is for a different model, but I'm guessing the command set is probably the same or very similar.

[keroba]

Hi there,

It is wear that you say that when you create a subVI you lose all the controls and indicators. Do you know that a VI can be used as a subVI? Without lose the control and indicators? the only thing that you have to do is create a project and in that proyect you save all the VI. At the end you are going to have one main VI and a bunch of subVI depends on your application. For doing a VI (without loosing controls and indicators) the only thing that you have to do is to configure the connector pain (inputs and outputs) and the icon of the VI. And may be for the inputs you could use refnums (depends on your applications) 

Here you can find information about refnums:

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/refnum_controls_and_indica/

http://www.ni.com/white-paper/3159/en/

When you have created your VI and set the connector pin for it, you can drag that VI to your "Main VI" and by this way the controls and indicators wont be lost.

And for passing information between loops, does a producer/consumer architecture works for you? Here is a link where you can find information about it

http://www.ni.com/white-paper/3023/en/

Regards

[Accuiti-Bob]

Taki1999, I have done this.  I have built the driver and the companion front panel representation of it from the description in the BK1687B manual.  It is a working module.  I don't want to use it as a "driver" that I have to put into each of programs, I want to use it as a virtual instrument with all of its pre-defined front panel graphics, indicators, and controls.  I want my main program to be a small experiment control program that communicates with multiple virtual instruments to perform the experiment.  When I want to run a different experiment, I only re-write the main code, but I shouldn't have to touch any of my virtual instruments at all (having previously been written).

[RavensFan]

The fact of the matter is that you need to rearchitect something.  You can't take some program that was built for one purpose, (stand alone program that is designed to just control a real piece of hardware with no interaction with other programs) and expect it to server multiple other purposes.  Not without doing some additional programming.  Especially if the "virtual instrument" program you have was never architected right in the first place to even help make that programming process easier.  Without having seen it, it sounds like one master .vi with no subVI's in it.

I would stop using the phrase "virtual instrument".   It is just confusing the conversation here.  While the code you were given could be considered a virtual instrument in that it acts as a standalone, "virtual", on screen representaiton of the the actual physical instrument, a VI file really is not a virtual instrument.  It's a shame that NI call the files VI's with the extension .vi from the beginning.  The abbreviation mean "virtual instrument", but in reality, it is just a file format.  Someone in NI thought it was a good marketing ploy in the early days of LabVIEW to relate the two, but in reality, they aren't.

I do have an idea for you that could allow you to use your single file, .vi, program you were given by the instrument manufacturer, and still write other LabVIEW programs to interact with it, without having to rewrite the original program.

Use VI server.  Create a new LabVIEW program that opens a reference to the original program.  Use property nodes and methods such as Ctrl.Get Value and Ctrl.Set Value.  Now you can have one LabVIEW program control the other without having to fix the original LabVIEW program.

[Taki1999]

That makes things a little clearer to me. It does sound like you should implement crossrulz suggestion for your virtual instruments. Have an event or notifier from your main program trigger controls on your virtual instrument and have your virtual instrument pack output data into queues or events that your main program is monitoring.

It is a more complicated architecture than using drivers and a test executive like TestStand.

[Accuiti-Bob]

Thank you Keroba.

Your suggestion to edit the whole vi to have inputs and outputs is a good clue to wrapping the module I created in the way I hoped.  This may answer the Question 2 I posed.  I am experimenting with this now.

Your suggestion of using refnums to pierce the while loop is interesting and I will have to study refnums more to determine if it can help.  Ultimately, using a reference for a cluster is what I would like to pass into a while loop.  We'll see if I can do that.

Perhaps the combination of the suggestions on this topic can resolve both issues.  I am going to do some additional digging.

Thank you to all that have helped!  I am going to leave the post unresolved at the moment, but will close it if these leads pan out.

[Jordan_M]

I have created a quick example based on the scenario that you describe.  The main vi calls the virtual instrument, which runs in its own thread.  The virtual instrument accepts commands from the main vi and passes data back to the main vi.  The main loop is connected to the virtual instrument with a wire (in this case a bundle of queues).  Is this what you have in mind?

Cheers,

    Jordan.

[Accuiti-Bob]

Hi Jordan,

I really like the way you have created a cluster wire as a bundle of the queues to interconnect the main module to the virtual instrument module.  This is a very nice demonstration - thank you so much for creating it.  Let me study this, as a solution to my Question 1.

Regading Question 2 ... Why, in your example program, when the virtual instrument VI was added to the Main VI as a block, were the graphics, controls, and indicators of the virtual instrument front panel not added to the main module's front panel?

[Jordan_M]

I thought you wanted the virtual instrument to run in its own window.  I have attached another example here that runs the virtual instrument as a sub panel in the main vi.