01-17-2019 08:50 PM
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:
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?
Solved! Go to Solution.
01-17-2019 09:23 PM
What path is File to Fit trying to open?
01-17-2019 09:26 PM
The issue occurs when I click on this button:
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.
01-17-2019 09:47 PM
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?
01-17-2019 09:50 PM
Seemingly that was the problem....
Thanks!
01-22-2019 10:33 AM
I have now put a valid path into the box and the same issue is occurring (this time on 32-bit LabVIEW). Any suggestions?
01-23-2019 05:32 PM
Is it still only happening on the one computer? Or is it happening on multiple computers now?
01-23-2019 06:07 PM
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?
01-24-2019 04:41 AM
@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.
01-28-2019 10:48 AM
@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.....