LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Name collision error occurs when building executable

Knowledge base article 4KG6SEKG addresses this error, but I find the solution unacceptable.  I am using two Agilent drivers, one for a power supply and the other for a DMM (it is interesting that the KB article uses one of the drivers I'm using as an example).  Anyway, I really, really don't want to rename the VIs.  The program runs fine with the alledged conflicts in place.  Is there something I need to be concerned about?  The KB article is for version 8.5.  Is this a new "feature" in 8.5?
 
 - les
 
0 Kudos
Message 1 of 21
(6,112 Views)

>Anyway, I really, really don't want to rename the VIs.  The program
runs fine with the alledged conflicts in place.  Is there something I
need to be concerned about?  The KB article is for version 8.5. 
Is this a new "feature" in 8.5?

It is a bug that this doesn't work in an executable. The ability to have two
VI's with the same name in memory is a new feature, introduced with the
project explorer (8.0).

Renaming is the only simple solution. The only other solution I can think of
it to make a dll out of the driver... Updating to 8.5.1 or 8.6 might also
help, although it's not in the list of bug fixes (for 8.5.1 or 8.6).

Regards,

Wiebe.


0 Kudos
Message 2 of 21
(6,084 Views)

Hi Les Bart,

The name collision error occurs due to name conflicts and at present all third party instrument driver dependency files are given the same names regardless of the instrument. They follow a standard naming standard and therefore, the only option is to manually rename them.

Ipshita C.

National Instruments
Applications Engineer
0 Kudos
Message 3 of 21
(6,072 Views)

I am having the same issue with the Report vi's. See attached screenshot. This same name shows up in 6 different locations! The builds work, but it is annoying.

 

Tay

0 Kudos
Message 4 of 21
(6,026 Views)
Same exact problem here.  It showed up when I upgraded to 8.6.
0 Kudos
Message 5 of 21
(6,005 Views)

I just started using reports in my project.  The number of renamed vis increased dramatically.  I would suggest that NI investigate resolving this issue at least for the vis they deliver.  I need to be made aware of name collisions, but when NI's own vis cause collisions among themselves, there become a lot of warnings that can be safely ignored.  However, I am concerned that buried in that list of warnings there is a legitimate warning I need to be aware of.

 

 - les

 

0 Kudos
Message 6 of 21
(6,004 Views)

For VIs in libraries, you can rename the VIs during the build process instead of on disk. Starting in LabVIEW 8.5, you are able to do this via the build specification properties dialog. In the Source File Settings page, there is the option "Rename this file in the build" for individual files. You can also apply prefixes to files that are in a project folder from within the same page.

 

You will get similar warning for dynamic dispatch VIs that are used in LabVIEW classes. Because the mechanism used to perform the dynamic dispatching relies on the name of the VI, you should not rename the VIs. While there are extra files and directories generated during the build process, the application will function properly. This KB - 4OKDCDES  provides information on a way to handle the generated files.

George M
National Instruments
0 Kudos
Message 7 of 21
(5,998 Views)

It's easy to replicate the problem - open up the example "HTML Report.vi", and create a project with this file as the startup VI.   Specify this VI as an application (NEW Application) under Build specifications, and then build all.  You get a lovely barrage of warnings... here is a truncated list (the full list exceeded the maximum allowed characters for this post!)   Any time you use any of the report generation VI's included in the application you get similar warnings.  I suspect this is an 8.6 bug.

 

LabVIEW prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination. You can rename files as part of the build process to avoid name conflicts.

The following files were moved to a unique location:

C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append Control Image to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\HTML\Append Control Image to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append File to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\HTML\Append File to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append Horizontal Line to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\HTML\Append Horizontal Line to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append Hypertext Link Anchor to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\HTML\Append Hypertext Link Anchor to Report.vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append Image to Report (path).vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\HTML\Append Image to Report (path).vi
C:\Program Files\National Instruments\LabVIEW 8.6\vi.lib\Utility\NIReport.llb\Append Image to Report (string).vi

Message 8 of 21
(5,987 Views)

 Hi Stevengd,

 

The filename collision error used to show up as an error in 8.5.1 and used to prevent the build process. I suspect that in 8.6 the errors have been modified to warnings so as to let the build continue. This is a namespace issue and as the back-eng of LabView follows normal text-based programming constructs, two variables cannot share the same namespace. I hope that answers your question.

 

Ipshita C. 

National Instruments
Applications Engineer
0 Kudos
Message 9 of 21
(5,955 Views)

 I appreciate the responses from the NI AEs.  However, I'm not getting any impression that this will be fixed.  In my opinion, these warnings are just plain wrong.  One fix I can think of is that if the collisions occur between NI supplied VIs, don't report a warning (or error) because you have done your homework and know that these name collisions are benign.  If the collision occurs between my VIs and NI VIs, then a warning is appropriate.  I'm still trying to decide if there should be a way for me to disable that warning on a VI by VI basis.  This would let me suppress certain warnings so that I will see the "important" warnings.

 

Thanks,

 

 - les

CLAD

 

0 Kudos
Message 10 of 21
(5,952 Views)