binary files and stand alone builds

[mikeporter]

You need to show us some code. If there are really no errors (as opposed to errors you just aren't reporting) the write routine isn't being run.

Mike ...

[Dboucher]

here is a cropped section of the initialization routine. The two binary files required are the Alarms and Signals files. They are created and initialized as null files for later reads and writes.

[mikeporter]

How do you know there are no errors? You don't have any of the error clusters connected.

Mike...

[crossrulz]

1. Wire up your error wires so that you can actually detect errors.

2. You are using "Current VI's Path".  Use "Application Directory" instead.  That will also eliminate the need for that Strip Path.

Curreent VI's Path is useful for dynamically calling VIs since the relative path to VIs never changes when you go to an executable.  For external files, you have to use Application Directory as it returns a path to the folder containing the project file (in development) or the executable (in runtime).

[Bob_Schor]

... and I would say that, given your problems, it makes much more sense to specify the initial folder, either by wiring in a Path Constant (which won't change between Development and Execution modes) or by getting the User to (at run time) specify a folder (and thereby have the ability to use the same folder in the two environments).

     It would seem to be a logical thing for you to have done to include an Indicator with the Path you are using for the Folder (and/or for the File+Folder).  If they are the same (which I really doubt), then you really do have a puzzle.  However, if they are different, then you need to ask why you can't write in the case where no output is produced.  The answer is almost certainly because you are generating an Error in one of the File I/O VIs -- too bad you are not making use of the Error lines, you might have figured this out yourself by now ...

Bob Schor

[johnbt29]

Dboucher,

As you said that the null files are created initially for future Reads and Writes.

I think the problem is that,

Consider the VI resides in C:\FOLDER\Test.vi

In Development Mode:

1. Current VI's Path will return "C:\FOLDER\Test.vi"

2. stripping the path will give you the location of the folder "C:\FOLDER\"

In Executable Mode:

1. Current VI's Path will return "C:\FOLDER\Application.exe\Test.vi

2. stripping the path will give you the location of the folder "C:\FOLDER\Application.exe"

Solution: Double strip the Path in Exe Mode to avoid the error.

[natasftw]

---

@John1981 wrote:
 

Solution: Double strip the Path in Exe Mode to avoid the error.

---

Wouldn't an easier solution be to use the Application Directory constant instead of the VI constant as several others have mentioned?

[mikeporter]

The problem with double stripping the path is that it won't always work. Depending on how you have your code organized on disk the virtual path inside the executable can vary wildly.

Mike...

[Bob_Schor]

My method will always work.  And if it doesn't (ha!), then wiring the Error lines and reporting both the Error and the actual path being used (as I suggested) will provide more insight than random (untested) suggestions (even if they are, in fact, correct -- measure and get the facts!).

BS

[crossrulz]

---

@John1981 wrote:

Solution: Double strip the Path in Exe Mode to avoid the error.

---

There are two conditions where this will work:

1. Your VI is actually in the top level directory

2. Your EXE is using the 8.X style.

Starting with LabVIEW 2009, the executable actually keeps the relative directory structure of your VIs intact.  So the exeuctable is not flat in structure like the 8.X style.

So my rules for relative file paths (which you should be using nearly all the time):

1. For dynamic VI calls, use Current VI's Path and then use Strip Path once to get its folder.

2. For external files, use Application Directory

With those folders, you can use Build Path to get to the location you want.

The beauty of this setup is that you do not care if you are in the Development or the Executable.  It works in both.