LabVIEW
Fixed width spreadsheet string to array
Solved!
BowenM wrote:To this note, I plan on actually doing the loading inside of an "in place element structure" that uses a data value reference, and a message handler passing that reference in order to keep track of what is writing/reading the data when. This will be done with a producer-consumer state machine architecture.
(sorry, I was posting by phone earlier).
Maybe you could use a few more sentences to explain in more detail what you are trying to do.
What is the purpose of the message handler? Access to DVRs is already blocking and prevents concurrent access to the data.
I'm exploring a potential solution using the "scan from file" function, but knowing how your headers are formatted would be very helpful. Could you possibly post an example header (or even an entire dataset)?
Here's an example that bypasses loading the numeric values to strings as intermediaries. It accomodates an unknown number of columns of unknown widths, and an unknown number of rows.
It does have some limitations:
The columns must all be of the same width
The data file must have a separator between the header label and data of the form "--- "
It becomes inneficient with very large header files
The .vi is attached as well. Snippet is good for LabVIEW 2011 and the .vi is good for LabVIEW 2010.
As always:
Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms which can be found at: http://ni.com/samplecodelicense
I dont like the Read single character, it must be inefficient. Read the full first line and parse the text. Check the snippet, this'll give a list of column names and their offsets, so it doesn't even need to be the same width. Currently it doesn't allow spaces in column names.
/Y
Yamaeda,
Thanks for looking it over. While writing this, my biggest concern was the efficiency of reading in the actual data (since it's a significantly smaller portion of the file), but I may have had a touch of tunnel vision and wrote the code specifically for his example file. Looking back, there is definitely room for improvement in the parsing/processing of the header.
Another shortcoming I didn't take in to account is that with my code you can't use a hyphen in the text preceding the dividing row. By reading an entire line as you suggest, you could also check to make sure that the line only contains spaces and hyphens.
I haven't done extensive performance testing on this, but one more potential area for improvement that I didn't mention is parallelizing the nested "for" loops where the data is actually read in. This would likely increase memory usage slightly, but on a mutliple core machine may speed the process up significantly. I interpreted end goal as being more important to conserve memory than processing power, but if that's not the case it's definitely an area to explore.
I may end up doing some more thorough testing on this and then posting something along these lines to the code exchange. If so, I will definitely take your suggestions in to account.
