Error Code - 17208 "Could not find item in LabVIEW Packed Project Library"

[chbo@mir-robots.com]

I'm running into this problem when trying to run a main sequence on a deployed system after updating to LabVIEW Runtime 23.3.2:

All I did was rebuild the PPL "Robot communication" and I get this error.
I did the same for several other PPLs in the project without a hitch.

For reference, the path of the sequence is:

and the sequence search directory looks like this:

The Step is located at the path:
C:\Users\Public\Documents\National Instruments\TestStand 2023 (32-bit)\Components\StepTypes

Also, even though the path is definitely there in the search directory, a window still opens asking me to find the library like this:

I'm very new to TestStand, how do I proceed to troubleshoot this? Thanks

[Oli_Wachno]

Just to gather some information:

what was the RTE version before the update?

Does the sequence work on a dev (non deployment) system with the new RTE version?

Is your deployed system started using a TestStandEnvironment?

Has your lvlibp (old and new version) the version compatibility flag set?

Where is the lvlibp stored on then deployed system? In realtion to the StepType that's using it (sorry, if I've overread that)

[chbo@mir-robots.com]

---

what was the RTE version before the update?

---

RTE before the update was 22.3.1

---

---

Does the sequence work on a dev (non deployment) system with the new RTE version?

---

Yes it works on my dev system.

---

---

Is your deployed system started using a TestStandEnvironment?

---

Not sure as I inherited this project from a prev. developer, but I guess not:

How do I know for sure?

---

---

Has your lvlibp (old and new version) the version compatibility flag set?

---

Yes, both the old and the new.

---

---

Where is the lvlibp stored on then deployed system? In realtion to the StepType that's using it (sorry, if I've overread that)

---

Not sure what you mean exactly, the lvlibp is at:

C:\Users\Public\Documents\National Instruments\TestStand 2023 (32-bit)\Components\StepTypes

and there's the .ini file at:
C:\Users\Public\Documents\National Instruments\TestStand 2023 (32-bit)\Components\TypePalettes

[Oli_Wachno]

---

chbo@mir-robots.com wrote:

[...]

---

---

Is your deployed system started using a TestStandEnvironment?

---

Not sure as I inherited this project from a prev. developer, but I guess not:

How do I know for sure?

---

---

Has your lvlibp (old and new version) the version compatibility flag set?

---

---

Environment: <Global> effectively means No Environment, so that's ok

---

chbo@mir-robots.com wrote:

---

[...]

---

Not sure what you mean exactly, the lvlibp is at:

C:\Users\Public\Documents\National Instruments\TestStand 2023 (32-bit)\Components\StepTypes

and there's the .ini file at:
C:\Users\Public\Documents\National Instruments\TestStand 2023 (32-bit)\Components\TypePalettes

---

Looks alright....

I haven't found the aforementioned error coede -17208 in the TestStand documentation, so I rather suspect this to originate from the LabVIEW adapter.

On your deployment system, there is no LabVIEW Dev installed, is there?

What happens if you explicitely specify the lvlibp file on the browse window?

[chbo@mir-robots.com]

---

On your deployment system, there is no LabVIEW Dev installed, is there?

---

Nope, only LabVIEW RTE

What happens if you explicitely specify the lvlibp file on the browse window?

---

I get the same error message when I specify the lvlibp file in the browser window.

However, I seem to have found the culprit.
I noticed that the .ini file corresponding to the failing lvlibp in the TypePalettes folder had changed, and replacing that with an old one seems to have fixed the issue.
Any idea why this happened, and how to prevent it in the future?

[Oli_Wachno]

---

chbo@mir-robots.com wrote:

---

[...]
However, I seem to have found the culprit.
I noticed that the .ini file corresponding to the failing lvlibp in the TypePalettes folder had changed, and replacing that with an old one seems to have fixed the issue.
Any idea why this happened, and how to prevent it in the future?

---

Congrats on finding this! 

An erroneous ini file can lead to strange behaviour! Though no idea, how this happened.

The ini file holds a reference to the code modules used in the step definitions, so if somethings goes wrong there, the situation you were seeing sounds plausible.

Yet I would have expected trouble due to RTE upgrades rather in the adapter settings than in an ini file.

Guess to fully understand this, we're still missing an aspect.

So far, no..... no ideas how this can be prevented, since the actaul reason is not completely known IMHO

[Anand_Jain]

Hi, 

To help diagnose this issue, can you post the old and new ini files?

Regards, 

Anand Jain

NI