LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with "Open/Create/Replace File.vi"

Solved!
Go to solution

problem vi.png

I have an odd problem that I cannot figure out, it seemingly is something related to the LabVIEW environment on one of my PCs.

 

I have a sub-vi (seen above) that performs a fit of data collected in a .txt file.

This sub-vi is a member of a larger project I have, but this "debug vi" is essentially independent of my main program.

 

In 64-bit LabVIEW on one of my PCs, whenever I try to open a file in the "File to Fit" browse window:

Untitled.jpg

All LabVIEW windows open will freeze and be unresponsive, attempting to end the process or trying to end the task in task manager is no avail, it eventually just close LabVIEW.

However, when I copy the code over to another PC and use 64-bit LabVIEW, I don't have this problem.

 

I have replaced the Open,Read,Close file vi's with just a string control, copy&pasted the .txt file into the control, and the sub-vi worked fine, meaning it is just a problem with the "open file" vi.

 

Any suggestions?

0 Kudos
Message 1 of 11
(4,229 Views)

What path is File to Fit trying to open?




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 2 of 11
(4,213 Views)

The issue occurs when I click on this button:

problem button.png

Or, if a remove the File to Fit control and just allow the "Open/Create/Replace File.vi to open the prompt automatically, it still freezes. However, if I put a valid path into the box and don't use "Browse" button or prompt, things work fine.

0 Kudos
Message 3 of 11
(4,209 Views)

I suspect LabVIEW is defaulting to an invalid path (usually the last saved/used path).

 

If you put a valid path in, then hit browse does that work?




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 4 of 11
(4,194 Views)

Seemingly that was the problem....

Thanks!

Message 5 of 11
(4,186 Views)

I have now put a valid path into the box and the same issue is occurring (this time on 32-bit LabVIEW). Any suggestions?

0 Kudos
Message 6 of 11
(4,134 Views)

Is it still only happening on the one computer? Or is it happening on multiple computers now?

Niki Budgell | Product Planner - SW Management | NI
0 Kudos
Message 7 of 11
(4,119 Views)

What if you hid the built-in "Browse" button for the control, and add a call to the "File dialog" Express VI from the advanced file functions palette?  Does that still crash?

0 Kudos
Message 8 of 11
(4,112 Views)
Solution
Accepted by topic author Gryffin

@Kyle97330 wrote:

What if you hid the built-in "Browse" button for the control, and add a call to the "File dialog" Express VI from the advanced file functions palette?  Does that still crash?


That calls internally the same FileDialog function so I would be surprised if it changes anything.

 

Have you tried to just wait a few minutes to see if it returns again after that?

 

The file dialog in LabVIEW can have an issue when you have shared network paths configured in your system that are not currently accessible. That used to be the case even for network printers that where not accessible, but I believe they fixed that in one of the last versions. Basically what happens is that LabVIEW calls the File Dialog in a way that makes Windows enumerate all the drives including shared network drives and if the network resource for such a drive or printer is not accessible the underlaying function only returns after the network timeout, which is easily a minute or more. Some of the Microsoft applications have the same problem, although they replaced the standard file dialog in many of them with a completely customized one, which behaves differently. The one in older Microsoft Visual C systems is pretty slow even when no invalid network paths are present, as it enumerates all the different user locations every time.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 11
(4,102 Views)

@rolfk wrote:

@Kyle97330 wrote:

What if you hid the built-in "Browse" button for the control, and add a call to the "File dialog" Express VI from the advanced file functions palette?  Does that still crash?


That calls internally the same FileDialog function so I would be surprised if it changes anything.

 

Have you tried to just wait a few minutes to see if it returns again after that?

 

The file dialog in LabVIEW can have an issue when you have shared network paths configured in your system that are not currently accessible. That used to be the case even for network printers that where not accessible, but I believe they fixed that in one of the last versions. Basically what happens is that LabVIEW calls the File Dialog in a way that makes Windows enumerate all the drives including shared network drives and if the network resource for such a drive or printer is not accessible the underlaying function only returns after the network timeout, which is easily a minute or more. Some of the Microsoft applications have the same problem, although they replaced the standard file dialog in many of them with a completely customized one, which behaves differently. The one in older Microsoft Visual C systems is pretty slow even when no invalid network paths are present, as it enumerates all the different user locations every time.

 


That was the issue. I have a remote drive that is only accessible if I am connected to my network via ethernet. With access, everything works fine. Without ethernet network connection, the open file dialogue will freeze.

Thanks for the assistance! 

Would be nice if a custom routine was written so that this wouldn't occur.....

0 Kudos
Message 10 of 11
(4,072 Views)