Strange behavior feedback node in shared clone

[andre.buurman@carya]

Hello,

I have some strange behavior of a feedback node as can be seen in the inserted VI snippet.

The particular VI is called in a chain of shared clone calls (call parent and dynamic dispatch). 

When I remove the feedback node and rely on a previous value register further down the line all behaves properly.

Running a single chain of clones gives proper results for each interface, but running 2 chains in parallel give erroneous result due to the feedback node.

LV version 2019.0f1 64-bit

Am I overlooking an obvious need to know or is there a bug?

[rolfk]

Feedback nodes store some data and this storage is in fact provided by the dataspace of the VI in which a feedback node (or shift register) is present. LabVIEW creates one VI dataspace per VI instance. Normal VIs always have only one instance, clones use one instance per clone. Since you use shared clones there is typically only one or two instances in memory unless your application happens to call routines that access the same VI multiple times in parallel.

Basically the presence of feedback nodes or shift registers in VIs configured as shared clones is never really a good idea and it could be considered a bug that LabVIEW doesn't flag this as an error.

The use of feedback nodes and shift registers in reentrant clones is fully valid but most times not what the developer intended unless he knows exactly what he or she is doing.

In your situation you probably do not want to use a previous value tied to the VI instance but rather to your processor class so you should store it in that class and not rely on VI instance specific storage which has absolutely nothing to do with your class data.

[andre.buurman@carya]

Thanks Rolf for this explanation.

It looks like it's a bit of both then:

1. I overlooked some need to knows "avoid feedback nodes and comparable shift register implementations in shared clones" 

2. The use of feedback node and shift registers in shared clones should've somehow been flagged by LV as something to be careful with.

[Intaris]

---

andre.buurman@carya wrote:

Thanks Rolf for this explanation.

It looks like it's a bit of both then:

1. I overlooked some need to knows "avoid feedback nodes and comparable shift register implementations in shared clones" 

2. The use of feedback node and shift registers in shared clones should've somehow been flagged by LV as something to be careful with.

---

There are of course cases where feedback nodes in shared clones are perfectly OK. What should LV do, issue a warning? Nobody pays any attention to them at all.  What does VI Analyzer say about it? Does it flag a warning?

[rolfk]

---

@Intaris wrote: There are of course cases where feedback nodes in shared clones are perfectly OK. What should LV do, issue a warning? Nobody pays any attention to them at all.  What does VI Analyzer say about it? Does it flag a warning?

---

I can't easily think of one although I'm sure it's possible that that exists. Can you explain in what cases you would consider that a useful feature?

[RavensFan]

I'd argue it isn't the use of shift registers and feedback nodes that is a problem, but the use of uninitialized shift registers or globally initialized feedback nodes.

SR's and FBN's are okay for loops where the data is intialized and fully consumed within the subVI.  As long as the SR or FBN is initialized when the clone starts executing when it is called, you're fine.

[andre.buurman@carya · Accepted solution]

---

@rolfk wrote:

In your situation you probably do not want to use a previous value tied to the VI instance but rather to your processor class so you should store it in that class and not rely on VI instance specific storage which has absolutely nothing to do with your class data.

---

This is actually what happens when I remove the feedback node. It then uses a previous values stored in a session object at a lower level specific to a particular interface and that works.

[Kevin_Price]

---

@RavensFan wrote:

As long as the SR or FBN is initialized when the clone starts executing when it is called, you're fine.

---

Am I being dense?  If you initialize the SR or FBN when the clone starts executing, why even have the SR or FBN?

Oh, I think maybe I get it -- you're thinking specifically of clones with their own internal looping, not the classic single-iteration loop with a USR that I was thinking of.  Right?

-Kevin P

[Intaris]

---

@rolfk wrote:

---

---

I can't easily think of one although I'm sure it's possible that that exists. Can you explain in what cases you would consider that a useful feature?

---

If a shared sub-VI needs to interact with another object with state where reading out some of the state is important for performant code.  Knowing when the cached state data is out-of-date (new object passed) is crucial to this.

It's not going to be a huge use case, but it is one and it's perfectly valid.

[crossrulz]

---

@Intaris wrote:

If a shared sub-VI needs to interact with another object with state where reading out some of the state is important for performant code.  Knowing when the cached state data is out-of-date (new object passed) is crucial to this.

---

But if both classes are accessing that VI at the same time, Shared Clone rules dictate that a new clone would be added to the pool.  So you will not have the "cached" data as the new fresh clone will be used.  What you are describing sounds more like it should be non-reentrant.