Broken Wire in Express VI

[gradi3nt]

I couldn't figure out why this build text express vi stopped working after I changed its parameters around a bit. The only error message was that the subVI isn't executable. 

I decided to convert the expressVI to a normal VI to inspect it (after backing up the original file because the conversion is irreversible). Upon inspection I found a broken wire floating around. Where did that come from? Is this just a bug in the expressVI code? Is there a way I can get rid of it without irreversibly converting the expressVI to a normal VI?

Removing the rogue broken wire fixes the error and the VI is able to run.

 

[hooovahh]

That is interesting and I've never seen this issue before.  Have you tampered with any of the files installed by LabVIEW in the Program Files folder other then user.lib files?  How reproducible is this issue?  What version of LabVIEW?  What steps to reproduce it?  

 

NI maybe very interested in trying to fix this if it can be reproduced.

[gradi3nt]

I haven't tampered with anything.

 

Unfortunately I didn't notice what action caused the VI to go from working to broken since I made several changes to my program before testing it. My guess is that it was caused by having a build text with many parameters that have been shuffled around, deleted or added (sorry, that's pretty vague). 

 

I will pay closer attention in the future, since I have had some mysteriously broken build text VIs in the past too (I just found out today you can convert to normal VI and inspect the code so I can't prove this issue has ever happened to me before).

[Yair]

Where did that come from? Is this just a bug in the expressVI code? Is there a way I can get rid of it without irreversibly converting the expressVI to a normal VI?

 

My understanding of express VIs is that they basically run scripting code whenever you make a change in their configuration in order to generate the correct code. It's certainly possible that some circumstance caused the generation to fail in this specific case and to generate broken code. My understanding is that the BDs of express VIs are also saved in some kind of limbo state inside the calling VI, which is why you don't get a better description - the error window does not see the express VI as a separate VI with a diagram in can dig into, so it stops at the caller. It does at least point to the express VI, but I agree that it should be handled better.

[DFGray]

I have seen this type of thing many times before, but only when I was writing Express VIs, and I don't think any got out the door (I did not write this one). I filed a CAR on the issue. Details in your NI Forums post.

 

Converting the Express VI to a normal VI (showing the front panel) is reversible. Use your favorite form of undo. Converting to a normal VI and fixing the issue is also your best workaround at this point. If you can figure out how you caused the error, please post it on the NI forums to help us debug the root cause.

 

Express VIs are actually a special form of SubVI. This SubVI has a flag which signals the calling VI to save the called VI inside the calling VI rather than in another place on disk. But the called VI is a separate VI and you can get to it by showing the front panel, as you found out.  When you close the configuration dialog of the Express VI, the contents of the called VI are scripted to match the configuration. In this case, something in that scripting went wrong.