Code became invisible, fragmented and shifted on the block diagram

[Mephiengineer]

Dear all,

Let me present you a challenge. NI Support did not help me, but I am sure that NI community can be even more powerful when it comes to solving weird problems.

Short introduction: I have a deal with big project includes approx. 1500 VIs and operates microscope installation. Now this software is still under developing. I work on implementation new features but mostly on debugging existing code.

Description: I have main VI (weight is approx. 2,5 MB) that is crucial for the whole system and when I open the code I receive all this staff (please have a look at the pics attached). I try to scroll right and the scroll bar get stuck. The VI works at the same time and works well. Anyhow, it is not broken and conduct all activities. But when it comes to the code, it is just invisible, fragmented and not useful for editing.

Let me list what I have tried to do according to NI Support recommendations:

1. I have tested this VI on the same PC with version of LabView 2013, 2017. I have tested it on the other PCs with LabView 2017 and 2013 (two PCs with Win7 and Win10). No changes.
2. I have tried to ctrl+A ctrl+C and crt+V to copy-paste it into a new blank VI. At the end I got the couple of VIs with the same problem.
3. I have tried to masscompile. No effect.
4. I have tried to force to recompile. No effect.

The last recommendation was just to start from previous working backup or just rewrite it. I understand clearly, that it would be the most reliable option in this case. But let me explain why it is impossible. Well, my previous colleague forwarded me this project "as is". This project was initially started on LabView 2013 and then gradually transferred to LabView 2017. The problem appeared when it was already saved several times in LabView 2017. There is no documentation, just pure code with rare warnings about problematic places. So it is impossible just to rewrite the code from the beginning - nobody knows how it works in detail. In addition, I found out that the previous working backup of this project dates back to September 2017 and a lot of changes already done since this time.

As I traced, the problem did not appeared suddenly, first of all code became shifted, then wires became seem as unplugged (but connected in reality), finally scroll bar stopped working. Sometimes it requires a time to show the right part of the code, approx. 6 hours, the left part of the code become invisible in that case. I am skeptical about idea that PC has low capacity. First, it has really good computing power. Second, The same VI dates back to Sep 2017 shows the code fine despite it has the same weight.

To sum up, I still have this problem and need to edit this VIs. I would be happy to discuss it with you.

Thank you in advice!

[altenbach]

Start reading here

[Mephiengineer]

Thank you so much for this link! The width of the block diagram is 65506 vs approx. 32000 for the last working version.

I see the recommendations how to prevent this occasion. But this is not my fault, and my goal is to overcome it.

Do you know how can I restore the code in this case?

[Bob_Schor]

Before you do anything else, set up a Version Control Repository.  However you are able to "go forward" with this Project, having Version Control will mean that you always have a path back to "something that more-or-less worked before I did this-and-such" (without having to struggle with "My Prog.vi", "My Prog-Rev 1.vi", "My Prog-Rev 1a.vi", "My Prog-Rev 1a-Test.vi", etc.

If you need help with the above step, many of us can assist.  TortoiseSVN seems to be a fairly-widely-used Client (I've been using it for probably a decade), and SVN Servers are relatively easy to set up (I'd have your IT department handle this, or use a commercial service, which will be well worth almost any price they charge).

Are you using LabVIEW Project?  More specifically, do you have a folder that contains all of your VIs, possibly with sub-Folders that help you isolate different functionalities, and a "Project File" with the extension .lvproj that is the one that you open when you want to work on this Project?  If not, you should.

Do you have any collection of VIs that you can open and view in any version of LabVIEW?  If so, collect them in a "top level folder" (it really helps to have all the code, including documentation, LabVIEW Project file, sub-folders, etc. in one top level folder to allow you to do "all-at-once" operations, such as checking out from Version Control), make a copy (just in case), and, once you have your VCS ready to go, commit this collection as the initial "Revision" of your Project.  Once committed, if you do not yet have a LabVIEW Project file, create a New Project, add the entire top-level-folder into the Project, save the Project inside the Top Level Folder, then commit it again (to save the changes).

Now the hard work, going through and modernizing the old code.  Some principles that should help:

• Try to keep Block Diagrams "reasonable" in size, say the size of your monitor.
• A good way to do this is to use a suitable "Design Pattern", such as a State Machine, Queued Message Handler, or something like that, for the top-level VI, and "hide the details" by encapsulating function inside of sub-VIs.
• As you develop, give every VI an Icon (such as a Square with 2-3 short words that say what it does) and write a brief Description that at least mentions the inputs and outputs.
• Try to use a 4-2-2-4 Connector Pane for all your VIs, with Error In and Error Out in the lower corners.  If you only have 1-2 inputs or outputs, that's usually a Good VI.  If you have >4, consider using Clusters.
• Having a colleague, a Student, or (if all else fails) a Rubber Ducky and doing a Code Review, or a brief explanation of what the code does (emphasize "What" rather than "How") is very helpful.

Bob Schor

[johntrich1971]

I would try doing a block diagram cleanup. I don't normally recommend auto-cleanup, but in this case it might be worth a try.

[billko]

Whatever you try, set up a repository first, as Bob mentioned.  You can then goof around with this thing until the cows come home and always know you have something to go back to.  Commit often - the more often you commit, the more snapshots you can go back to.  Right down to the individual files.

With this method, you can be bold; if you hit a brick wall, you can always go back and start in a different direction.

[Ben]

---

@johntrich1971 wrote:

I would try doing a block diagram cleanup. I don't normally recommend auto-cleanup, but in this case it might be worth a try.

---

My money would be on Clean up making things worse.

Since it was reported the VI still works...

Attempt "save for Previous" and choose an older version of LV as the target as a quick attempt to get LV to recreate the VI in an older version.

If that (by some miracle helps) shut off Auto-explode (auto-grow) on every structure and then work to get the diagram smaller even if it means introducing over-lapping objects.

Then start to push things into sub-VIs and continue to make it smaller.

I hope you find a solution because your predecessor left you with a ticking time bomb that was just waiting to go off.

And while I am at it...

You wrote that you spend a lot of your time fixing bugs. Judging by what little I could see of the diagram, the use of global variables may be introducing race conditions and the code should be reworked from the beginning.

While that is most likely not going to go well with your boss I can offer this tid-bit.

"The good thing about having to rewrite a VI is you usually do a better job the second time."

Ben

[johntrich1971]

---

@billko wrote:

Whatever you try, set up a repository first, as Bob mentioned.  You can then goof around with this thing until the cows come home and always know you have something to go back to.  Commit often - the more often you commit, the more snapshots you can go back to.  Right down to the individual files.

With this method, you can be bold; if you hit a brick wall, you can always go back and start in a different direction.

---

I 100% agree with this.

[RavensFan]

I'm wondering if it is possible to use any scripting tools to help clean up a VI like this.

Basically write a script that iterates over all objects in the VI, if it finds an item whose bounds are beyond reasonable limits, that it will reposition that object to coordinates within the limits.  But will you need to act on wires connected to that node and do a clean up wire after moving the node so the wire doesn't loop out and back from outside of the limits?

Though the final diagram will still be a mess, at least all the objects will be accessible within the I16 range, then you can go and start cleaning stuff up further manually.

[Ben]

---

@RavensFan wrote:

I'm wondering if it is possible to use any scripting tools to help clean up a VI like this.

Basically write a script that iterates over all objects in the VI, if it finds an item whose bounds are beyond reasonable limits, that it will reposition that object to coordinates within the limits.  But will you need to act on wires connected to that node and do a clean up wire after moving the node so the wire doesn't loop out and back from outside of the limits?

Though the final diagram will still be a mess, at least all the objects will be accessible within the I16 range, then you can go and start cleaning stuff up further manually.

---

Or try a "Ctrl-a" then align left and align top.

Save.

Close and re-open.

Ben