Jump to content
Aristos Queue

Help talk me into or out of this hack: a new conditional disable symbol

Recommended Posts

21 hours ago, Aristos Queue said:

This comment is really bugging me.

To me, toggling debugging is the same as moving from Desktop to FPGA. The entire code base is compiled differently for the new target. I cannot see anything about the existing Enable Debugging option that is an existing hack...Can you expand your thoughts for me here?

I'd expect compilation to be different, how else will all the debug symbols get put in place? But what I don't expect is all the other stuff you said goes on. The text presented to me in the dialog says "Allow debugging." Not "Enable debugging, and constant folding, and loop invariant analysis, and target specific optimizations, and a bunch of other stuff."

I expect the checkbox to toggle letting me attach a debugger to the VI to perform various forms of debuggery. Stuff like breakpoints, probes, step execution. 

Taken directly from the LabVIEW 2017 context help:

Quote

Allow debugging

Allows debugging on this VI. For example, you can set breakpoints, create probes, enable execution highlighting, and single-step through execution. Remove the checkmark from this checkbox to reduce memory requirements and improve performance slightly.

I've been using LabVIEW since the 90s and had no idea other optimizations were tied to this checkbox until you mentioned it the other day. Nowhere had I ever read it was. It may be obvious to you, someone who's intimately familiar with the innards of LabVIEW, but LabVIEW.exe is a black box to me.

That's what I mean by hacked up. There's a discontinuity between the function and indication of that checkbox. The fact that the setting affects things other than debugging means one of two things: the setting shouldn't be used for these other purposes; or the function of the checkbox has not been clearly expressed.

I'm not trying to argue against having these optimizations and such. They're good and part of what makes LabVIEW so efficient. But since that checkbox really isn't "Allow debugging" and more "Allow pandora optimization", it may warrant some review of how the information is presented to the user?

You'll also be my hero if you can get the word "debuggery" into updated UI or documentation.

Edited by mje

Share this post


Link to post
Share on other sites
25 minutes ago, ShaunR said:

I would like to see a case implemented for the "LabVIEW version"

Oh that's a good one and one I have used in the past.  I had found that in some versions of LabVIEW, some methods of doing functions were more efficient than others.  And so I would have the VI on start read what version of LabVIEW it was running in, and then do things differently based on if it was in 2015 versus 2016.  Of course there are other issues in that this needs to be saved in the oldest version supported, and that would generally mean not using some new features that might be more efficient.  But my point is I would have found LabVIEW version useful in the past.

Share this post


Link to post
Share on other sites

mje, to make things worse regarding the "Enable Debuggery" flag, what it ACTUALLY does is not only secret but also varies depending on the actual code complexity (real complexity, not what LV pretends it is) and the setting for "Limit Compiler Optimisations" in the Environment settings....

Share this post


Link to post
Share on other sites
23 hours ago, hooovahh said:

 Other things I check I can see changing at run time like if the actor is in a subpanel I may behave differently, or if the VI has its window showing.

Right, but I'm asking for things that you could change at *compile* time. Anything that toggles at run-time is irrelevant to my question in this thread.

Share this post


Link to post
Share on other sites
7 hours ago, mje said:

 Not "Enable debugging, and constant folding, and loop invariant analysis, and target specific optimizations, and a bunch of other stuff."

You have it backwards. In order to enable debugging, we have to turn OFF all that stuff. That's what allows debugging is doing away with all the optimizations of the code. The optimized code looks nothing like the block diagram and isn't amenable to exec highlighting, probing, etc. These aren't orthogonal things... enabling debugging MEANS turning off all the stuff that prevents debugging.

The documented reduction in memory and performance improvement? Turning off debugging allows all those things to kick in. The only error in the documentation to my eyes is the word "slightly".

Edited by Aristos Queue

Share this post


Link to post
Share on other sites
4 hours ago, Aristos Queue said:

You have it backwards. In order to enable debugging, we have to turn OFF all that stuff. That's what allows debugging is doing away with all the optimizations of the code. The optimized code looks nothing like the block diagram and isn't amenable to exec highlighting, probing, etc. These aren't orthogonal things... enabling debugging MEANS turning off all the stuff that prevents debugging.

I see, yes that makes sense. I get how that's a problem in LabVIEW since there is no lower level representation presented beyond the block diagram. For example when I debug my optimized gcc code I can always peer at the resulting assembly to get an idea of what's going on when code seemingly jumps from line to line or look at registers when a variable seemingly vanishes and never makes it's way into RAM. Without a lower level presentation, you're pretty much hosed with respect to debugging if any optimizations are enabled.

I withdraw my objection, especially since there's some reference to optimizations in the dialog if I recall.

Seriously though, thanks for taking the time to set me straight. Cheers, AQ.

Share this post


Link to post
Share on other sites
20 hours ago, mje said:

I see, yes that makes sense. I get how that's a problem in LabVIEW since there is no lower level representation presented beyond the block diagram. For example when I debug my optimized gcc code I can always peer at the resulting assembly to get an idea of what's going on when code seemingly jumps from line to line or look at registers when a variable seemingly vanishes and never makes it's way into RAM. Without a lower level presentation, you're pretty much hosed with respect to debugging if any optimizations are enabled.

I withdraw my objection, especially since there's some reference to optimizations in the dialog if I recall.

Seriously though, thanks for taking the time to set me straight. Cheers, AQ.

No problem. It helps me to know how customers see the world... sometimes we can restate things in more intuitive ways. :-)

Share this post


Link to post
Share on other sites

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.


  • Similar Content

    • By Aristos Queue
      Giant VI hierarchy. Runs for some long amount of time. Somewhere in the mess, a value is generated that is causing the program to go awry. You only know about it at the point where the program goes wrong, which appears to be a long way from where the value was generated.
      Your challenge: Find the VI that is generating that value and make it generate some other value.
      I've had to debug things like this in LabVIEW before... I just tried something that worked surprisingly well. It works if the value to be generated is somewhat unique in your application (i.e. a particular string or a particular double value... doesn't work so well for common values like "1" that may occur a lot in your application).
      Steps:
      Run a quick bit of scripting to change all of your VIs to enable "Show front panel when called" and disable "Close afterwards if originally closed". See picture. Run your top-level VI. Set a breakpoint in the subVI where things are going wrong -- which you know has to be after the value is generated. (optional) Abort the VI hierarchy. This just cuts down on other stuff happening in the system. Now you can use ctrl+F and do a text find for the value. Because all the panels were open, the value they last emitted is on their panels. Even if it is nested inside an array of cluster of array of cluster of... etc. Even if it eventually got packaged into a DVR or passed through some other data-passing mechanism, the original VI that generated the value will still have the value on its panel unless that VI has been called again for some other purpose. This does slow down your whole application -- having the panel open makes LV spend a lot of time updating the controls and indicators, which is a lot more data copies. But at least in my most recent case, this strategy was effective. I figured I'd pass it along. By using the "Show front panel when called" option, you get all the reentrant clone VIs, which you won't get if you just open all of the source VIs in your project.

    • By _Y_
      Hi all,
       
      I got a strange queue behavior that is probably related to race conditions. The problem is eliminated (a way around is found), so there is no need in a quick solution. However, I would be happy to understand reasons for such a phenomenon.
       
      BD of the “problematic†VI is attached. The queue size is limited to 1. The program consists of multiple asynchronous processes.
       
      Execution reaches the Enqueue Element node than stops. The timeout never happens; the program hangs. However, there is more. If I try to execute the VI step-wise, everything works fine until the execution enters the internal Case Structure. When it enters, three Stepping buttons become disabled.
       
      If I try to decompose the program, i.e. to use the same VI in a simple single-process program, both problems disappear.
       
      Have you encountered such a strange behavior? Any ideas that can help to the poor creature (me) to avoid sleepless nights?

    • By curiouspuya
      Hi all,
       
      Have you ever tried to debug a large application and wished that you could quickly retain wire values on all VIs in the main application so you could find your problem with data etc?
       
      I would love to have a function where I could quickly toggle the "Retain Wire Values" button on all my subvis (ideally also be able to choose how many levels I do this down the hierarchy).  My colleague and I have searched for a property node or a method in the scripting functions but have not found anything other than "Highlight Execution" setting.  Is this a hidden feature or have we just not looked hard enough.
       
      This question was asked by others back in 2009 : http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Enable-Retain-Wire-Values-for-entire-VI-hierarchy/idi-p/1045552
       
      Vishal Devanath came up with a JKI RCF vi to do this back then but this no longer seems to work (at least in LabVIEW 2012).
       
       
       
      Any ideas? 
       
       
       
      P
       
       
      "Give a man a fish, and he will live for a day.  Teach him to program LabVIEW™ and he wont need fish again"  Confucius cira 480BCE
    • By JodyK
      I recently spent some time describing a logging tool that we use here at DMC that has significantly reduced our debug times and helped a lot with onsite support and I thought it was worth bringing it up to the LabVIEW community.
      Essentially, it's a logging utility based off of NLog that allows the user to add the equivalent of print statements to their code - any string that can be built is fair game. It also allows a logging level to be associated with the print statement and this is the concept that makes it extremely powerful. Some statements can be low-level "trace" statements, while others are "warnings" or "errors". During run-time (even in an executable) the level of the logger can be changed and you can easily do trace-level debugging for a glitch, and then set it back to an informational level afterwards.
      Multiple targets are supported, including RT console, log files, TCP/UDP streams, and email. All the calls are made asynchronously, so the debug statements have a minimal impact on the code execution.
      At this point we are finishing and polishing the implementation, but more information and details can be found in a blog post I recently wrote:
      NLog for LabVIEW: Logging done properly
      -Jody Koplo
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.