VIA_Ignore for vi's that should be non-reentrant even called by cloned vi's, like Functional Globals (FGVs)

[sdusing]

I sometimes have vi's that I really only want 1 instance of, so I make them non-reentrant.  It is sometimes necessary to use these vi's within clones.  A perfect example of this is a functional global that just contains an uninitialized shift register that you want to set once and then be able to read out anywhere else you call it.  The Reentrant VI Issues test will always fail whenever it comes across a cloneable vi that calls a non-reentrant vi, since that's potentially a bottleneck.  Usually this is good, but in the case that I really only want 1 instance of a vi, it produces unwanted test results. Furthermore, there's no easy way (that I know of) to ignore this test by placing a #via_ignore in the non-reentrant vi.  This would be desired since it is within that vi that I know that I'm likely to come across this issue.  The only current workaround is to find every vi that uses it and drop the "#via_ignore Reentrant VI Issues" tag inside of it and point it at the non-reentrant vi.

Am I missing something or is this a good feature for the VI Analyzer Roadmap?

[Darren]

I understand the request, but I can't think of an easy general solution. You want to ignore all instances of a particular *type* of VI failure for a particular test across all VIs. The #via_ignore tagging isn't designed for that (as you know).

This request feels very test-specific to me, i.e. I'm having a hard time thinking of examples like this that would apply to other tests. Given that observation, it seems like the best solution may be for the Reentrant VI Issues test to provide a list of excluded subVIs, like this:

[sdusing]

Darren,

Thanks for the thoughtful reply.  This is exactly what I'm looking for.  I agree that my request is much more test-specific, so adding the configuration that you showed in your image would be perfect - even better than what I had envisioned as it would allow someone to ignore non-reentrant vi's that come from NI, a 3rd party package, etc where you couldn't just go into the vi itself and add a bookmark.

I would love to see that feature get added!

Thanks!

[Darren]

I'll look into getting this feature added to a future VI Analyzer Toolkit release. In the meantime, what version of LabVIEW are you using? I'll see about getting you a custom copy of the test with this feature added if you want to try it out.

[sdusing]

I'm using 2020 mostly!  I'd be happy to try it out

[Darren]

Ok, backup your existing copy of the Reentrant VI Issues test and replace it with the one attached to this post. Here is where the test lives:

[LabVIEW 20xx]\project\_VI Analyzer\_tests\Block Diagram\Warnings\Reentrant VI Issues.llb

I tested out the changes and they worked for me. If you don't find any issues, I'll see about getting this updated test included in a future VI Analyzer Toolkit release.

[sdusing]

Hi Darren,

The new analyzer test worked pretty well!  After using it I do have a new thought I wanted to get your opinion on

I ran into a few vi's that are non-reentrant.  Some of these are in vi packages that I've installed (OpenG, MGI, etc) and others are native LabVIEW primitives. I would imagine most times when you use these vi's in a reentrant vi, you would not really care that they are non-reentrant, since there's not much you can do about them.

Would it be possible to add an option to ignore non-reentrant vi's that live in vi.lib, and perhaps other folder locations (just thinking ahead to when we start using JKI's virtual environments via Project Dragon).  For the project I was running this analyzer on, it would take the number of specific vi names I would need to specify in the analyzer setup from 21 to 5, which allows a bit better focus on the specific vi's you're trying to analyze and make meaningful changes on.

[Darren · Accepted solution]

Ok, give this copy of the test a try, and let me know how it goes and if you have any additional feedback.

[sdusing]

Darren, that is perfect! Works wonderfully! Thanks for your quick responses on this!!

[sdusing]

I did a little more testing and have one other question - is there a way to specify a relative ignore folder path.  Suppose I have the following structure and there I want to ignore all non-reentrant vi's located in the Utilities folder:

• repo root
  • Testers
    • myAnalyzer.viancfg
  • Source
  • Utilities

Is there a way to use relative paths to specify that I want to ignore the Utilities folder?  I see I can do it with an absolute file path, but my concern here is that if I'm designing a vianalyzer script that I'm going to commit to a repo and run as part of my CI pipeline, then I would want to use relative paths so that it does not matter where the repo is checked out.  The same concern applies for multi-developer projects, where two people might check out the repo at a different folder location.  In short - could this test store the relative filepaths to the configured folders?

Something like ..\Utilities