"LLB of that name already exists" Error

[MerRhosyn]

Hi -

I just tried to move a LabVIEW VI from a desktop to a laptop PC.  6-year-old desktop wasn't powerful enough to run the program.

In order to group the main VI with the sub VIs, I used the "create folder" option.  I then copied this over to the laptop.  The laptop has operated LabVIEW for a while.  I also recently loaded the drivers for Labjack U12 onto it (my program reads voltages from a Labjack).

I was able to run the program perfectly fine until I restarted the computer.  When I opened the main VI, I had to redirect LabVIEW to several of the sub VI files.  This worked (and has worked fine in the past) until I got to loading the ljackuw.dll folder.  When I go to select it from the location where it is stored I get an error "You cannot choose this folder name; an LLB of that name already exists." 

I've read some of the topics regarding duplicate .dll files.  I found several instances of the .dll file on the notebook (one from the folder copy, one from the LabView intallation package, one from the Labjack driver package.  I deleted all save for one copy of the .dll file, but that hasn't solved the problem.  I tried creating a new .dll with the sub VIs that weren't loaded...that didn't work.  I tried going into the configure driver library panel and specifying the new path for the .dll.

Help!  Not a programmer and not sure what to do now that the program crashes the desktop and won't open on the laptop!

Meredith

[mikeporter]

First let me say that I have no real idea what could be causing the problem, but I can think of a few things that I would check (yes, this is a shot-in-the-dark). Do you by any chance have the Windows extension turned on that allows Explorer to treat LLBs as directories? If so, try turning it off and see if that helps.

Second, let's take the error message at its word... Do you have an llb and a directory that have the same name?

Again, these are WAGs but they are worth a try.

Mike...

[LabJackSupport]

A couple other ideas:

See if you can open and run some of our simple examples such as "e function example.vi".

Zip up and send us (support@labjack.com) your VIs and we can see if we can open them (LV 7.1 or less).

[Danielle3]

I'm having this same problem - was there a solution?

[aeastet]

Try mass compiling the folder with all of the software.

[Danielle3]

Thank you for your swift response!

Unfortunately, it has the same errors - when I just let it run on its own, it says "Search failed to find "ni845x.dll" previously from "ni845x.dll" " and when I successfully click the "browse" button while it is looking for the DLL during the compile, browsing to the new location of the file and selecting it results in the "LLB of that name already exists" error.  Is there a step I'm missing?  I'm self-taught in LabVIEW (boss said, "Danielle, we need you to do this LabVIEW stuff"), so maybe I'm missing something obvious?

[aeastet]

The dll "ni845x.dll" is part of a driver that NI provides for SPI and I2C for the 845X cards. Maybe the driver is installed in the vi.lib folder and you are taking it to a folder for the build of an exe. Maybe the driver is not installed. It is hard to help without knowing more about what is going on here.

Are you using a project file?

Did you install LabVIEW and then just try to get this program running?

Did you install the drivers for all of the things that you are trying to use or did you just copy things from another computer and hoped that it would work?

[Danielle3]

I was hoping this was a more generic error, because I'm a little embarrassed to explain the convoluted way I got to where I am right now.  But try not to shake your head too hard.  XD

I've actually moved on from altering existing programs in the last four or five years that I've been slowly trying to learn LabVIEW (in the background, because this is, of course, not all of my job).  I created this program on my Windows 7 computer a couple of months ago, and it was working fine.  The users requested a change a couple of days ago, but I have been upgraded to a Windows 10 computer in the meantime.  It seemed simple enough to just install the driver for the NI-8451 and make the change - but it had some trouble recognizing the device after installing.  I'm afraid I don't remember the specific details of how I eventually got it working - something to do with renaming the device in MAX.  It seemed pretty computer-specific at the time.  Perhaps it was and this has nothing to do with the error, but I felt it was useful to give you the information, just in case.

Either way, when I finally managed to get it working, I built the application - but the end-users now report that the application can't find the DLL on their computer.  I visited them and tried adding the DLL into the location it seemed the application was looking for it, but that didn't help.  So I decided it was a good idea to try to include the DLL in the build data folder, to avoid this issue in the future.  But when I copied it (I didn't want to burn my bridges by moving it entirely!), it seems that half of the VIs followed it to the new location, and half didn't.  So I tried renaming the file in the previous location, which caused it to be unable to find it, and allowed me to tell it where to find the DLL - but now it refuses to talk to the new file, because it's already using that file for the other VIs.

If I return to an earlier version of the project file, where I assume all of the VIs were talking to the same file, and then *move* (instead of copying) the DLL, will that work?  Or is there a better way to include the DLL?  Or is there a better solution I am not seeing?

Thanks again for your time.

-Danielle

[aeastet]

OK so here we go:

When you created the NI-8451 in NI max it had a name that was auto generated when the NI MAX program fond the device. It generates this name every time it find a new device. The name will be different. You must have eventually changed the name to the name when the code was originally developed. That is why it started working. To fix this and make you code more flexible you need to give the user a way to configure what device they are using. I usually have a populated enum that is populated with available devices so they can pick from devices that are on the system they are using. Once they select the device I save it somewhere (ini file, registry, setup file etc...)

Now moving to why your code didn't work at the new location. You need to have the other user install the driver for the NI-8451 on their computer. You cannot just copy a dll and expect it to work. Give them your software and a list of drivers they need to install or make an installer that includes all of the installers they will need through the application builder.

I hope this helps.

[Danielle3]

I'm afraid this doesn't quite fit, sorry - my VI has a control on the front panel for the user to select the device - it is not coded to use a specific device. I couldn't figure out how to make it find a list of connected devices and simply select the one that was an 8451, though I had wanted to.  When it wasn't working, I was still selecting the device from the auto-generated list in the control - but, even though it listed the device, after I selected it, it would say it couldn't find the device.  I know for a fact that I did not change the name to the same alias it was using on the previous computer, but after changing it a few times (because that was the suggested solution after a Google search for why it wasn't recognizing the device), it finally started working.

As to the end users' problem, the application was working for the last two months - they had installed the driver a long time ago.  But when I sent them the new application built after the move to my new computer, they were unable to run it - the error said it couldn't find a bunch of VIs, and when I inspected the list, they were all VIs that should have been in the DLL.  I assumed it was looking in a different place and simply copied the DLL to the new place - should I have reinstalled the driver?  If I do, will I be able to put it in a new location?  Or can I create the installer for my application to install the driver in the appropriate location?  I've never made an installer before.  I'm starting to wonder if this level of restructuring is worth the two textual changes they asked for...  Maybe I just tell them to go back to the working software version.  But I assume there will be more change requests eventually, and I'd rather get this fixed while I still remember most of what I've done...