Jump to content
curiouspuya

How to Retail Wire Values for ENTIRE VI Hierarchy

Recommended Posts

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

  • Like 1

Share this post


Link to post
Share on other sites

If he hadn't password-protected the block diagram, it would be pretty easy to convert it to a quick-drop plugin.

Share this post


Link to post
Share on other sites

If you activate private stuff (SuperPrivate... blablabla) you'll have access to this as a VI property : post-7452-0-60572600-1358772376.png

 

Then if you want to have a VI that enables this option to the whole sub-hierarchy of a VI you'll need to do some work, but be carefull before doing this on all sub-vis that will slow you down a lot, maybe you want to sort a bit and avoid those VIs that are in vi.lib and user.lib.

 

Also I think it will be much easier to get the VI's project item ref and then use the "get all descendents" method than trying to get the list of all sub-vis from the VI's ref directly.

Edit : or maybe I'm wrong : https://decibel.ni.com/content/message/36585#36585, in this discussion is shown a method to get VI's dependencies with some exclusion options, you could just remove vi.lib VIs fron there. 

 

If it helps, here's a VI I use to get all VIs in a project excluding VI.lib

 

post-7452-0-85229400-1358772955_thumb.pn

 

Edit : not sure the VI posted above sorts VI from vi.lib.

 

Hope this helps (and sorry for my messy answer)

Edited by Antoine Châlons

Share this post


Link to post
Share on other sites

Put these files in <LabVIEW>resourcedialogQuickDropplugins and Bob will be your Quick-Dropping uncle.  Ctrl-space, Ctrl-e will activate the plugin.

 

It'll ask you for Right Click API.llb, so you'll have to have the RCF installed somewhere.  (It'll be in <LabVIEW>vi.libaddons_JKI ToolkitsRCF API).  These are type-defs for a control on the password-protected VI Vishal Devanath gave us.

 

Now, as far as Flarn2006 hacking it for us, most of us can get at the block diagram without much effort but it's "wrong".  :P

QD_RetainWireValues.vi

Retain All Wire Values core.vi

  • Like 1

Share this post


Link to post
Share on other sites
[...]

Now, as far as Flarn2006 hacking it for us, most of us can get at the block diagram without much effort but it's "wrong".  :P

 

I didn't notice Neal's post until now.

 

Neal, aren't you worried that someone will accuse you of stealing someone's bicycle?

Share this post


Link to post
Share on other sites

I'd be upset if someone stole my bike, regardless of whether or not they cleaned and tuned it up before returning it.  On the other hand, I'd be pleased as punch if someone took and used some software I've written (even if they didn't return it).  The presence of a BD password indicates that the author doesn't share our sentiment. Your bicycle example illustrates one of the problems I have with "intellectual property": you can lock (and someone else can steal) a bike but It's impossible to "steal" software because the original "owner" hasn't lost anything.

 

Keep up the good work.

Share this post


Link to post
Share on other sites
well, the owner perhaps loses some revenue...

 

How has he "lost" anything?  He can still sell the software.

 

The only scenario I can find where someone isn't justified in copying software is if they have entered into a license agreement with the author (or employer, if they've agreed to write software for them).  Copying what you find "in the wild" is never theft.  License notifications in the software notwithstanding, as the copier hasn't, in fact, agreed to anything.

 

That said, I'll obey the law, even the ones I think are monopolistic and protectionist.  :D

Share this post


Link to post
Share on other sites
The author has potentially lost that single sale.

 

I understand your point of view; I just disagree with it.  :P  When we use words like "theft" and "property" and "stealing" we're not far away from using words like "crime" and "enforcement" and "arrest".  If someone "steals" software, then it seems natural to "punish" them for it.  Now, if the only damage you can point to is that the original author "has potentially lost that single sale" I say that there's no evidence that a crime was committed.  Please, Mr. District Attorney, put me on that jury.  :D

I'm sorry for taking this thread so far off topic...  :oops:  At least we have a few good options for setting Retain Wire Values in our LV2012 projects. :)

Share this post


Link to post
Share on other sites

I think if someone locks their block diagram for a simple feature that should have been openly included in the API they are making a less than benevolent statement.  On the one hand they are feely providing a help that they are not going to benefit from commercially.  On the other hand they are stopping peers from learning how it was done.  Why?  It's basically saying hey look how good I am!



in any case thanks very much guys for your help.  Antoine, you are right, you definitely have to be careful which VIs you retain the write values for otherwise it will go out of hand. 

 

All the best

 

p

Share this post


Link to post
Share on other sites

I think the reason NI password-protected the VI is not to prevent people from learning (seriously, why would they do that?) but rather to prevent misuse of a feature which has not yet had enough testing for a public release. Thankfully in the case of private methods and properties they have provided a "backdoor" of sorts for people interested in experimenting with them at their own risk: the SuperSecretPrivateSpecialStuff INI key. (This is what Antoine Châlons mentioned before.) No idea why they chose to do it for this and not built-in Xnode editing though.

 

Also, must every topic containing a mention of disabling LabVIEW's password "protection" turn into a moral debate? :D

Edited by flarn2006

Share this post


Link to post
Share on other sites

Nope... this one is password protected because that property is unsafe. Toggling the retain wire values at the wrong time causes LV to enter a bad state and crash. I have no idea if this is a technical limitation (i.e. adding the code needed to detect the crash and just return an error would require some change that would have a runtime performance impact) or if this is just a crash we decided not to fix. Regardless, this feature was not made public for a reason. 

 

As I've said before, we don't make things private just to be obnoxious.

 

> Also, must every topic containing a mention of disabling LabVIEW's password "protection" turn into a moral debate?

 

No. It is a moral debate from the beginning. It never turns into one. ;)

 

 

I think if someone locks their block diagram for a simple feature that should have been openly included in the API they are making a less than benevolent statement.  On the one hand they are feely providing a help that they are not going to benefit from commercially.  On the other hand they are stopping peers from learning how it was done.  Why?  It's basically saying hey look how good I am!

 

 

 

In this particular case, one could make the argument that the NI employee who posted this VI used poor judgement in releasing it, as the VI has the same potential flaw as the property node itself. There is nothing special about the VI that would make it any safer to use than the property node, which we deliberately made private. From that point of view, one would see it as a case of "R&D made the call to make it private, others who have access to private things decided to make it public without actually doing the legwork needed to make it public, but private things must be password protected to limit the spread of them, so they followed procedure and locked it down." Because there are times when wrapping an unsafe property node in some G code can turn it into a safe node, and in those cases, the node should be viewed as atomic... there isn't any "taking it apart" any more than you take apart a compiled DLL. Demanding to see the G code is absurd since all you're doing is disturbing the parts that make it safe to use.

 

 

From another point of view, it is *mostly* safe, and releasing it as a VI on LAVA is vastly different from it being discoverable in the property lists of LabVIEW ... someone who gets that VI probably gets it from a place where it comes with the warnings about "may crash your LV", whereas someone discovering it in the property list would not.

 

In neither case is it as "look how good I am". It is more that exposing it one way promotes it differently than promoting it another way.

 

No one is preventing peers from learning anything. There isn't anything to learn in these cases.

 

 

The evidence that a crime was committed is that they are using the software, and (hopefully for them!) making profit out of it. Cheaper/free alternatives probably exist, but the "thief" chose to use your software. Ergo you have lost a sale and thus money has been stolen from you.

 

In this instance there is a crime that has been committed, and there should be some enforcement; probably not arrest though.

 

 

Doesn't even matter if they are making a profit from it. If you play a video game that you didn't pay for, you aren't making a profit. You're still stealing. Cheaper and free alternatives might *not* exist -- they definitely don't exist in the case of a game title, and often don't exist for specific types of professional software. Doesn't matter.

 

 

If nothing else, you commit a crime by promising to abide by the EULA and then not doing so. That's called lying.

 

 

Actually, due to its virtually zero distribution cost I think all software should be free for non commercial (i.e. playing about) purposes. Smart businesses would realise that once somebody becomes familiar in a tool they are more than likely to use it in a commercial sense, in this case it would then be used in an environment where it had legally been paid for, so the software vendor wins then anyway.

 

 

 

Tell that to the game manufacturers... their software is *always* used for a non commercial purpose. :-) Even if you limit this to production-type software, there's a problem of the software author screwing his own paying customers. You have to be very careful ... if you provide your software free to one group and charge to another group, both groups can now produce whatever it is your software provides. That means you're empowering a non-profit group to completely undercut your paying customers. I have seen student projects worked up in dorm rooms that can be every bit as good as the professional software. You'll lose your paying customers if *their* market is undercut by labor willing to work free that has access to the same high quality tools.

 

I'm not saying that there isn't merit in the idea, but it isn't the slam dunk you claim.

 

 

anyway who more than NI knows that if they really want their IP to be safe they should remove the block diagram?  :shifty:

 

 

 

Which would be problematic since then the VI wouldn't recompile for upgrades or alternate chip sets or when you change the compile optimization settings.

 

but It's impossible to "steal" software because the original "owner" hasn't lost anything.

 

 

 

You gained an ability you did not have by using your copied software. The owner has also lost an ability -- the ability to make further software. The owner has lost the chance to recoup the time, talent and treasure that went into making the software in the first place. Just as what you gained by your theft was an opportunity cost, what they lost by your theft was an opportunity cost. Measuring gain/loss based on first-order value is very 19th century. As any capitalist will tell you, money loses value just sitting in the vault. We measure the economic value of all sorts of things as what they could be traded for, not what they actually are traded for. Software is no different. Weigh the cost of buying the software vs the cost of writing it yourself.
 

Flarn: I realize I have contributed to the hijacking of your thread, but I figure it's ok because I also contributed to the main topic at hand first. :-)

Share this post


Link to post
Share on other sites

Flarn: I realize I have contributed to the hijacking of your thread, but I figure it's ok because I also contributed to the main topic at hand first. :-)

 

This isn't my thread.

Share this post


Link to post
Share on other sites
If nothing else, you commit a crime by promising to abide by the EULA and then not doing so. That's called lying.

That's not a "crime". It (the EULA) is a civil offense and last I heard, lying wasn't a crime unless you were in a court under oath.

The war that's raging about whether pirating/copying is stealing will not be resolved on forums and, I don't think it will even be resolved in courts (as bizarre as it may sound). The argument on one-side is that an "opportunity" has been denied and needs to be recompensed to the amount that "could" have been obtained. The argument on the other; that an "opportunity" has no value, cannot be proven and cannot be "stealing" since it was never realised or owned.

Which side you sit on depends a lot on your world view and whether you prize cooperation over ownership. One is a communal view, while the other is feudal. History tells us that they are generally orthogonal and each rises to be the "norm" at various times. Again. Historically, cooperation has been the most common and invariably when the greatest leaps in human progress occur.

Might I suggest we move all these to the "Licencing" thread where they belong?

Edited by ShaunR

Share this post


Link to post
Share on other sites

Aristos Queue Thanks for your detailed perspective.  I see some of your points.  I didnt realise that the original provider of the VI was an NI employee to begin with (hence my "look how good I am" comment).  As for "stealing" concepts in the thread, I think that's going overboard.  The world is not so black and white (that is more 19th century).  Without a clear defenition of an author's wishes for the use of their creation one cannot make such judgements so clearly.  If I write some software (not as an NI employee) that solves some problem for my peers but I lock it without any intention to gain anything from this other than the awe and respect of my peers then I am actually being annoying and maybe going about it the wrong way.  That's how I had perceived the transaction to be.  Having read your perspective I do look at it differently now.  However, I would not use a one size fits all perspective to all situations where code is shared.  Anyway, thanks again for your comments and contribution to the thread.

 

P

Share this post


Link to post
Share on other sites
That's not a "crime". It (the EULA) is a civil offense and last I heard, lying wasn't a crime unless you were in a court under oath.

I was, in all honesty, under the impression that it was covered by the various wire fraud laws, like the ones that prohibit pulling a scam over a telephone.

Share this post


Link to post
Share on other sites
Copying what you find "in the wild" is never theft. License notifications in the software notwithstanding, as the copier hasn't, in fact, agreed to anything
That is fundamentally not the way copyright works! All software you write is covered by copy right as soon as you write it whether you write any copyright notice or not. By default this means anyone else cannot use it. A license attached then permits you to use it where copyright would have prevented you. It all comes back to copyright law.

Now if you find a piece of software in the wild with no license, no author details then it is probably very hard for the author to prove it is his and defend the case but that doesn't necessarily make it right.

(That is not to say I disagree with your point, if it is out there without a license that is probably the way the author intended it to be used, but legally there is no right there)

Share this post


Link to post
Share on other sites
That is fundamentally not the way copyright works! [...]

 

You're absolutely correct, I know.  I'm saying that copyright is absurd!  To think that legislation can redefine words...

Share this post


Link to post
Share on other sites
You're absolutely correct, I know.  I'm saying that copyright is absurd!  To think that legislation can redefine words...

 

Well, copyright was in the first place invented to protect creations, such as writings or even paintings. Maybe some want to claim that anybody can copy a book for instance and distribute it as his own, but I doubt anyone really would want to make that claim seriously. Unless of course you think writing a book is trivial and can not be viewed as an ability and therefore an author has no right to gain anything from trying to sell it. But whoever does that should please start writing their own books first and make them available for free before even trying to make that claim.

 

The application of copyright on software is in many ways flawed but it is the best we have generally come up with so far. It's definitely something not everyone can do, especially doing it good, so it would seem an ability that deserves some protection. Of course it would be nice if that would not be necessary since nobody needs to earn any money anymore as everything in this world is free and available to whomever needs it, but that is not how this world works, as we all know.

 

So why would it be ok to copy software for free and deny the creator a decent income but not to steal money from the rich as they have more than enough of it? Does someone really need Billions of dollars? Do you really want to limit software creation to "free as in beer"? Or do you say that the decision to pay for a software should be voluntary, no matter if you use it to make profit yourself or even just for some leisure time? I think whoever makes such claims should first have a proven track record of providing his own creations under such conditions, before he or she has any right of speaking.

  • Like 1

Share this post


Link to post
Share on other sites

All I hear are red herrings and appeals to emotion.

 

If I own a piece of paper and a pen, and I write on that paper something that I read somewhere else, the natural conclusion to copyright arguments is that the original author and/or government is justified in using whatever force is necessary (including murder) to prevent me from selling it.

Share this post


Link to post
Share on other sites
All I hear are red herrings and appeals to emotion.

 

If I own a piece of paper and a pen, and I write on that paper something that I read somewhere else, the natural conclusion to copyright arguments is that the original author and/or government is justified in using whatever force is necessary (including murder) to prevent me from selling it.

 

You realize that the emotional aspect of this thread has really just started when you brought in murder!

Share this post


Link to post
Share on other sites
[...] So why would it be ok to copy software for free and deny the creator a decent income but not to steal money from the rich as they have more than enough of it? Does someone really need Billions of dollars? [...]

 

An example of an appeal to emotion.

 

You realize that the emotional aspect of this thread has really just started when you brought in murder!

 

That's how far enforcement of copyright naturally extends.  If I don't stop selling my paper when I'm told and, if I resist what I feel to be an unjust arrest, does the enforcement just stop?  Do we only enforce copyright with people that will stop when they're told to?  Or, do we use whatever force is necessary to gain compliance?

Share this post


Link to post
Share on other sites
That's how far enforcement of copyright naturally extends.  If I don't stop selling my paper when I'm told and, if I resist what I feel to be an unjust arrest, does the enforcement just stop?  Do we only enforce copyright with people that will stop when they're told to?  Or, do we use whatever force is necessary to gain compliance?

 

With this reasoning any law enforcement attempt would be useless. But as it seems it is usually quite effective without the need to get the death penalty invoked, and to my knowledge even in the US exist states where the death penalty is not even an option as means to enforce the law. And in this particular case, stripping the offender of the monetary gain and some additional fine is usually the modus operandi, with possibly jail for repetitive offenders.

 

Death penalty for copyright violation would seem really archaic to me, and at least here it's definitely not an option.

 

As to the fact that reasoning with stealing money or the work of some writer, certainly has an emotional component, claiming that stealing software or a book by copying it is both legally and/or morally right would seem emotional to me too already.

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
      The TL;DR is in bold.
      I want to add to the Conditional Disable structure a new built-in symbol that toggles when the VI's "Debug Enabled" setting is toggled.
      I've wanted this for a long time, but I finally got around to opening up the code to see what's possible.
      Let me take care of one question right away: I have no idea what version of LabVIEW this might or might not go into. So don't get excited. :-)
      Anyway... it turns out, what I'd like to do isn't straightforward. All existing conditional disable symbols are global to the application instance. The three built-in symbols -- bitness, target, and run-time engine -- are universal to the running environment. The symbols that users can define are in the project and target. In other words, if I want to know the value of any symbol, I just need the reference to the application instance, not to a particular VI. And, guess what, all the C++ code is therefore oriented around application refnums not VI refnums. *sigh*
      Now, it turns out that I can see a way to add the debug-enabled flag in a sort of sideways manner, and I would just hardcode that symbol as a special case in some parts of the code.
      RED FLAG! Alert! Developer has used the phrase "special case"!
      One of my colleagues likes to refer to the "0, 1, Infinity Rule". That is, there are either zero cases of something, one case of something, or an infinite cases of something. There's never just 2. Or 3. Or any other finite number. Basically, as soon as you are prepping the second special case, your code needs to be architected to accept an infinite number of such special cases because otherwise, you're going to build up a huge number of unmaintainable hacks over time. If there really is just one special case, then the code generally remains maintainable. One special case isn't a hack... it's just the special case of the problem you're code is solving. The second special case is a hack.
      I try to avoid hacking up the LV code base and developing more stuff that needs refactoring in the long-term, so I'm hesitating about working on this feature. With this in mind, I went to a couple of other dev and asked a question, and I want to ask the LAVA community the same question:
      Besides "enable debugging," are there any other VI-specific settings that would cause you to want to change the actual code compiled into the block diagram?
      I honestly cannot think of any. Reentrancy? I don't typically change the reentrancy of a VI on a regular basis. A VI is either designed to be reentrant or not... flipping that switch usually changes how the node is used entirely. Thread affinity? I can't think of any VI where I have ever wanted to sometimes have the VI in UI thread and sometimes have it in Exec System One, and where I wanted different code in those cases. No one else I've asked has been able to come up with any scenarios for that sort of thing either. Oh, the hypothetical COULD exist, but hypothetically, I could want the font on all my numeric controls to become italic whenever the VI is set to "run when opened". It ain't a real use case. :-)
      One person suggested that there might not be VI-property-related settings that would want to change out code on the diagram, but maybe there is a case for user-defined symbols at the VI level? Maybe. But, honestly, the Diagram Disable structure pretty much covers the "I want to change out the behavior of this VI". Yes, we all know cases where we have code on the left half of the screen and code on the right-half of the screen, and we need a separate disable structure around those regions... but that's just as probable as having that right-side of the screen dropped into a subVI. The setting then is not a per-VI setting, but it is either a per-project setting (which we have today) or a per-library setting... and that I can easily imagine a use case for. Having a per-VI user-defined setting just seems problematic if you dropped the code into a subVI and lost the link between those two VIs. I hate adding any feature that discourages people from creating subVIs as needed! So I'm rejecting that use case. And the library use case, while a good one, is outside the scope of what I'm asking about today. Go put it on the Idea Exchange if you want to promote it. :-)
      Which brings me back to the "debug enabled" setting. That setting can be programmatically toggled when doing a build (if you go into the custom per-item settings because NI doesn't have an easy single-checkbox for you) and frequently we do things while debugging that would just slow down a release build. Which means it makes sense to write code into the VI that could be either compiled in or compiled out based on the VI's debug settting, unlike any of the other settings.
      So... brainstorms anyone? And please be honest. Even if you want this specific feature, and you think, "Well, if I present this valid use case, it means he won't put in his hack, so I'm cutting my own throat," trust me... for the long-haul, you'd rather LV develop as cleanly as possible, for the sake of your own trust in it!
    • 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 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.