LabVIEW exe Generic file I/O error

[AdzyA]

Hello everyone, I have built a LabVIEW program where I'm using channel writer streams, the VI runs perfect, however, when I've built it into an exe I get the following error;

LabVIEW: (Hex 0x6) Generic file I/O error,

The file 'StreamData.lvclass' could not be loaded

I've tried changing my streams to high speed and lossy streams, deleting the build folder, renaming the application.exe but nothing has worked. Does anyone know a simple fix to this or will I have to re-write my entire code?

[crossrulz]

Another thing to try is to clear the Compiled Object Cache (Tools->Advanced->Clear Compiled Object Cache).  This will clear out where the object files are stored for LabVIEW to use for your VIs that have the "Separate From Compiled" enabled.  But it is also used for building executables and PPLs.

[AdzyA]

Unfortunately clearing the Compiled Object Cache did not fix the issue 😔. After rebuilding the VI I still have the issue, after clicking okay and trying to run the exe, this error message pops up;

Do you have any further suggestions?

[AdzyA]

I've also tried deleting all channel instances in; LabVIEW Data\2020(64-bit)\ExtraVILib\ChannelInstances, then rebuilding the VI, which didn't work.

Then I tried removing all channels from the VI, deleting all channel instances (in the folder above), copying it to a new project, then rebuilding the channels but even this did not work.

[mw42]

Maybe this is too late a suggestion for you, but I had the exact same problem and it seemed, that the path length (path to where the exe is stored plus the exe name itself) is not allowed to exceed a certain length.

When I named the program just "application.exe" and started it from "c:\temp" it ALWAYS worked. But when I put it in c:\Applications\Customer\MyNewVersion_v28\Customer_Version_v28.exe" it produced the error "Could not load ...Channel.lvclass".

Maybe this is helpful, I wanted to post about this here, maybe this is a known problem with Channel Wires?

[Mitty_Phonney]

I've been struggling with this same problem to for a little while. And simply moving the executable to a shorter file path folder indeed does do the trick.

Which is fine. Or it would have been if I was anywhere close the the path length character limit. But I wasn't. So I looked into it.

I found that the LabVIEW executable zips up the project VIs within itself. So the path to a main vi becomes path\to\application\application_name.exe\main.vi and the path to supporting vis becomes  path\to\application\application_name.exe\Support_VIs\support_1.vi. This is the ultimate path length limit. The path to the exe + the path to a file within the exe.

Which is still fine. Except. Even then I shouldn't have been hitting the limit of 260 characters. So looked into it a bit further.

So I looked at the file structure the exe actually built (I wish this was a lot easier) and the path to the main vi wasn't path\to\application\application_name.exe\main.vi. It was path\to\application\application_name.exe\path\to\application\main.vi. It had copied large parts of the file path to the project into the executable. 

That would do it. 

It defaulted the project root folder to be the equivalent of my documents folder.

And without being 100% sure of the next part, here's my guess.

The channel support files reside in the LabVIEW data folder in the documents folder. So the application builder decided that this was the root folder, that way it could reference the main.vi, other project VI's and the channel support files without "changing" the disk hierarchy. This added another 60 or so characters to the path length, which with a nested project folder structure and a long documents folder name pushed me, and my users, over the edge.

My solution to this problem so far has been to configure the build settings to move all dependencies into an easier to reach application_name.exe\dependencies folder. 

But if you're struggling with the same problem other measures to reduce the path length inside of the exe would probably also work.

- renaming files in build to be shorter

- not nesting support vi's within the project

- and, in case you're dealing with my specific variation of the problem, it's possible that simply placing the labview project itself in a shallower location would help. 

[mw42]

This is definitely an interesting observation. Thank you for your research on that topic. I will try that out.

[GrayyR]

You're right.
I got error #6 when creating an executable after adding "Channel Wires" (LabVIEW 2020) to the project. If channels are removed from the project, the executable file is built successfully.
I solved the problem like this: D:\TEMP\AppName.exe.

---

@Mitty_Phonney wrote:

- not nesting support vi's within the project

I don't understand, please explain.

[rolfk]

The application builder determines the common root folder of all sources in a project. This can be more or less your C:\ folder if you mix and match project files from your personal user document folder with files on some C:\Projects\MySuperProject. The paths in the exe file are then relative to that common root folder. It can only get slightly worse if you mix and match sources from different disk volumes as that will treat the disk letter as another hierarchy level, which is however only 2 characters.

There is one exception in this and that is for files located in one of the vi.lib, user.lib or instr.lib folders, which the application builder treats separately to try to reduce the chance for that problem. However at the time the Channels were added to LabVIEW two things had changed: Common computer wisdom had moved to the understanding that user files belonged into the user specific Documents folder (which in itself can be already quite long C:\Users\<more or less long user name>\Documents\LabVIEW Data\<version>/Channels" and the people who were intimate with those path handling issues in LabVIEW, long ago had moved on into other areas of work so that the application builder didn't get an additional special case dealing with user document files.