05-06-2015 03:49 PM
I'am trying to build my LabView project but get the following error:
VIEW 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:
***\MotorLoad_class\protected\ObjectAttributes.ctl
***\MotorLoad_class\protected\ClassAttributes.ctl
***\MotorLoad_class\utils\ObjectAttributesRef.ctl
***\MotorLoad_class\utils\NotARefNum.vi
***\ACS800_class\protected\ObjectAttributes.ctl
***\ACS800_class\protected\ClassAttributes.ctl
***\ACS800_class\utils\ObjectAttributesRef.ctl
***\ACS800_class\utils\NotARefNum.vi
***
... Here follows a long error list (100+) with most of my G# classes .ctl and .vi files
Most of the VI's (and .ctl) in the error list are automaticly created by the G# IDE.
Do I have to rename all "protected" and "utils" methods and control in the classes manually to be able to build my app? Or are the some other way to solve this problem?
I'm using G# 1.6.4 and LabView 2013f2 (32-bit)
05-06-2015 06:07 PM
As the controls are part of a class, they should have a unique namespace so it shouldn't be a problem, do you have LV8.2 file structure active when building? That's the 1st thing on my mind.
/Y
05-07-2015 01:17 AM
Don't know. How can I check that?
05-07-2015 01:58 AM
Hi,
Strange, but I do think this is some kind of LabVIEW problem, since G# is just LabVIEW - a native class with a DVR inside. I think it is something in your LabVIEW class, a type in the attribute clusters or similiar that causes the problem.
Try the following:
1) Open up your entire LabVIEW project in memory, press and hold CTRL + SHIFT and the press the "Run" button for your top level VI. This will force LabVIEW to do a complete recompile of all VIs in memory. For a large project, it will look like LabVIEW freezes or hangs, but be patient. It can take an hour or so, but when finished, you need to resave all VIs. Then restart LabVIEW (to clean memory), open build project and try building again.
2) Open the G# example call G# - Dependency Injection.lvproj (Help->Find Examples-> search for G#). In this project there are two build projects defined. Can you build these example projects?
What LabVIEW version and OS are you using?
Mattias
AddQ
05-07-2015 02:16 AM
1) no change after recompile, same errors as before.
2) Works OK!
I'm using LV13.0f2 (32-bit), G# 1.6.4 and Win7 64bit
Part of the error message:
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:\...\Platform\Code\Testbed\class\MotorLoad_class\protected\ObjectAttributes.ctl
C:\...\Platform\Code\Testbed\class\ACS800_class\protected\ObjectAttributes.ctl
C:\...\Platform\Code\Testbed\class\MotorLoad_class\protected\ClassAttributes.ctl
C:\...\Platform\Code\Testbed\class\ACS800_class\protected\ClassAttributes.ctl
C:\...\Platform\Code\Testbed\class\ACS800_class\utils\Kernel.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\utils\NotARefNum.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\Destroy.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\utils\ObjectAttributesRef.ctl
C:\...\Platform\Code\Testbed\class\MotorLoad_class\utils\ObjectAttributesRef.ctl
C:\...\Platform\Code\Testbed\class\ACS800_class\utils\ClassAttributesRef.ctl
C:\...\Platform\Code\Testbed\class\MotorLoad_class\utils\ClassAttributesRef.ctl
C:\...\Platform\Code\Testbed\class\MotorLoad_class\utils\Kernel.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\utils\NotARefNum.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\Destroy.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\CreateInstance.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\CreateInstance.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\Instance.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\Instance.vi
C:\...\Platform\Code\Testbed\class\ACS800_class\DestroyInstance.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\DestroyInstance.vi
C:\...\Platform\Code\Testbed\class\MotorLoad_class\properties\mode\Getmode.vi
C:\...\Platform\Code\Testbed\class\WT333_class\properties\mode\Getmode.vi
C:\...\Platform\Code\Testbed\class\WT333_class\utils\ObjectAttributesRef.ctl
.
.
.
.
05-07-2015 02:30 AM
Hi,
Well, it seems like the G# parts work. The renaming and moving is as it should be. It will be like this in a build when there are files with identical parts. Thats just the way LabVIEW classes behaves in builds. By default LabVIEW places every file in the "root" of an exe, but if there are collisions between files, they will be moved like you se above.
I still think you have some problem with LabVIEW code, like the drivers you are using for your motor load ACS800. You need to isolate what is causing LabVIEW not to build. Try the following:
1) Try making just a simple VI without any classes and just put the communication code from your ACS800 directly in this and try to build.
2) Remove the ACS800 from you large project (I assume this is a subclass of MotorLoad) and try to build.
This way you can try to narrow down to what part of your code that causes LabVIEW not to build.
A general tip is that I almost always try to follow, is to build very often, even when project is not finished. As soon as I have the first compilable code, I build even if the resulting executable is useless, but I will very early in my project find issues that may cause problems during builds that I can deal with directly and it is not that fun to find these late in the project close to a real delivery.
Mattias
05-07-2015 02:51 AM
05-07-2015 02:59 AM
Yes, but can you really control that inside of an exe? I believe that you can only do that but putting the VIs outside the exe. The two build examples in the demo illustrates just that.
However, that should not affect if the project builds or not. Which is the case here.
Mattias
05-07-2015 03:44 AM
05-07-2015 03:56 AM
I build a very simple project with the classes that caused me trouble and now its possible to build without error 🙂
I will now try to remove some of these classes from my large project and see if something changes.