Alternative to creating re-entrant VI for storage of persistent values (for easier debugging)

[ToeCutter]

Okay, poor title but I can't summarise any better than that at the moment.

So I'm sure many of us use the old trick of creating a re-entrant VI so we can use a loop structure within the VI (that usually executes only one cycle per call) to allow us to store persistent (static) variables within the VI between calls. The problem with this is that all the headaches that come with a re-entrant VI in terms of not being able to run 'with the lightbulb on' to debug then arise.

Most of the time, I only need a single instance of this VI, so how about an alternative to re-entrancy like 'allow statics' that gives me the stored info but only allows a single instance to be used, and gives me the ability to run 'with the lightbulb'?

Of course, I have made an assumption that limiting to a single instance would make this feasible without major architectural modifications. If not then this is one for the scrapheap.

[tst]

If you want to keep values in a single VI, you can use a USR in the VI itself. Or local variables. Or any other tool which will work for you. I'm not sure what your use case is exactly, so I can't comment.

In any case, I'm not sure how what you describe is different from a non-reentrant VI. It's a single instance and you can debug (which I'm pretty sure you can also do with reentrant VIs if you didn't disable debugging, but I haven't checked to confirm).

[ToeCutter]

Hi tst.

Here's a scenario. I have a loop in my top level VI. Within that loop I call a subVI and I want that subVI to maintain it's own state information (could be in an uninitialised shift register or a local variable). I don't want to have to pass the state to a shift register in the top level loop or use a global. My experience is that the USR method requires the subVI to be made re-entrant to retain the shift register values between calls. I haven't tried, but I expect the local variable within the subVI to behave the same way.

It is also my experience that I cannot run traced execution internally on a re-entrant VI, which is a pain.

I'm guessing not many people use these methods from the lack of comment/kudos.

[AristosQueue (NI)]

ToeCutter: In that case, just don't make the VI reentrant. Non-reentrant subVIs store their state also. There's no requirement to make a VI be reentrant just because it has an uninitialized shift register.

[Darren]

Already possible as described here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Alternative-to-creating-re-entrant-VI-for-storage-of-p...

[ToeCutter]

Thanks chaps. Appears my knowledge is outdated. Does anyone know in which version this was changed?

[crossrulz]

It has alwaysbeen that way since LabVIEW 2.0.  How else do you think Action Engines work?  The only thing wih non-reentrant VIs is that every call to that VI will use the same memory space.  But since you are just talking about 1 instance, this will not be a problem.

[ToeCutter]

Okay, thanks crossrulz. I have believed for years I needed to make these things re-entrant. Don't know how I got my wires so crossed, but that's always a danger with LabVIEW.