Difficulty calling reentrant VI using open VI reference and invoke node (LV 6.1)

[nickayres]

Hello All

I have a VI that I would like to run asynchronously with the rest of my code.

I have tried to implement it by having a VI with a STOP button on the front, that is initially called by using an invoke node and then told to stop (it takes about a second or so to finish and save everything) afterward using Set Control Value on the stop button. The VI is set to be reentrant in its options.

It needs to be reentrant because I need a new instance to start collecting data again as soon as "STOP" is pressed on the previous instance, so while the old instance is finishing up a second will be running.

However, when I wire HEX 8 to the option terminal of my open VI reference node, as specified in the help file to "prepare for reentrant run", my VI doesn't actually run. The front panel opens, and the usual run button is replaced with a solid black run button.

If I press run and stop manually, the VI works as expected. If I leave the option terminal unwired, the VI still works as expected. I cannot see why my VI is behaving any different to the example (DateServerUsingReentrantRun).

I've screenshotted the relevant parts of my block diagram and what happens when I run (I made a simpler app to demonstrate the issue).

EDIT: the reentrant VI I am trying to call does its file operations (i.e. the only output that is not shown on the front panel) using a subVI that stores details (file path to be written to) in an uninitialised shift register. Could it be that my VI is running (silently), but because it runs reentrantly in its own memory space the subVI is losing its information and so not producing output?

[altenbach]

First of all, LabVIEW 6.1 is almost prehistoric. Secondly, you should attach your actual VIs. We cannot debug pictures. Thanks.

[tst]

I don't have the date server example in front of me, so I'm not sure how that works, but I can say that before 8.x reentrant VIs didn't have separate front panels for each copy of the VI. This might be causing what you're seeing.

What you can do instead is change the VI's extension to VIT, which will make it into a template. Then, using OVR on the template should generate a new copy of the template in memory which you can use to do what you want.

[nickayres]

@Altenbach, In retrospect I probably should have included the actual VIs. My reasoning before was that these little VIs all link into a much larger application, so have a lot of dependancies. I'll get to making simplified versions without the dependancies for people to look at.

Using Labview 6.1 was not my decision, I am working on someone else's much larger project which was developed in LV6.1 and has not been migrated to a new version for what I am assured are good reasons.

@tst Changing to a VI template hasn't done what I wanted unfortunately.

I have narrowed down the problem: what seems to be hapenning is that my call is working find, but my subVI to save the files which I am calling from the reentrant VI is losing the information in its shift register between times it is accessed.

If this is the case, can someone suggest an alternative way of holding the path?

[altenbach]

---

@nickayres wrote:

I have narrowed down the problem: what seems to be hapenning is that my call is working find, but my subVI to save the files which I am calling from the reentrant VI is losing the information in its shift register between times it is accessed.

---

Is that subVI also reentrant? It probably should not be.

[RavensFan]

---

@nickayres wrote:

I have narrowed down the problem: what seems to be hapenning is that my call is working find, but my subVI to save the files which I am calling from the reentrant VI is losing the information in its shift register between times it is accessed.

If this is the case, can someone suggest an alternative way of holding the path?

---

You can use a global variable to hold information (assuming they existed in LV 6.1), but I wouldn't use that.

You could use a Functional Global Variable  aka Action Engine to hold the information.

But if you are losing information in your shift register, that means you either don't have the wire on the shift register wired through all of your cases, or your VI is leaving memory between calls.

[crossrulz]

---

@nickayres wrote:

If this is the case, can someone suggest an alternative way of holding the path?

---

Save the path in the reentrant VI.  Each clone of the VI will keep its own memory space.  Just make sure the reentrancy mode is set to preallocate for each instance and not shared clones (hoping those settings are in 6.1).

[nickayres]

Thank you all for the many suggestions and help

After consulting with my supervisor, we decided that the best way to avoid these sorts of issues would be to avoid using reentrancy alltogether and instead use an (admittedly more complicated) proceedure involving a while loop to read the data.

[tst]

You haven't said why the VIT method didn't work and you still didn't include any actual code, so I can't offer any real advice other than to say that as far as I know, changing to a VIT should have worked.

The only guess I have as to why it didn't work is that you also left it as reentrant and that probably caused the exact same issue, but since you seem to say the call to the reentrant VI wasn't the issue in the first place, I'm not sure what the actual problem is and without actual code I don't see a real way to help. We could keep guessing, but I think that's a waste of our time.