Absolute path to vi in project

[JÞB]

Moving an existing tool into TestStand 2012 (And introducing the benefits of *.lvproj files)

You guessed right! our home-built tool for SW control looks at all steps that use a LabVIEW Adapter for TS.SData.ViCall.VIPath

Obviously thats not a path that I can do an MD5 hash on!

But The darn Absolute path IS around!

Right There!!!! now where can I get it?

[Norbert_B]

You refer to the path display right in the bottom of your screenshot?

I would expect that to be the evluated path result coming from "Project Path" excluding the project name, then adding the VI Path as it is stored in the LV project.

Note that the VI Path indicates the location of the VI as it is found in the project tree. It does not necessarily match the "real relative path" from the lvproj-file to the vi-file!

So essentially it look like asif the LV adapter queries the LV project for this information, building the path and displaying it. Sad thing that this feature is encapsulated in the module tab of the editor. I don't think that this code is public available 😞

Norbert

[JÞB]

Norbert

You cannot be serious. the path displayed at the bottom of my snip HAS GOT TO BE resolved from the path to the *.lvproj and rel Path stored In the *.lvproj

but let that go for now....


how can TS.SData.VICall.VIPath be "not a path"? When it has always been a path and your users expect it to be a path?


I'll get over that too if I can get the displayed path to the tool. don't. say it isn't publicly available. Its right there in the step details! displayed for public consumption. And if the sdata has another, useless value just because I need a *.lvproj to store a DAQmx Task specific to this client sequence....

well those idea exchange threads exist...

now why is a sdata path not a path and where is the path?

[Norbert_B]

Jeff,

well, i am serious. I only want to point out that i am not aware that the path is exported as such that you have access to it.

Here is what happens inside the LV module configuration dialog:

This is the (dummy) LV project as seen in the LV project explorer. Looking nice with some virtual folders. Makes the project managable....

But here, we got the file view:

OOOOOPS. Both lvproj and vi-file are in the same folder! This is not nice!

But let's take a look into the settings of our TestStand module configuration:

As you can see, i selected the lvproj-file. The VI Path is the path where to find the vi in the items list, not the file list!

The bottom string indicator shows the absolute file path to the VI as it comes from:

lvproj-file path information to the VI.

This information is read from the lvproj-file itself:

As you can see, VI Path in the TestStand step stores the layout of folders as the VI is found in the project's Item view. The path is then evaluated by reading the (relative) path to the VI directly from the lvproj. If it is a relative path, the path to the lvproj-file is added as prefix (excluding the lvproj-file name of course) and this is the path displayed in the string indicator.....

As i said initially: I am not aware that you can pull out that displayed path programmatically. So in the worst case, your "MD5 tool" had to follow the same approach to get the absolute path to the VIs.

Sorry,

Norbert

[JÞB]

Thats exactly what I expected was happening.

Why did NI do that?  No, I really don't care why just fix it!  VIPath needs to be a path in all TS Steps Data.  It can't change to "Not a path" just because I called a LabVIEW step through the context of a lvproj

Now, lets get a work around that I can use to patch my tool youall broke.

Sorry if I sound grumpy--- I am

[Norbert_B]

---

@JÞB wrote:

[..]Sorry if I sound grumpy--- I am

---

And i am not offended, don't be afraid 😉

Well, i can only guess about the reason:

LV application instance management.

But please note again, that i don't know the internal functions used here. So maybe (though i doubt it) there IS a way to collect the data you are looking for without reading out the LV project file.....

Norbert

[JÞB]

Lets get someone warmed up on this because "showstopper" does not even begin.....

if vipath Is not a path I can catch and try another means to get A vi path. It is that or return a dozen vsts because we can't trace our product with teststand

[Teds]

 I use the VIPath for a tool I wrote to generate configuration files from the sequence file directly.  I never used LabVIEW projects so I it doesn't look like this issue would affect me.

You said:  Moving an existing tool into TestStand 2012 (And introducing the benefits of *.lvproj files)

What is the true benefit of using *.lvproj files in TestStand?

Thanks,

PH

[JÞB]

---

@Teds wrote:

 I use the VIPath for a tool I wrote to generate configuration files from the sequence file directly.  I never used LabVIEW projects so I it doesn't look like this issue would affect me.

You said:  Moving an existing tool into TestStand 2012 (And introducing the benefits of *.lvproj files)

What is the true benefit of using *.lvproj files in TestStand?

Thanks,

PH

---

• Project Task Configurations
• organized file layout
• sample templates
• source distributions
• namespacing

need I elaborate

[Norbert_B]

Jeff,

we all concur that using lvproj are recommended during development for exactly the points you listed.

But does that also apply for deployment? Does it apply for the finished application?

I am not sure about that. The only advantage using a lvproj for deployment (in the context of TestStand Code Modules!) is the dedicated runtime system in LV. So it is possible to define if "global" storages (global variables, queues/notifiers, FGVs, ...) are available to all modules or only to certain ones.

So if the requirement of dedicated management of runtime systems is not applicable, i recommend you to reconsider using lvproj files for managing code modules if you require the full path to the VI in the step.

I think that packed project libraries are more the technology you are looking for. But please be aware of the PPL pitfalls when going for more complex setups.

hope this helps,

Norbert