LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"LLB of that name already exists" Error

I think you have a misconception about how LabVIEW works. There are no vi's included inside of a dll. The missing vi's were because the driver was not properly installed on the new computer. When they move the program to a new computer the drivers (including the vi's that go with the dll where not in the vi.lib folder that would have been generated when installing the actual driver.

 

As far as the problem where the device was not working then all of a sudden started working. It seems like a naming problem or the drivers were not installed properly here as well and you finally moved over enough files that you finally got it to work. You should install LabVIEW (or the run time engine), then the rest of the drivers for what you are using. If you were using a DAQ device you would have to install all of the drives through DaqMX and not just the dll's. Then you would have to additionally add the driver for the 8451. It is not included in the DaqMX dirver set.

Tim
GHSP
0 Kudos
Message 11 of 28
(1,193 Views)

Whether or not they are actual VIs, the files listed as missing - which have the ".vi" extension - correspond to many of the files listed in the LLB manager when looking at the NI845x.dll:

Danielle3_0-1580401360691.png

All of the computers on which I have attempted to run this application have had the driver for the NI-8451 installed properly - all DLL copying occurred AFTER the errors.  Additionally, the missing file errors occur on the end-user's computer, which has not changed since the working version, and which, indeed, still works perfectly with the previous version of my software.

I did not move any files by hand when attempting to get the device to work on my new computer - and I reinstalled the NI-8451 drivers several times using the NI Package Manager when attempting to make the device work - reinstalling had no effect.  I'm not just willy-nilly moving and copying files - that was my response to the problem, not the cause of it.

0 Kudos
Message 12 of 28
(1,189 Views)

A few more thoughts:

If you are including a copy of the DLL that could be causing a problem. I would remove that from your build. It should find the DLL in the vi.lib folder atomically as long as the driver is installed. What is the setup that you are using (daq cards, drivers, computer, etc...)?

 

I use the NI8452 on at least 5 other computers. They are running off of an exe. I do not have this problem. I am running in WIndows 10 64 bit. I do not include the NI845 dll in my build data folder.

 

What happens when you let the computer try to find the missing vi's? does it ever find them in the vi.lib folder? If you post your code it might help figure out why you are having this problem.

Tim
GHSP
0 Kudos
Message 13 of 28
(1,183 Views)

I have a few other thoughts here:

 

Let's try to figure out if the problem is your software or the driver.

  • Install NI Max
  • put the driver software on a clean machine for the NI845x.
  • Open NI Max and see if you find the device.
  • See if the NI8451 device shows up. Unfortunately there is no self test for these devices

Make a simple program that only talks to the NI8451. See if you have any problems. Then start adding layers until you find the problem or until it is working.

Tim
GHSP
Message 14 of 28
(1,176 Views)

One other thing I can think of would be Windows permissions. Have you tried running this program as an administrator? Make sure you have access to any place where you are trying to access a file.

Tim
GHSP
0 Kudos
Message 15 of 28
(1,171 Views)

I know you stated the customer had the drivers installed from a previous build.  But If you got the latest drivers on you development PC and then built an application, it is likely that you need to update the driver to the latest version version on the deployment PC.  I recently ran into problems with DAQmx this way.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 16 of 28
(1,165 Views)

@Danielle3 wrote:

Whether or not they are actual VIs, the files listed as missing - which have the ".vi" extension - correspond to many of the files listed in the LLB manager when looking at the NI845x.dll:


Look closer.  You are opening NI845x.llb.  A DLL is a fully built library.  An LLB is a collection of LabVIEW files.  But it is very likely the VIs in that LLB are calling NI845x.dll.



There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 17 of 28
(1,160 Views)

I have not been including a copy of the DLL in my build - I have been *trying* to do so in response to these errors, but I have not been successful, and, in light of this conversation, I will obviously stop trying.

I'm not sure how to describe my setup, and I completely agree with you - I hadn't been having these problems and it seems ridiculous that the application would suddenly have trouble finding a properly installed driver.  It didn't need administrator permissions to run previously, so I'm hoping it's not that.  I have not seen the LabVIEW runtime trying to find the missing VIs, so I can't tell you what would happen if I let it do so.

My code consists of a large number of interlocking VIs and sub-VIs, and I wouldn't know where to begin trying to post it.

I will, however, take my "control panel" VI - that I made just to control the NI-8451 and has nothing else on it at all - to the end-user computer and see what happens when I try to run that.

0 Kudos
Message 18 of 28
(1,156 Views)

The reason I asked about the administrator access. is you said that you were developing in Windows 7 and now the new systems are using Windows 10. Windows 10 allows the IT group to lock things down and control access to things more stringently. I have had this problem over the years as Windows has evolved.

Tim
GHSP
0 Kudos
Message 19 of 28
(1,152 Views)

crossrulz, that is an interesting theory, and I'll look into updating the driver, thanks.  I see what you mean about the "LLB" extension.  I wonder if I have messed that up in my attempt to solve this issue.  I'll reinstall the drivers again.  Thanks.

-Danielle

0 Kudos
Message 20 of 28
(1,147 Views)