02-22-2012 07:40 PM
Replace array subset. Input array is an array of a large cluster (typddef). Index a single value and input an element of that same typedef. Input and output arrays only exist on wires from/to a get/set routine, i.e get the array, which lives in some front panel, index and replace one element, store the array back. See attached image.
This seems to work on LV7 development, executable. Now on LV2011/64 bits, development, things don't work right, with some values on the array displaying zeros (but values in the cluster are correct). Did something change in the way displays are updated?
I added indicators on the wires (the input control is already there in the front panel) and can see the value retrieved being initialized with default values (NaN), the element having the proper new value, and the ouput of replace array subset being displayed wrong. Before running this routine (part of a large program) I indexed both indicators to the right index and made sure the control in the cluster that I care about is visible. In cames a value of -0.075 or so, to override the initial NaN, out goes a zero being displayed. Somewhere down the line we use the displayed value (don't ask me why) and it's wrong.
02-22-2012 08:15 PM
I can see that you are searching for a value in the array and taking that index and giving it to the Replace array. Did you check what is the index calue you are getting there and are you sure that it is not -1.?
02-22-2012 09:52 PM
Yes, I had a probe on the index and it had the correct value. Also, the array entry for that index value is the one that gets corrupted.
02-23-2012 12:40 AM
Could you post the complete code where this is used? Is the Get/Set VI used somewhere else in your main application? Just trying to rule out the possibility of a Race condition.....
02-23-2012 09:07 AM
Too many VIs to post here. The get/set VI is dynamically loaded on init and not closed so it remains in memory. Getting returns the cluster array that lives in the front panel. Setting sets the front panel control. I doubt there are race conditions when I debug the code and step over the array subset, as no other threads (that use that cluster) are running.
02-23-2012 09:08 AM
And also check the vi is configured as clone (Reentrant vi).
02-23-2012 11:12 AM
Not reentrant.
02-23-2012 03:48 PM
Assign this to the perenial bug (or is it just the way it is supposed to work?) where we have a control on a given VI, marked "Auto Update from the Typedef", but where it differs from the typedef somehow, i.e. it doesn't match the typedef.
Some VI up higher from the code that fails has a front panel control, a cluster of a bunch of elements, some with units. It is marked Auto Update from Typedef, but right clicking it and selecting Open Typedef shows that even though the elements match in type and name, the units don't!!! Thus a conversion from THz/W to Ohm yields an unexpected result.
This VI and the control were probably silently upgraded by LV2011 when opened, with the last version saved with LV7, but I can't garantee it anymore. This has happened to us in the past...