Jump to content

Referencing VIs inside running exe


Recommended Posts

Hi,

I want to get a reference to a front panel object of a VI (test1.vi) that is built into an executable file, while the executable is running. If i first start the executable (by doublecliking on the exe), then in another VI (test2.vi) use the 'open VI reference' VI, pointing it to the executable, the reference opens just fine but it doesnt seem to point to the running instance but rather to the VI on disk. This means If I reference a front panel object and read values with a property node the values doesnt match what is seen in the frontpanel of the running instance of test1.vi .

I did find the solution of simply starting test1 with an invoke node inside test2, but I am curious if there is another solution. Is it possible to get a reference to the frontpanel of a running VI that is inside of an executable?

any clarification about htis would be great.

/Gustav

Link to comment

QUOTE(gustav @ Jan 28 2008, 04:48 PM)

Hi,

I want to get a reference to a front panel object of a VI (test1.vi) that is built into an executable file, while the executable is running. If i first start the executable (by doublecliking on the exe), then in another VI (test2.vi) use the 'open VI reference' VI, pointing it to the executable, the reference opens just fine but it doesnt seem to point to the running instance but rather to the VI on disk. This means If I reference a front panel object and read values with a property node the values doesnt match what is seen in the frontpanel of the running instance of test1.vi .

I did find the solution of simply starting test1 with an invoke node inside test2, but I am curious if there is another solution. Is it possible to get a reference to the frontpanel of a running VI that is inside of an executable?

any clarification about htis would be great.

/Gustav

One question, does test2.vi run in the executable or outside it (from the development environment)?

  • executable:
    What you could do is add a static VI reference to test1.vi in test2.vi, then you should be able to set properties. Debug this well, so popup a screen when some action succeeded or failed.
  • outside:
    Use a 'open Application' node to open a reference to the app (use a specific port which is specified in the build specs), then open a reference inside the VI, by only using the filename as a string, debug this in the same way (should be easier since you are in the Development environment. Make sure you allowed the application to export this VI via VI server.

Ton

Link to comment

If the VI you want to reference is a part of the executable and is loaded as part of the executable (by having it used as a subVI somewhere in your code or having a static VI ref to that VI) then you can easily open a reference using Open VI Reference primitive. Instead of wiring a path, just wire a string that is the VI's name (doesn't work for VIs that are inside libraries because you'd have to wire the fully qualified name and I don't think the primitive is updated to accept those (though I might be wrong; someone could've fixed that in 8.2 or 8.5 and I might not have heard about it)).

Link to comment

QUOTE(Aristos Queue @ Jan 28 2008, 01:46 PM)

Instead of wiring a path, just wire a string that is the VI's name (doesn't work for VIs that are inside libraries because you'd have to wire the fully qualified name and I don't think the primitive is updated to accept those (though I might be wrong; someone could've fixed that in 8.2 or 8.5 and I might not have heard about it)).

Pretty sure that works. At least with 8.5 and LV Class members.

Link to comment

I do practially this exact thing that AQ is talking about when sending information to an EXE w/ LVx

You may even want to change what your trying to do after seeing how it works.

http://forums.lavag.org/LVx-Exported-LV-Fu...lity-t9437.html

It uses a top level object to handle the flow of information and command into and back from the EXE.

Then you make children objects/commands, that have the specific data for that command and when the EXE is done w/ the command it sends it back w/ any status or processsed data that may also be there.

Link to comment

Thanks for the replies all!

I realize I missed quite a bit of important information in my post, sorry about that.

I am using labview 7.1.1 for this project. The actual case is that I have an allready compiled exe, and I want to some data out of it. I'm thinking that an ugly but working hack would be to use a reference for reading the data from a frontpanel control. So I can not really change anything inside the exe.

So in my example test1 would be inside the compiled exe, while test2 would be in the development environment (or possibly in another exe) .

QUOTE(tcplomp @ Jan 28 2008, 07:30 PM)

The test2.vi is ran in the development. The suggestion about opening a reference to the app is interesting (even if I cant use it since it would require rebuilding the exe?), how do I specify a port in the build specs?

QUOTE(Aristos Queue @ Jan 28 2008, 08:46 PM)

If the VI you want to reference is a part of the executable and is loaded as part of the executable (by having it used as a subVI somewhere in your code or having a static VI ref to that VI) then you can easily open a reference using Open VI Reference primitive. Instead of wiring a path, just wire a string that is the VI's name (doesn't work for VIs that are inside libraries because you'd have to wire the fully qualified name and I don't think the primitive is updated to accept those (though I might be wrong; someone could've fixed that in 8.2 or 8.5 and I might not have heard about it)).

But this would require test2 to also be inside the exe?

QUOTE(Norm Kirchner @ Jan 28 2008, 11:35 PM)

It uses a top level object to handle the flow of information and command into and back from the EXE.

Then you make children objects/commands, that have the specific data for that command and when the EXE is done w/ the command it sends it back w/ any status or processsed data that may also be there.

Seems like a good tool, but not applicable here since I can not recompile the exe.

Once again, apologies for not being clear enough in my first post.

Link to comment

QUOTE(gustav @ Jan 29 2008, 11:50 AM)

...The test2.vi is ran in the development. The suggestion about opening a reference to the app is interesting (even if I cant use it since it would require rebuilding the exe?), how do I specify a port in the build specs?

I think the port tcplomp is taking about is the port that this application uses for remote access through VI server.

You can change this port after you have compiled your exe, just open up the ini file that should be next to the exe file, check for the following keys

server.tcp.enabled=True

server.vi.access="+*"

server.tcp.port=3340

basically these keys enable TCP access on port 3340, and exporting all VIs for remote access.

In your test2.vi you then open an Application reference to localhost (if they are on the same computer), port 3340 (default is 3363 if the key is not present).

Then use this application reference as an input to the Open VI reference.

/J

Link to comment

QUOTE(JFM @ Jan 29 2008, 03:38 PM)

I think the port tcplomp is taking about is the port that this application uses for remote access through VI server.

You can change this port after you have compiled your exe, just open up the ini file that should be next to the exe file, check for the following keys

server.tcp.enabled=True

server.vi.access="+*"

server.tcp.port=3340

basically these keys enable TCP access on port 3340, and exporting all VIs for remote access.

In your test2.vi you then open an Application reference to localhost (if they are on the same computer), port 3340 (default is 3363 if the key is not present).

Then use this application reference as an input to the Open VI reference.

Thanks, I will try that.

Link to comment

QUOTE(Aristos Queue @ Jan 28 2008, 02:46 PM)

(doesn't work for VIs that are inside libraries because you'd have to wire the fully qualified name and I don't think the primitive is updated to accept those (though I might be wrong; someone could've fixed that in 8.2 or 8.5 and I might not have heard about it)).

Did anyone else note that AQ used properly nested parentheses in his reply?

Does anyone else besides me notice things like this? My brain throws syntax errors when I read peoples' posts containing improperly closed parenthetical notes. :P

Dave

Link to comment
Link to comment

QUOTE(Aristos Queue @ Jan 29 2008, 12:29 PM)

The correct syntax is simple (as can be shown in this example :-) ).You must include a space between the parens or the mental parser will assume that you're claiming "I have a double chin", and, in addition to being confused about why your double chin is relevant to the discussion, the mental parser will still be bitter about the lack of a closing parentheses. It is an article of emoticon law that emoticons cannot include whitespace as a legal character in their construction, thus the space is sufficient to delimit end of emoticon from closing parentheses. You may also use tab or carriage return, and, in printed material only, it is acceptable to use any printable character with the font color set to be the same as the background color. Or you could restrict your posts to places such as LAVA which support the "rich emoticon iconography set." :ninja: For the record, an emoticon at the end of a sentence should always have a space between the period and the start of the emoticon, as shown here. ;-) Without the space, I wonder why your emoticon has zits, and I keep scanning, desperately seeking the end of the sentence.

I'm thrilled at the rich store of knowledge I've tapped into about proper syntax. Thanks, Stephen.

And of course, I'm always happy to hijack a thread. What were we discussing again?

Dave

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.