Built Executable not working same as vi

[rocksolidsr]

So I'm having an issue where the vi works correctly every time but when I build the vi into an executable it no longer works correctly and it seems to only happen when I'm trying to save to a network drive.

The basic operation of the vi is to create the start of a data log file and this vi builds the headers, when I set C:\ as my root everything works fine in the vi and the executable.  When I save to a mapped networked drive Q:\ everything works as expexted in the vi but in the executable after creatation of the file the executable just freezes.

Attached is my project, and help would be much appreciated

[Bob_Schor]

How frustrating!  You include a Zip file that includes a Project, but only a single VI is present, and all of the sub-VIs are missing!

What often happens when having File Paths go awry between Development and Run Time versions has to do with path locations and path constants, especially relative paths.  I was thinking that would be what I found in your code, and could make a helpful suggestion, but I can only say that you should look at all of your Path statements, how you build your paths, and take special care if you use relative paths.  I'd concentrate on the code you didn't post ...

Bob Schor

[rocksolidsr]

Sorry I didn't realize I had those two subVI's in there still.  I removed them and reuploaded the project.

[altenbach]

Wow, that code is pretty bad!*

In any case, it could be a firewall permission issue. You might have given LabVIEW access to the network, but the built application does not.

 *some comments:

• Greedy loop to set the initial path, which can never be changed afterwards during execution, even though the operator can still change it on the surface.
• Doing string operations on entire paths instead of using build/strip path primitives.
• Blatant overuse of value property nodes for no good reason.
• Unecessary sequence structure.
• The terminals of latch action buttons belong into their respective event case or they'll never reset.
• Pure Rube Goldberg code to create a new folder or whatever it is supposed to do. This runs in parallel to the code below it, so you might run into race conditions.

[rocksolidsr]

Thanks for the comments:

• Greedy loop to set the initial path, which can never be changed afterwards during execution, even though the operator can still change it on the surface.
  • I knew this was not good practice but this vi is part of a larger vi and I was trying to simulate how it worked on the larger vi.
• Doing string operations on entire paths instead of using build/strip path primitives.
  • Thanks for the tip, I've tried to make those changes
• Blatant overuse of value property nodes for no good reason.
  • Would  you suggest just wiring to where those property nodes are or using local variables?  Sometime a vi can get very busy with wires going everywhere?
• Unecessary sequence structure.
  • Removed, I put it in to test something, but as you pointed out unnecessary 
• The terminals of latch action buttons belong into their respective event case or they'll never reset.
  • Are you referring to the Continue and Cancel buttons?
• Pure Rube Goldberg code to create a new folder or whatever it is supposed to do. This runs in parallel to the code below it, so you might run into race conditions.
  • I am now using a create folder function in a sequence, does that seem better?

So even with those changes and turning off windows firewall, the executable is still hanging when the root directory is a network drive (i.e. Q:\).  What is interesting is even though the program hangs it is still creating the directory structure and file, and even more interesting is if I browse to where the file is located and just click once on the file the labview executable stops hanging and finishes its execution.

Any ideas!?

Thanks

[crossrulz]

---

@rocksolidsr wrote:

• Blatant overuse of value property nodes for no good reason.
  • Would  you suggest just wiring to where those property nodes are or using local variables?  Sometime a vi can get very busy with wires going everywhere?

---

Yes, you should use wires whenever possible.  If your diagrams are getting "busy", that is usually a sign that you need to modularize your code.  SubVIs and clusters are a good start to modularizing code.

[altenbach]

 Especially over the network, creating the folder might take longer so you run into race conditions. 

• Create the folder only if it does not exist
• Use the output path of "create folder" for the later code (instead of branching before) so you can guarantee that things happen in order and you don't need the sequence.

(EDIT: Sorry, I did not notice the sequence structure initially)

[rocksolidsr]

I tried as you suggested anyways but still same result, would it be possible for you to try this vi/executable to see if the error is repeatable or if I'm dealing with a network/server issue, although if it was a network/server issue I would expect the same error when using the vi, but the vi works fine. 😕

[altenbach]

So Q: is a network mounted drive? Does it work better for a plain network location ( e.g. \\machine\folder...).

Does it make a difference if you run the application as administrator?

[rocksolidsr]

The network is a mounted drive.  The executable has the same behavior with the full network location.  It does not make any difference if I run it as administrator, the executable still hangs, but the file is still created and when I single click on the file the executable no longer hangs and finishes execution.