08-21-2016 07:41 PM
Hi
I just built my teststand sequence and it failed due to a broken VI. On inspection my sequence should not be calling this close.vi at all (Its closing a piece I equipment I am not using in this sequence). So does any one know how to find why it appears when I insert code modules?
I have tried finding callers of the VI, run sequence documentation... with no luck. Tried to find it will a mass compile... Call hierechy in the delopyment utility says its dependent on my sequence file. I have performed a find on sequence file and not found it.
I have fixed the VI so I can move on, but I would still like to remove "dead" VI's from the installer. Any suggestions?
08-22-2016 12:55 AM
Tools>Update VI Calls can produce a nice list of called VI's. But its not on this list either.
08-22-2016 10:40 AM
Hi NickTrim,
What happens if you exclude the Vi from your deployment build? In general the file you shouldn't include files in your workspace if you're not using them in your sequence file. Do you get a missing file error in a specific part of your sequence if you remove "close.VI" from the workspace?
08-22-2016 03:33 PM
Hi Daniella
Thanks for your response. That is my next problem.... Build is throwing an error. I have raised a ticket. 6148-98R634.
Just about to reinstall.
I think this might be linked to my build issue now.
Regards
Nick
08-22-2016 04:35 PM
Hey NickTrim,
I don't think you should need to reinstall. It looks to me like the simplest solution would be to remove Closing.vi from your TestStand Project directory.
The VI may have been included if the TestStand Project or Workspace you're working with was copied from another that called Closing.vi as a code module, or if the VI was being called when the Code Modules were added to the project. That would explain why it is contained in the TestStand Project as your screenshot shows (Closing.vi [code module]).
Files are not dynamically linked to a TestStand Project, so even if the step calling Closing.vi was removed, the project won't drop the VI from the CodeModules folder unless you do so manually. The Deployment Utility sees that Closing.vi is included in the Workspace, so it includes it as a dependency. Since the Workspace sees the VI as contained within the Sequence File, it will list it as a dependency of the Sequence File in the Call Hierarchy tab.
Basically TestStand assumes it is a dependency because it is in the Workspace. If it isn't needed in your sequence or deployment, it should be deleted from the Workspace.
08-22-2016 04:46 PM
Hi Steven
I am most of the way though a reinstall. Lets see if it solves the problem.
The project I was working on was done by another engineer who was learning and struggling. So it was a bit of a mess.
So one of my aims was a good tidy up and remove a lot of VI's in the project folder that are no longer needed. One of my problems is figuring out the no-longer needed VI's I can remove.
I will review the workspace.
08-22-2016 08:45 PM
Reinstall did not solve the problem. I deleted and recreated the workspace and project files, again with no luck.
08-23-2016 05:42 PM
Hi NickTrim,
As Steven mentioned in his earlier post, deleting the VI from your workspace is probably a good first step to either eliminate it from your sequence or locate where the dependency exists. What happens if you do this?
08-23-2016 05:45 PM
Hi Daniella
I have deleted it from the workspace and the sequence analysis tool does not report any issues.
Thanks all for your suggestions. I am now working with a NI support engineer on my build issue. Will update later with solution.
Nick
08-30-2016 02:02 AM
Hi
I can now build my teststand sequence. The issue I had was a VI owned by a library.
The deployment utility included the library - which had a missing control. This caused my build to fail with no error message.
This shows that the deployment utility doesn't analyze library files and flag errors.
However now I can build the sequence - I can see this close.vi is still included.
Interesting. I am going to see if I can create a new demo sequence to show the problem or narrow it down. WIP.
Nick