Bytestream File Refnum issue

[MogaRaghu]

I am dynamically creating a file name using current date .

Once created, I open a file with the name. Since the code is in a timed loop, I open the file inside a case structure which fires only once. 

I pass on the File Refnum to a Write-To-Spreadsheet function to write data once every minute.

All the above works well on my Laptop. 

But when the code is loaded on the client machine( which has a LV12 Run Time Engine) , for every Spread Sheet Write, it pops up the File Dialog box asking for a file name. Obviously the ByteStream Refnum property node does not seem to work ?

I dont know what is different on the client machine. My Laptop is a WIN7/ 64 Bit system. Client machine is a WIN 7 / 32 Bit system. 

The relevant code is below :

[Dennis_Knutson]

Why don't you simply create an indicator for the path? I'm sure it's incorrect because of the building into an exe. Opening the file and getting a reference is not required. The Write to Spreadsheet will do that and you just set it to append. Correctly build a path and you can use a shift register to store it. Your code is much to convoluted with the local variables.

[MogaRaghu]

You wrote " it's incorrect because of the building into an EXE " I am not sure which is incorrect. It does work as EXE in my laptop. Please clarify ...

Never knew the Write to Spreadsheet function will open or create the file. Thanks.

[Dennis_Knutson]

Please look at the path, then. No idea from your image where the file is supposed to exist.

[Bob_Schor]

Somewhere, you have a loop that fires once a minute and includes the Write to Spreadsheet function.  Put the File Open/Create code outside (in front of) this loop so you demonstrably only do it once, you never do it inside the loop, and you use the File Refnum created outside the loop to save the data generated inside the loop.  When you exit the loop (having written all of the data), you can safely close the file.

Much simpler, logic is intuitive, no need for Case Statements, for (mis-used) Local Variables to guarantee opening the file once, etc.

Bob Schor

[Dennis_Knutson]

If you are going to create a new file once a day, you have to put it inside the loop. As long as it it is called once a day, that's perfectly fine. What you would never do is mix the file open/reference and the Write to Spreadsheet File. You would use Spreadsheet String to Array with a Write to Text File when using the reference so that the file only opens once.

[MogaRaghu]

---

@Bob_Schor wrote:

..... Put the File Open/Create code outside (in front of) this loop so you demonstrably only do it once, you never do it inside the loop, and you use the File Refnum created outside the loop to save the data generated inside the loop.  When you exit the loop (having written all of the data), you can safely close the file.

Much simpler, logic is intuitive, no need for Case Statements, for (mis-used) Local Variables to guarantee opening the file once, etc.

Bob Schor

---

What you wrote is generally what is done. But then exceptions exist - in my case there is no way I can generate the file name outside the 0.5 Sec Timed Loop. OK this was not obvious in my original post - but then my problem was different - the same EXE works fine on a laprtop on which it was built. But on  the client desktop, keeps asking for File Name for every write to the Spread Sheet. That I guess is still not answered..

( The image shows 5 instead 120 of logging. This is only for checking the logic ) 

[Dennis_Knutson]

You still have not done any basic troubleshooting. You still have not looked at the path being created. If it's not valid, you WILL be prompted for one. Basic stuff. It's your exe on your deployed computer.

[crossrulz]

1.  What is in that black subVI?  You are obviously generating a path in there.  What is that path?  Is it based on the VI location?

2.  File I/O inside of a timed loop?  That is just asking for trouble (missed cycles, late cycles, etc.).  Wait...Windows code?  Do not even bother with the timed loop.  It does nothing but add overhead and you gain little to nothing from it.  Just use a normal While loop with a Wait ms fuction.

3.  Since you appear to care about your timing (why else would you use a timed loop), then you really should use a Producer/Consumer to move your file I/O to another loop.  Further, you should not use the Write Spreadsheet File since it opens and closes the file each time it is called.  Instead, open and close the file only when you are changing files.  Write to the file with Write Text File.  If you dig into the Write To Spreadsheet File VI, you will see this being done.  Store your file reference in a shift register.

[MogaRaghu]

---

@crossrulz wrote:

1.  What is in that black subVI?  You are obviously generating a path in there.  What is that path?  Is it based on the VI location?

2.  File I/O inside of a timed loop?  That is just asking for trouble (missed cycles, late cycles, etc.).  Wait...Windows code?  Do not even bother with the timed loop.  It does nothing but add overhead and you gain little to nothing from it.  Just use a normal While loop with a Wait ms fuction.

3.  Since you appear to care about your timing (why else would you use a timed loop), then you really should use a Producer/Consumer to move your file I/O to another loop.  Further, you should not use the Write Spreadsheet File since it opens and closes the file each time it is called.  Instead, open and close the file only when you are changing files.  Write to the file with Write Text File.  If you dig into the Write To Spreadsheet File VI, you will see this being done.  Store your file reference in a shift register.

---

1. The Black Sub Vi just returns the current path based on the situation - whether in Design mode or Run time system.

2. File I/O inside a Timed is a true concern. But  then my acquistion rate is rather slow at once per minute. And the user needs the plot to reflect only once per hour intervals. So I thought its simpler to do what I did even if it means opening and closing the Spread Sheet file 1440 times a day. Not much ?? Anyway I do agree the overhead of the Timed Loop and have since changed to a simple while loop. 

3. The producer / consumer with Queues is something that I normally use for relatively fast data grabbing say at about 50ms rate. But here again i wanted to keep it simple since its a slow process. The following one is what i have got working and it seems to hold reasonably well for the intended purpose. 

Thanks for your time.