Labview, degrading quality editor / compiler

[Ettepet]

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.

[Norbert_B]

I am sorry, but i dont share your experience.

From your description, i expect you to update your code base from version to version. During that process, do you use the mass compile tool?

How is your project made up, does it have a good layout or does it include crosslinking to other projects?

Regarding the build issue:

Without specific examples, i think there is little chance to help you. Also you should keep track of the errors displayed. In my experience, often errors occur because of files being already in the target location.

What does "re-linking" of property nodes mean? Do you use implicit binding?

Norbert

[Dennis_Knutson]

I share Norbert's experience as well. It would help if you attached some code. Also, some clarification about the compiler. Your code is compiled in the development environment when you click the run button (after an edit).

[Ettepet]

---

@Norbert_B wrote:
 

From your description, i expect you to update your code base from version to version. During that process, do you use the mass compile tool?

How is your project made up, does it have a good layout or does it include crosslinking to other projects?

Regarding the build issue:

Without specific examples, i think there is little chance to help you. Also you should keep track of the errors displayed. In my experience, often errors occur because of files being already in the target location.

What does "re-linking" of property nodes mean? Do you use implicit binding?

---

Norbert,

1. When moving to a new Labview-version I open the project and my top-layer .vi's and save the converted result.

2. I share some low-level .vi's and Controls between 3 closely related projects in a very simple and straightforward way.  Imo this should not be allowed to cause problems.  If Labview cannot handle this I expect to see it object in a plain and clear manner.

3. About the Build-issue: I have already created a topic, several months back.  Also I have read several related topics pointing to corruption in the underlying database.  A procedure was mentioned where you'd have to find the defective object (line, node, etc.) in your code and replace it.

4.  Re-linking means: use "Link" to maken the Property-node point to a different (but in my case: very similar) Control.

This is b.t.w. the first time I see mention of "crosslinking" as a source of problems (by backwards deducing your question).  Is sharing low-level .vi's and Controls crosslinking?  How else am I supposed to share functions and functionality?

[Norbert_B]

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

[Ettepet]

---

@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.

[Norbert_B]

---

@Ettepet wrote:

[...]What I do is open each project seperately and save any updates it wants doing.  This -should- do the same as a mass compile.[...]

---

No, it is not the same.

There are very strict rules when LV compiles a VI and how VI hierarchies are compiled. Simply opening it does not compile the code. Saving and running the VI 'triggers' a recompile.

The mass compile tool essentially takes EVERY SINGLE VI in the project, recompiles it and saves it. This ensures that everything in the VI hierarchy is compiled in the correct order (usually bottom up) and components, which might be dynamically included/called are also recompiled. Also you get a final report showing you which sources created issues ("bad VI", most often because of write protection of the file or broken run arrows...).

While for small projects, your approach can provide the same result (except the final report), experience shows that it does not scale well for big projects.

Norbert

[Ettepet]

---

@Norbert_B wrote:

---

@Ettepet wrote:

[...]What I do is open each project seperately and save any updates it wants doing.  This -should- do the same as a mass compile.[...]

---

No, it is not the same.

There are very strict rules when LV compiles a VI and how VI hierarchies are compiled. Simply opening it does not compile the code. Saving and running the VI 'triggers' a recompile.

---

I don't expect it to.  But I DO expect a recompile when I open each project (and all top-layer .vi's) in the described manner in a new Labview version and then saving the changes.

[billko]

In general, LabVIEW only recompiles stuff that changed, so if you save the top level VI, it doesn't recompile anything undeneath.  I forget what the exact rules are, but it's here somewhere.