referenced vi won't execute

[shadow72]

I am currently working on a program that will call vi's from a sub directory, all works well till I call a vi that has several sub vi's contained within it, also hardware devices it may be looking for.

I am fairly new at using labview. I am using LV 8.2

[Gabi1]

Hello Shadow,

your question lacks details. maybe you could post your software for us to look at?

do you have some kind of error handling in those subvis, that allow to return to main vi without an error message appearing?

in general, be aware that there is a tool called "probe" that you can put on any wire, including in nested subvis. you can put several of those at places which look suspicious (hardware calls are very prone to such). a small window will appear floating on the front panel, which will allow you to monitor the information that is passed trough the probe. a good first check would be to put some on the error wires.

[shadow72]

Sorry about lacking detail. I am calling different vi's into a subpanel of the main vi. It works well until I call a vi with dependencies like hardware. It will open the front panel is all, no errors that I can see at all. I figure it is because of not having it's internal subvi's also installed. Do I need to somehow reference or link all the internal vi's to the subvi that I am calling?

Sorry if this isn't very clear, I don't get alot of time to play around with this software much.

Message Edited by shadow72 on 09-14-2007 01:28 PM

[shadow72]

Here is the base program I am Playing with, you should be able to mod it up to try it out.

[Gabi1]

shadow,

virtually all the vis have a broken arrow - > all of them because of missing subvis...

could you save your main vi as:

save as...->duplicate hierarchy to new location ->..

so it will save as a llb, with all subvis included. then we can look it up.

[shadow72]

Here you go, I didn't attach the reference folder with the called vi's in it. Hopefully it works for you.

[Gabi1]

this is a relatively big project you have there. it took me some time to pass trough. apart the fact that some called vis are still missing (eg. "update job list.vi"), and i dont have the xml file so i cant run it, it doesnt seem to have any obvious bug. (this is not to say, some operations, especially boolean, are definitely useless, but not buggy. same for a lot of locals: works, but ugly).

reading again your posts, i tend to believe the problem is in the vis you call in your subpanel (not included in what you sent). i would guess (wildly), that there is an error not handled in those subvis, that kills the process.

but i figure if you managed to create this program you should easily find them. try to redesign a very small vi, whose only job would be to call those subvis, run them and display them in a subpanel. to check this operation you do not need your project at all. if it doesnt work, follow the error line.

could you post the subvis that doesnt load in this subpanel?

[shadow72]

Those sub Vi's have hardware specific sub vi's that is why I did not include them. I know this program is messy, it is just a mock test for the original(main program) that we are working on that is much larger.

I guess I am not getting my point across very well, This program does work when I call a simple vi that does not have any internal sub vi's. My only problem is when I call a sub vi that also has sub vi's internal to it (or hardware allocations to call). I guess my question really is with the sub vi's I'm trying to call that have sub vi's to them.

How can I make sure all of my sub vi's stay with the main vi (main called vi) that I am trying to call into the sub panel of the caller vi? When I install the executable on a system, I need to be able to only install the called vi with out all of it's sub vi's with it, Is this possible and still be able to execute that vi?

[Brian_R]

Does your project work in the development environment and not the executable environment?  Instead of opening the VI references, try statically calling the subVIs and see if that changes anything.  I would also suggest working with a smaller application for the purposes of debugging.