From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Filenames/Paths too long

Solved!
Go to solution

Hello everyone,

 

because of the update to Teststand/Labview 2020 we rearranged some of our model-plugin VIs to call them from a .lvlibp because of dependencies. We use the standard structure in the Teststand Public Folder for our files and copied the NI_SimpleTextReport.seq and renamed it Company_SimpleTextReport_Specific.seq. 
Now with all the subfolders and the .lvlib structure it seems that we can't access the files inside of the .lvlibp because the filename is too long. The error message from Teststand when i want to select a VI is "not a valid Fileending", but the path shown is cut and not fully visible.

 

Now my question: Is there a way to use longer Filenames in Teststand ? I haven't found quite much about this topic in the internet. It seems there is a limitation for 256 characters, 

Additionaly i ask myself if it is a good idea to use the standard file structure and expand it to my own use ?

Many thanks in advance for your help.

 

Best regards,
Stefan

 

 

0 Kudos
Message 1 of 4
(1,368 Views)
Solution
Accepted by topic author StevieP

Hello Stevie,

 

Are you using TestStand 32 bits ? If the limit is 260 characters, then I'm not sure TestStand is the one who limit the supported path lenght, but it may be the OS (WIndows): Maximum Path Length Limitation - Win32 apps

 

About Project Packed Libraries (PPL, or *.lvlip files), there should be a way to limit the length of "internal path". I observed that when LabVIEW builds a PPL, it has to reflect in the PPL the "lowest common denominator". I mean, if my library exposes a public file in C:\some\path\to\my\public\VIs\MyPublicVI.vi, and if a dependency is set in C:\some\other\path\to\Dependency.vi, you may see your public VI into the build PPL under path\to\my\public\VIs\MyPublicVI.vi


So, by adjusting with your source files hierarchy, you may optimize the lenght to your VIs exposed in your PPL.

 

I always take care, for an existing PPL, of the dependency I may add by updating the source code (bug fix, improvement). If I add a "far away" VI in terms of relative path, it may change the top lever common folder. If the path in my PPL is changed, existing call in TestStand are broken and have to be updated (I guess referencing LabVIEW project in TestStand may address this problematic - I did not yet changed my habbits to adopt this way of doing things).

 

Regards,

0 Kudos
Message 2 of 4
(1,336 Views)

Hello Mathieu,

 

thank you very much for your help!

I now changed the hirarchy in the .lvlibp and it just works fine now. Additionaly i tried to deactivate the Path-length limitation as guided in the article you sent, but i wasn't successfull. Maybe it's because of Company-Restrictions, i will investigate further if i have time.

Best Regards,

Stefan

0 Kudos
Message 3 of 4
(1,312 Views)

Glad to read that it helped you.


I mentionned the Microsoft link to indicate where comes from the limit. Even it seems it can be possible to change that limit, I think it is not a good option. Because of possible IT restrictions, and because this specific OS configuration may have to be deployed on other computer (deployment).

 

Simple is better, so I would prefer to use standard OS configuration, with no specific "trick". It's one less source of issues.

0 Kudos
Message 4 of 4
(1,310 Views)