LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Better way to unbundle array of clusters of array of clusters?

Solved!
Go to solution

What I have been doing works just fine but I have this feeling that when I'm not looking someone is going to post it for the Rube Goldburg award. I have convinced myself there has to be a better way to access buried cluster controls inside arrays?

 

 

As you can imagine not only do I have to unbundle these things i need to rebundle them with the new data / changed data. I like the current data structure because it prevents me from having the same data in multiple places.

 

What I have is an array of configuration information which contains config controls, inside that is an array of panel information which contains panel specifics, there is a 3rd array that contains the actual trace data for each panel. This is a great data structure but accessing the elements is no fun 😞 Note that I have simplified that number of controls for this post; the full version still uses 3 arrays but a few dozen controls.

 

Any comments that can point me in a better direction would be welcome.

 

-Chris <-- Taking on larger projects and feeling the pain.

 

 

 

0 Kudos
Message 1 of 9
(6,205 Views)

No, that's about the only way I can see to get to that part of your cluster.  You have a pretty complicated cluster that looks like it is about 6 or 7 levels deep.  Array , cluster, array, cluster, array, cluster, element.

 

The only thing that might be a Rube Goldberg is whether your data structure needs to be that complicated, particularly when 3 of those levels are arrays.

0 Kudos
Message 2 of 9
(6,198 Views)

An Idea was proposed on the Idea Exchange to make "deep access" have a cleaner syntax. Refer to Aristos Queue's 5th comment about the possibility of refactoring data structures, perhaps using LabVIEW classes' inheritance feature. 

Message 3 of 9
(6,172 Views)

I also agree that the data structure should be questioned. A nested cluster/array structure is very bad considering performance. Today you don't realize this, but I was taught that on an old PC where I had hit a nesting depth where I couldn't edit(!) the data structure.

Since then I try to keep my data flat by sperating array and cluster content. So in the top cluster, there are some nested clusters and a cluster with all the arrays.

But I wouldn't do a refactoring if the task (physical world) is represented better by the data structure.

 

Felix

Message 4 of 9
(6,159 Views)

I've never had to deal with such a complicated structure in LabVIEW. It is clear I'm going to have to break this structure up; I just can't tolerate how complicated drilling down inside has become.

 

Last night I think I may have figured out how to elminate two levels which will dramatically reduce confusion.

 

I've also thought of using a database to hold my configuration / test data sessions. Seems like simple inserts would be sooooooo much easier and pulling the data back to build the report would be much easier because of inner / outer joins. Maybe I'm dreaming?

 

-Chris <-- Grabbing a beer and setteling in to read some more posts on this message board.

 

 

0 Kudos
Message 5 of 9
(6,146 Views)

Feel free to post a .PNG of the typedef'd cluster (with all labels showing) and a description of the physical system, and you could get a second set of eyes to help reorganize the data structure.

Message 6 of 9
(6,142 Views)
Solution
Accepted by topic author F1_Fan

I'm thinking the overall system data could be modularized.  It looks like yu have 1 "God File" that saves everything for every subsystem.  Your "God File" could offer sections for dependant module's config locations and pass that (the file name) to the modules that really need the data and will act on it.  Your srceen shot suggests (vaguely) that your archetecture sacrifices modularity by over coupling information that is not strongly related


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 9
(6,136 Views)

Our of pure frustration I took what I consider an old-school method to come to a solution. 

 

I wrote out the contents of every cluster, array, and array-cluster on graph paper; made 20 copies and started drawing lines to come to grips with the relationships. It took a few hours but I was able to rid myself of 3-layers and moved the arrays outside of the main cluster. I now have a nice clean group of data structures that are at most two layers deep and MUCH MUCH easier to work with. Also was able to take full advantage of auto-indexing and eliminate a few indexes I was using to control loops. 

 

IMHO my biggest mistake was not paying enough attention to what needed to be kept run-to-run vs session to session. I was taking a save-everything approach which was resulting in a disaster due to poorly planned structures. 

 

The posts in this thread really pushed me to take a solid look at my structures; something I perhaps am a bit weak at. I hope in the future I can repay with similar solid advice. 

 

-Chris 

Message 8 of 9
(6,057 Views)

Very good.  I'm glad to hear that you decided to go back and look over your data structure again.

 

I think that is a lesson for others who may have the same problem.

 

If something is getting too complicated to work with, it might be time to take a few steps back, look at the big picture, and look for ways to simplify and improve what you are doing.

 

It may have taken you a few hours to do this task, but I bet it saved you far more time in the long run by not continuing on with an unwieldy data structure.

Message 9 of 9
(6,034 Views)