Darren's Weekly Nugget 05/17/2010

[Darren]

Have you ever looked in your LabVIEW Data directory?  There can be a lot of stuff that piles up in there.  Here's what's in mine at the moment:

On Windows 7 or Vista, your LabVIEW Data directory will be in C:\Users\[username]\Documents.  It's a different location on other operating systems...you can use the VI I linked to above to figure out its specific location on your system.

Now one purpose of the LabVIEW Data directory is to serve as a data storage for files generated by your own VIs, whether they be log files, configuration files, data files, etc.  But as you can see from the screenshot above, LabVIEW itself stores quite a bit of stuff in there, too.  This is not a comprehensive list, but here's a description of each of the items in the screenshot above, all of which are either automatically generated by LabVIEW, or are used directly by LabVIEW features:

• Dependencies - Stores cached dependency information for all the VIs you have ever used in vi.lib, instr.lib, and other locations.  This improves load-time performance because, whenever you load those VIs into memory again in the future, we use the cached dependency information so that we don't need to read linkages from the VI file on disk to recalculate dependencies.
• Glyphs - Contains the glyph library for the NI Icon Editor.  The contents of this folder are populated by the Icon Editor upon its first use after a LabVIEW installation.
• Icon Templates -Contains information pertaining to user icon templates in the NI Icon Editor.
• LVAutoSave - Stores temporary VI save information for the Automatic Saving for Recovery feature.
• lvfailurelog - Stores log files that contain internal error information.  These files are created when you select the "Investigate internal error now" or "Investigate later" options in the Investigate Previous Internal Error dialog box that comes up on LabVIEW launch following a LabVIEW session in which an internal error or crash occurred.
• LVRSS - Contains information pertaining to the RSS feeds provided by the Getting Started Window.
• Probes - One of multiple locations for storing custom probes.  This is the default location where new custom probes are saved.  It's also where I keep my History Probes. One cool thing about keeping probes here is that they are available in all LabVIEW versions you have installed on your computer.
• QuickDrop Templates - This is where merge VIs for Jarrod's Ctrl-G shortcut for Quick Drop are stored.
• VI Analyzer Tests - Contains user-specified VI Analyzer tests.  This is the location you should place any VI Analyzer tests that are not installed by the VI Analyzer Toolkit or some other VI Analyzer test suite.
• MathScript.ini - Configuration file for the MathScript Window.
• VI Analyzer User Dictionary.txt - Contains all custom user-specified words that are not in the default VI Analyzer Spell Check dictionary.

There are many other items that can be stored in the LabVIEW Data folder...these are just the ones I happen to have right now.  If you find any other mysterious items in there, let me know, and I'll try to help you figure out where they came from.  🙂

[TCPlomp]

---

Darren wrote:

Have you ever looked in your LabVIEW Data directory?

• Probes - One of multiple locations for storing custom probes.  This is the default location where new custom probes are saved.  It's also where I keep my History Probes. One cool thing about keeping probes here is that they are available in all LabVIEW versions you have installed on your computer.

---

This is exactly the reason why I have a seperate LabVIEW Data folder per LabVIEW version...

Ton

PS the LabVIEW data folder should include the Code Capture Tool.ini file

[Cepera]

I find it unfortunate that data generated by LV is stored in the "Default Data Directory". I have always used this folder as a place where I store data related to my customers/projects (typically I change the default location to something like C:\Customers). This makes it convenient for me to backup/synchronize folders. Now I find all kinds of additional folders there, including Glyphs and Icon Templates, and I don't want them there.

Incidentally I think that LVAutosave is still in "LabVIEW Data" folder and not in my default data folder, which is fine with me. I wish that the stuff for the new icon editor also stayed in "LabVIEW Data" rather than in my default data folder.

Alternatively, consider adding another path to the LV configuration, something like "Default User Directory", such that when I select File/Open, the start browsing location is in this directory, but make sure that LabVIEW itself does not put anything in it.

Thanks,

SL

[PhillipBrooks]

---

Cepera wrote: 

Alternatively, consider adding another path to the LV configuration, something like "Default User Directory", such that when I select File/Open, the start browsing location is in this directory, but make sure that LabVIEW itself does not put anything in it.

---

NI proposed a change to the LabVIEW directory structure in 2008. The changes would have included a folder as you described, but some of the other proposed changes would have rendered some libraries and toolkits unusable.

NI suspended that proposal...

(Proposed) Changes to the LabVIEW Directory

[Ben]

---

Darren wrote:

...

• Dependencies - Stores cached dependency information for all the VIs you have ever used in vi.lib, instr.lib, and other locations.  This improves load-time performance because, whenever you load those VIs into memory again in the future, we use the cached dependency information so that we don't need to read linkages from the VI file on disk to recalculate dependencies.
• ...

  ---

Ah Hah!

One of my co-workers had trouble with a build the other day and had to resort to re-booting his machine to get it to work. now I have a possible answer and a question.

How can we force LV to flush that cache and is it safe to just blow away the contents of that folder?

Ben

[Darren]

---

Ben wrote: 

One of my co-workers had trouble with a build the other day and had to resort to re-booting his machine to get it to work. now I have a possible answer and a question.

How can we force LV to flush that cache and is it safe to just blow away the contents of that folder?

---

LabVIEW has no built-in way to flush the dependencies cache.  You could "blow away" the contents of that folder if you want...the consequence would be potentially longer load times.

I spoke to the architect responsible for the Dependencies folder, and he said he's never heard of any problems associated with outdated or stale information in the cache.  He says this is because mod dates are stored for all files whose dependency information is cached...this information is used to determine if the cached data needs to be refreshed before loading.

[Ben]

---

Darren wrote:

---

Ben wrote: 

One of my co-workers had trouble with a build the other day and had to resort to re-booting his machine to get it to work. now I have a possible answer and a question.

How can we force LV to flush that cache and is it safe to just blow away the contents of that folder?

---

LabVIEW has no built-in way to flush the dependencies cache.  You could "blow away" the contents of that folder if you want...the consequence would be potentially longer load times.

I spoke to the architect responsible for the Dependencies folder, and he said he's never heard of any problems associated with outdated or stale information in the cache.  He says this is because mod dates are stored for all files whose dependency information is cached...this information is used to determine if the cached data needs to be refreshed before loading.

---

I will remember that for the next time if it happens again. When we saw this the first time I could not explain in anyway other than something being cached but since LV was stoped and restarted and no joy he resorted to the re-boot and then it worked. Its a crazy app with five manifestations all designed to run on cFP on trucks with a central control PC. It is keeping 3 developers going full time to keep up with the changes.

Ben

[tst]

---

Darren wrote: 

• Dependencies - Stores cached dependency information for all the VIs you have ever used in vi.lib, instr.lib, and other locations. 

---

Then why are the files in my folder only 81/82 bytes in size? I don't think you will be able to convince me that this holds all my dependency info. 😉

The only one which is larger (~150 KB) is the one for 8.5, which I only had installed in eval mode quite some time ago.

[Darren]

---

@tst wrote:

Then why are the files in my folder only 81/82 bytes in size? I don't think you will be able to convince me that this holds all my dependency info. 😉

---

Do you eschew project-based development?  Upon further investigation, I'm thinking the Dependencies cache may only apply to VIs loaded in a project (i.e. .lvproj) application instance.

[tst]

Practically all my VIs are in projects, which I usually have open while working. I try not to include most VIs in the project (to avoid simply making it look like another version of the files tab), but I would expect that if anything, that would make the dependcy file bigger (since most of the VIs are in the dependencies section, which presumably isn't part of the lvproj file).