09-14-2018 04:07 PM
I have two VIs i wrote today that I now can't open their block diagram. Additionally these VIs behave oddly upon opening. They have the appearance of 'running' (no grid lines) on opening, but if i run them once, I can again see the grid lines. In either case before/after running I can't open the block diagram.
I definitely did not click any option to save without a block diagram. (I have never had the need). If it was done with an errant keypress I'd like to know what this possibly was so it can be disabled. I am skeptical after using LV for a few years without this issue all of a sudden in one day this happens twice.
I copied the VI out of my project and opened it and got an 'error 6'. When I move it out of its home class and open it it is broken with an error
"This VI has a bad connection to or cannot find a subVI or external routine but it has no block diagram to show or fix the error. You must find or correct the subVI or external routine. Check for more information in the Explain dialog box in Get Info."
I opened/close it a third time and got an access violation and LV crashed. I don't want to have to rewrite it if possible, it has some non trivial regular expression evaluations, but i/o and dependency-wise it is a simple helper method for its parent class (it doesn't even have any dynamic inputs or anything). But I'm more concerned about eliminating this problem in the future since I have no idea how it happened.
I attached one of these VIs (LV 2017, it won't let me backsave it, or resave it at all). As i said however, it only appears to open and run properly if i leave it in place in the project.
Thank you for any help
I first noticed the issue after I git pushed my most recent code to my repo.
Any idea what happened?
How it can avoid it happening again?
How can I find out if any of my other VIs in my project have been destroyed in this same way?
Solved! Go to Solution.
09-17-2018 03:35 AM - edited 09-17-2018 03:46 AM
@AdamZeroK wrote:
Any idea what happened?
Maybe git tried to do you a favor, and merged the VIs?
@AdamZeroK wrote:
How it can avoid it happening again?
In SVN there are options to mark VI types are binary, so the never will get merged. In SVN this is only needed for projects (xml), never needed it for VIs.
I'd be interested if this is what happened, recently started using git..
@AdamZeroK wrote:
How can I find out if any of my other VIs in my project have been destroyed in this same way?
You could try VI server, and use a recursive file search (*.vi) to open and save all VIs. This could be tricky, as LabVIEW will probably crash when a VI is corrupt... There are many variations on this theme, like open a VI ref, and then opening a reference to it's diagram (scripting). since things are bad, unexpected things will happen.
09-17-2018 07:24 AM
Thanks for the thoughts.
I set this up for .vi and .vim. Is it wise do likewise for other file types, even those that are nominally pure text? (e.g.: .lvclass, lvproj)
09-18-2018 03:22 AM
@AdamZeroK wrote:
Thanks for the thoughts.
I set this up for .vi and .vim. Is it wise do likewise for other file types, even those that are nominally pure text? (e.g.: .lvclass, lvproj)
I'd say that would be wise. You don't want a lvclass or lvproj to be merged, although it probably causes less trouble, I don't think it's desirable.
09-18-2018 07:28 AM
Ok Thank you. Don't think I have any way of being sure a merge caused it, but it is plausible so I'm marking it as a solution.
Suggestion to others: make your repo's .gitattributes include at least:
*.vi binary *.vim binary *.lvproj binary *.lvclass binary *.lvlps binary *.aliases binary
to prevent merging of these file types.
09-18-2018 07:53 AM - edited 09-18-2018 07:54 AM
Thanks, that will save me some time looking for what that's called in Git.
Some more items for the list:
*.vi binary
*.vim binary
*.lvproj binary
*.lvclass binary
*.lvlps binary
*.aliases binary
*.lvlib binary *.vit binary *.ctl binary *.ctt binary *.xnode binary *.xcontrol binary *.rtm binary
And probably even more... Of course these only apply if you ever use them (libraries, VI templates, controls, control template, xnodes, xcontrols, run time menu's).