How to fix wrong dependencies and a confused LabVIEW ?

[sv123]

Hi,

My LabVIEW (2011) seems to have lost its mind, atleast I think so and am looking to find a way to fix it.

So, we have a project that uses FPGA and we compiled the FPGA code on computer A and the entire code was working fine on computer A. Lets say that the name of the project folder is 'Acquisition'. The project folder is then uploaded to a SVN server where the folder is stored in a repository.

I have posted another question about a problem that occurs when we checkout the folder from the repository. Upon opening the checked out project, we find that the previously  compiled FPGA code needs a fresh compilation. In the process of understanding this FPGA compilation problem, something has been messed up in Labview that I cannot follow.

So I made a copy of the Acquisition folder which had a perfectly working code, call it Copy of Acquisition. I renamed 'Acquisition' to 'Acquisition1'. Now I opened the project from 'Copy of Acquisition' and there were some files that were not found and I had to manually assign them (as the dialog box appeared) to the files that were in 'Copy of Acquisition' folder. After all the assignments were made, the project opened fine but I found that the compiled FPGA code still required a recompilation. So then I decided to quit LabVIEW and delete the 'Copy of Acquisition' folder. Now I renamed the 'Acquisition1' back to 'Acquisition'.

And here is what the problem is, now when I open the project file in 'Acquisition', I get messages that says 'Project Dependancy Conflicts Detected', and the dialog box lists reference to files in 'Copy of Acquisition' folder. I cannot understand how a perfectly working code is now producing errors. Labview is clearly messed up.

So to investigate further, I now deleted the 'Acquisition' folder as well. Then I checked out the project folder from SVN into a new 'Acquisition' folder. Now remember, the working code was uploaded to SVN before even the 'Copy of Acquisition' folder ever existed. Upon launching this brand new project in a brand new folder, I still got the same dependancy message. Again, I just cant seem to follow where is it that Labview gets its misguided information from.

Finally, I went to another computer, say B and checked out the project folder into a fresh folder on it. When I launch the project on B, everything loads fine, the only problem is that the compiled FPGA code requires a recompilation.

So the project gives dependancy message on A but not on B. So it seems Labview on A is messed up, but how, why and where and what can I do to clear this memory on A. I have tried Clear Compiled Object Cache, deleted the labview.ini file, there is no change.

If anyone has any insights, I would appreciate it.

Thanks,

Best,

Saumil

[Brandyn]

Have you tried mass compiling on Computer A?

[Mark_Yedinak]

How are you copying and renaming the projects? If you are doing this from Windows Explorer you will run into problems like you are seeing. When working with projects you should always do any renaming or copying from within the project itself. This allows LabVIEW to update all of the path information in the project file itself. If you copy and rename from outside of teh project the project file does not get updated and it refers back to the old location and names of the files.

[GregFreeman]

How is your Open FPGA VI reference configured? Is pointing at a specific file, or at a VI? And, is your bitfile in svn? If the bitfile isn't in SVN, it won't get moved onto your second computer. Therefore, it won't be able to find the bitfile and a recompile will be necessary, no matter how you have your Open FPGA VI reference configured. Both ways of configuring this function require a bitfile, but they do some things a little differently. I won't go into the details (unless you want me to) but either way, a bitfile is required.

As for saving, take Mark's advice. All sorts of issues happen when you have multiple copies of the code laying around your computer. But, if you do save as and save the hierarchy, this should keep these sorts of issues from happening.

[Brandyn]

Good suggestion Mark