Shift register equivalent for updating elements in a cluster in an array in a cluster in an array?

[abvenk]

Hi all,

I'm using LabVIEW 2016. I have this complex structure in an array of clusters:

Top level - array

Second level - cluster

Third level - array

Fourth level - cluster

Fifth level - numeric (double) elements

(Don't ask me why this is so complex, I inherited the code, and I'm trying to work with it).

Now, in my program, I want to update the numeric elements for, say 30 seconds, as new values come in every second. At the end of 30 seconds, I want to output the juggernaut array of clusters. Obviously, each cluster of numeric elements is unique, so I have to update those specific elements within the specific cluster, at the specific array index, within the specific cluster, at the specific array index.

So it's not an easy case of using shift registers to hold the values through multiple iterations. I even tried a 3D array, but I still don't have the code right. Is there a different way of doing this? I would appreciate any help!

[altenbach]

Please attach a simplified version of your code, at least containing the data structures. All you probably need is a single shift register containing the toplelel array and a pyramid of "in place element" structures.

[abvenk]

Hi altenbach,

Attached is a simplified version of my subVI. This is my latest attempt. I'm using a copy of the incoming array and trying to update the elements in the copy each time a new array comes in. It doesn't really work as intended. And, of course in my original code, the clusters are all typedefs.

[altenbach · Accepted solution]

Maybe you want to keep the current values in a feedback node, replacing the array constant with one element that limits the outer iteration to one.

Maybe something like this? (assuming that the outer array size remains constant).

Also note that much of your code could be replaced by min&max and IPEs. Also note that since you replace all elements of the outer cluster, there is no need for your bottom code where you feed many things across unchanged.

This is probably not quite right, but will hopefully give you some ideas....

[abvenk]

Hmm... I've never used a feedback node. Looks interesting. I'll try it out and let you know. Thanks!

[abvenk]

So I kept the 2 FOR loops with IPEs the same, but on the suggestion of another LabVIEW programmer, I did use shift registers on the outside in place of the feedback node.

Thank you!   

[JÞB]

And now you know.....

Why not go all "Paul Harvey" ?

That "Code Smell" is known as a "God object"

Drat, there are at least 3 good Google search links in this I cannot link via an Android .

...The rest of the story.

[altenbach]

---

@abvenk wrote:

... but on the suggestion of another LabVIEW programmer, I did use shift registers on the outside in place of the feedback node.

---

My advice: Never listen to "another LabVIEW programmer". Who is it? What are his qualifications?:o

For example there is no "globally initialized" shift register unless you add more code to work around that limitation. A shift register also needs a dummy loop as a scaffold. These are some of the reasons I suggested the feedback node here. Keeps it simple! 😄

Can we see your final code?

[abvenk]

Haha you're funny

Here's the final version. I have 2 cases "Collect" as you see below, and "Send" where I initialize the shift register to a null array, and connect the input shift register to the indicator.

[altenbach]

That's just a truncated image with little information content. How about the actual VI?

Some observations:

• There is no reason to auto-index the error wire at each loop output and merge it immediately. Since the error is not even used inside the loops, it can remain completely outside.
• Shouldn't the shift register be initialized, e.g. with an empty array?
• Why do you even need to process the loops if the little case is TRUE?