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?
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.
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?
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.
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?
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.