Baffling VI Breakage

[paul_cardinale]

I am working on a very large and complicated project.  For many reasons, this needs to run in the development environment, not as compiled code.

I want to distribute it without diagrams, but removing the diagrams breaks things.  I've managed to narrow it down to this:

1. I build the distribution, leaving the block diagrams intact.

2. From that distribution, I:

   1. Open the top-level VI. It’s not broken.

   2. Save it without the block diagram*. It’s still not broken.

   3. Close it, then re-open it. Now it’s broken; with the error: "VI has a bad connection to or cannot find a subVI or external routine."

   4. Close it again.

   5. Open a VI that’s dynamically loaded (as far as I can tell, there are no static references nor calls to this VI from any other VI).

   6. Now open the top-level VI again. It’s not broken,

How is it possible that a VI is broken or not depending on whether a dynamically loaded VI happens to be in memory?

Note that it I:

1. Revert the top-level VI to the version with the BD.
2. Delete that dynamically loaded VI from the file system
3. Load the  top-level VI, it's not broken.  It has no static dependency on that dynamically loaded VI until I delete its block diagram.

This whole affair is degenerating the quality of my insanity.

* I have a tool that does that.  There used to be a keystroke sequence for saving a VI without its BD. but I don't remember it.

[aputman]

---

@paul_cardinale wrote:

For many reasons, this needs to run in the development environment, not as compiled code.

---

I don't understand this but hey...to each his/her own. 

In order to save your sanity, or at least what is left of it, could you just password protect the block diagram instead of remove it? 

[RTSLVU]

---

@paul_cardinale wrote:

 For many reasons, this needs to run in the development environment, not as compiled code.

---

I for one am interested in these reasons. As there's not a single reason that I can come up with for any program, no matter how complex that it would NEED to be ran in the development environment.

But I will add that the most common cause of a program failing to run properly when compiled but runs fine in the development environment is race conditions because the compiled code runs faster. 

Also are you by chance using Chanel Wires? I recall recently seeing a post about Chanel Wire OOP failing when VI's are loaded.

[paul_cardinale]

---

@aputman wrote:

---

@paul_cardinale wrote:

For many reasons, this needs to run in the development environment, not as compiled code.

---

I don't understand this but hey...to each his/her own. 

In order to save your sanity, or at least what is left of it, could you just password protect the block diagram instead of remove it? 

---

LabVIEW's password protection is way to weak.

[paul_cardinale]

---

@RTSLVU wrote:

---

@paul_cardinale wrote:

 For many reasons, this needs to run in the development environment, not as compiled code.

---

I for one am interested in these reasons. As there's not a single reason that I can come up with for any program, no matter how complex that is would NEED to be rain in the development environment.

But I will add that the most common cause of a program failing to run properly when compiled but runs fine in the development environment is race conditions because the compiled code runs faster. 

Also are you by chance using Chanel Wires? I recall seeing a post about Chanel Wire OOP failing.

---

I have the same problem with my cow-orkers: The pay attention to about every 3rd word that I utter/write.  Obviously it's NOT a race condition because the VI is broken!  That means it can't run!

As for needing the development environment:  Try looking at the detailed help for a property or method.  There you will see a table; and one of the entries will be "Available in Run-Time Engine".  For many properties and methods, there will be a "Yes" after that; but, guess what: there are also many properties and methods that have a "No" for that.

[RTSLVU]

---

@paul_cardinale wrote:

---

@RTSLVU wrote:

---

@paul_cardinale wrote:

 For many reasons, this needs to run in the development environment, not as compiled code.

---

I for one am interested in these reasons. As there's not a single reason that I can come up with for any program, no matter how complex that is would NEED to be rain in the development environment.

But I will add that the most common cause of a program failing to run properly when compiled but runs fine in the development environment is race conditions because the compiled code runs faster. 

Also are you by chance using Chanel Wires? I recall seeing a post about Chanel Wire OOP failing.

---

I have the same problem with my cow-orkers: The pay attention to about every 3rd word that I utter/write.  Obviously it's NOT a race condition because the VI is broken!  That means it can't run!

As for needing the development environment:  Try looking at the detailed help for a property or method.  There you will see a table; and one of the entries will be "Available in Run-Time Engine".  For many properties and methods, there will be a "Yes" after that; but, guess what: there are also many properties and methods that have a "No" for that.

---

Then I would probably find a different property or method as there is absolutely no reason am end user needs to be mucking around in the development environment.

As you are finding out you can not protect your code from and end user making changes or breaking it.  

I guess it's job security... Good luck with that.

[paul_cardinale]

---

@RTSLVU wrote:

---

@paul_cardinale wrote:

---

@RTSLVU wrote:

---

@paul_cardinale wrote:

 For many reasons, this needs to run in the development environment, not as compiled code.

---

I for one am interested in these reasons. As there's not a single reason that I can come up with for any program, no matter how complex that is would NEED to be rain in the development environment.

But I will add that the most common cause of a program failing to run properly when compiled but runs fine in the development environment is race conditions because the compiled code runs faster. 

Also are you by chance using Chanel Wires? I recall seeing a post about Chanel Wire OOP failing.

---

I have the same problem with my cow-orkers: The pay attention to about every 3rd word that I utter/write.  Obviously it's NOT a race condition because the VI is broken!  That means it can't run!

As for needing the development environment:  Try looking at the detailed help for a property or method.  There you will see a table; and one of the entries will be "Available in Run-Time Engine".  For many properties and methods, there will be a "Yes" after that; but, guess what: there are also many properties and methods that have a "No" for that.

---

Then I would probably find a different property or method as there is absolutely no reason am end user needs to be mucking around in the development environment.

As you are finding out you can not protect your code from and end user making changes or breaking it.  

I guess it's job security... Good luck with that.

---

Your statement "Then I would probably find a different property or method" is quite ignorant,  (Do you really believe that for every property or method that is not available in the run-time engine, that there is an equivalent that is available in the run-time engine?)

Furthermore, my "end users" are test development engineers.

[RTSLVU]

---

@paul_cardinale wrote:

---

---

Your statement "Then I would probably find a different property or method" is quite ignorant,  (Do you really believe that for every property or method that is not available in the run-time engine, that there is an equivalent that is available in the run-time engine?)

Furthermore, my "end users" are test development engineers.

---

Maybe so, but there is no way I would be allowed to deploy anything in the R&D lab let alone production that required the development environment to run.

The cost of having the development environment installed on every computer is just prohibitive, unless you are skirting the licensing requirements in some way. 

[James_W]

I've run into this sort of problem very occasionally before.
Each and every time it turned out to be that a specific VI had got corrupted.
When I had traced down the offending wire I deleted it, rewired it exactly the same and everything was good again.
Generally happened in VIs that had been ported across multiple LabVIEW versions and saved in multiple versions. 
finding the corruption is a PITA.

edit:
Don't worry about reprogramming the Cow-orkers, just give them a VI-Analyzer task to run on all their code that checks for functions not allowed in the Run-time! (And then make it gating criteria for release 😉)

James

[Bob_Schor]

---

@paul_cardinale wrote:

This whole affair is degenerating the quality of my insanity.

---

I'm trying to understand if to "degenerate the quality of my insanity" is a Good Thing or a Bad Thing ...

I had a piece of code in LabVIEW 2011 that if I opened it and moved a wire, I got the "We apologize for the inconvenience" message.  Turns out it was something wonky with Network Streams (as I learned at the subsequent NI Week when I "asked a Developer").  Got rid of it by printing out the Block Diagram, deleting the VI, then reconstructing it "from the picture".  Ran fine after that ...

Bob Schor