Labview: (Hex 0x626) Cannot Open a File With Separated Compiled Code in the Labview Run-time Engine

[Kraslan]

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA0VU0000008igb0AA&l=en-US, In this document, on step 4: "Uncheck the box labeled "Separate compiled code from source file", what if that box to uncheck is grey for that vi (see my screenshot), and you cannot go to the back diagram because it requires developer password?

 

  

[avogadro5]

Seems to work programmatically for a workaround:

 

[Kraslan]

Thank you for your reply. I tried your method and make the following workaround vi, named "connector2.vi", intended to skip through the compiled codes run the "time structure.vi". I made this "time structure.vi" to contain only a simple "Fire-Software timed structure.vi" function, which is the one of the mains thing that have been locked (cannot unselect compiled code, which can be seen in the screenshots of my original question). It didn't work out. It tells that "Fire-Software timed structure.vi is missing"

I'd appreciate you have more suggestions

[avogadro5 · Accepted solution]

---

@Kraslan wrote:

Thank you for your reply. I tried your method and make the following workaround vi, named "connector2.vi", intended to skip through the compiled codes run the "time structure.vi". I made this "time structure.vi" to contain only a simple "Fire-Software timed structure.vi" function, which is the one of the mains thing that have been locked (cannot unselect compiled code, which can be seen in the screenshots of my original question). It didn't work out. It tells that "Fire-Software timed structure.vi is missing"

I'd appreciate you have more suggestions

---

I see the same thing where the VI can't find the subVI in vi.lib when opened in RTE, even when compiled code is included. I confirmed it wasn't related to having multiple LabVIEW versions (ie development using 2023 but RTE using 2025 because "allow future versions" is checked), and using debugging saw it was linked correctly to the right path in vi.lib. When you load the subVI in first by opening it by path, the caller loads correctly. I am not that familiar with this mode of operation (loading source code from vi.lib into RTE) other than to say I would expect it to work but it isn't, so this may be a bug in LabVIEW. I suggest opening a service request with NI unless someone here has another explanation.

Approaches that do seem to work are building a source distribution or packed library and using that instead.

If doing source distribution make sure these are unchecked or it will have this same issue. Note that the source distribution also unchecks "separate compiled code" for you.

[Mark_Yedinak]

Are you trying to circumvent a third secured third party library and crack into the code? What is your end goal. If it simply isn't working correctly contact the owner of the library. If you are trying to crack the password to look at the code that is not ethical or legal.

[Kraslan]

Thank you so much! I was able to solve the problem by doing a source distribution, exactly uncheck those box and it works. You are really an expert with your LabVIEW knowledge.

[Yamaeda]

---

@avogadro5 wrote:

---

@Kraslan wrote:

Thank you for your reply. I tried your method and make the following workaround vi, named "connector2.vi", intended to skip through the compiled codes run the "time structure.vi". I made this "time structure.vi" to contain only a simple "Fire-Software timed structure.vi" function, which is the one of the mains thing that have been locked (cannot unselect compiled code, which can be seen in the screenshots of my original question). It didn't work out. It tells that "Fire-Software timed structure.vi is missing"

I'd appreciate you have more suggestions

---

I see the same thing where the VI can't find the subVI in vi.lib when opened in RTE, even when compiled code is included. I confirmed it wasn't related to having multiple LabVIEW versions (ie development using 2023 but RTE using 2025 because "allow future versions" is checked), and using debugging saw it was linked correctly to the right path in vi.lib. When you load the subVI in first by opening it by path, the caller loads correctly. I am not that familiar with this mode of operation (loading source code from vi.lib into RTE) other than to say I would expect it to work but it isn't, so this may be a bug in LabVIEW. I suggest opening a service request with NI unless someone here has another explanation.

If memory serves, IDE and RTE are different users, to the compiled cache can't be used by RTE, thus all VI's run this way must have the compiled code included. If you build an .exe that's a non issue and if you do a code export you can tick the box.