How do you initialize a large number of variables neatly

[DianeS · Accepted solution]

If I understand you correctly, when you say "pull the typedef onto the block diagram", you mean create a constant of it?  Yes, you'll see a cluster of all the variables with their default values.  If you have a lot of variables, that cluster gets pretty big and looks kind of ugly.

To the best of my knowledge, there is no way to fix that directly.  What you can do, though, is stick your cluster constant inside a sub-VI, and use the output of that sub-VI to attach to the wire leading into your state machine.  Yes, I know it's a bit of a hack, but I do find that it comes in useful for setting initialization values of the cluster and keeping the block diagram looking nice and tidy.  I always make a nice little icon that says "Initialize data cluster" so that I (and others) know what's going on in there.

It's an idea, anyway...

d

[Hummer1]

Thanks all.  these are really good ideas.  I may actually try a mix of the two suggestions, by creating the class and then using the sub.vi to access everything and put it on a cluster wire for access by the main vi...that will let me bundle and unbundle by name conveniently...too bad there is not a bundle/unbundle several elements function for class elements ... that would be helpful.

Back to work.

Thanks a bundle...

Hummer 1

[hecmar.arreola]

You can make your own data accessor that bundles/unbundles all the data for you.  But it has to be wrapped up in a VI that is part of the class library.

Even then, I'd probably set up individual accessors for each field, and then use them in another VI to read/write bulk data.

It does seem like extra work, but NI did it this way to enforce high coding standards.  The bennefit of going about these things in this particular way are not apparent at first...but when you come back and need to revise your code you start to see the payoffs.  For instance, if you decide to change the way a particular field is stored (say it was a double and needs to be a string for some odd reason), all you need to do is change your accessor VI.  All your top level VIs access the data through accessor VIs, so you do not need to change them to account for a string vs a double.

Message Edited by Nickerbocker on 02-03-2010 12:50 PM

[Hummer1]

Thanks...I'm having a hard time getting my head around the accessor...positionof the vi in the class library ... private ... thing. 

Let me chomp around on it for a while and see what happens.

Thanks

(ps...I'm rewriting a bunch of my old event only code in the form of a state machine with events, states and error handeling...This is such a long way from the original code I wanted to try to make the I/O initialization cleaner too and these tips look like the way to do it...)

Thanks for your patience.

Hummer 1

[paulmw]

Check out this proposed idea here and see if it is similar to what you are asking for...

[Hummer1]

Yes....that would be perfect...

!!!!

Hummer 1

[Hummer1]

There seems to be a problem putting 2d arrays in the type def and building the accessor for them.  Is that a known problem?

Attempt to add 2d array, create accessor, try to save control type def and can't (get repeated error messages which can't be read because they flash behind the "you must save the changes to the type def to close...owthe)...ultimately have to remove the array...

I guess I'm back to the init sub.vi idea...reading from disk...and not using any of the type def stuff for variables...just bundeling them out of the init sub.vi.

Thanks.

Hummer 1

[hecmar.arreola]

I'm not sure I understand the problem.  Are you putting a 2d array in a type def or in a class?  Accessor is a term that relates to Class Private Data, not Type Defs.

As for the bug you see, I am not seeing it on my end.  If I make a class, and place a 2d array of double values in my Class Private Data the accessors generate just fine.  I was able to make an accessor for the full array, and for individual elements.  (I really like the individual element accessors...if ever you have done this with unbundling/bundling clusters it is a bit of a hassle.  With individual element accessors NI does all the nitty-gritty array work for you).

What version of LabVIEW are you using?   If it is LV 2009, have you installed the f2 patch?

Message Edited by Nickerbocker on 02-04-2010 01:47 PM

[Ben]

After adding stuff to the private clas data, the class should be saved before trying to create the accessor.  THis lets LV know what is in the private data before trying to create code to access data in it.

I really like the Class of constants idea becuase prvate data will retain its default values (unlike the normal cluster). Since the constant are constant there is no need to pass the class wire and the accessor can just read the default data so.... Toss the class terminals and error clusers... edit the icon and you can now create your own library of constants. Attached you will find a zip of a project that utilizes this idea to read the constant "Three". Here is a screen-shot of the code with the constant in use.

 

Ben

[Hummer1]

Sounds like I need to learn another level here.  I'll look at that and see where it takes me.  I was able to do the accessor on a simple thing and then ran into trouble when I tried to "load up" the class with more variables,  Since it went astray (due to an error on my part I'm sure) I "satisficed" by using the sub.vi idea.  However, as time permits, I would like to continue to explore this class/accessor thing some.

Thanks

Hummer1