Recursive VIs

[SarmaHari]

Not sure if  already addressed somewhere

Take a  recursive VI (call  it a.vi)  to a desktop(any version of Windows) where  LV  not installed  at all. Copy  a.vi to b.vi. Take  b.vi to a computer where LV  installed and run

I expected b.vi to look for a.vi. However,  b.vi run did  not expect a.vi.  

How exactly Windows OS interfering in internals of an VI?

If this is  the expected and correct  way of VI working, why LV NG(NextGen) not following this?

[wiebe@CARYA]

---

@SarmaHari wrote:

I expected b.vi to look for a.vi. However,  b.vi run did  not expect a.vi.  

---

This is just one way that is "correct".

The VI could simply see itself being used, and store that. Then when "itself" is being changed from a.vi to b.vi, itself is changed from a.vi to b.vi.

[Bob_Schor]

And, to answer your second question, LabVIEW NXG is not LabVIEW, it is LabVIEW NXG, a new and different product (still in development).  It is not guaranteed (nor expected) to work exactly the same as LabVIEW.  However, it is useful to ask such questions as the Developers might not (yet) have thought about how they are implementing recursion in NXG ...

Bob Schor

[wiebe@CARYA]

---

@SarmaHari wrote:

How exactly Windows OS interfering in internals of an VI?

---

Windows has nothing to do with this.

The SubVI is marked (somehow) as "call to myself". When the name changes, it's still a call to itself.

LabVIEW CG does this exactly like this.

[Ben]

---

wiebe@CARYA wrote:

---

@SarmaHari wrote:

How exactly Windows OS interfering in internals of an VI?

---

Windows has nothing to do with this.

The SubVI is marked (somehow) as "call to myself". When the name changes, it's still a call to itself.

LabVIEW CG does this exactly like this.

---

And make sense in the big picture of LabVIEW.

While I did not see any code associated with the Q, I have to guess that the VI in question has an instance of itself in the diagram which simply points back at the VI itself.

It was not always possible to do that in LV. In the old days, we had to use a Call By Reference to make the recursive call. In that situation we had to explicitly open a reference to the target VI and that was often done using the VI file path. The path could be explicit or relative. If the VI grabbed its own path it would work the same way as being discussed in this thread. If however the Open VI ref used an explicit VI name defined in the code, THEN it would operate in the manner the OP was expecting.

So choose which effect you want and code it the way you need it to work.

Ben

[alexderjuengere]

---

@Ben wrote:

---

...

While I did not see any code associated with the Q, I have to guess that the VI in question has an instance of itself in the diagram which simply points back at the VI itself.

...

---

aputman

did share this SolveSudoku.vi in Sudoku.zip ‏58 KB found here

The vi is set to reentrant and does point back to itself:

[wiebe@CARYA]

---

@alexderjuengere wrote:

---

@Ben wrote:

---

...

While I did not see any code associated with the Q, I have to guess that the VI in question has an instance of itself in the diagram which simply points back at the VI itself.

...

---

aputman

did share this SolveSudoku.vi in Sudoku.zip ‏58 KB found here

The vi is set to reentrant and does point back to itself:

---

That is a recursive VI alright.

Is it anyhow related to the question?

[alexderjuengere]

---

wiebe@CARYA wrote:

---

That is a recursive VI alright.

Is it anyhow related to the question?

---

stating the obvious: no

sorry for being annoying, and I also don't want to offend you.

Furthermore, I appreciate your the explanations in the other posts of this thread (and various others, I even have a favorite wiebe-post, which is several years old and about the flood-fill algorithm implemented with labview, of course)

the forums is a place to share opinions, suggestions, ideas, solutions ... it's an archive of knowledge.

I rarely use recursive VIs, as I am not confronted with many use cases in my programming practice.

After all, I am an engineer, not a computer scientist

But I am  of course interested in any approach to solving problems .

There have been 1 or 2 occasions in the past 10 years, when I couldn't avoid recursion and I had to come up with a working solution, and I did in the style like Ben described in Message 5, last paragraph.

[SarmaHari]

Replying to Ben (message 5)

Please find attached a quick recursive vi (re-entrant) saved for LabVIEW Version 15. Very basic, not much of error handling etc., 

- "open a reference to the target VI ", would  obviously fail, if I rename a vi. 

On my present computer, I do not have NXG , so can not  give a copy. However I tested. As the behavior of CG & NXG LV's different, when copying a recursive file at Windows (OS) level, I see the following problem

1. If there is a set up  that, has set of shell scripts (or batch files or any scripting language files) that rename ("ren" in windows , "mv" in Linux) a recursive file and executes, in this kind of  setup, changing CG LV to NXG LV files would not suffice. Changing the script is also required

2. Assuming Nestedness (stack depth) of recursive file is same in CG & NXG, NXG would  go one more level extra. That is because NG first invokes new file, which invokes old (before renaming) file

[wiebe@CARYA]

---

@alexderjuengere wrote:

---

wiebe@CARYA wrote:

---

That is a recursive VI alright.

Is it anyhow related to the question?

---

stating the obvious: no

sorry for being annoying, and I also don't want to offend you.

Furthermore, I appreciate your the explanations in the other posts of this thread (and various others, I even have a favorite wiebe-post, which is several years old and about the flood-fill algorithm implemented with labview, of course)

the forums is a place to share opinions, suggestions, ideas, solutions ... it's an archive of knowledge.

---

Sorry if that sounded like 'bugger off', that was not the intention at all. I'm not at all the right person to call 'off topic', as I'm a big offender myself.

Just wanted to make sure I understood correctly that it was OT.

Please consider it as "message lost in translation" (from thoughts to mail).