Jump to content

VI Server connection to external EXE


Recommended Posts

Hi!!

I've used VI server before for some simple tasks, and it has always worked as expected. However, for this task, it is becoming increasingly frustrating.

What I'm Trying To Do:

Look into any previously made executable in LV and get the memory information of the VIs internally. We're suspecting a memory leak in one or many of our named LV2 Globals within a range of our applications on the production line. Instead of painfully editing the EXEs on the production line, we want another EXE to go in and analyse the VIs we're interested in.

What is Going Wrong:

The tool I've created only sees the list of VIs within its own EXE and not the other!!! I'm connecting to port 2020 (set in the ini file of the EXE I'm trying to access) and set the port of the analyser to 2022, and it STILL somehow connects internally!!!!

What I've Tried:

  • server.tcp.port=2020 in target exe
  • server.tcp.enabled=True in both
  • Simple "Open Application Reference" VI with the port number set to 2020
  • Read the "Srvr.Port" application attribute of the analyser to check it is set to 2022 (and it is)
  • Checked out this CONFUSING NI link http://digital.ni.co...62571DA005B896C The last option seems to suggest you can just go ahead as always.... I don't get itblink.gif

I'm expecting at the very least to get an error when it tries to connect to port 2020 when it's not there, but it doesn't. It just somehow connects to itself and returns the list of VIs within itself.

NOTE: The application is in LV8.5.1 and the Analyser is in 2009 SP1. I didn't think that would matter as the TCP layer should abstract all that right?

I've compiled it in 8.5.1 now and still exactly the same result.....I'm fresh out of ideas now

Any help would be greatly appreciated.

Thanks in advance,

Youngy

Edited by MrYoung
Link to comment

Hi!!

I've used VI server before for some simple tasks, and it has always worked as expected. However, for this task, it is becoming increasingly frustrating.

What I'm Trying To Do:

Look into any previously made executable in LV and get the memory information of the VIs internally. We're suspecting a memory leak in one or many of our named LV2 Globals within a range of our applications on the production line. Instead of painfully editing the EXEs on the production line, we want another EXE to go in and analyse the VIs we're interested in.

What is Going Wrong:

The tool I've created only sees the list of VIs within its own EXE and not the other!!! I'm connecting to port 2020 (set in the ini file of the EXE I'm trying to access) and set the port of the analyser to 2022, and it STILL somehow connects internally!!!!

What I've Tried:

  • server.tcp.port=2020 in target exe
  • server.tcp.enabled=True in both
  • Simple "Open Application Reference" VI with the port number set to 2020
  • Read the "Srvr.Port" application attribute of the analyser to check it is set to 2022 (and it is)
  • Checked out this CONFUSING NI link http://digital.ni.co...62571DA005B896C The last option seems to suggest you can just go ahead as always.... I don't get itblink.gif

I'm expecting at the very least to get an error when it tries to connect to port 2020 when it's not there, but it doesn't. It just somehow connects to itself and returns the list of VIs within itself.

NOTE: The application is in LV8.5.1 and the Analyser is in 2009 SP1. I didn't think that would matter as the TCP layer should abstract all that right?

I've compiled it in 8.5.1 now and still exactly the same result.....I'm fresh out of ideas now

Any help would be greatly appreciated.

Thanks in advance,

Youngy

Make sure to use a non-blank string for the IP Address. A blank string indicates the local application instance, regardless of the port specified. I've made that mistake, too. Instead use the string "localhost".

  • Like 1
Link to comment

Make sure to use a non-blank string for the IP Address. A blank string indicates the local application instance, regardless of the port specified. I've made that mistake, too. Instead use the string "localhost".

This is most probably the issue I'm having. I didn't think it ignored the port input! Thanks heaps!

worshippy.gif

Link to comment

The tool I've created only sees the list of VIs within its own EXE and not the other!!! I'm connecting to port 2020 (set in the ini file of the EXE I'm trying to access) and set the port of the analyser to 2022, and it STILL somehow connects internally!!!!

Good post!

However I don't think you'll succeed in retrieving the list of VIs remotely. From the help from the property All VIs in memory:

The following table lists the characteristics of this property.

Data typei1dstr.gifPermissionsRead OnlyAvailable in Run-Time EngineYes (Read Only)Available in Real-Time Operating SystemYesRemote access disallowedYes

Remote access disallowed—Specifies if access to this property or method is disallowed with a permission error by a remote application instance. If this characteristic value is Yes, LabVIEW returns error 1032 if you try to use a remote reference to this property or method.

However I would love to be proven wrong.

Ton

Link to comment

Ton,

you are right.The All VIs in memory won't work due to the restrictions you mentioned.

But the Exported VIs in memory works if you haven't explicitly denied access.

To be sure adding the line

server.vi.access="+*"

will export all VIs in memory.

The line

server.vi.access="-*"

will deny access to all VIs.

However I would love to be proven wrong.

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
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.