Action Engine with Recursion fails on first two executions

[kc64]

I'm trying something new and having a bit of difficulty.  The bottom line is that my code only runs successfully after the first two attempts fail.  From then on, everything works fine.

The Context:

I have an action engine with a USR that stores references to a collection of table controls.  The action engine contains some methods for setting the color, value, and size of the cells of a given table control.  These are simple property manipulations and are low-level code.  I then added some higher-level code to enhance the behavior.  The higher-level code sets the text value and color of a given cell based on the power level of the object that the cell represents.  For instance, if I want the cell to indicate a power level of 100W, I set the cell contents to 100W and set the color to red.  Since I already have code in the action engine to do this, I thought I would try having the action engine call itself to set the color and text.  I followed the instructions on the NI website for making a VI recursive-ready and it does work but only after the first two attempts fail.  I believe the two failures to be related to the levels of recursion that are present in this scheme.

So, what fails?  I get "Error 1055 occurred at Property Node" (Object reference is invalid) when the code tries to execute a property node on a control reference I've loaded.

I realize the approach might be questionable to some but, since I'm learning Lisp presently, I'd like to see if I can borrow some of the concepts that I've learned there to help make me a better LV programmer.

Any comments or suggestions?

[Omar_II]

Making a Action Engine Reentrant will defeat the mechanism for storing your data in the USR.

Each clones (or recursion call) will have it's own copy of data.

Setting it to share clones between instances I do not beleive will help.

I have never tried what I think you are doing. My Action Engines are always NON-Reentrant.

[TCPlomp]

Could you show the exact code you use?

Second, in LabVIEW 2009 or 2010 you can drop a VI on it's own block diagram to make it recursive.

Without any code it's quite hard to see what goes wrong.

Ton

[Ben]

---

@TCPlomp wrote:

Could you show the exact code you use?

Second, in LabVIEW 2009 or 2010 you can drop a VI on it's own block diagram to make it recursive.

Without any code it's quite hard to see what goes wrong.

Ton

---

Yup! show us the code.

I suspect that the clone instances are not inititalized since each instance has its own data space the USRs used by one instance aren't available to the clone instance.

Ben

[kc64]

Interesting comments.  I think you have identified a misunderstanding that I have in the way that re-entrancy is implemented.  When I set up the VI to be re-entrant, I selected the "Share clones between instances" option.  I guess I don't really understand the difference between an "instance" and a "clone".  I thought that this would use the same USR for every call to the VI, even when called recursively.

[TCPlomp]

---

@kc64 wrote:

Interesting comments.  I think you have identified a misunderstanding that I have in the way that re-entrancy is implemented.  When I set up the VI to be re-entrant, I selected the "Share clones between instances" option.  I guess I don't really understand the difference between an "instance" and a "clone".  I thought that this would use the same USR for every call to the VI, even when called recursively.

---

Yes, I guess you misunderstood that. The 'Share clones between instances" means that LabVIEW tries to use the least number of clones possible, however this can cause data leakage from one run to another. In my opinion there is no difference between a clone and an instance.

When calling recursivly you cannot turn of cloning, since for the sub-vi call you will need a new execution (data and CPU-power) space.

But please post the code.

Ton

[kc64]

Thank you all for your helpful comments.

Since the approach is flawed, I will abandon it and use a wrapper to call the lower-level calls.