Debug Executable

[Squal]

Hi every@ll,


I have developed an application in Labview v8.6 ActiveX used to call the MATLAB software (by MatlabScriptNode) and a small program run well with the rest of Labview code.

Under Labview everything works fine but when running the application. Exe generated with Aplication Builder is not true. Everything works except when the call is made to MATLAB.

I tried to use Debug Aplication from localhost to find the problem but when run will not let me browse and select menus I have in the developed application. This issue is another detail I'd like to find. How to handle menús in debug aplication?

Regards

[DaHelmut]

Hi,

I don't clearly understand what you are doing :

Are you using a Matlab ActiveX called by LabVIEW ? Are you using a remote front panel ?

How are you handling erros in your application ? You should maintain dataflow in order to know if an error occurs in your application and the you'll be able to debug it.

Can you post your VI or an example that would reproduce your issue ?

Regards,

[Squal]

Hi,

i explain you:

I have a mean program  VI working fine with deveploment (inside has Matlab ActiveX called by LabVIEW) . When i build the executable with aplication builder all works correctly excepts the part where calls matlab file.

I dont hand errors because doesn´t crash but not working as expected (performs others cases of code that sholudn't occur). I think the problem is related to the paths, i mean the fail is when build the .exe file.

For this reason i want to debug to see the blocks diagram and check the paths used when the Matlab Call occurs. But in debug mode from localhost (remote front panel in the same pc) doesn´t let me navigate over menus that i have created. However, i can handle menus perfectly running the build executable.

I'll try to upload a file example later

Regards

[sendia]

Hello Squal,

To debug executables, just follow the indications of these links (to debug local or remote executables):

http://digital.ni.com/public.nsf/allkb/3087D91EEADBAF3D862571D1004AF192?OpenDocument

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

However, if the problem is with the ActiveX control, there are a number of different reasons that ActiveX objects may not work. This KnowledgeBase gives a few ideas to try before contacting Technical Support.

1. Ensure that your VI is working without any errors. It may even be worth checking for warnings too. One way to check for warnings would be to place a probe on the error cluster in the VI and monitor what happens or comes through.

There are a number of ActiveX warnings and these may be causing problems when the application is deployed.

2. Check that there are no programs stopping ActiveX programs from running. These can include any of the following: Anti-virus programs, Firewalls, Network policies, Windows Defender and Windows Firewall.

If any of these pieces of software are installed, check their settings and verify that they are not interfering with the ActiveX execution.

3. Also try registering the ActiveX program with Windows. Details of how to do this are located in this KnowledgeBase - How Do I Register or Unregister An ActiveX Control?. If you want to do this dynamically at run time, use the System Exec VI to do this.

[Squal]

Hi again,

At the first I followed always the indications  of these links and i can debug the local executable but with the inconvenience that doesn´t let me hands the menus toolbar. Everything works fine unless this detail so i can´t show the blocks panels of sub vi i'm interested to check.

By the other way there can´t be programs stopping ActiveX programs from running because it works under the file.vi correctly.

I want to know the reason that doesn´t appears the menus:

I'll try to check the other options in next days

Regards

[sendia]

The following list contains some guidelines or steps you can follow to view custom run-time menus when debugging:

• Whether you use the VI Server to load a specific *.rtm file programmatically or you link the *.rtm file directly to a specific VI, you must remove the checkmark from the Wait for debugger on launch checkbox on the Advanced page of the build specification Properties dialog box.
• To guarantee a specific entry point when debugging your application, make use of a structure, such as a sequence structure or a While Loop, to enforce the appropriate data flow.

The attachment shows one possible solution using a Flat Sequence structure. The code before the Flat Sequence structure sets a customized run-time menu and checks whether you can remotely debug the application. The first frame of the Flat Sequence structure guarantees a specific entry point during debugging because of the restriction that it is not allowed to use the Wait for debugger on launch option. You can add your code to the second frame of the Flat Sequence structure. Also, notice the Start Debugging control. Ensure that the Start Debugging control is not hidden when you build the VI. In this example, the programmatically processed menu entries are not affected.

[Squal]

Hi, I found the cause of the error. This was the path to the directory where the file requesting (process.m)

Processv.m is created with aplication builder in c:\documents and Settings\Lan\Escritorio\Install tometor\SETUP\APP  but  when it's created,  the path change to "c:\documents and Settings\Lan\Escritorio\Install tometor\SETUP\APP\tometor.exe"  instead "c:\documents and Settings\Lan\Escritorio\Install tometor\SETUP\APP\"      (i don´t know why because in the VI worked fine).

 I had to add another "strip path" while running directly the VI file didn't generated errors, I mean the path was correctly indicated but when i built de aplication.exe didn't work.

Thanks all

Regards

[Yamaeda]

That's a classical problem, when built into an executable, the .exe name works like a folder (you can consider it as all VI's being compressed into a .exe), thus, if you access a file outside the project you'll have to handle an extra folder.

The benefit of the system is that all VI's that are 'compressed' this way works.

/Y