Scripting: Help with Automated VIM Replacement

[_carl]

The problem:

VIMs (aka malleable VIs) don't always get refreshed in situations where they should. The most common headache for me is that they'll sometimes hold on to dependencies that are no longer part of the VIM, which, especially when building PPLs or renaming libraries, can lead to bugs, crashes, general instability, or just ugly broken-but-not-broken wires.

Manually replacing these VIMs in block diagrams tends to clear up these problems.  However...I can't realistically track down all VIMs manually and replace them when things go wrong.

The solution I'd like to implement:

Use scripting to programmatically refresh all VIMs in a VI or library.

Finding all sub VIs is easy.  But I don't see a way through the exposed API to:

• Differentiate VIMs from regular VIs (they seem to be the same GObject, but perhaps I could make assumptions about the path having a GUID and the parent VIs path in it...)
• Get the original VIM's path

With these two pieces of info, the rest should be pretty straight forward.  Anyone happen to know how to access these properties?

[_carl]

PS I recently did something similar to find and replace class controls, indicators, and constants because of corruption (old invalid data was used as the default class values).  I also regularly run a script to wipe mutation history in classes.  This would just be one more tool for wiping out LabVIEW ghost dependencies, and I can't imagine it'll be my last.

Are there any other tools out there already for doing this kind of code sanitization? Or if you all have seen other common (but fixable) data dependency corruption issues, feel free to mention them here!

[Kyle97330]

If you traverse for subVIs, then get the VI reference then point to, you can check the "IsInstance" property as a first pass filter.  This should remove most standard calls and leave you only with VIMs and express VIs.  If after that you run a "Get VI dependencies" invoke node on it with the default options (i.e. no "Whole Hierarchy"), a VIM should return only one dependency, that being its original VIM on disk, which you can check for by extension.

I can't guarantee there are no edge cases that could trigger this falsely but I think it should work.  Running it on a test VI with a standard subVI, an express VI, and a VIM did work for me.

[_carl]

Wow, fantastic, exactly what I was looking for, thank you much!

(I'll mark as solution tomorrow once I get a chance to test it out.)

[paul_cardinale · Accepted solution]

This might be helpful.

[raphschru]

You may also use VI methods "Compile" then "Save.Instrument" on the callers instead of replacing the VIMs on the block diagram. It usually fixes these kind of issues.

I once had a project in LV2018 where I used the same VIM accross all my libraries. After modifying the VIM, I had to run a script to force recompile all its callers, otherwise the compiled application would crash inexplicably at runtime with some access violation error...

[wiebe@CARYA]

AFAIK, the only way to make a VI a VIM is to change it's extension.

So I'd assume you can use the path (or name) to filter:

Note that inlined VIs are not .vims, but are instances. So filtering on Is Instance will give you inlined VIs and .vims, which might be what you want, or not.

[_carl]

Thought I'd follow up.

I tested out both @Kyle97330 and @paul_cardinale's solutions and @paul_cardinale's came out the winner. It was quite a bit more performant, and the other solution didn't return a path in my scenario (although I didn't debug it as much as I would have had there not been an alternative).

@raphschru: I like that idea too, and it does seem simpler, will keep that in mind (and test it out) moving forward!  I've seen some scenarios where simply opening a VI will unbreak the VIM (and suspect this might help in those cases), but other scenarios where I do need to mess with the VIM or wires around it in order to make things happy again -- and it may very well solve these issues too, who knows?

@wiebe@CARYA: The path returned from a subVI VIM is an internal ".vi" path made by LabVIEW, containing the name of the host VI and a GUID -- so can't be used as described.

(Edited because I accidentally tested the same solution twice when I first posted...)

[_carl]

I may have spoken too soon...  the paths returned from @paul_cardinale's solution are sometimes relative, and I can't pass those directly into a the sub VI replace method.

I can come up with a solution to this that works in my scenario, but...  is there a universal mechanism for converting LabVIEW relative paths to the first-found absolute path?

[_carl]

Interestingly (/terrifyingly), one of the VIMs I'm trying to update thinks it's at a relative path that hasn't existed in months -- even though it has run successfully since then...