Project is Screwing Up...

[d.gelman]

I have a large problem:

I have been making VIs and incorporting them into a main VI.  As I got better with LabVIEW, I realized making a project was better.  I made a project but now my VIs cannot be found because the drivers are used in a different project (i think).

I get a message:

Loading:

<instrlib>\Keithley 622x LV 2009\Action-Status\Low-Level\KE622x -- Clear Trace Buffer.vi

Searching...

(cannot find)

Now, at first I Browsed and found all of them (+40 VIs and CTL) and now I try to open my project again and it asks me to find them all again. 

How can I fix this????

Danny

[d.gelman]

All of the VIs and CTL are in the Keithley 622x.lvlib... not sure what that is.

[Freelance_LV]

---

@d.gelman wrote:

All of the VIs and CTL are in the Keithley 622x.lvlib... not sure what that is.

---

Hi

From what i understand, your project is not able to locate the files required to communicate with the Keithley device. if you expand the 'Dependancies' on the project, you may find these vis and controls.

Could you post a screenshot of the project and the message you are getting?

Edit: You said the drivers for Keithley are in the instrlib. So, when you open the dependancies of the project, you will know if there is a conflict with the files that the vi needs.

Did you save your project after manually loading all the files?

[Norbert_B]

---

@d.gelman wrote:

All of the VIs and CTL are in the Keithley 622x.lvlib... not sure what that is.

---

This is a software package called "instrument driver". Obviously, the machine you are working on don't have this installed; at least not for the correct LV version.

The dependency points to LV 2009. Are you working with this version?

If YES:

Download the instrument driver from Keithley and install it.

If NO:

If you have LV 2009 installed in parallel and working with a more up-to-date LV version (e.g. 2011), search the <LabVIEW2009>\instr.lib folder for the Keithley driver. Copy the driver from this into the appropriate LabVIEW2011-folder. Masscompile the driver. If this runs without issues, the driver should work in the current LV version as well.

If you get errors, contact Keithley for support.

If you work with an older version of LV than 2009, search Keithley downloads for your LV version (e.g. 8.0). If you don't find some, either update LV or contact Keithley for support. 

hope this helps,

Norbert 

[d.gelman]

To solve this, I just didnt use Keithley drivers.. I copied and pasted and made my own VIs.  This is obviously not the greatest way of doing it, but now I am independent of them.  I hope not to run into this issue with this project anymore.

[Ben]

---

@d.gelman wrote:

To solve this, I just didnt use Keithley drivers.. I copied and pasted and made my own VIs.  This is obviously not the greatest way of doing it, but now I am independent of them.  I hope not to run into this issue with this project anymore.

---

That is what I do most of the time to avoid the types of issues you encountered particulary when projects move from one developer to another.

Here take a Kudo for the "right" answer and feel free to mark your post as the solution.

Ben

[Mark_Ramsdale]

Hi Ben,

I have had mixed results using both approaches, to use or to copy drivers. 

I used to like to copy drivers to have a unique set.

Lately I have been putting drivers in LVLIB that sits in the INSTR folder.  Then I can distribute the Library to other developers.  I link the library to my project and drop the VI's from the project rather than a pallet.

We you suggesting making a copy of a driver set for a project and modifying as needed?  Do you put the copies in a library anyhow to avoid name conflicts ( like close, initialize, etc... )?

[Ben]

---

@Mark Ramsdale wrote:

Hi Ben,

I have had mixed results using both approaches, to use or to copy drivers. 

I used to like to copy drivers to have a unique set.

Lately I have been putting drivers in LVLIB that sits in the INSTR folder.  Then I can distribute the Library to other developers.  I link the library to my project and drop the VI's from the project rather than a pallet.

We you suggesting making a copy of a driver set for a project and modifying as needed?  Do you put the copies in a library anyhow to avoid name conflicts ( like close, initialize, etc... )?

---

Yes. If the driver uses names like that then a libray works fine or if the driver is really old I rename them to use legal file names.

The Use Case that drives this practice is;

I work in a LV shop with a bunch of other CLAs. Any or all of us can work any project at any time. If I am working a project when I have to jump and handle another project, I can simply walk away and the other developer can take over. To ease the switch over, the extra time required to resave the drivers is mor than made up for by the time saved when the new developer opens the project and does NOT have to find and install drivers. SCC ensures they have exactly what I have.

This also serves us when we discover we have to modify the driver. Examples of this include making sub-VIs re-entrant so we can control two widget at the same time or optimizing poorly written drivers (side note: I once spoke to a driver developer on the phone about his driver and he said "Yeah, that was more an exercise in parsing text in LV than anything else.")

It also serves for our long term support of our customers. I can bring in the latest and greatest version of code developed by a former associate years after they are gone and what I have on my machine is virtually the saem as what the custer has. We adopted this practice after I showed up on-site with source code but no drivers.

This also serves our customers in secure facilites with no internet access since EVERYTHING is in the backup.

Other shops will have different use cases with developers using a standard set of hardware and drivers or they can leverage of the VI Package Manager.

Those are luxuries I can only read about.

That is my "2 cents",

Ben