The full development version of LabVIEW is required to fix the errors

[Mark_Yedinak · Accepted solution]

We ran into a similar issue one time and found that the cause was some code in a diagram disable structure. Even though the code was disabled it still wanted to load VIs that were inside it. Any chance you have any diagram disable structures in your code?

[bmann2000]

Many thanks to everyone who has responded with ideas to keep me motivated.

I've been back through SVN and tried to build around 20 different copies of the source code.  This was not easy because a lot of the SVN entries were work in progress and would not have built anyway, I had to figure out which SVN entries were buildable, then establish at which entry the broken run arrow appears.  That process led me to a single SVN entry where 4 VIs had changed, there were not many changes either, so it was easy to spot the issue.  BUT I'm still baffled and a bit annoyed at the offending edit.  See .jpg inserted inline below.

I had disabled a pulse log VI using a regular case structure to help find another bug.  There is nothing in the False case except the error wire passing through.  The VI with the edit is a dynamic dispatch VI that is part of an OOP Class.  I do not have any diagram disabled structures in my application because an NI applications engineer once told me they can cause problems with the compiler.  I really can't believe this is the cause.  I've removed the case statement, compiled, no broken run arrow, added the case statement back in, compiled, broken run arrow, repeated the same 3 times, this is the sole cause of the broken run arrow.

How can this happen?

I then moved to the most recent SVN copy and removed the same case structure, created build, broken run arrow was gone.

[Mark_Yedinak]

I think you may have implemented the diagram disable structure, at least in terms of the compiler and optimization goes. Logically it is the same as a diagram disable function and for whatever reason the compiler is getting confused. Does the subVI that you commented out have any dynamic calls in it? If so, the compiler may expect those to be loaded but because the case is disabled the compiler may never include that subVI as part of its optimizations. this sounds very similar to the issue I described above with diagram disable stuctures and aligns with what the NI AE told you.

[Kyle97330]

Instead of a False constant on the block diagram, can you try replacing it with a Boolean control with a default value of False, and then hide that control on the front panel?  Even though the control will never be toggled, LabVIEW's compiler can't "know" that for sure, so it doesn't treat it as a dead case.

If you have ever loaded old (pre-8.0) code into modern LabVIEW, that's what it does whenever it finds a constant wired into a case structure for backwards compatibility.

[JÞB]

---

@JÞB wrote:

Probably the quickest way to drill through the problem is to enable remote debugging on the broken exe then open a debugging session from a machine with the full dev enviornment.  that will allow you to use the error window to isolate the root cause fairly quickly.  NOTE: this may just ressult in a running exe  (Wildly suspicious of an unknown bug) 

I'l also recommend running VIA on the vis that commited when things went bad.

---

And the Magic 8-Ball strikes again!

The compiler removed the unreachable code!

VIA would have flagged that!

Seriously, I'm glad you got to the root cause.  Congrats  And thank you for sharing the root cause!  That will save someone else a handful of hair!

[bmann2000]

Hi Jeff,

Just to clarify, the exe application got broken because the compiler removed the unreachable code i.e. the VI in the True case of the case structure that was wired with a False constant.

The exe wanted to load that VI, but it was missing because the compiler removed it, hence the broken run arrow.

I had a look at VI Analyser, never used it before but I will definately be using it on all new VIs.  Although when I added the offending broken arrow case structure back in, ran VIA, there was no warning about unreachable code. 

The PulseLog VI inside the case structure contains a write to spreadsheet VI inside a case structure that receives it's True/False from a Functional Global, this allows me to enable/disable pulse logging from a config file.

I quite often like to rewrite a section of code, but leave the old version in a case structure on a diagram encase I decide to revert at some future date.  This has never been a problem before, but it looks like it's not safe if the code includes a SubVI that's not used elsewhere in the application.

[JÞB]

---

@bmann2000 wrote:

Hi Jeff,

Just to clarify, the exe application got broken because the compiler removed the unreachable code i.e. the VI in the True case of the case structure that was wired with a False constant.

The exe wanted to load that VI, but it was missing because the compiler removed it, hence the broken run arrow.

---

 Exactly- with full compiler optomizations unreachable code MAY be removed.  Curious, did you change optomization setting in the .ini or leave it at the default 5?  it would give me a clue as to wether the app builder respects the ini file setting?

---

I had a look at VI Analyser, never used it before but I will definately be using it on all new VIs.  Although when I added the offending broken arrow case structure back in, ran VIA, there was no warning about unreachable code. 

---

 See above 

---

The PulseLog VI inside the case structure contains a write to spreadsheet VI inside a case structure that receives it's True/False from a Functional Global, this allows me to enable/disable pulse logging from a config file.

I quite often like to rewrite a section of code, but leave the old version in a case structure on a diagram encase I decide to revert at some future date.  This has never been a problem before, but it looks like it's not safe if the code includes a SubVI that's not used elsewhere in the application.

---

 From hearsay and imagination I think this is only a DD vi issue- wireing the case selector to a hidden bool control should make it safe.  You should Kudos Kyle that suggested it