Glitched block diagram - adding local variables is faulty and scrollbars are wrong. Corrupt vi file?

[JonnyOhJonny]

Version: LabView 2018 SP1 32-bit

Dear swarm intelligence,

While working on a large block diagram, the VI started to act weirdly: It is not possible to scroll to the far left with the scrollbars, it just stops too short. It is only possible to get to the far left of the diagram with the navigation window, but the view just snaps back when moving in the diagram: See here how the scrollbar is on the far left, but as the navi window shows, the view is not showing the left-most part of the code:

Additionally, when adding a local variable via right click -> create, it is only ~1 pixel wide, only visible when selecting with the marquee tool:

This is how a variable looks right after creation:

After that it's only visible when selecting:

Impossible to wire. The wire just expands to infinity:

It does not matter which variable I choose. This behavior appeared after trying to tidy-up the diagram and de-activating auto-grow (including some diagram-explosions, because auto-grow is really flawed). Is there anything I can do to "reset" the VI or make LabView completely re-compile it?

Mutliple restarts and clearing caches did not help. The last non-glitched version of this VI is quite old and would take a lot of time to re-program (especially the tidying-up...). It would be good to know how to prevent such evil things from happening.
Very thankful about any hints!

[Mark_Yedinak]

I think your problem is that your block diagram is simply too big. There is a max size the block diagram can be. I don't recall the exact size but this looks like it is very likely what your problem is. I highly recommend that you start simplifying this code. Put things into subVIs, reduce the complexity of this VI, don't try to do everything in a single VI. You should never have a block diagram this large. It is just not maintainable.

[JonnyOhJonny]

Thanks for having a look! Yes I am trying to simplify it, but now cannot continue(and I was stuck at the limitation that not all refnums can be stored in clusters for passing into subVIs, but that's another problem).

Before this glitch happened, the VI was even bigger, so I'd be surprised if the max size was reached already. Who knows what else got corrupted in the code - I was hoping for the existence of a "reset" operation for VIs, instead of needing to re-program them.

[Mark_Yedinak]

---

---

---

@JonnyOhJonny wrote:

Thanks for having a look! Yes I am trying to simplify it, but now cannot continue(and I was stuck at the limitation that not all refnums can be stored in clusters for passing into subVIs, but that's another problem).

Before this glitch happened, the VI was even bigger, so I'd be surprised if the max size was reached already. Who knows what else got corrupted in the code - I was hoping for the existence of a "reset" operation for VIs, instead of needing to re-program them.

---

Source code control. That should be your code reset. If this was larger and now is corrupted, you may have no alternative than to re-write. In all honesty, it should be be completely re-written since it is terrible code to begin with. It may work (at least before your corruption) but it is a mess, it is EXTREMELY difficult to look at the code and understand what is going on and it is very difficult to maintain and extend.

[altenbach]

Start reading here

[altenbach]

Note that it is not just the "size", but also the position. If your diagram elements are way offset from the center (e.g. near -32768 or 32767 horizontally or vertically), even a smaller diagram can get corrupted.

[JonnyOhJonny]

Thank you both. Through your hints I now understood what happened: While tidying up this huge inherited code, I've accidentally copied a section that contained local variables by ctrl-c/ctrl-v. 
This created copies of some front panel elements that LabView randomly placed outside its own boundaries. I was dumb enough to not notice this and continued working + used the clean-up selection tool quite often with auto-grow on in some structures, which resulted in wires to Nirvana and some explosions, thus the code got more and more corrupted. 

I've painfully learned a few things:

- Never copy parts of code by Ctrl-c
- Always turn off auto-grow

- Use clean-up selection only very carefully

Still, I cannot comprehend how such a widely spread, highly developed, expensive software development tool like LabView (2018) does not have a safety feature to at least not corrupt its code by itself. This is just fatal and makes me wonder what other surprises are waiting for me. 

I ended up re-programming the progress from my last functioning backup and can now continue to further compress the code. Unfortunately this code has 7 state machines that run in parallel, ~>100 nested subVIs and multiple parallel loops that monitor some devices, sharing references and data between each other, not really the easiest situation for compressing code, for me as a beginner...  

[billko]

---

@JonnyOhJonny wrote:

Thank you both. Through your hints I now understood what happened: While tidying up this huge inherited code, I've accidentally copied a section that contained local variables by ctrl-c/ctrl-v. 
This created copies of some front panel elements that LabView randomly placed outside its own boundaries. I was dumb enough to not notice this and continued working + used the clean-up selection tool quite often with auto-grow on in some structures, which resulted in wires to Nirvana and some explosions, thus the code got more and more corrupted. 

I've painfully learned a few things:

- Never copy parts of code by Ctrl-c
- Always turn off auto-grow

- Use clean-up selection only very carefully

Still, I cannot comprehend how such a widely spread, highly developed, expensive software development tool like LabView (2018) does not have a safety feature to at least not corrupt its code by itself. This is just fatal and makes me wonder what other surprises are waiting for me. 

I ended up re-programming the progress from my last functioning backup and can now continue to further compress the code. Unfortunately this code has 7 state machines that run in parallel, ~>100 nested subVIs and multiple parallel loops that monitor some devices, sharing references and data between each other, not really the easiest situation for compressing code, for me as a beginner...  

---

I hate to say it, but you can't account for every kind of stupid.  Exceeding 2^16 pixels or i16 pixels around the origin is pretty unreasonable.

[JonnyOhJonny]

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

[Mark_Yedinak]

---

@JonnyOhJonny wrote:

It is stupid, yes. Makes it even more embarrassing that LabView can do this to itself, without even notifying.

---

I am sure you can mess with any compiler if you throw extremely bad code at it. As stated, the compiler can't cover every possible situation. This codes seems to break a large majority of good coding practices. While you might think 7 parallel tasks and 100s of VIs is a lot of code I work on systems that have thousands of VIs and dozens, even hundreds of parallel tasks. I have never encountered this because I never let any Vi get anywhere near the size of this VI. Don't blame the tool for terrible code. Blame the developer of the bad code.