Labview palette tips and tricks?

TG · February 9, 2008

I have always struggled with LabViews palette folders, especially User.lib folder.

I have 4 copies of LabVIEW 8.2.1 and I need to work on one program at a time in 4 different places for various reasons.

What Id like to be able to do is have "exactly the same" user.lib palette display on the four machines so as to not get twisted around looking for

user made VIs.

I really would rather have a few meaningful tips as to how this and other nice things could be accomplished.

Its easy enough to copy the folder but Q is how do u guys get the palette views to copy over?

Also, since Ivs started this one how about a palette tips and tricks thread regarding user palette for future

Thank You

pallen · February 9, 2008

I'm not positive here, but what about copying the LabVIEW .ini file? (I'd make a backup first though)

Neville D · February 9, 2008

QUOTE(pallen @ Feb 8 2008, 08:58 AM)

I'm not positive here, but what about copying the LabVIEW .ini file? (I'd make a backup first though)

I don't think pallet info is stored there. I know some pallet info is in your /LabVIEW Data/8.5/pallets folder. I agree, it is quite annoying when you have multiple installations, and all the pallets are just slightly different enough to be frustrating.

Neville.

Ton Plomp · February 9, 2008

QUOTE(TG @ Feb 8 2008, 03:14 AM)

What Id like to be able to do is have "exactly the same" user.lib palette display on the four machines so as to not get twisted around looking for user made VIs.

The problem is that LabVIEW branches throught the contents of user.lib and creates a palette item for every item found. It will ignore items in folders that start with a _

So what I do for tools (like the Code Capture Tool) is put the code in '_' folder, then create a .mnu file that contains the items I want (and that refer either to a <user.lib> or are located in the source and refer to a relative path to the '_' item), than copy that together with the items I want.

You can put the .mnu file in the user.lib folder and it will show up restart (or fire a private method called app.palettes.refresh)

QUOTE(pallen @ Feb 8 2008, 05:58 PM)

I'm not positive here, but what about copying the LabVIEW .ini file?

(I'd make a backup first though)

The ini stores the views and position of the palettes, so that will be covered by this.

Ton

TG · February 9, 2008

QUOTE(tcplomp @ Feb 8 2008, 05:22 PM)

So what I do for tools (like the Code Capture Tool) is put the code in '_' folder, then create a .mnu file that contains the items I want (and that refer either to a <user.lib> or are located in the source and refer to a relative path to the '_' item), than copy that together with the items I want.
You can put the .mnu file in the user.lib folder and it will show up restart (or fire a private method called app.palettes.refresh)

The ini stores the views and position of the palettes, so that will be covered by this.

Ton

I appreciate the response Tcplomp.

I just wish I could follow through on it. Ive read it a hundred times.

please bear with me, this may be a dum Q but how is a mnu file created?

Ton Plomp · February 10, 2008

QUOTE(TG @ Feb 8 2008, 07:50 PM)

please bear with me, this may be a dum Q but how is a mnu file created?

This is what I've done for the Code Capture Tool:

[*]This should give you a palette under the user.lib palette with your tools

PS: The name of the folder from step 1 doesn't need to be user.lib, but for the Code Capture Tool it was neccesary because it should be called by a VI from the Project folder.

Good luck

Ton

PPS, if I have the time to make some screenshots of the process I will dump it to the http://wiki.lavag.org' target="_blank">wiki

MikaelH · February 11, 2008

QUOTE(TG @ Feb 8 2008, 01:14 PM)

What Id like to be able to do is have "exactly the same" user.lib palette display on the four machines so as to not get twisted around looking for
user made VIs.

I have User.lib under source code control so all developers have the same look and feel.

//Mikael

Daklu · February 14, 2008

QUOTE(Neville D @ Feb 8 2008, 09:22 AM)

I don't think pallet info is stored there. I know some pallet info is in your /LabVIEW Data/8.5/pallets folder. I agree, it is quite annoying when you have multiple installations, and all the pallets are just slightly different enough to be frustrating.

I develop on multiple machines too and use sync software to keep projects and palettes updated across them. When I'm done with a programming session on one computer I sync with a flash drive and use that to sync with the other computer. A couple sync programs are SyncToy (free) and Syncback ($30).

Daklu · February 15, 2008

In the spirit of tips and tricks, here's what I've learned about customizing the palettes. I think it's all correct, but it's very possible I've made a mistake somewhere. I find the help files rather vague. I trust the more experienced users will set me straight. :rolleyes:

\LabVIEW Data\x.x\Palettes\ - This directory contains .mnu files for built-in palettes you have customized via the palette editor. VIs and controls are not stored here. Labview checks this directory on startup to see if there are any custom .mnu files that override the default files. The custom .mnu files are stored in a directory structure that mimics the location of the original .mnu file. In general I believe we should avoid editing these files directly. (I have deleted them before to reenable the default palettes.)
\Program Files\National Instruments\LabVIEW x.x\menus\ - This seems to be where all the default .mnu files are stored. I believe the "categories" subdirectory holds Functions palettes and the "Controls" subdirectory hold Controls palettes. There are several other subdirectories that don't seem to correlate to locations on the palettes. Some addons put menu files here (such as the OpenG toolkit) but I don't know if there are any conventions on what we should put here.
\Program Files\National Instruments\LabVIEW x.x\user.lib\ - Controls and VIs dropped here are automatically detected and placed in the User Libraries subpalette. This is the easiest way to add custom VIs and controls to your palette. Since the User Libraries palette is auto-populated by this directory you cannot use the palette editor to remove controls, VIs, or subpalettes that exist in user.lib. NI recommends most custom VIs go here. If you create a subdirectory in user.lib that subdirectory will automatically show up as a subpalette. Any VIs in the subdirectory will show up in the subpalette. If you create a new .mnu file and place it in user.lib that .mnu file will show up in User Libraries as a subpalette. This is useful if the palette structure you want doesn't match your VI directory structure.
\Program Files\National Instruments\Labview x.x\instr.lib\ - VIs dropped here are automatically detected and show up in the Functions -> Instrument I/O -> Instrument Drivers subpalette. I'm not sure what happens with controls dropped here. This directory auto-populates the Instrument Drivers palette so, like the User Libraries palette, you can't remove subpalettes or VIs from the Instrument Drivers palette. NI recommends you put (you guessed it...) instrument drivers here.
\Program Files\National Instruments\LabVIEW 8.5\vi.lib\ - This seems to be where most of the shipped VIs reside. It's possible NI addon or modules (is there a difference?) are put here too. Maybe third party VIs as well?
\Program Files\National Instruments\LabVIEW 8.5\vi.lib\addons\ - This directory appears to auto-populate the Addons palette in the same way the user.lib directory does with the same restrictions other synched directories have.
Although I said you can't remove subpalettes and VIs from palettes that are automatically populated, I lied. If you right-click on a subpalette icon such as User Libraries while in the palette editor, a context menu will appear with the option "Synchronize with directory" checked. If you uncheck that option you can go into User Libraries and delete things to your heart's content. You need to reenable the option if you want any future VIs in user.lib to automatically appear in the User Libraries palette. (Of course, if the items you deleted from the palette are still in user.lib they will show up on the palette again.) I frequently use this technique to remove missing subpalettes (the ones with the big question marks) that I otherwise can't get rid of.
Like tcplomp mentioned, in a directory that is synched with a palette, prepending a subdirectory or filename with an underscore ("_") will prevent Labview from putting that item in the palette. (In fact, I think I learned that from his Code Capture tool.) This can be a good way to keep your User Libraries palette from getting out of control.
Many of the menu directories have a 0 byte file named readonly.txt. I believe if you delete that file you get more control over the palettes contained in that directory. I haven't experimented with this much so use at your own risk.

There are a few things I'm still trying to figure out:

I'd like to organize my VIs and add subpalettes to my Favorites palette. Unfortunately I broke something somewhere and now my favorites palette remains perpetually empty. Resetting my palettes to default didn't help.
I'm sure there are conventions on which directory (user.lib, vi.lib, and vi.lib\addons) to use when you are distributing VIs, but I don't know them. I've seen things put in all three. Anyone have ideas on the rules here?
I'm under the impression that you can add items to the Tools menu by putting a .mnu file in the right place. No idea if that's right or not. In any case the Tools menu looks to be reserved for VIs that are executed (wizards, etc.) rather than VIs used in a block diagram.
In Labview documentation I've seen references to "addons," "modules," and "toolkits." Are these synonyms or is there a real difference between the three? Does the "correct" distribution location depend on what your VIs are categorized as?
tcplomp, you mentioned firing app.palettes.refresh a couple times. I've looked for it in the application property and invoke nodes but haven't found it. Could you explain how to do that?

Ton Plomp · February 15, 2008

QUOTE(Daklu @ Feb 14 2008, 01:44 AM)

When I'm done with a programming session on one computer I sync with a flash drive

What folders do you sync?QUOTE(Daklu @ Feb 14 2008, 07:46 AM)

In the spirit of tips and tricks, here's what I've learned about customizing the palettes. I

think

it's all correct, but it's very possible I've made a mistake somewhere. I find the help files rather vague. I trust the more experienced users will set me straight.

\Program Files\National Instruments\LabVIEW x.x\menus\

- ....Some addons put menu files here (such as the OpenG toolkit) but I don't know if there are any conventions on what we should put here.

OpenG puts a category (displayed in the root of the palette) in this folder. The OpenG.mnu is a proxy to an auto populating link to user.lib\_dyanamicpalette_dirs which contains a folder for every OpenG toolkit.QUOTE

I'm sure there are conventions on which directory (user.lib, vi.lib, and vi.lib\addons) to use when you are distributing VIs, but I don't know them. I've seen things put in all three. Anyone have ideas on the rules here?

My rule of thumb:everything under vi.lib is available on every LabVIEW install.Unfortunately this doesn't go for addons {vi.lib\addons}, or modules, things under user.lib are not default installed so you should include them if you distribute a toolQUOTE

I'm under the impression that you can add items to the Tools menu by putting a .mnu file in the right place. No idea if that's right or not. In any case the Tools menu looks to be reserved for VIs that are executed (wizards, etc.) rather than VIs used in a block diagram.

Wrong, the How_to_do_Menu_Launch_VIs has an entry on this, remember it just opens the VI, if you want to execute it set it to 'autorun'.QUOTE

In Labview documentation I've seen references to "addons," "modules," and "toolkits." Are these synonyms or is there a real difference between the three? Does the "correct" distribution location depend on what your VIs are categorized as?

A module is tied to one specific LabVIEW edition (OS and version) like the block diagrams are removed.Addon and toolkit are two names for the same (if I'm correct), addon is the technical term, toolkit the marketing mumbo jumbo. They can be installed on any version. Most toolkits from NI are 7.x and up.QUOTE

tcplomp

, you mentioned firing

app.palettes.refresh

a couple times. I've looked for it in the application property and invoke nodes but haven't found it. Could you explain how to do that?

It's a private method:

TonQUOTE(MikaelH @ Feb 10 2008, 09:18 PM)

I have User.lib under source code control so all developers have the same look and feel.//Mikael

How do you deal with different LabVIEW versions?So you find a bug in a 8.x user.lib VI and want to fix this in 7.x as well?Ton

Jim Kring · February 15, 2008

Here is an article that I wrote a while back, which includes some info about how the palettes work:

Customizing the LabVIEW Development Environment

Cheers,

-Jim

Daklu · February 15, 2008

Great article Jim! That earns a printout and permanant thumbtack on my cubicle wall!

QUOTE

What folders do you sync?

I've set up sync links with my user.lib directory and the directory I use for working on projects. When I come across a need for a general purpose vi I code it up, add it to a _MySolutionsForEverything directory, and add it to the subpalette I want. Since I'm still a Labview noob my personal toolkit changes quite often. Mostly adding functions but occasionally refactoring, renaming, or just deleting ones that don't work very well. I do all this on my c: drive and sync it up with my flash drive when finished so I can copy it down to my other dev computers.

It's not a perfect solution but it's miles better than what I was doing before. I was trying to do toolkit development on my flash drive. For a while I experimented with using my VIs directly from the flash drive rather than my c: drive but that failed miserably. Mostly I would make changes on my flash drive and copy that down to my c: drive. Ultimately toolkit dev on my flash drive didn't work so well. When I made a change to my toolkit I'd have to copy it down to my c: drive, modify the palette, and then copy the new .mnu file back up to my flash drive.

I do the project work a little differently--all my project dev work is done directly on my flash drive. I sync with a folder on my dev computers as a backup and just in case I forget to bring my flash drive.

Based on the information in this thread I'll probably add a few more files or directories to my sync list.

QUOTE

It's a private method:

I haven't done anything with built-in private methods before. How do I find it? (And if it's private, how is it that we can call it from outside whatever class or library it's in?)

--------------------------

In case anyone else ever has this problem, I figured out what was wrong with my Favorites palette. You have to be in a Category or Icon view to add VIs to your Favorite palette. I knew this, so although I use Tree view by default I would switch over to Icon view using the View button at the top of the palette when I wanted to add something to my Favorites. Labview doesn't like this. You have to go into the options menu and change the default if you want to add to your Favorites palette.

I also created subpalettes in my Favorites palette (which is easy to do) but haven't found a way to actually get any primatives in the subpalettes. Is there a way to put Labview primatives on a palette of my choosing?

Ton Plomp · February 16, 2008

QUOTE(Daklu @ Feb 15 2008, 12:03 AM)

I haven't done anything with built-in private methods before. How do I find it? (And if it's private, how is it that we can call it from outside whatever class or library it's in?)

Private in this case means 'LabVIEW R&D only', but you can be upgraded as well.

Read it all http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">here

Ton

Sign In

Labview palette tips and tricks?

Recommended Posts

TG

Link to comment

pallen

Link to comment

Neville D

Link to comment

Ton Plomp

Link to comment

TG

Link to comment

Ton Plomp

Link to comment

MikaelH

Link to comment

Daklu

Link to comment

Daklu

Link to comment

Ton Plomp

Link to comment

Jim Kring

Link to comment

Daklu

Link to comment

Ton Plomp

Link to comment

Join the conversation

Browse

Activity

Important Information