Labview, degrading quality editor / compiler

Question

Working with Labview since version 8.1, nearly 6 years ago, the functionality has been extended but the quality underneath the surface of both the editor and compiler is getting worse and worse.  Do others experience this?
Just some observations:
- The compiler has become a lot slower, as it seems to be doing continual consistency checks, at each run.
- Saving a bunch of slightly modified vi's and controls has become a lot slower, as it seems to be doing a lot of continual consistency checks and preemptive/preventive corrections before saving.
If these checks were effective I could live with the mostly unnecessarily-repetitive overhead.  But then I find that:
- Since moving to Labview 2010, 2011 and now Labview 2013 I find myself in a position where I have to do 2 (or more) compile runs (Build .exe) of several minutes to create a single .exe.  Each intermediate Build ends with an unspecific, vague error message right at the end of the Build.  As far as I have been able to determine several of these errors have to do with corruption in the underlying database which represents the Labview code.
- Even though it should be fixed I find that after re-linking a bunch of Property-nodes from one Control to a similar Control, the whole group of Property-nodes is linked to each other but not to the new assigned Control.  This is just an example.
- Labels not in their default spot are still being mishandled after conversions, re-linking Controls, etc.
Most of these issues come down to problems (or blatant corruption) in the underlying database where Labview stores your code, introduced or mishandled by either the Labview editor or its compiler.
In stead of gradually lessen I feel these issues have become worse and worse in recent Labview versions.  Combined with all the minutes wasted by the editor and compiler trying to prevent this I would rate this as a (very) poor state.
On a personal level I am getting to a point where I will have to advise my manager to move to a different environment for all non-Labview-essential coding.

Answer 1

Norbert_B wrote:
OK, "backwards" answer :
The term "Crosslinking" describes a situation where a component is shared between multiple projects. So obviously, you have crosslinking between at least three projects.
That being said, crosslinking does not need to be a problem; but it is something easily creating issues as it is a shared resource.
Updating your projects is a perfect example:
If you mass compile (you obviously don't do it yet) one project (e.g. "A"), all components are updated.
After doing this, the other two projects ("B" and "C") wont open up in the 'old' LV version as the crosslinked components are already recompiled for the new version.
There are three feasable options:
a) Keep crosslinking. Be aware of all issues which might occur by this, but it could be an advantage (changes dont need to be deployed to each project over and over).
b) Dissolve crosslinking by putting the shared component into each project as separate, project-specific copy. I recommend you to prepend a project abbrevation to the component during that process; otherwise, crosslinking can be easily re-introduced.
c) Separate Compiled Code from VI. This is an option NI added to LV 2010. This will add overhead to the development as each machine has to recompile the VIs after opening them (no compiled code in the VI file!). Advantage is that each compilation can be system specific and re-compiling doesnt modify the VI-file.
It sounds as if you are using implicit bound property nodes. Do you have an example VI where we can reproduce the issue you are seeing?
Yes, building an application can be tricky from time to time. Another source of errors i forgot to mention are conflicts in the project. Rule of Thumb: Never try a build if there are still conflicts displayed in the project explorer. Do you already follow that rule?
Please try running the mass compile before working on the project in the new version. Opening the top-level VI(s) and saving is most often not sufficient. This recommendation is 'invalid' regarding your base libraries if you chose to go for option c) mentioned above. Reason: Compiled code is not part of the VI-file, so the compiler has always to recompile all VIs once they are opened first time on the machine.
Norbert
Norbert,
I did a couple of mass compiles to tackle a few "Nonfatal insanity" (talk about "Backwards" ) errors I had, and which mysteriously dissapeared.
What I do is open each project seperately and save any updates it wants doing.  This -should- do the same as a mass compile.
And this brings me to one of the main issues I have with Labview:  I constantly have to avoid a straightforward solution because of shortcomings in Labview.  The alternative is just as bad: I have to create examples of bugs to be used on this forum and go through all the effort of generating bug-reports.  A process which has already amounted to several working days of my (and my companies) time so far, to discover none of these bug-reports have been solved a year later or are even mentioned in the "Known bugs" list.
I will have a look at your suggestions to see if somehow I can make this into a manageable working procedure.