How can I create a list of which VIs are reentrant?

[Andrew_Scott_SPCi.ca]

I have several hundred Vis executing on multiple cores through a VIT structure. If I forget to make one or more of them reentrant, execution of the threads declines, as one thread must wait for the VI in the other thread to execute.

How can I find out easily which VIs called by the VIT are not (or are) reentrant? Right now I am reduced to opening each VI individually to see if it is a clone. There must be a better way!

Andrew

[Pachi]

Hi Andrew,

Of course there is.

Here's how to do it:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019V5iSAE&l=en-US

Regards,

[Bob_Schor]

I recently had the same situation in trying to debug a rather large project with quite a few reentrant VIs.  The problem with reentrant VIs is that it is harder (but not impossible) to debug them.  I'd "turned off" reentrancy on several (where I could get away with it temporarily), which made debugging simpler.  But there was so much going on I forgot which ones were actually "on" and which I needed to turn back on.

I wrote the attached VIs (LabVIEW 2011) to take a Project file, delve into its properties deep enough to get its "Children" (its files and folders), then recursively enumerate all of the VIs.  As each VI is identified, its "reentrancy" property is also noted, and an array of paths to the VI and a boolean (true if reentrant) accumulated for inspection.

One could easily modify this to do other things to the files in a Project.  Hope it is helpful.

Bob Schor

[Bob_Schor]

A caveat -- I just built an executable of my routine to find reentrant VIs, and it doesn't work!  From within LabVIEW, it works fine, however.  May have to do with needing the Development Environment to get some of the Project and VI property features to express themselves properly.

[GregFreeman]

You're better off not making an exe but instead creating a tool and adding it to the tools menu within LabVIEW. Also, if you are using any scripting nodes (the blue ones) many are not supported outside the dev environment anyways

[Andrew_Scott_SPCi.ca]

Hello Bob,

Thanks for this. I am currently still running 2009 but plan to update to 2012 around mid October. I will try it then.The other thing bugging me is to find out which VIs are no longer called from anywhere, so perhaps it will work for that as well. I will keep you posted.

Andrew

[dbell0971]

Hi Andrew,

One of our best tools for debugging is called Desktop Execution Trace Toolkit.  It's an add-on for LabVIEW that allows you to see which VI's are called into memory and to... well, trace execution 🙂  It's a great module that I have used to not only follow my order of execution, but also to see how much memory each VI is using.  It's a great way to find memory leaks and may help you find which VI's are reentrant.  I've never used it to find reentrant VI's, but it will show you what VI's are currently in memory and how much memory they are using.

https://www.ni.com/en/support/downloads/software-products/download.labview-desktop-execution-trace-t...

Thanks,

David B

National Instruments

Applications Engineer

[DFGray]

Looking at the color of a node is not a good method for determining if you can use it at run time.  The color only tells you what use bin it falls in (normal, scripting, deprecated, etc.).  To find out whether you can use a property or method at run-time, look at the property matrix in the LabVIEW help.  For the "Is Reentrant" property, it is listed as Read Only for the run-time.  So you can check it, but not set it.  This is what you would expect, since you cannot change code at run time.

Note that reentrant code can be debugged if you set the debug flag and can get into your particular instance (very old versions of LabVIEW do not allow debugging of reentrant VIs).  To get into your particular instance, I have found the judicious use of breakpoints works well.  The best place is usually on a wire leading into the reentrant subVI or on the subVI, not in the reentrant VI.

[Ben]

---

@Andrew_Scott_SPCi.ca wrote:

Hello Bob,

Thanks for this. I am currently still running 2009 but plan to update to 2012 around mid October. I will try it then.The other thing bugging me is to find out which VIs are no longer called from anywhere, so perhaps it will work for that as well. I will keep you posted.

Andrew

---

Source Distributions will do the inverse operation not tell you what is NOT used but what IS used. It will pick up all active sibVIs and move the whole kit-n-kaboodle to a new location leaving the unused VIs behind.

Ben

[Bob_Schor]

---

DFGray wrote:

Note that reentrant code can be debugged if you set the debug flag and can get into your particular instance (very old versions of LabVIEW do not allow debugging of reentrant VIs).  To get into your particular instance, I have found the judicious use of breakpoints works well.  The best place is usually on a wire leading into the reentrant subVI or on the subVI, not in the reentrant VI.

---

Yes, this is how I debug reentrant VIs -- a bit of a pain, particularly if all you want to do is place a probe in them or turn on Watch.  If my VI is reentrant because I'm using the same one in multiple Clones (and don't want them to interfere with or block each other), and I'm testing one Clone, I usually "make life easier" by turning reentrancy off, but then sometimes I forget to turn it back on ...