wrap a vi having indicators into a stand-alone block

[Jordan_M]

Hi Bob,

Regarding question 1, the type of wire you describe does not exist as of LabVIEW 2014.  There are many ways of communicating between to simultaneous processes, including the global variables that you mentioned, the event structure that crossrulz brought up, queues, TCP-IP, etc., but none of these has a wire that goes from the while loop to the instrument vi.

Regarding question 2, it sounds like you just want to create a sub-vi, which is very fundamental concept in LabVIEW.  There is an introduction here:  http://www.ni.com/white-paper/7593/en/.

Best,

    Jordan.

[Accuiti-Bob]

Hi Jordan,  Yes, I understand the concept of the sub-vi.  But so far as I can tell, the sub-vi cannot have any of the indicators or controls inside of it.  When I try to make a sub-vi out of my whole virtual power supply, it pulls out all of the indicators and controls and and makes the sub-vi out of the remainder with a spider web of wires attaching the controls.

What I want is to have a virutal instrument that has the indicators and controls inside of the wrapped block.  When I pull this block into another program which I intend to use to control the power supply (in this case), I want to pull it in as a small sub-vi-like block with all of the indicators, controls, and decorative graphics all bundled into the block.  The only thing I want coming out of my block diagram sub-vi-like block for the power supply is the programming interface "cable".  

This seems fundamental requirement of a programming language purporting to support virtual instrumentation.

[Accuiti-Bob]

So, Crossrulz, are you suggesting that Labview fundamentally only supports a program consisting of one virtual instrument?  Instead of, for example, an interconnection of multiple virtual instruments?

As I mentioned in the previous reply, it may turn out while experimenting that you have to switch to a different power supply for reason of needing more current or higher voltage.  In the vision I propose, you simply delete your old power supply block out of your virtual system, drop in the block for the new supply, re-connect the wire, and the program is ready to go again.  In your scenario, you must re-integrate a completely different (potentially) raw driver interface to the instrument into your control code.  This is the core difference between programming for mass production and programming for the engineering/scientific environment.  What is optimum for execution is unimportant - what is optimum for assembling the experiment quickly is what is important.

I want that program modularity and interchangeability.  Are you saying that my architectecture vision is not what you would use in your application, or are you telling me that Labview is fundamentally not capable of implementing my architecture? 

[crossrulz]

---

@Accuiti-Bob wrote:

So, Crossrulz, are you suggesting that Labview fundamentally only supports a program consisting of one virtual instrument?  Instead of, for example, an interconnection of multiple virtual instruments?

As I mentioned in the previous reply, it may turn out while experimenting that you have to switch to a different power supply for reason of needing more current or higher voltage.  In the vision I propose, you simply delete your old power supply block out of your virtual system, drop in the block for the new supply, re-connect the wire, and the program is ready to go again.  In your scenario, you must re-integrate a completely different (potentially) raw driver interface to the instrument into your control code.  This is the core difference between programming for mass production and programming for the engineering/scientific environment.  What is optimum for execution is unimportant - what is optimum for assembling the experiment quickly is what is important.

I want that program modularity and interchangeability.  Are you saying that my architectecture vision is not what you would use in your application, or are you telling me that Labview is fundamentally not capable of implementing my architecture? 

---

You are grossly misunderstanding things.

Your definition of Virtual Instrument is way too narrowly focused.  I have hundreds of virtual instruments (VI) in a single program.  They all interact using wires, queues, and user events.  I have a VI for logging my data.  I have a VI for communicating with who knows which model of an intrument with who knows what serial port settings (I seriously am talking to potentially 3 different models of an instrument each with 5 different possible serial port settings).  I have a VI for error handling.  I have a VI to act as my main state machine.  I even have a VI to cause a very annoying beep when there is an error or something else has happened.  I have all kinds of tiny virtual instruments for doing a particular task.

If you need to switch things out, what you really need is a Hardware Abstraction Layer (HAL).  This is easily done by using Objected Oriented Programming.  You just make a child class of your main Power Supply class, make what changes you need in the child class, and then change your initialization of your application to use the child class.  Done.  Ok, it isn't quite that simple.  HALs take a lot of upfront planning in order to get them to work well.

If you follow the advice I gave you in my first reply, your architecture can work.  But your communication is not going to happen with a wire unless it is passing around a reference to a communication mechanism (queue, user event, notifier, etc).

[Dennis_Knutson]

If you want complete interchangability, then there is an existing architecture for that called IVI. it does not require changing your code at all. This is a basic architecture that has been around for quite a few years. IVI stands for Interchangeable Virtual Instruments. You are reinventing the wheel but with poor design principals.

[Accuiti-Bob]

Thanks again Crossrulz.  

I like your proposal to pass around a reference for the communications via a wire.  I will dig into how that might be done. 

Yes, I understand the idea of a HAL, and in my vision, the HAL was going to be a defined cluster wire.  Only there appears to be no way to pass this cluster wire through a while loop by reference.  How can something so simple be missing?

How do you wrap your virtual instruments, along with their corresponding controls, indicators, and decorative graphics, into one block that you can drag into your program and connect?  Since you have hundreds of them, this must be an easy process.

[Accuiti-Bob]

Thanks, Dennis for the reference to IVI.

However, I am not trying to re-architect a whole industry.  That is not my job.  My personal experience with such activities is that they create un-manageable monsters and by the time the specifications are done the system becomes too bloated to use and in many cases no longer an economical solution.  I only want to have interchange-ability for the instruments I have on my bench that can be automated.  I will write my own simple HAL for these if necessary.  I will write a virtual instrument for each if necessary, as it becomes necessary to use a piece of gear.

It is much more important to me to be able to easily re-use the code I have written.  For example, if I write a virtual instrument module for my BK1687B, I want to use this in many programs, without having to touch the low level code, controls that are specific to this VI, or graphics for it ever again.  This is a general purpose bench supply.  I want to use if for many things manually and with automation.  My question 2 asks how I wrap this all up so I never have to touch these things again to use the BK1687B in other automated experiments.

[crossrulz]

---

Accuiti-Bob wrote:

How do you wrap your virtual instruments, along with their corresponding controls, indicators, and decorative graphics, into one block that you can drag into your program and connect?  Since you have hundreds of them, this must be an easy process.

---

Again, you have a very narrow definition of Virtual Instrument.

Anything that does not have a data dependency will run in parallel.  So I just make modules that can run in parallel with each other, each doing their single job, and communicate with whatever mechanism I need (queues and user events usually).  I have a main VI that calls each of these modules so that they run in parallel.

[Dennis_Knutson]

You are the one trying to re-architect and making things more complicated if you ignore what has already been designed and implemented for exactly the scenario you describe. IVI drivers are what the majority of instrument vendors provide. Talk to BK to see why they don't.

An IVI driver consists of the low level functions as well as a virtual front panel that is built on top of the low level functions. Please give them a closer look. When you use IVI class functions, no code changes are donewhen you switch to a different instrument even when it's from a different vendor. If you want to create your own in LabVIEW, then LVOOP should become your friend.

[Accuiti-Bob]

Thanks Crossrulz, I really do appreciate that you have thought about my problem and spent time and keystrokes to steer me in the direction you would use.

Though, I keep thinking of a story of a business VP from the previous large corp I worked for.  He was sent to S. America to meet with the president of a country to discuss their need for a communications system for the country.  When he got there, the president of the country started telling the business exec what he wanted.  The business exec, presuming to know better, went on to describe instead what he throught the customer should buy.  In less than an hour, security forces were escorting that exec out the door with the president saying, "leave my country and never come back".  Needless to say, the career of that business exec was nearly ended and severely curtailed.  Moral:  Listen to the customer, do your best to give him what he wants.  If you cannot give him what he wants, and at his beconing, offer him a possible alternative.

I have a working program to do exactly what I want with the virtual BK1687B power supply.  It uses global variables inside its while loop to communicate IN the settings I want to change, and global variables to communicate OUT the power supply state.  I really want a WIRE to communicate these things, because the global variables hide the control path.  Thus the question about having a wire that penetrated the loop with access to the variables.  I will look closely at queues and event structures, but from what I have seen, these don't address the problem.

Even still, how do I wrap up my whole virtual BK1687B in a block that includes the controls, indicators, and decorative graphics?  Is it too much to ask that I can insert this into another program as a single block?