VI calling itself (run top level)

[newbie217x]

I don't have a problem reading the configuration from the loop. The problem is:

Program 1 calls Program 2 and loads configuration

Program 2 tries to call Program 2 to load next configuration but cannot b/c Program 2 is now top-level execution state and generates error when it tries to call itself again (even though Program 2 is seto to re-entrant).

This is a problem b/c I'm trying to build multiple nested loops based off of Program 2.

One quick fix is to create multiple instances of the same Program 2 (call it Program 3, Program 4, Program 5, etc). Then I can call one after another and b/c the names are different, there is no error.

[smercurio_fc]

You're missing the point. NOTHING that you have described so far has pointed to you requiring recursion or even re-entrancy. All that I see is a single loop. In fact, what I really see is a state machine (Application Design Patterns: State Machines ). You seem to be fixated on this recursion/reentrancy.

[Timmar]

I agree with smercurio,

The only reason for this sort of recursion is if a .vi uses the result of a previous calculation.

Newton Raphson is a classic example of this.

In your example:

Read the configurations,

Put them into an array

Put your VI in a for loop, passing the indexed configs.

Job Done.

[newbie217x]

I probably need to spend more time thinking about this... but how does one go about building an infinite nested loop?

For example, the ini file being read contains an unknown number of sweeps inside sweeps... how do I write a state machine that can run a for loop, read the file to see if another sweep is requested and then wrap another for loop around that... and so on...

The idea w/ the re-entrant vi is that it could keep calling other vis or itself w/o bound.

Thanks.

[Dennis_Knutson]

By your definition here, you are not at all running anything 'nested' and there are not sweeps inside of sweeps. What you have described is sequential where you run one sweep with one configuration and when it completes, you run another with a different configuration. A main program would first determine how many configs exist. Then it would load config n. It would pass that config to the sweep VI. When that completes, it returns to the main VI. It would load config n+1, pass that data to the sweep VI, etc. The main vI would continue until the last config was loaded and the sweep for that has run.

If your initial description is not correct, then change that and define exactly what is nested.

[Timmar]

I have worked in a similar environment.

I used a queue for each new sweep.

your main loop takes the next sweep out of the que, processes it (pushing new sweeps onto the front of the que [reversing their order of course] if it finds them).

As a word of caution, for each loop of main, check the queue size, and error handle above a threshold, infinite recurrsion gets very messy very quickly.

Tim L.

[newbie217x]

Hi Timmar,

Would you happen to have an example of the code you are using to do this? I haven't yet found the time to try implementing the suggestions from above.

Thanks.

[Timmar]

noob,

Can I offer some frendly advice,

Don't post "I havent found time yet" and then ask for someone else's help.

We are all busy people and this forum tends to be a place of quid-pro-quo.

I have had many very hard problems that I have asked for help with, many of which go unresolved.

As a general rule, I will try to help out on about 5 simpler ones in return.

My belief is that if the forum saves me 4 hours with a solution, I should give an hour back (helping others save 4 hours).

This is not a place for "Do my work for me".

That said, I recognize that you are a new starter so I have knocked together a VI for you. In the hope that in 3-6 months you will be helping someone else solve their problems.

Caviets:

1. This vi is for concept only, I haven't trialled it.

2. I have used auto cleanup on my code. The result is not inspiring.

3. There will be latencies between each sweep while it reads each sweep file,

3a. Pre-compiling all of the sweeps into a "sweep data" queue will speed this up.

3b. Pre-compiling can be sped up by only reading each referenced file into memory once, avoid re-loading it if possible. On a fast pc with pre-compile and small text files i wouldn't bother. For .xls and more complex structures, it's well worth the effort.

Tim L.

[newbie217x]

thanks Timmar. Understood. I will take a look at this, try to understand it and hopefully be able to contribue something more meaningful to this thread. I'm probably in over my head at the moment, so don't have any useful code, thoughts to share. This might be the insight I need to move forward

cheers.