LabVIEW "VI cannot be referenced"

[upot]

Hello,

I currently have a BK Precision DC Power Supply. On downloading the instrument driver, I went into the Private Folder where I saw the 'Special Write' vi, however this particular vi does not appear on my functions palette. When I try copy pasting this into one of my codes, I get an error message saying this vi cannot be referenced. On the other hand, all the other instrument driver VI's (appearing on the functions palette) work without any issues as expected.

I understand this is because the 'Special Write' VI is in the Private Folder and therefore can be accessed only within the folder. Can someone tell me how I go about changing the access to this, so that I can use the 'special write' normally like the other VI's the driver comes with? For example, ideally I would want to open up a blank VI, go to the functions palette and be able to access the Special Write VI. I also read somewhere I would need to add this to a .mnu file, however I'm unsure on how to do this.

I have attached an image of the folder for further reference. Any help would be appreciated

[billko]

Your understanding is incomplete.  It's not inaccessible because it's in the private folder; it's inaccessible because it is either marked as private in a library or is part of a class.  It's marked as "private" for a reason.  Your safest bet is to make a copy and place it in your own project, preferably in its own library to make sure it has its own namespace and doesn't get mixed up with the other VI of the same name.

Why do you feel that you need access to what is probably a low level function?

[Bob_Schor]

---

@billko wrote:

Your understanding is incomplete.  It's not inaccessible because it's in the private folder; it's inaccessible because it is either marked as private in a library or is part of a class.  It's marked as "private" for a reason.  Your safest bet is to make a copy and place it in your own project, preferably in its own library to make sure it has its own namespace and doesn't get mixed up with the other VI of the same name.

---

I disagree -- if the creators of the Library marked a routine as "Private" (and gave it a name like "Special Write"), then you are not supposed to call it directly, but through some other routine that does the necessary preparation and/or cleanup to ensure that things get done correctly.  Read the documentation that came with your device, and use the functions that they provide to you (these will be "Public" functions) and leave the "Private" ones alone (until you get good enough with LabVIEW Object Oriented Programming to make safe changes).

Bob Schor

[billko]

---

@Bob_Schor wrote:

---

@billko wrote:

Your understanding is incomplete.  It's not inaccessible because it's in the private folder; it's inaccessible because it is either marked as private in a library or is part of a class.  It's marked as "private" for a reason.  Your safest bet is to make a copy and place it in your own project, preferably in its own library to make sure it has its own namespace and doesn't get mixed up with the other VI of the same name.

---

I disagree -- if the creators of the Library marked a routine as "Private" (and gave it a name like "Special Write"), then you are not supposed to call it directly, but through some other routine that does the necessary preparation and/or cleanup to ensure that things get done correctly.  Read the documentation that came with your device, and use the functions that they provide to you (these will be "Public" functions) and leave the "Private" ones alone (until you get good enough with LabVIEW Object Oriented Programming to make safe changes).

Bob Schor

---

I agree with your disagreement, actually, and for the reasons you specified.

[cbutcher]

In the interest of providing some further points to help you get started in this journey of increased understanding (which I also agree is both helpful and likely necessary to writing whatever code you're trying to write) I took a look at what might well be the driver you're talking about.

On closer inspection, the contents of the Special Write.vi are basically nothing more than "VISA Write" and a Wait function. The crucial point here is that the "VISA Resource Name" must be initialized before you can use it to "Write" data.

This is exactly what the public function in the driver, Initialize.vi, is there to do. The Initialize VI contains various constants that have presumably been chosen by the manufacturer to match the expectations of their Power Supplies.

You are free to either call Initialize.vi, or copy its contents into your own VI. 

If you choose to just copy the contents, it sounds a lot like you're creating "the VI", which is a term used (often with judgement or derision) to point out that you should instead be creating a project (lvproj file) containing multiple VIs (perhaps including something like the driver's Initialize.vi) to do the jobs you want.

Assuming that you have some particular task you'd like to accomplish using the power supply (and that the power supply is not the entirety of your real-life project) you should create whichever "subVIs" you will need to control the power supply (which may in fact, be just what is contained neatly on the palettes and public facing parts of the driver) and then call those in some other VIs that you write to do other things (like make a measurement from some device powered by said power supply).

What are you actually trying to do?

[Michael_Munroe]

<<On closer inspection, the contents of the Special Write.vi are basically nothing more than "VISA Write" and a Wait function. The crucial point here is that the "VISA Resource Name" must be initialized before you can use it to "Write" data.>>

The more crucial point is that in all 76 instances of the VI the Delay (0 ms) is wired to a property called UserData.  This property is set to 150ms for TCP/IP and 0 for all other interfaces.  There is no mention of the interface used in this application, but the VI would not function properly if used independently of this parameter and TCP was used.

BTW: I find it surprising that this VI depends on a property placed external to the VI which is a sub-property of one of the inputs.

[JÞB]

Well MM, that explains exactly why its a special write that requires the VISA session to be initiallized with Open VISA.  In most cases a VISA Open and VISA close are "Optional" since VISA does its own namespacing under the hood....EXCEPT the value of "User Data" is never persisted if the session is implicitly opened.