unknown library error

[Sprow]

Hi, I have a VI that stopped working, I believe it is because one of the necessary libraries has been corrupted in some way. I've tried repairing any corrupted files from my labVIEW download but it didn't fix the problem.  I've attached images of the error messages that come up.

Thanks

[Bob_Schor]

Now attach the code (probably it should include the entire Project folder, zipped up) so we can understand what the error might mean.  It is probably not that a library has become corrupted, more likely that something went awry in your code.  In any case, showing us a listing of VIs with errors, but not letting us see these VIs (and judge for ourselves) does not help us to help you.  Attach your code.  Please.

Bob Schor

[Sprow]

Unfortunately I can't include the whole project as it is far to large. It's an inherited code from a former student for a research project. I attached the sub VIs that aren't running.  The code was running not to long ago and even if I try to run previous versions of the code from before I joined the project they won't run.

[crossrulz]

Those errors appear to be a class access issue.  You are trying to use private methods of a class in a VI that is not part of the class.  At least, that is most of the errors I saw.

[cbutcher]

Like crossrulz said, these look like issues with class ownership of the VIs.

Is it possible that the two VIs you mention (Read Subsystem Map, Open Session) were previously members of the "niInstr FIFO Register Bus v1 Host.lvclass" and that they were (perhaps accidentally) dragged out of that class?

If so, dragging them back in will probably fix the issue, although you may retain some issues with bundling and unbundling that need manually fixing (but that would just be open the VI, click on the {un,}bundle node and choose the same name that is visible, or the renamed value if the class has changed in the time since they were dragged out.

If that's not the case, you could consider making those VIs that are mentioned in the error panel public (obviously this has other effects - anything can call them then) or Community scope (and making these two VIs friends of the class) - again, this probably suggests that your VIs need access to private data of the class, and so should be class members (or your class might need refactoring/breaking into more than one class, but your question is about errors, not design choices).