LabView Executable can't find *.lvclass

[StaLor]

Hello community,

I recently upgraded from "LabView 13 SP1" to "LabView 2023 Q3"

After fixing all the broken vi's i was able to run my application without a problem in the development environment.

When i build an executable the build finishes without any errors or warnings.

When i try to run the *.exe on the same PC i get a prompt, asking me to locate the *.lvclass and afterwards the following error:

Error 7 occured at Get LV Class Default Value.vi

Possible reason(s):

LabVIEW: (Hex 0x7) Datei nicht gefunden. Die Datei befindet sich evtl. an einem anderen Speicherort oder wurde gelöscht. Verifizieren Sie in der Befehlszeile oder im Datei-Explorer, dass der Pfad korrekt ist.
=========================
GPIB-Schnittstelle existiert nicht.

Complete call chain:
Get LV Class Default Value.vi
Motor.lvclass:Load_Classes.vi
Motor_Init_Class.vi
MotorGUI.vi
GUI.vi

LabVIEW attempted to load the class at this path:
C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\Lib\Motor\Classes\ELMO\ELMO.lvclass

This is just the first of many similar error messages, all telling me that it failed to locate the *.lvclass files.

All of this has worked previously in Labview 13 and also LabView 20.

All of my *.lvclass files are in the "Always included" section and their destination is set to the executable (My_Wonderful_Application.exe)

The length of the path is less than 100 characters for all of the files involved. The paths have not changed when i switched to LabView 2023 Q3.

I have 18 different classes in my project, 3 parent classes and 15 child classes that inherit from them.

I have built other applications (that include the same classes) from the same project with the same outcome

What i have tried so far:

1) I have tried to exclude and include all of my files in the builder

2) I have tried to reinstall LabView 2023 Q3

3) I have put constants of all my classes in my code like this

4) I made a new build from scratch, copying my original build

5) I created a new class, that also failed to load when running the .exe

6) I have "played around" with the options in the application builder

7) I have created a new project and copied my classes to this project, same problem

😎 I have created a new project and added a couple blank classes with different inheritances and this worked

So i don't think there is something inherently wrong with my machine or the LabView installation, instead it seems to me that my project and/or classes are broken in some way that i can't seem to fix.

Another weird thing that happens since the switch to LabView 2023 Q3 is, that it claims to use one of my .dll everytime after i build the application and i have to close LabView to be able to delete the file and make a new build in the same folder. I'm not sure if this is important, but it appeared at the same time.

Thanks in advance to anyone trying to help 😄

StaLor

[Kyle97330]

---

@StaLor wrote:

3) I have put constants of all my classes in my code like this

6) I have "played around" with the options in the application builder

For #3, there is something in LabVIEW where it optimizes your code to not include things that will never run.  As such, anything in the True case of a False constant may never make it into a build.

Try just removing the case statement... class constants are harmless to have on a block diagram if not connected.  When I do it I wire up the class constants to the edge of a nearby structure just so they don't show up as "unused code" in VI analyzer checks, but even that isn't necessary.  Just get rid of the case statement.

For #6, that's called "Checkbox roulette" and you might watch this video here (link points to relevant section):

https://youtu.be/HKcEYkksW_o?t=2028

The video is close to an hour long but the section in question is just about 4 minutes.  It will point you towards the most likely checkboxes to try.

Finally, how does your code get this path:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\Lib\Motor\Classes\ELMO\ELMO.lvclass

I would have expected it to just be:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\ELMO.lvclass

Normally you don't see paths inside an EXE, so whatever you're using to load it may be adding paths that don't exist.

[StaLor]

Hello Kyle,

---

@Kyle97330 wrote:

---

@StaLor wrote:

3) I have put constants of all my classes in my code like this

6) I have "played around" with the options in the application builder

For #3, there is something in LabVIEW where it optimizes your code to not include things that will never run.  As such, anything in the True case of a False constant may never make it into a build.

Try just removing the case statement... class constants are harmless to have on a block diagram if not connected.  When I do it I wire up the class constants to the edge of a nearby structure just so they don't show up as "unused code" in VI analyzer checks, but even that isn't necessary.  Just get rid of the case statement.

---

I did this because of another comment from this thread, which talks about the same problem.

https://forums.ni.com/t5/LabVIEW/Executable-can-t-load-class/m-p/4210817/highlight/true#M1220214

I have also tried to put the constants without the case structure and in different places in my code all with the same result.

Finally, how does your code get this path:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\Lib\Motor\Classes\ELMO\ELMO.lvclass

I would have expected it to just be:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\ELMO.lvclass

Normally you don't see paths inside an EXE, so whatever you're using to load it may be adding paths that don't exist.

---

The relative paths stay the same inside the *.exe according to this.

https://labviewwiki.org/wiki/Executable_Directory_Structure

I have not changed the structure of my project, nor the code that loads my classes, so it should not have changed when i switched to LabView 2023 Q3.

For #6, that's called "Checkbox roulette" and you might watch this video here (link points to relevant section):

https://youtu.be/HKcEYkksW_o?t=2028

The video is close to an hour long but the section in question is just about 4 minutes.  It will point you towards the most likely checkboxes to try.

---

I will try this and report back.

Thank you!

[StaLor]

Unfortunately none of the tips from the video have worked.

I watched the whole thing and except for the xnodes i use nothing of what he described as problematic. 

Since everything worked fine in LabView 13 and LabView 2020 i am inclined to think that those are not the cause of my problems. Also replacing all of them would probably take me a week, so i'd rather save that as a last effort kind of thing before going back to LabView 13.

[Yamaeda]

---

@Kyle97330 wrote: Finally, how does your code get this path:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\Lib\Motor\Classes\ELMO\ELMO.lvclass

I would have expected it to just be:

C:\My_Folder\My_Application_Folder\My_Wonderful_Application.exe\ELMO.lvclass

Normally you don't see paths inside an EXE, so whatever you're using to load it may be adding paths that don't exist.

---

I'd only expect such a path if you have the Flatten file structure option. Otherwise LV .exe's havs an internal file structure, it's basically a ZIP file. In old versions it was a renamed LLB.

[IlluminatedG · Accepted solution]

I should scroll more before replying 🙂 Won't add to the pile.

Class constants by themselves do nearly nothing, it's safe to leave them in a VI not inside of a structure that would get constant folded out of existence.

How are you getting the paths for the classes? With classes always included you can just use the Get Default by Name and then you don't have to worry about the folder structure that gets generated. Also, the folder structure is entirely dependent on the disk organization, not the virtual folder organization of a project.

[StaLor]

Thank you so much!

---

@IlluminatedG wrote:

How are you getting the paths for the classes? With classes always included you can just use the Get Default by Name and then you don't have to worry about the folder structure that gets generated. Also, the folder structure is entirely dependent on the disk organization, not the virtual folder organization of a project.

---

This fixed my problem. I have changed my code to use "Get LV Class Default Value By Name" and now it seems to work again.

Before that i used "Get LV Class Default Value" which needs a path to the class instead of just the name.

I am still confused as to why this has worked for years in LabView 13 and LabView 2020 and why there is an LabView Wiki entry stating that it works like that (https://labviewwiki.org/wiki/Executable_Directory_Structure)

[IlluminatedG]

Some of the folders inside of the LabVIEW install locations could have changed which could mess up some of the relative pathing. Stuff like drivers now using the LVAddOns folder instead of being directly installed in vi.lib, but during builds they get moved as if they came from that location. Some internal stuff can just change layouts. Or if in your new LV version you have some different layouts between your main code and other dependencies that could change folder structure as well.

If you figured out the new paths with the new version of LabVIEW, the path method would work again but the name is just much less finnicky overall.