Jump to content

iwire

Members
  • Posts

    5
  • Joined

  • Last visited

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
    1990

iwire's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. asbo, No cuts, just embarrassed. Linking the main-VI to shared/reusables does make application (embarrassingly) vulnerable to modification. It bugs me and you pointed it out immediately! I don't use the VIPM - not sure I understand it's application here. Is this controlling a VI-lib object which application SOURCE code refers to? Or, does the VI-lib object live on targets with deployed apps? Re: SVN and tagging dependencies (VIs) automatically. The tag will identify the app&version being released and shouldn't show-up on any objects(VIs) under Common folder - unless the VI is part of current released app. This would seem to imply a "high" degree of integration between SVN and LabVIEW - maybe unrealistic.
  2. Paul, Yair - Thanks. I followed link re: "Externals" and read JK's coverage with great interest. If I understand correctly, tagging is applied to folders (via symbolic-link)(?) Am still hoping to tag only VIs that are part of an application being released...
  3. asbo - Ouch! - Yes, this shared-area, open for edit, is a liability. Of course edits can be made with existing code in mind. While I'd like to create/control application-specific instances (of generic VIs) with a release, I've no idea how this would be handled as far as (unique) VI naming/organization, or how I'd track every usage of a generic VI, in case it needs a bug-fix. Again, any/all ideas are welcome.
  4. Hi Steve, In order to help troubleshoot these kinds of dependency-issues with dynamic calls, it can be useful to open the FP of all a VI's broken sub_VIs. I typically check for errors when loading the dynamic VI, and if the open throws an error, then call an "OpenBroken.vi" (passing it the VI path) which does a recursive traversal of the broken VI and its dependencies - opening only the broken dependencies. The deepest (broken) VI is the last opened - just click on the broken-arrow... This method doesn't necessarily yield a better/good/more-helpful error message - in fact it's success rate is probably less than 50%. But when it does work, it saves so much debug time as to be well worth the investment! I'm at home and didn't have access to this tool, so built&tested it again. (in other words, i think it will work...) Luck/Cheers. Util.VI.OpenBroken.vi
  5. Greetings!, A quick search didn't reveal any titles appearing to address this specific question... My application's source-code is organized under two directories - a project-specific directory where all the sub-VIs and directories are part of the application, and a "utility" directory which contains a hierarchy of generic functions used by many projects. When releasing an application revision, (i think) it's necessary to create a tag in order to obtain a snapshot of applicable VIs, however, if the tag is applied to the "generic" folder, it will be applied to many VIs, the majority of which are not applicable to the release. I'm relatively new to SVN and wondering if SVN and LabVIEW can be integrated in a way that would allow a tag to be applied to [only] the dependencies of a top-level VI. Any ideas, including alternative approaches, are welcomed!
×
×
  • Create New...

Important Information

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