Read from text file vi won't read file...

[Mr._Jim]

Hi Kiauma,

Did you have any success yet?

If not...

So just to confirm, is it only happening while compiled as an executable?

As far as the read routine goes, have you looked at the string coming directly out of the file read function? (Not after the parsing?)  Is that string blank, meaning that nothing's being read from the file?  If the trouble only occurs inside the executable, you could add a "debugging" indicator on the front panel of your top level VI or you could use the one button dialog to pop up a message containing the string.  (There are other methods, but these are easy ones) Otherwise, if it occurs in the development environment you could probe that string as usual.

If the string coming directly from the file read function is showing the file contents, then the trouble has to be with the parser.  It's really easy for the "match pattern" function to return an empty string if everything isn't just right.

-OR-

If that string is empty, it means that the file IO isn't working which would most likely point to a path issue.

Also, have you tried isolating the part of the code that's giving you trouble?  Removing it from the rest of the code should make debugging a lot easier.  If it's only causing trouble as an executable, you could try making a "debug" executable that only contains the file read and parse routine.

For what it's worth,

Jim

Message Edited by Mr. Jim on 12-02-2009 08:45 AM

[Kiauma · Accepted solution]

Hello Jim,

First of all I want to thank you for all your thoughtful and helpful posts.  It is always nice to find a truly helpful person, especially in a professional capacity!

As to the problem, after sleeping on this it occurred to me that the only difference between this part of the program and the other parts of the program that worked fine was that the read and write to text file VI's were both called in it.   Looking at my diagram, it was apparent that both VI's were also being given the path and filename at virtually the same time.  Though in theory it shouldn't matter because of data flow, it occurred to me that as small as the program was, and the fact that both VI's being given the file path and name at the same time, perhaps the read and write to text file VI's were interfering with each other somehow.

As an experiment I added a tiny bit of code using a conditional comparator that steered the file name '0000.txt' to the write to text file VI until a 'count string characters' returned a count from the read from text file VI that was greater than zero, which then steered the correct filename to the write to text file VI.    This prevents the write to text file VI from getting the same file name until the read from text file VI has already read the file.   I built it, and it works fine.   Problem solved.

But thanks anyway - I was hoping I wasn't just doing something stupid, and you helped me to count that out - this time.  😉

[Mr._Jim]

Great to hear that you figured it out!  "Race conditions" are notoriously difficult to troubleshoot, so don't feel too badly.

It sounds like your method works fine, but as long as I'm replying I should probably point out that this is a textbook case in which a semaphore would come in handy.  If you're not familiar with them, semaphores are useful for instances in which you've got a single resource that you need to share with several parts of your code.  It's a way of ensuring that only one part of the code can manipulate the resource at a given time.  There's a pallet dedicated to semaphores located under "synchronization".  There's also a semaphore example under the example finder that illustrates the concept better than I could probably explain it.

Just thought I'd throw that out there... if you already know about semaphores then feel free to ignore my free advice.

Take care,

Jim

[Yamaeda]

You gotta love those timing issues, they are quite problematic to find. 🙂

/Y

[Kiauma]

It sounds indeed like using semaphores might have avoided this problem altogether - thanks again Mr Jim!