05-30-2006 08:16 PM
I find tst's two samples, as modified the cluster to control and not use global variable, or property node value item, but connect it directly, the result is correct at LV7.0.
Yup, we use global variable or property node value item of cluster usually, that will trap us.
05-31-2006 01:55 AM
@Yukee wrote:
I find tst's two samples, as modified the cluster to control and not use global variable, or property node value item, but connect it directly, the result is correct at LV7.0.
The original was not a local but a typedef cluster which came out of an LV2 global, so replacing with a control is not an option. The local is there because that's the simplest way to demonstrate the problem - it doesn't require any additional VIs. The solution, as already mentioned, is to only unbundle the value once.
Altenbach Wrote:
@Ben wrote:
PS I do not have time to invesatigate but this sounds like the "data flowing backwards" bug.
I think it is more complex than just "flowing backwards". It is really strange, e.g. if you do execution highlighting, all unbundle outputs show as zero and the wrong values only appear after the increments. Even a probe placed right before the increment still shows zero. ...
I would also agree that my initial description of the data going back to the unbundle node was inaccurate. This appears to be a buffer reuse issue, which would explain what you need a local to trigger it, although I have no idea which buffer is the being reused. What really surprised me was how it screwed up the array as well. I tried typecasting the various wires to see if there was any additional data, but couldn't find any.
This actually reminds me most of Stephen Mercer's story about the multiply node bug. They said that story was fictional, but now you can see that it is grounded in some reality.
05-31-2006 04:10 AM