"could not be loaded" error for subvi in llb

[dpak]

I have created a new llb which contains a duplicate hierarchy of my top level vi - using the "Save as..." dialog.  When I open the new duplicate top level vi I get an error for two of the subvi's - "General I/O Error.  The File <the sub vi> could not be loaded".  However, when I go into the block diagram and replace the offending subvi's, I can browse to them and find them correctly in the llb.

These sub vis were specially written for this project - they are not NI subvi's.

After having replaced the subvi's in the block diagram (by right clicking on the missing subvi icon and selecting replace), with those from the same llb,  the top level vi runs correctly.  If I now save everything and close the top level vi and then reopen it, I get the same generic file I/O error and have to manually re-find the sub vi's again.  I've never had this error before and am surprised to be having it here.

What can cause this error?  How do I fix it as I want to port the whole lot to our collaborators for testing and it is a lot easier to do this as an llb?

(LV 2011 64bit, Windows 7)

[IanS]

Hi,

I'm an applications engineer at NIUK, and I've been looking into this.

I'm not sure if this is still an issue that you need to resolve (now being 11 days old), but if you would like me to continue looking at it, it would be helpful if you could post the llb for me to take a look at. I'm unable to replicate anything similar on my machine. I assume you've checked things like naming issues.

Is there a reason you have particularly chosen to use an llb format? Another option is to put all the vi's in a project, and send it all together.

Let me know if you still require action on this.

[dpak]

Hi Ian,

I have solved the problem by converting the llb to a folder - well, it's a workaround, rather than a solution!  But, it works well enough just now.  I'm not sure I could lay my hands on the llb that was causing an issue - and in any case, it was a few hundred megs in size (the programme crunches some several megapoint fourier transforms).

I have to admit that I've been using Labview since version 5 and have not bothered with the whole project issue yet - projects didn't exist back then.  Perhaps I need to revisit this?

David

[IanS]

Hi David,

Glad you managed to work around the issue.

I would highly recommend using projects to manage any LabVIEW application with more than a couple of vi's.

In 2012, the launch screen has create project and open existing project as its main options to encourage users to manage their applications this way.

If you've never used projects before, a good source of information is LabVIEW Help >> fundamentals >> working with projects and targets.

Best Practices with projects also has some useful information about managing projects.

It shouldn't take too long to pick up, and it is a really easy way to manage all the files for a particular application.

[dpak]

Hi Ian,

What I mean is, I've looked and looked at LV projects since they came out and I can't identify a key benefit what would drive me to using a project over the folders/llb method, so I haven't really bothered about them.

But, thanks for your help,

David