I thought I understood shared clone reentrant execution mode but I guess not?

[David99999]

I have a subVI that does calculations. In my main VI I'm using this subVI 3 separate times. I was looking at the values being outputted by all 3 subVIs and I noticed they were all incredibly similar to each other, when they shouldn't have been. My VI execution mode was set to shared clone reentrant mode.

Well when I changed the execution mode to preallocated clone reentrant execution, the values out of all 3 subVIs started to make more sense.

This whole time I was under the impression that the shared clone reentrant option did the same thing as preallocated clone, but when the subVI wasn't being called/used, it would just get rid of the reference in memory (or whatever the correct terminology is) so it could free up processing power for other tasks. But regardless, I thought shared clone still created 3 (in this case) separate subVI's each doing their own independent calculations.

Here are the settings I have for the subVI. I've only ever messed with the reentrancy mode radio buttons, nothing else.

[Kyle97330]

Well, what sort of stuff does this subVI do?  Can you post it?

It's likely that something is going on like the use of feedback nodes or uninitialized shift registers that is persisting something from one call to the next that you didn't plan on.

[David99999]

Attached. And here's a screenshot of the main VI that calls the subVI in 3 instances

[Yamaeda]

---

@David99999 wrote:

This whole time I was under the impression that the shared clone reentrant option did the same thing as preallocated clone, but when the subVI wasn't being called/used, it would just get rid of the reference in memory (or whatever the correct terminology is) so it could free up processing power for other tasks. But regardless, I thought shared clone still created 3 (in this case) separate subVI's each doing their own independent calculations.

---

Not quite. It creates a pool of VI's that gets reused as it sees fit to save memory instead of having one copy for each one placed in code (which can be quite a few if the project is large). So it's important to not have anything internally that has effects/dependancies for future calls, as feedback loops or ... PtByPt functions ...

In your case you'll basically randomly call copy 1-3 and the PtByPt and get strange results.

[Kyle97330]

Yep, definite agreement that the PtByPt functions are the problem here.  It shouldn't be hard to duplicate them though... just replace them all with storage in a fixed-size array, where the storage index location is the iteration number of the loop mod <size of array>. 

Depending on your total setup you also might want to switch more of your internal wires to fixed point, since it seems you are using a FPGA.

[altenbach]

Yes, the LabVIEW compiler should have noticed the ptypt functions and not share clones between the three instances. I guess that was beyond the scope. 😄

Do you really have two different histories for the various data paths to be combined (400 vs 500 points)?

I would probably do my own ptbypt mean based on arrays of all 12 scalars. Would probably be much more efficient. The subVI input could be a single FXP array of 9 elements (since all FXP are of the same type here). Also note that there is a Sin&Cos function to simplify things.

[altenbach]

---

@altenbach wrote:

I would probably do my own ptbypt mean based on arrays of all 12 scalars. Would probably be much more efficient. The subVI input could be a single FXP array of 9 elements (since all FXP are of the same type here). Also note that there is a Sin&Cos function to simplify things.

---

Here's how that could look like:

In the caller, you would make an array of the 9 FXP wires in the given order. For the prbypt mean, you could modify this by using an array input and a 2D array for the history.