LabVIEW code cleanup of VIs that have not been used in a while: suggestions for finding

[SoftWEng]

I have a very large repository of LabVIEW code called from Teststand running in dev that has been used for a couple of years.  I just took over management of the code and it looks like previous developers created copies of VIs with different names or VIs were created for other projects and saved in the code base that are not used anymore.  Is there any good way for me to tell if a VI has been called by a system within the last year for example?  Ideally it could be seen for all the files in a directory.  Has anyone done anything like this before?  Any idea or suggestions would be appreciated.  Is there a property for last called timestamp I could use to write something like this myself?

[wiebe@CARYA]

There is only the "Last Access Time" file property.

It might does not do what you want. But it's the only thing related you what you're looking for. Apparently it depends a lot on your system settings:

enable-disable-ntfs-last-access-time-stamp-updates-windows-10 

It's pretty easy to toy with it (and other file time properties):

(FileInfo lives in mscorlib, System.IO.)

[Kyle97330]

You could try a systematic approach rather than hoping the file system gives you answers:

1. Make a list of all TestStand sequence files that are currently used

2. If any of them save as binary files, change them to save as a plaintext format (XML probably, INI maybe)

3. Parse the sequence files to create a list of all VIs they call

4. Run a de-duplication filter on the list of VIs

5. Use scripting in LabVIEW to open each VI on the list, list its complete dependencies, and add them all to a list

6. Remove any dependencies from VI.lib, instr.lib, etc. that aren't part of the code you're trying to clean up

7. Merge this list with the original list of VIs and de-duplicate it as well

8. List all files in the repository, and remove any files from this list that are on the list you just created

9. The remaining list of files are the "orphans" you can probably delete.  Assuming you have a proper source control system you can recover them later if it turns out one of the deleted files was in use after all.

[wiebe@CARYA]

Another approach would be to simply delete all duplicates, and make all projects use a centralized code base. Of course if the duplicates where modified for each project, you're in trouble.

Don't do anything before you have proper SCC set up...

[Yamaeda]

---

wiebe@CARYA wrote:

Another approach would be to simply delete all duplicates, and make all projects use a centralized code base. Of course if the duplicates where modified for each project, you're in trouble.

---

I did something similar a year ago. We had a project that ran through TestStand via Source Code distribution and when trying to change this code things got really messy as LV itself relinked to this code repository ... It had also been upgraded a couple of LV versions, so the distribution itself became the development 'branch' and was recompiled.

I ended up grabbing a file list of vi.lib and simply deleting all files with the same name in the project, then fixing up until it seemed to run again. 

I reduced the code by some 2/3 and got rid of the cross linking, but it took a couple of days.

In this case you could create a small program that checks and lists duplicates and e.g. opens them in LV Compare so you can see if they can be merged/generalized.