Clearing arrays and clusters automatically

[RTSLVU]

I am not sure how to explain this but I have a vi that reads a spreadsheet to setup two data loggers. 

The problem I am having during development is every time I run the program it reads the config file and the arrays, clusters, and therefore strings I write to the instrument keep growing and growing and growing.

How do I make it clear the arrays or reset everything to the default value "empty array" each time I run the vi?

I do not think I can use the Initialize Array function because I do not know exactly how big the arrays will be.

I guess that could work for the string arrays as I can initialize an empty string but what about numeric arrays?

I have attached the vi and a sample config file so you can see what I have tried

[RavensFan]

Thers is A LOT of code there that is repetitive and should be handled as subVI's.  Proper use of arrays could minimize the controls as well.  Along with the proper use of shift registers, you shouldn't need those hundreds of local variables along with indicators that are hidden on the front panel whose only purpose seems to be to hold data.

But to answer your question, if you want an empty array, all you have to do is create an array constant (right click on a wire of the correct array type and select Create Constant).  Then wire the empty array constant that is created into whatever code you are trying to use it with.

[altenbach]

Make sure to globally initialize your feedback nodes with empty arrays.

(btw: your VI contains about 100x too much code and is a prime candidate for a honorary mention in our Rube Goldberg thread. Get rid of the property nodes, stacked sequence structures, duplicate code, and local variables ... and things will improve. 😉 Also don't use controls and indicators with the same name (e.g. "Logger configs".)

(sorry, I am currently traveling and don't have time to rewrite your code in a reasonable way...)

[smercurio_fc]

I think Ray would have a mild coronary looking at that VI.

I agree that your VI has massive scaling problems. meaning that it doesn't scale well. 

Other comments:

•  
  • Learn to use the Build Path and Strip Path functions. As I pointed out here, it is not good programming to build paths using strings. For instance:
    
• You also have a lot of repetition within your loops. For instance, in frame 1 you index out column 0 of the 2D array inside each loop. Instead, index it out once, and use it multiple times. 
• Use the Spreadsheet String to Array rather than loops to convert your strings to arrays.

Message Edited by smercurio_fc on 04-13-2009 01:22 PM

[RTSLVU]

---

smercurio_fc wrote:

I think Ray would have a mild coronary looking at that VI.

I agree that your VI has massive scaling problems. meaning that it doesn't scale well. 

Other comments:

•  
  • Learn to use the Build Path and Strip Path functions. As I pointed out here, it is not good programming to build paths using strings. For instance:
    
• You also have a lot of repetition within your loops. For instance, in frame 1 you index out column 0 of the 2D array inside each loop. Instead, index it out once, and use it multiple times. 
• Use the Spreadsheet String to Array rather than loops to convert your strings to arrays.

Message Edited by smercurio_fc on 04-13-2009 01:22 PM

---

I think the "Current VI's Path" Issue was why I quit doing it that way and started using strings...

Obvously I really could use some help on the main issue of how to read the config file and generate the strings I need to send to the insturments.

I have attached the vi that works with this one to create the strings I need. 

[JÞB]

RSTLVU

What they are trying to tell you is that you have MUCH BIGGER problems than a few hundred uninitiallized shift registers. (BTW the feedback nodes are holding the data previously assigned to them until the vi is removed from memory- and you keep adding more elements to them every time you run )

Each device needs to be initialized in about the same manner.  this should suggest to you that a sub.vi "Init DL.vi" would be reasonable.  It Didn't

Each of your clusters has the same elements (off by an assigned numeric in the name)  this should suggest to you that an array of clusters would be reasonable.  It didn't.  The spreadsheet is awful and should never be confused with an appropriate "configuration file".  however, I would be using an XML file for this much information just to enable it to be readable.  

Once yo fix your data structure, you can go back through the other good ideas that were posted and, for gosh sakes, start having fun coding in LabVIEW! We all learned somehow!

[RTSLVU]

What they are trying to tell you is that you have MUCH BIGGER problems than a few hundred uninitiallized shift registers. (BTW the feedback nodes are holding the data previously assigned to them until the vi is removed from memory- and you keep adding more elements to them every time you run )

That was the explanation I was looking for, at least now I know why it was happening.

Each device needs to be initialized in about the same manner.  this should suggest to you that a sub.vi "Init DL.vi" would be reasonable.  It Didn't

Believe it or not this was the beginning of a sub-vi "init-logger.vi" sub-vi of a much larger program. I wanted to make it easy to change the data logger configurations instead of just hard coding the channel functions like I normally do. 

Each of your clusters has the same elements (off by an assigned numeric in the name)  this should suggest to you that an array of clusters would be reasonable.  It didn't. 

This is my first attempt at using clusters at all to be honest. Obviously I am doing something wrong as the clusters seem unwieldy and over complicated at this point.

The spreadsheet is awful and should never be confused with an appropriate "configuration file".  however, I would be using an XML file for this much information just to enable it to be readable.  

I wanted to be able to use a program everyone has (Excel) to change the file as I was also going to have test parameters, email addresses as well in the one file.

I know nothing about XML files. How are they created and modified?

Once you fix your data structure, you can go back through the other good ideas that were posted and, for gosh sakes, start having fun coding in LabVIEW! We all learned somehow!

I hope I can recover from this, I wasted a lot of time here

[JÞB]

Its certainly recoverable.  And yes, sometimes we waste time learning new things (there is good reason to troll this board now and then)

As an example- When I first met LabVIEW I actually thought it was a great idea to ask my employer to provide me with the LARGEST MONITOR they could find.  Worse- the boss thought it was a great idea and bought me a huge monitor.   Some of the code I developed under that theory still scrolls through my nightmares! 

Don't be afraid to browse for a good book on LabVIEW basics- and read it!  you don't have time to make all the mistakes yourself.

Good luck

[smercurio_fc]

If I were doing this I would change the structure of the data as the program holds it to make it more flexible. Jeff already alluded to this. For instance, consider this structure:

 

This gives it a more hierachical structure and it greatly benefits from allowing you to use arrays to easily scale your program. For example, let's say you want to add a measurement type. Nothing to change. The data structure already takes that into account. A simple subVI can be used to parse out each section into the structure. Attached is an example (note that the clusters should be typedefs - I did not go that far) of your VI modified to use this structure. As you can see, I do the same thing you were doing in less than 1/10 of the code, and I have the added benefit of a flexible structure. I am not telling you to do it this way, but this is to show you a different approach. It's possible that this may not work too well for what you're doing in the larger program, but it should give you an idea of how to think more hierarchical using arrays and clusters.

As for the file format: A different file format would make the parsing a little easier, but it's not mandatory. If I were to choose a different file format I would use a standard .ini file format so that each section can be extract directly with the "Chan", "Label" being keys, or I would use an XML file format since the XML file would give me the structure directly. With XML you define your own file format. You can start here for a general introduction to XML. LabVIEW has some built-in XML tools, and you can also use LabXML or Easy XML from JKI.

Message Edited by smercurio_fc on 04-13-2009 05:15 PM

[RTSLVU]

OMG!