Named arrays

[jvh75021]

I have a deeply nested VI that now must handle multiple models of UUTs. Currently I have an array of setup strings which a for loop nicely iterates through sending each in turn to telnet. This array needs to change with the model number so I would like something analogous to a named array. Based on the suffix of the model number I would want to load a different array. I can think of four possible ways:

1) Create a subVI with a typedef that only contains the array, then use a case statement to determine which connector to use. This method would allow several arrays to be viewed and maintained side by side. Downside I am weak with controls.

2) Use a case statement and put a different array in each case.

3) Put all the setup strings (usually around 12-14) in a two dimensional array where one element of the array is the model suffix. Then parse the array and return only the strings with the right suffix.

4) Put all the string arrays in a text file array and use TestStand property loader to read them based on model suffix. Downside is passing string array through 6 layers of VIs.

What would a seasoned veteran do?

Thanks,

jvh

(the non-veteran, who surprised himself by thinking of four ways, the last while typing the post)

[RavensFan]

I would set it up as a action engine or functional global variable.  That way you can access the data at whatever level of subVI you want.

It would be basically be like your option 1 and 2.  Your subVI would have 3 inputs and 1 output.  The 3 inputs being an enum for Get and Set, an enum for which array it is you want to Get or Set, and an array input so that you can set the selected array.  The output is an array so that you just return whichever array you want to Get (or have just Set).

[Dennis_Knutson]

What I would do is store the different settings in a database have a column specifying model name/type. I prefer to do everything in TestStand but you can certainly do it at whatever level you want.

It might be time to revisit the architecture of the LabVIEW code. This was mentioned in another thread of yours. Six layers of subVIs seems a bit excessive. It sounds like you are going to have to pass at least some information (model number) a long ways down. If the original code used an array constant, that was probably a mistake in the original design.

[jvh75021]

Thanks for the post, your idea reminds me that I didn't specify the problem completely. The arrays as currently designed are loaded when created so there is no need for the load option so I think we're down 1 one input. 

Could you tell me a bit more about the functional global idea?

Thanks again,

jvh

(who fears he may never be worthy of the Collective)

[RavensFan]

I would search the forums for either the terms "functional global variable" "LV2 style variable" and "action engine"

Also look at Ben's Action Engine Nugget

[Dennis_Knutson]

Created where? Inside the step, in a previous step? Do you reate multiple arrays or just one array that is specific to the model that is currently being tested?

What do you need to know about functional globals? What idea? Frankly, I think that passing the data directly through the connector pane is the best way. If you used the default connector pane, it has 12 connections and should not be that difficult to implement.

[jvh75021]

The current VI has two string arrays that were populated when the VI was edited or created. Since there are now only 2 models a selector function controls which one is sourced. Since we now have many models these 2 arrays will be placed in a subVI wherein there is a case for each array and more arrays will added and populated with their constant values when placed. The new VI will have four terminals, model in, array out, error in, and error out.

Regarding functional globals, just wanted some concept material which another post has provided.

thanks,

jvh

[Dennis_Knutson]

Well, that's not at all the approach I would take. I would avoid anything that might require ever again editing the VI. I would actually use TestStand to get the array (from database, ini file, whatever) and pass the array to the VI. You could also do something similar in the VI. In any case, all you would do in the future is add new information to the database.ini file keyed with the model number. No adding another case to the VI - no doing anything at all to the VI.

[jvh75021]

Sorry to disappoint you but this relates to my thread of yesterday about not wanting to plumb in new objects through 6 layers of VIs. A lot of these arrays already exist, if I were designing it from scratch and using more TS and less VI layers I would certainly use the TS property loader as I have in other cases. 

I would really like to make it right but as it is I just live with it. I had a pair of certified NI instructors look at my inheritance and they thought they could clean it up and make it maintainable in about 8 - 10 man-weeks. No such budget allowances are available since the company already threw $80K+ at it with a contractor before I was drafted to maintain it. My orders are to upgrade and repair, not redesign. As we all know there is always time to do it over but never enough to do it right the first time.

 I was drafted because I said I might like to learn TestStand and LabWindows, somehow that got turned into LabView. You'd think someone 56 years old would know when to keep their mouth shut. But as is self-evident, I am a slow learner.

jvh

[Dennis_Knutson]

Well, I know that I could modify six layers of VIs to pass an object from TestStand in an hour or two but you still don't have to do that. You could still use the global aprroach in the lowest level VI to do a query based on the model number. It all depends on how many times you want to edit the same VI.

You asked how a seasoned veteran would do it. I've got 12 years of TestStand and 20 of LabVIEW (and I'm older than you).