wrap a vi having indicators into a stand-alone block

[Accuiti-Bob]

I am a Labview rookie, so this may be a common rookie problem.  However, I have asked more experienced Labview users this question and came away with no solution.  This post is a little long and it actually contains 2 somewhat related questions - apologies.  I hope this is truly a rookie question and not a language limitation.

When I began working with Labview, I envisioned being able to create virtual instruments for my test equipment to automate my experiments.  I began with a BK1687B power supply having a USB interface, but no .vi from the manufacturer.  The manufacturer provided a sufficient description of the commands over the PC virtual serial port, and I was soon able to write a working .vi that put up a picture of the front of the power supply on the Labview front panel and overlay it with digital readouts to mirror the appearance of the real power supply.  I created a while loop around the code to have it regularly poll the real instrument and update the Labview virtual instrument to read the same as the real power supply.  

I created controls to change the voltage & current settings in a separate while loop outside the while loop for the virtual power supply (modeling the interface to be driven from another program). Then I ran into my first problem - How do I communicate from the control setting while loop (modeling the rest of my control program) to within the while loop operating the virtual power supply?  I tried (successfully) to get it to work with local variables, but when I went to create a sub-vi, Labview wanted to pull all of the indicators out of the power supply sub-vi - what a mess! 

Then, instead I re-wrote this with global variables to provide the control signal exchange, and this worked and reduced the complexity; but using these globals is far from my vision of how I want to have this work.  I want a well-defined, easily identified I/O path in my block diagram to a single block representing the virtual BK1687B power supply (see the enclosed diagram).  I don't want the communication to be done with somewhat invisible global variables, I want to cluster the signals between my virtual power supply block and the portion of the control program that will be utilizing the power supply - I want a wire for this function (I could make do with separate in and out cluster wires).  The problem is that I want these signals to be passed IN and OUT of the main program loop and the power supply program loop via the cluster cable(s) with internal updating at least every iteration of the program's while loop.  

Question 1:  How do you pass variables through the while loop in both directions with updates occurring at least every iteration?

Question 2:  How do I wrap the .vi for the complete power supply along with all of its indicators, controls, and decoration graphics as a block (its own thread) that can be loaded and wired into another program?

In general, I would like to be able to separate the operation of the power supply virtual instrument from the rest of the control program.  I want the supply to have its own front panel representation that includes all of its indicators, controls, and decoration graphics pulled into the program at the same time as I load an icon representing the power supply into the block diagram.  I cannot find how I do this full encapsulation of the virtual power supply.  The encapsulation is also partly inhibited by not being able to wire connect the in and out communication signals to the virtual instrument.

[crossrulz]

It sounds like you should be using an Event Structure inside of your loop.  You use the Timeout event to poll your instrument's settings and the value change events for the controls to set the power supply settings.  This will set up the real fun...

So with that event structure, you can register to recieve User Events from other VIs.  You can have an event for setting the voltage.  That user event can run the exact same case as the Voltage Value Change event from the VI's front panel.  Do the same for the rest of your controls on that VI.

I highly recommend making wrapper VIs for allowing other parts of your code to send these commands.  They other parts do not need to know that you are using a User Event.  They just see a VI that sends the command.  I like to store my User Events in an Action Engine to make these wrapper VIs easier.

Now, how do you get the data out?  You could use more User Events, Queues, Notifiers.  It really depends on what your requirements are.

[Bob_Schor]

About a decade ago, I was introduced to LabVIEW as my "new language in which to become proficient" (I already had a few under my belt).  This was a very different language and mindset for me, needless to say.  I had the benefit of working with someone reasonably experienced in LabVIEW (but not necessarily an expert), but no access to classes or tutorial material (I did not think to look for LabVIEW tutorials on the Web).

I bought two books.  Jim Kring's book "LabVIEW for Everyone" covered the rudiments of the language, with examples and (some) useful guidance in using LabVIEW tools and functions.  However, the book that really got me into the "mind-set" of LabVIEW was Peter Blume's "The LabVIEW Style Book".  If you intend to use LabVIEW in a serious manner and want to learn how to write LabVIEW routines that (a) you'll understand when you revisit them in six months, (b) you can explain to someone else who is not a LabVIEW expert, (c) you can explain to someone who is a LabVIEW expert (and not be embarrassed), (d) is easy to debug, and (e) is easy to maintain and modify, this is the book to get.

If you do not have a local LabVIEW Guru for guidance and have not availed yourself of the on-line LabVIEW tutorials, you might consider looking at some of them.  A list of tutorials is frequently posted in this Forum (I can't find it right now, of course), and if you Google LabVIEW Tutorials, you will find a number of sites, including a series at NI.Com.

Welcome to LabVIEW.

Bob Schor

[Accuiti-Bob]

Thank you, Crossrulz, for your reply.  

Unfortunately, I don't see how your suggestion of using an event structure addresses either of the two questions.  Close examination of re-implementing the virtual power supply as an event structure says that the event structure itself must still be contained within a while loop.  Having the event structure does provide additional options for how the information may get communicated to the structure from the controlling vi, but it doesn't provide any means to pierce the main power supply while loop with a WIRE.  My current implementation using global variables works fine, but hides the interconnection of the virtual power supply to the controlling program in the cloud of globals.  I specifically want the controlling I/O to the power supply virtual instrument to come from a wire (cluster) so as to provide a concise and visible means of identifying the controlling source and to make it easy to disconnect and reconnect within the program (for example if I upgrade the power supply vi).

To me, this is a fundamental concept.  If one considers that a wire is a variable, in other languages a variable is reference-able directly or indirectly.  What I want to do is to pass the address of the variable through the loop, such that within the loop, the variables whose values are changing can be accessed indirectly.  This sounds pretty fundamental and would seem to be necessary for proper program architecture.  Is this fundamentally prohibited by the way that Labview code is executed?

Is the second question (wrapping of the whole virtual power supply with its indicators and decoration graphics into a single "block" that can be pulled into another program) so obvious that it doesn't need an answer?  This is surely is a rookie question.

[Accuiti-Bob]

Thanks Bob for the recommendations.  I do wish I had a directly accessible mentor.  In some sense I do, but only over the internet and not in person.  I am relatively isolated in a small village of 500 and haven't found anyone here in person that can help.  I have a friend available on the internet who programs in Labview, but so far, he has been unable to answer these two questions.

I am teaching myself, watching tutorials when I can, using Google to search for answers, and writing code.  I don't have the luxury of time for too much in the way of programming for academic learning - I have to learn while I am creating the app I need ... and muddle through, hoping I can get it to work well enough this time and be better prepared to make my next program improved.

I will have a look at the books you suggest.  There is nothing better than a personally recommended book!

Bob

[Dennis_Knutson]

I think you have done basic misunderstandings of instrument drivers and instrument control. A driver written for test automation does not have any user interaction and would not display a simulated front panel. What you would put in a main VI would be discrete functions for initialize, read, write, etc. Have you looked at the design of other instrument drivers? Your VI with a visible front panel is more like a custom application (that could use a driver) for manual control and not automating tests.

[Accuiti-Bob]

Hi Dennis,  what you describe as a "driver" may be true.  However a "virtual instrument" must have many of the features of the actual instrument, but exist on the computer.  I want to automate a long experiment in a way to enable repeatability.  I am not writing a factory test driver.  I have very specific monitoring funtions that I want to see on the front panel, and my virtual power supply state is one of them.  I may wish to check on the status of my long experiment from another computer and be able to see the recognizable instrument effigies as part of the remote visualization of what is going on.  There is a place for a driver and another place for a virtual instrument, and what I want is a virtual instrument.

Interestingly, most of my engineering friends that have programmed in Labview or VEE have entered into the language with a similar expectation - being able to create and use virtual instruments.

Bob

[Dennis_Knutson]

But it seems you've approached this virtual instrument backwards. You should start with the basic driver style, call those functions when required and update the main with results from the driver functions. A separate VI would be the virtual instrument that gets called only when manual intervention is required. This would be written using the event structure. The front panel of the main and the front panel of your manual VI could look exactly the same if you want. All of your stated desires is possible with a standard architecture. Your design is over complicating things in my opinion.

[Accuiti-Bob]

Dennis, whether this is backwards thinking or not depends on your perspective.  From the perspective of a programmer that is writing an application that is going to get used over and over again (in a factory for instance) with the same equipment, the full custom design as you describe may be the preferred architecture.  

However, an engineer setting up an experiment begins with selecting the equipment he needs for running the experiment, groups them around what he is going to test on his bench, and then performs the experiment.  He may discover he needs a more stout power supply than he originally selected, so he swaps it out.  He runs the test and then the equipment goes back on the shelf until needed for another experiment.  In this scenario, the "virtual" equipment shelf is the most important part.  Being able to grab the equipment, put it into one location (code space) for the experiment, and quickly write some control for the experiment is the most important part.  You do not want to be facing the raw driver interface every time you setup an experiment.  In fact, the experiment may get run with the actual equipment first, and then the small main app for the automation of the experiment would be coded afterwards to replicate what was done manually.  In this case, and obviously IMHO, the virtual and compartmentalized equipment shelf is king. 

[crossrulz]

---

Accuiti-Bob wrote:

However, an engineer setting up an experiment begins with selecting the equipment he needs for running the experiment, groups them around what he is going to test on his bench, and then performs the experiment.  He may discover he needs a more stout power supply than he originally selected, so he swaps it out.  He runs the test and then the equipment goes back on the shelf until needed for another experiment.  In this scenario, the "virtual" equipment shelf is the most important part.  Being able to grab the equipment, put it into one location (code space) for the experiment, and quickly write some control for the experiment is the most important part.  You do not want to be facing the raw driver interface every time you setup an experiment.  In fact, the experiment may get run with the actual equipment first, and then the small main app for the automation of the experiment would be coded afterwards to replicate what was done manually.  In this case, and obviously IMHO, the virtual and compartmentalized equipment shelf is king. 

---

Then that is just the Virtual Insturment.  I am with with Dennis here.  If you need an automated system, then you use the drivers to do only what you need.  If you want to "virtually control" an instrument, then you have your fun application with the fancy front panel.  Your Virtual Instrument does not belong in an automated test system except as a debug tool.