Does "Run VI" invoke node work on strict references to REENTRANT VIs?

[UFAPA Steve]

I am using LV 6.02 on Windows 2000.

I am trying to use the "Run VI" invoke node method with a reference to a Reentrant VI, with no success. (It works when VI is not reentrant. Perhaps there is a reason this cannot work. But if not, I wonder if there is a workaround, or if LabVIEW 6.1 has a fix?

Hopefully the picture of the block diagram I included is sufficient...but I also included the actual code just in case.

Thanks!

Steve

[Labviewguru]

Steve,

Your implementation is flawed. The call by reference node is the exact equivalent to calling a SubVI, and is primarily used to call multiple instances of a VI (for example, in recursion, or to force reentrancy of VI) but that's about the extent.

Also, you are using a path to the VI along with a reference. This is redundant, you don't need both inputs.

Also, you are using references to pass Values around. This also looks flawed, as you are passing references into the subVI to input and retrieve values. This should be done by wiring the subVI directly with your input values.

If you could advise of what you are exactly trying to do (not what the code is doing, but your goal, the function that your subVI/caller perform), we may be able to
offer a better solution.

[UFAPA Steve]

Hi, Labviewguru,

Thanks for taking the time to look at my admittedly messy (flawed) block diagram. I will try to state my ultimate goal:

You may be familiar with Levinberg-Marquardt nonlinear curve fit in Labview, which is about 5 VIs in a LLB file. In order to change the type of curve fitting, one has to either modify a formula node in the lowest subVI (Target Func and Deriv), or place a different subVI in there. That's fine until I want to have many different sorts of algorithms.

What I was thinking of doing is instead passing Target Func and Deriv a reference to the VI which would perform the calculations. This would allow me to use the same fitting code to fit different types of data with substantially different methods--without modifyin
g the low-level fitting code at all.

I'm not sure this is going to make any sense to you, but thanks again for your help.

In regards to your answer above, let me clarify somewhat. I had the call by reference node in there to prove that the reference to the VI was "good" and worked fine...this same reference was passed to the invoke node, which didn't have any apparent effect.

Also, I don't think the path to the VI I am opening the reference to is redundant. It is required to tell the "Open VI reference" which VI to load.

I agree that using references to pass values around is not generally a good idea: I was using that method for my supposed versatility in the future.

Thanks,
Steve

[Labviewguru]

Steve,

I'm still not entirely sure of what you are trying to do.

If you want to be able to use different algorithms to perform the operation, then you should consider putting the different subVIs in a case, and allowing input to determine which subVI to call.

If this is something that needs to be dynamic as a built executable, then I would suggest simply using the VI server to call the approriate subVI. The "Call by reference" node may also be appropriate, but you can't use property nodes or invoke nodes in conjunction with that call. The "Call by Reference" acts exactly like a subVI, but allows you to call a VI by name. This is where I was talking about the redundancy in your code, the VI Path only needs to be used, a reference d
oes not need to be input, as the Open VI Reference creates a reference from the VI Path.

I hope this helps.

[UFAPA Steve]

Thanks Guru, You have helped a bunch.

The case structure works, of course, and maybe I should just keep doing that.

I think I understand now that I can't use Call by Reference in conjunction with the invoke nodes.

Best wishes,
Steve

[JeanPierre]

UFAPA Steve,

when you open a strict reference to a VI (reentrant or not) it is put in the state "reserved for call" then it can't be run by "Run VI" method or by the Run arrow. I don't know why you stated that it works for non-reentrant VIs because it doesn't, returning error 1000 "Vi is in a state incompatible..."

About the Target function of the LM minimization, you can indeed modify it to use dynamic call to function VIs. I have done it before and I may be able to retrieve the code from my HD if you can't do it by yourself (code the dynamic call, not retrieve it from my HD...).

[UFAPA Steve]

Hi, Jean-Pierre,

Thank you very much for the thoughtful answer. I have accessed your harddrive and downloaded the appropriate VIs.

You say, "I don't know why you stated that it works for non-reentrant VIs..." You know why? Because I flat-out lied. I re-did my code, and you are correct...I just got confused in all the different things that I tried. In fact, I DO get the error code when the called VI is NOT reentrant. The funny thing is that I DON'T get an error message in the code that I included with my original post.

That is, when the VI is reentrant, "Run VI" doesn't work, but it also doesn't report an error. Maybe I should tell NI about this?

Thanks again for your help. If it is not too much trouble to upload, I would love to see y
our dynamic call LM code.

Best wishes,

Steve

[JeanPierre]

UFAPA Steve,

here it is. It uses a global to store the target function path and a boolean to flag changes. They are 5.1 VIs, I didn't check if they still fit newer versions connector panes but you can see the picture.

[UFAPA Steve]

Thanks!!!