User.lib conflict

Using LabVIEW 8.5.1, I am trying to load a project which an outside developer and I have been working on. All the vi's and other files are bundled into an .LLB file which I retrieve via FTP. The problem is that the developer has a set of driver vi's which we have been trying to debug stored in the .LLB. On my system, driver vi's with the same name and general functionality, but which may or may not be the same, are loaded in my "user.lib" folder. Of course, when I try to open the project, I get conflicts. However, the "Resolve Conflicts" dialog locks the files so that I cannot remove the duplicates. Also, I can't seem to remove "user.lib" from the dependency tree. I want to use his driver vi's, not mine, but can't figure out how to do it. Can anyone help?

I would suggest using project libraries instead of LLBs. Project libraries qualify the names of VIs by prepending the name of the library, avoiding cross-linking. Another possibility is to change your VI Search Path to force it to look for files in a specific directory before any other place. You can change the VI Search Path from your LabVIEW options dialog.

Similar Messages

Palette not updated with user.lib files

I took a certified driver file, put it in user.lib, rename the project file and containing folder. I opened the renamed project, change the VI icon colors of all project files, relink all missing files to user.lib directory, saved all the files, saved the project. Then I restart LV2014 and no menu appear in Tools User Libraries.
Has anyone tested this using LV2014 or older?
Rich J
Solved!
Go to Solution.

Just an FYI there is a Refresh Palette funciton under the Application Control >> Palette Editing which can be used for testing. It won't refresh the tools menu but it allows you to modify files and MNUs in the user.lib then call that refresh to see if it worked without having to restart LabVIEW.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

How to package instrument driver in the user.lib or instr.lib directory

Hey guys,
I currently am using bunch of instrument drivers in my project.
In the VI form it works fine, but I noticed that once converted to an executable,
there are errors regarding the DLL that the drivers are calling.
Apparently the driver VI check if its being called in an VI or executable based on the current directory.
I dont think this is good/correct programming to begin with... but anyways since this driver is
saved in the instr.lib directory of LabVIEW, when I call it from the executable the default path becomes
XXX.exe/1abvi3w/instr.lib/.../.../VI above.vi
I saw this post which talks about how vi's in instr.lib and user.lib will get the path 1abvi3w in an executable but never talked about how to deal with it.
so my question is can i solve this problem smoothly without copying the entire driver.lvlib into my project and
editing the VI above? i am fine with creating wrappers for driver vi's but would to like to avoid editing the driver vi's themselves.

doradorachan wrote:
I dont think this is good/correct programming to begin with...
I don't disagree, but there is a reason this code was written like that (you might note that it doesn't actually work) - before 2009, EXEs were built as flat directory, so stripping twice would bring you to the folder. Because of the addition of libraries, where different files have different names, this was no longer possible, so 2009 builds the EXE as a zipped hierarchy of folders, which is why the check for a folder succeeds even inside the EXE.
There are a couple of things you can do:
Replace the VI path with the Application Directory primitive. This is designed to function differently in an EXE. Understandably, you don't want to do that.
Check the 8.x checkbox in the advanced page of the build settings. This will make the code work correctly, but if there's LVOOP code with VIs of the same name anywhere, it will create extra folders that you need to move around with the EXE.
Add the driver to the project (just the lvproj, don't actually copy the files) and then set an explicit destination in the build for its VIs as an LLB in the data folder. This will place the driver VIs in an wLLB, which is external to the EXE and should then strip correctly. I can't say I have much experience with this, but I'm assuming it should also work with code that was originally in user.lib. This is probably the cleanest solution in terms of number of files because you only have one extra file.
Try to take over the world!

Built application doesn't 'see' user.lib?

New AppBuilder user here.
I seem to be having a problem building a standalone application that has a few custom VIs in it. Debugging showed that it apparently refuses to recognize the custom VIs in my user.lib folder. I tried disabling them in my source and recompiling, and the rest of it works fine. Two are VIs in their own right, the third is a VI called from within an .LLB file, again in the user.lib folder. None of the custom VIs contain any 'custom pieces' from elsewhere.
I'd built an installer to get the runtime engine, support files, &etc. on the target laptop and it apparently properly installed all these components. Then I built the *.EXE separately. No errors.
As a sanity-check, I built an EXE from another VI that uses only Labview-native VIs &etc. (i.e. nothing from the user.lib folder), 'ported it over to the target laptop, and it works perfectly. I can only surmise that the EXE isn't properly 'seeing' stuff in the user.lib folder on the target machine. The crashing EXE _does_ work properly on the source machine.
I'd even tried (seen in another forum posting) saving the source with the 'duplicate hierarchy' option set and building from _that_ copy. No good.
The crashing EXE gives me the error: "Error -2147221164 occurred in class not registered in app.vi" on the laptop. Googling this error number seems to show that it is an OS error number, with several ni.com-related postings which do not seem to apply to my situation.
Sound familiar to anybody? I'm stumped. Thanks for any help.

Hi GerdW,
Yes, I would have thought everything was included in the build too.
To me, it seems like the three VIs I'd written that I'm using are crashing the EXE on the laptop. I can pull 'disable' structures around them, build the EXE again and put it on the laptop and everything else in the VI works fine (the three VIs are math-related and, now just output zero values to the data file, but let everything else in the VI function).
As I said: two of them are *.VI files and the third is a .VI inside a *.LLB file. They are all IN the C:\Program Files\National Instruments\Lab VIEW 8.5\user.lib\ folders on both machines but it seems the build recognizes them on the source machine but NOT the laptop.
Nope - not doing any vi server stuff: everything is called directly and these are all standalone machines. I've even copied the VI out of the LLB right into the user.lib folder (and properly updated the source) and get the same results. Everything called from vi.lib works fine on both machines but stuff called from user.lib only works on the source machine.
I could understand it if the stuff wasn't IN the folder but they're identical. After seeing the first time that things weren't recognized (running the installer I'd created, then the EXE) I physically brought over the entire user.lib folder from the source machine to the laptop, so I _know_ they're the same.
Thanks for your response - I appreciate any and all help. This is the first time I've had problems building an EXE and, coincidentally, the first time I've done a build incorporating stuff from user.lib. My next troubleshooting move will be to hardwire the contents of the offending sub-VIs directly into the main VI and see if it helps (as messy as it will look...).
6.1, 7.1, 8.5 on Windows, 7.1, 8.6 on OSX

Why is my user/lib/mail folder so big?

Looking to streamline and access some space and a look at my user/lib/mail folder shows me it's over 500Mb even after a severe trimming from within Mail. I now have a total of 268 messages across all mailboxes, folders etc, and that includes a total of less than 20Mb of attachments but yet the mbox file in the INBOX and Sent Messages folders are still ~ 250Mb each. Deleted messages folder is empty and permissions etc repaired. Any ideas? Thanks

The only items within a mailbox (i.e. within an .mbox or an .imapmbox folder) used by Mail 2.x are Info.plist and the Messages folder. Any other files you may see there (mbox in particular) are almost certainly Mail 1.x files that Mail 2.x leaves there after the conversion. This is poorly explained in Mac OS X 10.4 Mail: Some mailbox files used by Mac OS X 10.3 are not deleted after importing. The article only talks about mailboxes in ~/Library/Mail/Mailboxes/, but the same can also be said about mailboxes in “POP-”, “IMAP-”, or “Mac-” account folders.
As long as you keep a backup copy of the old files for a while (at least, until you’re sure everything was converted properly), they can safely be removed from the Mail folder. OnyX has a Cleaning > Misc > Temporary and obsolete items option for getting rid of all those files.

Instr.lib or user.lib?

Hi,
I want to publish some professional LV drivers for our hardware.
Intuitively, I supposed that the right installation folder would be "instr.lib".
Nevertheless, the NI Driver and VI Library Development Guidelines" (http://zone.ni.com/devzone/cda/tut/p/id/6395)
explicitely says that the driver should be in "user.lib".
What is then the common practice for commercial drivers?
Then I am also wondering: what is the purpose of instr.lib if all drivers and user VIs should be in user.lib???
Thanks

I think the statement about placing drivers in the user.lib folder is a bit confusing since the Instrument Driver Guidelines says to place the instrument driver in instr.lib. If you submit your driver to NI for certification and it ends up getting placed on the instrument driver network, the instructions there will tell you to unzip it to instr.lib. I can understand placing any custom tool in the user.lib but to me, it just doesn't make any sense to place instrument drivers in any location other than instr.lib.

Custom Run-Time Menu Not Found in User.lib

Our Instrument Run-Time Menus are getting lost.
This is because we have some computers that are 32 bit and the code is located at
C:\Program Files\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
Other computers are 64 bit and the code is located at
C:\Program Files (x86)\National Instruments\LabVIEW 2011\user.lib\InstrumentDrivers
The directories are thus slightly different because of how Windows treats the location of 32bit LabVIEW running on a 64 bit machine.
Does anybody have an easy work around?

I'm confused by "lost". Do you mean when you build the path to your custom menu within your vi or are running some executable? Is this code you have written? If so, then maybe a simple check when initializing the paths might work.
If it is as simple as just having to decide between those two directories, then I would just check to see if the win64 bit directory exist, using "file directory info" vi. If it doesn't' exist you should get an error, then check to see if the other path exists, it should hopefully, and use that.
Not sure if this is what you need.

2010 user.lib Path in Executable Changed from 2009 (1abvi3w)

Our group often uses VI server to control other LabVIEW executables to automated testing. To control VIs through VI server in executables and monitor VIs we need to build the full path we're expecting the VI to be at within the executable.
For LabVIEW 2009 user.lib VIs the path used to show up as:
<executable name>.exe\LabVIEW 2009\user.lib\...
For LabVIEW 2010 user.lib VIs (on Win XP AND Win 7) the path now shows up as:
<executable name>.exe\1abvi3w\user.lib\...
This is just an FYI for developers. This really threw a wrench into our VI server calls and are unsure as to why it changed and why its "1abvi3w". Who's the funny guy?
Seriously though, why did this change and why use a "1" and a "3". Is this an attempt at 1337 speak?
Solved!
Go to Solution.

Paths in built applications are based on the source VI's hierarchy. For files in the LabVIEW directory, the actual LabVIEW directory name was being used in 2009. This was ok except when creating builds across platforms or across machines where LabVIEW was installed in a different location. So for 2010, a unique, constant directory name was chosen.
George M
National Instruments

User lib menu

I'm using LV6i.
I have created an entry for my user lib menu as submenu. After
this I inserted some VIs. Then I save the changes in the "Edit
controls and functions" dialog.
The next time I want to change the user lib menu (inserting new
functions) the dialog tells me "Error saving menu ... Please check
read-only attibutes." I have administrator rights on my work computer,
the attributes are ok...
So do I need to set up the submenu from scratch (deleting the old one
at first) just to add a new VI?

I had the same problem until I upgraded to LabVIEW 6.0.2. This is a free upgrade that you can download from the NI site. Also, ensure that you are saving as a custom palette (mine is under the name Robert's Palette) instead of overwriting the standard palette. You should be able to edit your menu anytime you want and it becomes the default when it is in use and you exit LabVIEW.
Rob

Lock VI.Lib User.Lib VIs

So recently I found myself accidentally editing some VIs in my user.lib. They were some reuse VIs that I was making a copy of to edit, and instead of editing my copy I edited the original. Because of this I went through and made all reuse VIs locked but with no password to help others from making the same mistake.
So now when the reuse library is installed and a user opens, they will need to unlock it before editing. Not a big deal and it isn't hiding anything behind a password. But it got me thinking, should NI do something similar with their VIs? Is this one step to help users from editing these files? Is it not necessary? And can anyone think of any draw backs to mass locking a reuse library.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Jeff·Þ·Bohrer wrote:
The simpler solution is to make them read only and hit the ini option to treat them as locked. In Fact, your SCC does this already. Unless you check out the library you intend to edit, the files will be read only. That ini setting is one of my favorites and has saved me many headaches.
Depending on where I am- vi.llb gets set to read only and some user's are handed ini files that contain the treat read only vis as locked flag set and told to never ever change it or "Pain there will be pain!" and I've been known to have a vi.lib back-up on a thumb drive on my key-ring! (Some users just have to learn the hard way!)
Onto the next observation: if you are making a copy of a reuse vi to edit you probably saved it with the wrong extension in the wrong location. it belongs somewhere in templates as a vit.
I didn't fully explain my situation. This VI is not the kind of thing that I would want a VIT for. It was a utility VI that I wanted to see if I could improve so I wanted to save a copy elsewhere, as a new VI then edit it and compare the performance to the one in the user.lib which I expected to be untouched.
I started by setting all files to read only. This is faster then having to open a reference, edit, and resave the VI. But as soon as installed the reuse library on a new version of LabVIEW it had to mass compile, which it had problems doing since I couldn't resave the file. Part of the package making process involves opening references to update description and such so I already have the reference open. Adding the Lock to the VIs I wanted didn't seem to add much overhead.
Thanks for the link to the Idea exchange I did a search on locking VIs but that didn't come up. The discussion is very interesting since I use Save All quite often.
Edit: Oh geez. I event commented in that idea exchange shows how much I remember.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

SCC again (Instr.lib / User.lib)

Hi,
I want to control my instr.lib and user.lib directory with SCC.
Should I create a top-level VI for each directory?
Should I create a "Top-" project-group including both directories to realize
cross-references?
How do I install additionally hardware-driver with a complex
directory-structure?
I'm still looking for a extensive "How to"-document for SCC (the document
http://digital.ni.com/manuals.nsf/webAdvsearch/57CC60D27B73A6FB8625665E00635
940?OpenDocument
is not deep enough!)
Mareike

My suggestion would be to specify a local working directory for SCC that is not under the main LabVIEW directory. So what to do if you want your VI's under the user.lib or instr.lib sub directories? My suggestion would be to make a utility VI that would copy your VI's from the local working SCC directory to one of these sub directories.
Chris_Mitchell
Product Development Engineer
Certified LabVIEW Architect

Add User Lib to Pallette - Black Question Marks

Hi all,
Tried to add this interesting set of VI's to the User Pallette: https://decibel.ni.com/content/docs/DOC-10952
I end up with a set of black question marks:
Using LV 2010 f2.
How to fix?
Thanks,
Battler.
Solved!
Go to Solution.

Mads is right.
Sorry, I made the modification:
Create the folder “Exaprom PDF” in the directory user.lib:
C:\Program Files\National Instruments\LabVIEW XXXX\user.lib\Exaprom PDF
Download and copy the zip contents to:
C:\Program Files\National Instruments\LabVIEW XXXX\user.lib\Exaprom PDF\
Jean-Marc
LV2009 and LV2013
Free PDF Report with iTextSharp

User-Defined Conflict Resolution

Dear,
I'm going to design User-Defined Conflict Resolution method. But reference site / documents is very few. It's difficult to find them.
Have you ever designed that ?
Do you have any sample scripts for that ?
Thanks for advance.

There is an example in the Replication Management API Reference Manual Appendix B. http://technet.oracle.com/doc/oracle8i_816/server.816/a76958/user_con.htm#133

User Account Conflict with Photoshop

I've been having a 10-15 second delay in opening any size pshop file. I've reinstalled and still no fix. Same delay whether working off the HD or server.
I've narrowed it down to the fact that if I create a new user account on the OS, pshop works perfect.
Something in my current user account is screwing me up.
I've checked printers and I dont use airport devices. Both were known to cause some issues but for me neither of these are the problem.
I'm currently running CS3 on a G5 running 10.4.9.
Any help would be appreciated...

See the steps I posted for resolving conflicts/corrupt plists within an account at:
http://discussions.apple.com/thread.jspa?messageID=4703015

Deleted users cause conflicts with new users

If I delete a user in WGM and renove their home folder from the sharepoint, I get a conflict error if I try to create a brand new user with the same name (shortname) as the deleted user/s. I'm not using the Mail service at all in OS X Server.
Where else do I search for user records to purge?
thanks

1. Go to WGM > WGM Menu > Preferences > turn on 'Show all records tab and inspector"
2. Click on the 'target' symblol tab that appears next to the users/groups/computers tab in teh laft-hand, lower pane.
3. Select Users from the pulldown menu under the tabs
Is the shortname you deleted listed here? If so delete from here, then re-add.
hth,
b.

User.lib conflict

Similar Messages

Maybe you are looking for