Jump to content

how to find the Global's Path


Chris_S

Recommended Posts

How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams.

So how do I get the path to a global, from inside a top-level VI that uses that global?

Just how there is a “Current VI’s path” function, I need a “That VI’s path” function

Link to comment

How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams.

So how do I get the path to a global, from inside a top-level VI that uses that global?

Just how there is a “Current VI’s path” function, I need a “That VI’s path” function

I don't use globals so I can only start with some guesses.

A global is a callee of the VI so start with that list. I belive you can get a type for each VI ref so look for globals. For all global type vis, open the FP of each and get a ref to all control (traverse FP controls) and find one with the name you are after then get the path to the VI that holds it.

Like I said, just guessing.

Ben

Link to comment

How do I programmatically get the path to a global VI? You cannot use get this VIs path because global VIs don’t have block diagrams.

So how do I get the path to a global, from inside a top-level VI that uses that global?

Just how there is a “Current VI’s path” function, I need a “That VI’s path” function

Make a static VI reference to the global vi then use the path property of the reference.

Link to comment

If it's in memory, you can do this:

this didnt work.

Error 1445 occurred at Open VI Reference in Safe_Start.vi

Possible reason(s):

LabVIEW: Open VI Reference will no longer match VIs in memory by file name. A VIs full name now includes any owning libraries so a filename is no longer sufficient. You can use strip path to wire the filename as a string, but this will not work for VIs in libraries.

Edited by Chris_S
Link to comment

Make a static VI reference to the global vi then use the path property of the reference.

i cant make a ref to the global, because that would hard code the path in the static VI ref. The global may be in different locations on different systems. that is why i need to pull the path on the fly.

I don't use globals so I can only start with some guesses.

A global is a callee of the VI so start with that list. I belive you can get a type for each VI ref so look for globals. For all global type vis, open the FP of each and get a ref to all control (traverse FP controls) and find one with the name you are after then get the path to the VI that holds it.

Like I said, just guessing.

Ben

this only works if the global is in that vi. the point is to use the global by reference. using it by ref, it will not show up on a callee list.

The problem with pulling by reference, is that you need the path to pull it. So i need a way to get the path.

Our main program houses the global in different locations for development software and released executable software. For all of our development testing, the global is in an llb. when the software is released for use the global will be compiled into an exe that resides in a completely different location. The exe runs a secondary piece of software, stored in a different location. This secondary software is where i need to call the global by reference. Since the secondary is not inside the exe. if i strip path i will only be left with the location of the secondary software, not the exe that contains the global.

I cant run a list of callers from the secondary, trying to get the exe, because the exe calls everything by callback.

Im sorry the whole situation is very convoluted. It’s always a pain trying to conform around old issues, as opposed to cost of rewriting old code to do things right.

Link to comment

this didnt work.

Error 1445 occurred at Open VI Reference in Safe_Start.vi

Possible reason(s):

LabVIEW: Open VI Reference will no longer match VIs in memory by file name. A VIs full name now includes any owning libraries so a filename is no longer sufficient. You can use strip path to wire the filename as a string, but this will not work for VIs in libraries.

It worked for me. Did you wire the VI name with a String or Path datatype? I used String.

Link to comment

i cant make a ref to the global, because that would hard code the path in the static VI ref. The global may be in different locations on different systems. that is why i need to pull the path on the fly.

this only works if the global is in that vi. the point is to use the global by reference. using it by ref, it will not show up on a callee list.

The problem with pulling by reference, is that you need the path to pull it. So i need a way to get the path.

Our main program houses the global in different locations for development software and released executable software. For all of our development testing, the global is in an llb. when the software is released for use the global will be compiled into an exe that resides in a completely different location. The exe runs a secondary piece of software, stored in a different location. This secondary software is where i need to call the global by reference. Since the secondary is not inside the exe. if i strip path i will only be left with the location of the secondary software, not the exe that contains the global.

I cant run a list of callers from the secondary, trying to get the exe, because the exe calls everything by callback.

Im sorry the whole situation is very convoluted. It’s always a pain trying to conform around old issues, as opposed to cost of rewriting old code to do things right.

And now for something completely different...

I think you would be better off using Datasocket or the like, where all you have to do is change the URL for differnet environnets.

Ben

Link to comment

It worked for me. Did you wire the VI name with a String or Path datatype? I used String.

when i tried this within a vi that used the global normally. Yes it worked.

But when I ran it from a secondary program (with the first program running so the global should be in memory) I got that error.

And now for something completely different...

I think you would be better off using Datasocket or the like, where all you have to do is change the URL for differnet environnets.

Ben

I really haven’t used datasockets so I do not know. But wouldn’t using different URLs be equivalent to just using paths directly?

Like saying I can hard code the path to one location or the other. Or have a url to one or the other. Either way there is hard coded information.

Link to comment

My main goal here is:

I have a global I can use normally. That I can guarantee will always exist (its location may change development or exe). I also have a new global that may or may not exist. If it does exist, it will be stored in the same location as the first. If it does not exist I can handle any errors, my code will not be broken, and will still run without problems.

So for example if I have on my diagram a string global (from global_1.vi) used normally.

Can I get the path to global_1.vi so I can use that path to call Global_2.vi by reference?

See Ex1.jpg attachment

post-9793-0-76250200-1289489330_thumb.jp

Edited by Chris_S
Link to comment

when i tried this within a vi that used the global normally. Yes it worked.

But when I ran it from a secondary program (with the first program running so the global should be in memory) I got that error.

That is normal, VIs are enclosed in there own application space. If you want to open a (global) VI in a different application/project, you need to open a reference to that application first.

Ton

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.