G#

cancel
Showing results for 
Search instead for 
Did you mean: 

Can't build app. with G# classes

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)

0 Kudos
Message 1 of 11
(11,976 Views)

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

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 2 of 11
(10,032 Views)

Don't know. How can I check that?

0 Kudos
Message 3 of 11
(10,032 Views)

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

0 Kudos
Message 4 of 11
(10,032 Views)

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

.

.

.

.

0 Kudos
Message 5 of 11
(10,032 Views)

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

0 Kudos
Message 6 of 11
(10,032 Views)

Have you set "preserve disk hierarchy" on the destinations that include classes? If not, labview will try to put everything in one folder and will need to rename files with duplicate names. The filenames does not include the namespace.

Certified LabVIEW Architect
0 Kudos
Message 7 of 11
(10,032 Views)

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

0 Kudos
Message 8 of 11
(10,032 Views)

You are correct, Mattias. It depends on what you are building. I guess you are building an exe. Follow Mattias suggestions and the G# examples Mattias mentioned and it should work.

Certified LabVIEW Architect
0 Kudos
Message 9 of 11
(10,032 Views)

I build a very simple project with the classes that caused me trouble and now its possible to build without error 🙂

Capture1.PNG

I will now try to remove some of these classes from my large project and see if something changes.

0 Kudos
Message 10 of 11
(10,032 Views)