Can anyone tell me if there is reason for this array to reinitialize to another location in memory?

[rickford66]

First off, I'm using LabVIEW 7.0.  I've written a vi that is supposed to give me a rate value in degrees per second.  The Initialized Array variable is initialized outside a loop as an array of 40 int32's.  The index increments 0-39 inclusive.  The logic is that the array will hold 40 values, with the incoming index being the newest one and the index +1 being the oldest one.  Outside this vi, the index is held in the same variable so the new array index in is always the last array index out.  I'm inserting the newest value into the array, so I don't see why it would make a new array.  I'm not sure it is making a new array, but does anyone know by looking at it if it would create a new array?.... or how to test for it?

Thanks.

[RavensFan]

Is there a particular reason you are asking this question?  Why do you think it might be creating a new array if you don't know that it is?

Search the forums for "buffer allocations".

One thing that can help.  You are splitting your array wire and using two different Index Array functions. You'd be better off exanding the bottom of the Index Array function downwards to get yourself another output.  That way you are effectively getting two elements out of one array rather than getting two elements out of two "different" arrays that are caused by splitting the array wire.  (It may or may not be creating a buffer allocation.)

[Ben]

---

@Ravens Fan wrote:

Is there a particular reason you are asking this question?  Why do you think it might be creating a new array if you don't know that it is?

Search the forums for "buffer allocations".

One thing that can help.  You are splitting your array wire and using two different Index Array functions. You'd be better off exanding the bottom of the Index Array function downwards to get yourself another output.  That way you are effectively getting two elements out of one array rather than getting two elements out of two "different" arrays that are caused by splitting the array wire.  (It may or may not be creating a buffer allocation.)

---

I do not think "Show Buffer Allocations" was an option in LV 7. Back then we had to add the line

showInplaceMenuItem=True

to the LabVIEW.ini file (then restart LV) to pick-up the

"Show inplace set"

right-click option for each wire one at a time.

From what I saw of the code the answer is "depends" if the terminals are on the root of the sub-VI digram or not. There was also a version of LV back then that had some trouble scheduling operations to avoid buffer copies.

the code...

does not show the updated array being saved anywhere so there may indeed be a data buffer copy in the caller if it thinks the sub-VI is going to screw up it copy.

the caveat of the "Clear as Mud" thread may be kicking in.

Ben

[rickford66]

I was told long ago that an array will not be recreated if an operation on the array doesn't create a conflict... such as, going down two different branches and altering the array within each of them.

I've done the approach shown in my pic many times and so long as the array stays put in it's original memory location, it works fine.  I don't see how indexing the array twice would cause it to create a new array because I'm not changing anything in the array at that point.

[rickford66]

BTW, I tried using just one index and expanding it down.  It didn't change anything, but thanks for the tip.

[RavensFan]

---

@rickford66 wrote:

.  I don't see how indexing the array twice would cause it to create a new array because I'm not changing anything in the array at that point.

---

As I said, it may not be making a copy there.  Just because you've done that approach for a long time doesn't mean it can't be improved.  If anything, using a single expanded Index Array function will make your code look cleaner and you won't have an unnecessary wire branch and extra node on the block diagram.

EDIT:  Your next response came in while I was typing mine.

---

@rickford66 wrote:

BTW, I tried using just one index and expanding it down.  It didn't change anything, but thanks for the tip.

---

You're welcome.  I just feel the need to point that kind of thing out when I see it.  The worst cases are the ones where someone wants to break an array into something like 10 or 12 elements, so they branch the wire 10-12 times, use 10-12 index arrays, and then need to wire in constants from 0 to 11 on each one so they can get to each specific element.  One Index Array, and you don't even need the constants wired to the index input and you'll automatically get the elements in series starting at index 0 by default.

[RavensFan]

BTW, I tried using just one index and expanding it down.  It didn't change anything, but thanks for the tip.

[rickford66]

Ravens Fan, you are absolutely correct.  It is cleaner, and I changed it as you suggested.... that's why I said thanks for the tip.  I just was also stating that it didn't fix the problem.  I have double indexed as I had it shown in the pic, but more than anything, what I was meaning is that I've accessed arrays as shown, relying on them to stay put, and they always do.  I don't see what I'm doing wrong here.  I'll also admit that the problem may be in the code itself and the array is not moving at all... but I wanted to know how to test for the array being moved.

[Ben]

---

@rickford66 wrote:

I was told long ago that an array will not be recreated if an operation on the array doesn't create a conflict... such as, going down two different branches and altering the array within each of them.

I've done the approach shown in my pic many times and so long as the array stays put in it's original memory location, it works fine.  I don't see how indexing the array twice would cause it to create a new array because I'm not changing anything in the array at that point.

---

If the wire in the calling VI branches to feed this sub-VI then there will be a buffer copy since the sub_VI is changing it.

Ben

[rickford66]

No branch in the calling VI.  This VI is the only one that uses the array.

[Ben]

---

@rickford66 wrote:

No branch in the calling VI.  This VI is the only one that uses the array.

---

Then the only thing I can offer off-hand is to do what I outlined above so you can see if the buffer is being duplicated,

AND

review the Clear as Mud thread.

What makes you post this question?

An array of 40 values is hardly noticable.

Ben