LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to configure Labview executable for Desktop execution trace toolkit

I am trying the debug my application(exe) on the remote machine , I made the executable with vi server enabled  , default port number (3363) and even machine ip address added  in the Vi server options.But when I try to use the desktop executaion trace toolkit on my local computer to monitor the remote application , I couldnt see the application instance on my DETT .


I even tried disabling firewall and virus protection program without any success in getting the trace.Please let me know where I doing it wrong,

 

Thanks

0 Kudos
Message 1 of 11
(7,885 Views)

Hello AnkitG,

 

What LabVIEW version are you using? 

 

Please refer to the following link on how to debug executable remotely

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

 

Please also refer to the Advanced LabVIEW debugging white paper:

http://www.ni.com/white-paper/8083/en/#toc4

Luis S
Application Engineer
National Instruments
0 Kudos
Message 2 of 11
(7,857 Views)

@luissg wrote:

Hello AnkitG,

 

What LabVIEW version are you using? 

 

Please refer to the following link on how to debug executable remotely

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

 

Please also refer to the Advanced LabVIEW debugging white paper:

http://www.ni.com/white-paper/8083/en/#toc4


Thanks a lot luissg,

 

I am using Labview 2012,( when I launch labview  from start it says Labview 2012).

My DETT version is 2013.

 

I will go through these document in the link.

 

Thanks.

 

Ankit

0 Kudos
Message 3 of 11
(7,853 Views)

@AnkitG wrote:

@luissg wrote:

Hello AnkitG,

 

What LabVIEW version are you using? 

 

Please refer to the following link on how to debug executable remotely

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

 

Please also refer to the Advanced LabVIEW debugging white paper:

http://www.ni.com/white-paper/8083/en/#toc4


Thanks a lot luissg,

 

I am using Labview 2012,( when I launch labview  from start it says Labview 2012).

My DETT version is 2013.

 

I will go through these document in the link.

 

Thanks.

 

Ankit


Hi Luissg,

 

I am still unable to debug my executables , I followed all the instructions as mentioned in the link. Still when I try locate the executable from my computer to the remote computer the DETT is unable to find it.Is there a problem between different version as my DETT is 2013 and my labview version is 2012 sp1. In both link the port mentioned are different which port should I use?

 

Please let  me know

0 Kudos
Message 4 of 11
(7,832 Views)

Hello AnkitG

 

The execution trace toolkit is compatible with LabVIEW 2012. However, it is not natively compatible with 64 bit OS nor supported with LabVIEW 64-bit release. Make sure you are working with LabVIEW 32-bit version.

 

Regarding the ports. Make sure to follow recommendations on the following link:

http://zone.ni.com/reference/en-XX/help/372641A-01/lvdetthelp/debug_built_apps/

 

Step 4 and 7

 

 

Here's the resource page for Desktop Execution Trace Toolkit for additional information.

http://sine.ni.com/psp/app/doc/p/id/psp-845/lang/en

 

 

Luis S
Application Engineer
National Instruments
0 Kudos
Message 5 of 11
(7,825 Views)

Hello AnkitG

 

The execution trace toolkit is compatible with LabVIEW 2012. However, it is not natively compatible with 64 bit OS nor supported with LabVIEW 64-bit release. Make sure you are working with LabVIEW 32-bit version.

 

Regarding the ports. Make sure to follow recommendations on the following link:

http://zone.ni.com/reference/en-XX/help/372641A-01/lvdetthelp/debug_built_apps/

 

Step 4 and 7

 

 

Here's the resource page for Desktop Execution Trace Toolkit for additional information.

http://sine.ni.com/psp/app/doc/p/id/psp-845/lang/en

 

 

Luis S
Application Engineer
National Instruments
0 Kudos
Message 6 of 11
(7,825 Views)

@luissg wrote:

Hello AnkitG

 

The execution trace toolkit is compatible with LabVIEW 2012. However, it is not natively compatible with 64 bit OS nor supported with LabVIEW 64-bit release. Make sure you are working with LabVIEW 32-bit version.

 

Regarding the ports. Make sure to follow recommendations on the following link:

http://zone.ni.com/reference/en-XX/help/372641A-01/lvdetthelp/debug_built_apps/

 

Step 4 and 7

 

 

Here's the resource page for Desktop Execution Trace Toolkit for additional information.

http://sine.ni.com/psp/app/doc/p/id/psp-845/lang/en

 

 


Hi Lui,

 

I followed the exact steps as mentioned in the documents:

 

1). I made my executable with debugging enabled.

 

2).configured vi server on the developmental machine. with same ports

 

but still when I am trying to use DETT on the developemtal machine. Its telling me to configure the VI server , whereas I already configured it.I have also disabled the firewall to allow NI services.


I am using labview 2012 sp1 32 bit, my target and developmental machines are win 7 64 bit

0 Kudos
Message 7 of 11
(7,817 Views)

Ankit,

 

I'm guessing that the problem you are seeing is in the preferences file of the debuggable executable.  I encountered this problem recently while trying out the DETT, and it took me a LOT of effort to get it right.

 

As near as I can tell, it's not sufficient to just add the preference file tokens in the executable e.g.:

 

server.tcp.enabled=True

server.tcp.paranoid=True

server.tcp.port=3363

server.tcp.serviceName=""

server.vi.access="+*.*"

 

...although those tokens obviously do need to be set.  Since somewhere in the LabVIEW 8.x days, I think there was a push to tighten security on VI Server by requiring an additional entry of the form:

 

server.tcp.acl="<a-long-hash-of-the-network-nodes-given-access-and-or-the-list-of-VIs-exposed>"

 

And I'm guessing that the ACL hash is possibly even keyed to the executable in some way.  I think this is intended to prevent someone from gaining additional VI server access by simply modifying the INI file tokens after the fact.  But, how do we get the correct hash?

 

While you're in the project environment, before you build your executable:

 

  • right-click on the "My Computer" target, select "Properties"
  • on the properties dialog,  select "VI Server" on the left side
  • check "TCP/IP", choose a port value (3363 is VI Server default, but you can define another if that port is used on your target)
  • scroll down and add specific machine and VI ACLs (or just grant machine access to "*" and VI access to "*.*" if security isn't a concern)

 

Close the "My Computer Properties"dialog

 

Now, on the build specification for your executable:

 

  • right-click and select "Properties"
  • on the "Properties" dialog, select "Advanced" on the left side
  • check "Enable debugging" (and optionally "Wait for debugger on launch")
  • UN-check "Use custom configuration file" (discussion below*)

Now build your executable.  Wherever you deploy it, make sure the generated preferences (INI) file goes with it.  At this point, you should be able to get the DETT to see it, as long as you know the target machine name/address and the port you chose above.

 

*It appears to me that if you have a custom preferences file in your project resources, and check off "Use custom configuration file" to use it, the VI Server tokens needed for debug (specifically, the ACL hash) don't get added to your custom file.  In this case, you'll need to meld the preferences manually.

 

Hope this helps!

 

Dave

David Boyd
Sr. Test Engineer
Abbott Labs
(lapsed) Certified LabVIEW Developer
Message 8 of 11
(7,806 Views)

@DavidBoyd wrote:

Ankit,

 

I'm guessing that the problem you are seeing is in the preferences file of the debuggable executable.  I encountered this problem recently while trying out the DETT, and it took me a LOT of effort to get it right.

 

As near as I can tell, it's not sufficient to just add the preference file tokens in the executable e.g.:

 

server.tcp.enabled=True

server.tcp.paranoid=True

server.tcp.port=3363

server.tcp.serviceName=""

server.vi.access="+*.*"

 

...although those tokens obviously do need to be set.  Since somewhere in the LabVIEW 8.x days, I think there was a push to tighten security on VI Server by requiring an additional entry of the form:

 

server.tcp.acl="<a-long-hash-of-the-network-nodes-given-access-and-or-the-list-of-VIs-exposed>"

 

And I'm guessing that the ACL hash is possibly even keyed to the executable in some way.  I think this is intended to prevent someone from gaining additional VI server access by simply modifying the INI file tokens after the fact.  But, how do we get the correct hash?

 

While you're in the project environment, before you build your executable:

 

  • right-click on the "My Computer" target, select "Properties"
  • on the properties dialog,  select "VI Server" on the left side
  • check "TCP/IP", choose a port value (3363 is VI Server default, but you can define another if that port is used on your target)
  • scroll down and add specific machine and VI ACLs (or just grant machine access to "*" and VI access to "*.*" if security isn't a concern)

 

Close the "My Computer Properties"dialog

 

Now, on the build specification for your executable:

 

  • right-click and select "Properties"
  • on the "Properties" dialog, select "Advanced" on the left side
  • check "Enable debugging" (and optionally "Wait for debugger on launch")
  • UN-check "Use custom configuration file" (discussion below*)

Now build your executable.  Wherever you deploy it, make sure the generated preferences (INI) file goes with it.  At this point, you should be able to get the DETT to see it, as long as you know the target machine name/address and the port you chose above.

 

*It appears to me that if you have a custom preferences file in your project resources, and check off "Use custom configuration file" to use it, the VI Server tokens needed for debug (specifically, the ACL hash) don't get added to your custom file.  In this case, you'll need to meld the preferences manually.

 

Hope this helps!

 

Dave


thanks david, I will try once more.

 

Message 9 of 11
(7,789 Views)

Hi AnkitG,

 

try disabling UAC, I had exactly the same problem and this helped me after two days of struggling!

I'm using Win 8 64-bit and LV2013 32-bit.

 

Hope this helps.

Message 10 of 11
(7,709 Views)