03-20-2013 10:38 AM
Hello Christ0phe,
I think I found where the issue was located.
There are 2 things that should be changed when you build your executable:
- In the Advanced section of the Build Specification you should check the option wait for debugger on launch.
- In the Source Files section please ad your Global Test.ci to the Start Up VI’s section.
Normally the last option on itself should (in most cases) resolve the issue.
Can you test this at your side?
03-25-2013 07:34 AM
Hello, Thanks for your answer.... that I unfortunately do not understand.
If I follow your suggestion the Globals are now all updated BUT:
Basically you ask me to add all Globals of my code to the Startup VIs section when building an application. First off it is cumbersome especially with a code that includes dozens of Globals and also they will all pop up when starting the application !
The Global is certainly loaded as you can see in both my code and in the project (Test_Sub.vi is located in the Always Inlcuded section of the build application dialog).
Thanks
Christophe
03-26-2013 04:41 AM
Hello Christ0phe,
This was not meant as a final solution, but rather meant as a way to allow you to do some debugging in the meanwhile.
Seeing this response it seems like this work-around does not help you any bit further, we will have to search another approach.
As you correctly state, the global is being loaded, but it seems like the data values are not kept in the "debuggable" global unless when you write something to it, while you're debugging.
I have tried a lot of different options, but I don't seem to get the behavior you're looking for or would like to have.
If this is ok with you, then I would like to check with some R&D colleagues if there's no setting (behind-the-scenes) that I can use to obtain the wanted behavior.
About the other/first issue (opening subVI's on target PC), I'm still in communication with my colleagues.
03-28-2013 04:00 AM
Hello
Of course it is ok! Anything that would allow me to debug the applications I write will be much appreciated!
Thanks in advance
Christophe
-----
If this is ok with you, then I would like to check with some R&D colleagues if there's no setting (behind-the-scenes) that I can use to obtain the wanted behavior.
03-29-2013 07:49 AM
Hello,
Last 2 days I was Out-of-Office.
I started a parallel escalation about this issue.
However, with the Easter weekend it might be that I only get a response on tuesday evening.
When I receive a response I'll get back to you!
04-03-2013 11:13 AM
Hello,
After some talks with my US R&D colleagues we were able to pinpoint at which version the change regarding the opening of subVI's happened.
The decision for the change was made by NI R&D around the 2010 timeframe.
The details of this change have been kept internal only as they are relevant to LabVIEW's source code.
Seeing that you seem to absolutely require this type of functionality I would advise one of the following approaches:
- If this exact functionality is required, we would recommend continuing to use a LabVIEW version near 8.6-2009.
- Working with remote machine access for debugging and opening the VI's at the target pc.
- Replacing the Global Variables by Functional Global Variables or any other valid alternative.
We apologize for the inconvenience this change has caused, and I would also like to ask you to post your suggestion regarding the wanted behavior at LabVIEW suggestion on the LabVIEW Idea Exchange (ni.com/ideas). If many people agree with you, then it could be returning in one of the following versions.
Regarding the globals issue it seems like this is a bug in the Environment.
I also found a glitch that might be abused to be able to help you look at your globals:
- If you go inside the Stacked sequence structure in case 0 from your debugging pc.
- Then double-click on "String Initialized once"
- Then double-click on "Counter Initialized once"
Depending on the compilation the right values will show in the debugged global variable once one of those gets clicked in the beforementioned order.
Can you try this at your side?
04-04-2013 06:49 AM
Hello,
Regarding the globals issue I have filed a Corrective Action Request (#401421).
Feel free to check with me at any time about the current status of the CAR.
04-10-2013 03:44 AM
Hello, Not so clear to me:
- Issue 1: not able to open subVis of the executable and to keep them opened after the remote debug session has ended. Reverting my 200 applications worldwide to Labview 8.6 is not an option. I am sad to hear that this useful functionnality has been removed from Labview where on the other side we read in a lot of NI brochures that one of the strength of Labview is... its debugging capabilities. I disagree with the fact that this kind of change has been kept internal because clearly it has an impact to Labview programmer (us, the Labview community).
Isn't there a magical .ini trick that can be set to recover this ?
- Issue 2: Globals with wrong values. The 'glitch' that you propose is something that I indeed had observed but is not applicable as it is impossible to easily find one of the Vis that invokes the particular global that I am looking at. How long typically would it take to have the CAR taken into consideration by the development team?
Thanks
Christophe
04-12-2013 05:49 AM
Hello Christophe,
After some traveling I'm now back in the office.
Regarding Issue 1:
I have had talks with multiple US colleagues (R&D, support and marketing related) and they confirmed to me that there's no magical ini-trick.
Can you provide me with some specific use cases in which you need this specific functionality and there is no work-around?
If you have a specific use case that does not have an existing work-around, then this would also be a convincing factor to re-add that functionality.
This would also give me an extra item that can be used to lobby for a reappearance of this feature.
All of the use cases I have in mind can be replaced by a (relatively simple) other approach.
Probably I'm not thinking in the right direction over here or missing some specifics that you have.
04-12-2013 05:52 AM
Hello Christophe,
Regarding issue 2:
This is already reported to the development team and therefore also under consideration.
However, currently I don't have the feedback about in which version it should be fixed.