Text files, one line at a time

[pallen]

I'm probably overlooking something here. But I've tried this one a bunch of different ways and still can't quite get what I need.

I have a directory that contains a number of text files. Each text file is a single column of numbers. Some text files have an "X" in their name. Others have a "Y".

What I'm trying to do is pull the first row out of an "X" file and concatenate it with the first row out of a "Y" file. Output a concatenated string. Wait some time. Then get the next row of both "X" and "Y". Repeat until all points have been "sent".

I've tried this a number of different ways and keep running into stumbling blocks. Today I started looking at auto indexing For Loops. I'm pretty sure this is what I'm looking for. But I can't figure out how to make a subVI out of this mess and still be able to get a live "feed" from it.

Any ideas greatly appreciated.

Download File:post-247-1130971162.vi

[WMassey]

Are there always as many X files as there are Y files?

Are there always the same number of lines in any given pair of XY files?

In the VI you posted I don't see any concatenation going on.

If your intent is to just have this as a subVI that returns one X/Y pair (concatenated or not) each time it is called why not do just that and leave the timer stuff, if it is needed, to the calling VI.

If I have guessed the intent correctly, you could do it in a simple state machine. A first call to the machine would initialize it and subsequent calls would return an X/Y pair. If the files are not expected to be changing over the course of a run then the initialization state could read in all the file data and have it ready to spit out as pairs on subsequent calls.

[pallen]

Thanks for the reply.

I didn't include the section of code where I concatenate the results and add various commands because that part of things is pretty straightforward and working well.

The reason I've got the timers in there is that the X and Y data is being passed to hardware with a limited buffer size. The timers control the rate the data is being passed and this prevents the buffer from over flowing.

I am using the SDK (love it!) and did initially start off trying things that way. But I was hoping I could put the whole process into a neat little subVI.

[Mike Ashe]

The reason I've got the timers in there is that the X and Y data is being passed to hardware with a limited buffer size. The timers control the rate the data is being passed and this prevents the buffer from over flowing.

Since you are always passing XY pairs, there is no reason to have two separate loops and timers, do both in one loop, with one timer. Better, do it in a timed loop. The earlier comment about using a state machine is correct.

I am using the SDK (love it!) and did initially start off trying things that way. But I was hoping I could put the whole process into a neat little subVI.

What SDK are you talking about, the one for the HW? If there is any way to tell that the HW is done with the previous entry, you could then use that to fire an event for your state machine.

[WMassey]

I was a half-hour into a detailed reply to you when my browser crashed (due to something else going on on the machine). I figured that it would be simpler and almost as quick if I just showed you some sample code.

Since you didn't answer all the questions I asked in my 1st reply I had to make some assumptions. If they are wrong, you can adjust accordingly. This attached VI does depend on there being an equal number of similarly-names X/Y files and an equal number of lines in each file. I didn't have any of your data files to try it against so you are on your own for testing & debugging it.

I can see that you are relatively new to this LabVIEW stuff but you really do need to learn to use state machines. They are one of the BIGGEST hammers in the LabVIEW toolbox!

Download File:post-2800-1131035494.zip

[pallen]

Actually, when I wrote SDK I meant NI's State Diagram Toolkit.

There is a command that I can send to the hardware that will return the number of available buffer slots. I could monitor this to ensure that over fill the buffer. I was just going to try to get things working with a timer first, then modify if needed.

My state machine was working well, until I tried to start sending points from the second "set" of text files. For some reason I couldn't quite get that working, so I thought I'd try a different approach.

[pallen]

Sorry to hear about your lost post. I appreciate you taking the time to re-post after that. I can recall similar times when I've lost large amounts typing time, then being too frustrated to bother re-doing it. A result of this happening to me on more than one occasion has me now using a "compose" window in Thunderbird for nearly all my text writing.

Sorry for leaving out details in my last reply. The files are indeed similarly named and each "pair" of files has the same number of elements in it. (I've included a sample this time for anyone interested)

Thanks for attaching some code. It's always interesting to see how others (especially those with more experience than myself) approach a Labview program.

For some reason your VI only seems to be catching the first elements of the last "set" of files it reads. Perhaps I'm just missing something. In any case, it's given me much food for thought. Thanks.

Download File:post-247-1131038486.zip