result from reentrantly called subvi

[tartar813]

I have a subvi that I am calling reentrantly, I need to pass a cluster result back.  Doesn't look like I am doing it right because I am not getting any results.  

Image resultfromsubvi.png I am calling the subvi.

Other image is from the subvi in which I bundle the double's up.  I know that I have the same value going into 3.

Just testing.

Thanks in advance.  

[RavensFan]

You're not waiting until the subVI is done.  Is it possible that you are not waiting long enough for the subVI to get a value to place in the indicator you are trying to read?

[Nathan_S]

Could you post some code so we can see what is happening?  Why are you calling the subVI reentrantly? 

Also, you are disposing of the reference inside the called VI.  If it leaves memory before the final call can Get the value of the control, it probably won't return anything.  That's my thoughts for now before seeing the code.

[tartar813]

I am testing a/c impedance on on multiple channels.  I find an available slot and I pass the control values to the subvi to run the test.  Then we run another test 10 minutes later on same battery.  So in the subvi I have test, then timer, then test again.  

This keeps the main user interface updates.  

I did change the wait for finish and it works then.  But then I cannot start another slot since it is waiting.  I am using global variables for the results with a timer to update all of them, but was looking to reduce this by returning the values from the subvi.  

Must not be able to get the results if you say do not wait for finish. 

[Hooovahh]

---

@tartar813 wrote:

Must not be able to get the results if you say do not wait for finish. 

---

The thing you need to realize is there is no results until it is finished.  Reading that control before a value has been written to it will not fix your issue. 

Depending on your needs there are several architectures that work with a loop telling another loop to perform some action, and then get notified when data returns (Queue / Notifier / User Event / Polling)

[tartar813]

I am reviewing how to pass the indicator reference to the subvi to update it from the subvi. 

Do you think that would work?

[tyk007]

---

@tartar813 wrote:

I am reviewing how to pass the indicator reference to the subvi to update it from the subvi. 

Do you think that would work?

---

It would mean that your indicator would only be updated when the subvi is done (ie. when it writes to the reference). However it won't tell you when that is, as others have mentioned. If you have code contingent on getting the result of that subvi then this probably won't work for you. As already discussed, there are architectures out there to help you.

[tartar813]

Thanks guys, I will review the above and find a solution.

Much appreciated.  

[Hooovahh]

---

@tartar813 wrote:

I am reviewing how to pass the indicator reference to the subvi to update it from the subvi. 

Do you think that would work?

---

Well sorta.  Again I don't know the full story and how this is intended to be used.  But yes that is one option is to pass the reference to the UI control to each reentrant sub VI.  The issue you will run into is these reentrant subvis will be updating the UI control asyncronously so indicator will be constantly overwritten with new data.  If you plan on logging the data as it comes in you will run into issues keeping track of what data came from where and when.  If you don't care about this type of thing then a control reference maybe the easiest.

[Nathan_S]

Good thoughts.  I agree.  I was also thinking that using a Notifier that is instantiated on VI call would allow the passing of the 1. name of the subVI and 2. the data.  Then the main program could subscribe and receive the data and tell who it is coming from.  I don't know that reentrancy is really necessary in this case.  If a VI is spawned asynchronously, a template VI could be used instead, which would allow multiple instances of the same VI in memory (will need to be careful with the namespace) and this could be a little less of a headache. Just my two cents.