Jump to content

Jim Kring

JKI Team
  • Content Count

    1,688
  • Joined

  • Last visited

  • Days Won

    40

Everything posted by Jim Kring

  1. OK, great. Thanks for taking the time to report your experience. It helps us know where we can make things easier to use. Thanks,
  2. Hi Eric, This is one area that we're working on. VI Packages in a VIPC that are not being called by your project will be suggested for removal after doing a scan project for dependencies. We're working on adding a way for VIPM to know that you added the VI Packages Manually, rather than through a scan project. Also, we're looking at ways for you to specify dependencies that are not listed in the VI Package Configuration (.vipc) file. For now, you'll need to work around this, by ignoring VIPM's suggestions to remove the packages after a scan project for dependencies. Does this help you resolve all your issues, or is there still a problem with dependencies getting build into the package? Just to be clear, any packages marked as External Dependencies in the dependencies list of the VI Package Builder's Advanced Build Settings dialog should not be built into the package? Are you seeing something that contradicts this? Thanks,
  3. Hi Martijn, I found this thread on NI.com where a user was experiencing segmentation a fault on Ubuntu. The solution that the user found was to upgrade to a stable release of Ubuntu. NI support might be able to provide you with more answers (or at least point you in some good directions). It will probably be tricky to pinpoint the problem, as segmentation faults can be caused by a number of things. Of course, it might be as simple as changing to a different version/build of Ubuntu. Good luck and please keep us posted as to whether you're able to resolve the issue. Thanks, -Jim
  4. Hi Eric, > We have several packages in our code library that do not seem to detect the correct dependencies. So when the package is installed, it includes copies of VIs that should be sourced from other installed packages. Have you set the dependencies to be "External" (this prevents VIs from being built into the package) in the Dependencies tab of the Advanced Build Settings? Internal Dependency External Dependency See here for a detailed explanation: http://jkisoft.com/vipm/guide/managing-package-dependencies/ > There also seems to be a disconnect in the .vipc and the .vipb files. The VI Package Configuration file does not list all dependencies (see attachment .vipc.png), but they're present in the .vipb file: This is by design and might change in a future release of VIPM -- the .vipb sometimes contains packages that are no longer in the .vipc file. Please let me know if setting the package dependencies to External Dependencies fixes the issue for you. Thanks, -Jim
  5. Great idea! We're already working on it, so please stay tuned... Thanks,
  6. This is by design -- the "Revision" number was (a long while ago) intended to signify that the package contents had not changed, but the item had been repackaged. We decided not to expose this to users. We're considering adding support for a build number in a future release.
  7. I think you're still describing a feature, rather than a use case Can you tell me what task you are trying to achieve, and what information will help you? The reason that I ask is that a general purpose visualization tool would be cool, but it won't be easy. However, we're actively working on several features that will help you answer specific questions, related to dependencies. So, I want to make sure that I understand which points in the development work-flow you're at and what questions you'd like answered. I'll give you a hint at some of the things we're working on. We'd like to provide answers to several questions: Which packages does a project use? Which projects use a package? (keep in mind that a project can be the source code for a VI Package) For a given project: which VIs call a given package which VIs call which VIs in a given package Thanks,
  8. I agree with you that there is no ideal solution, except for NI to fix a few things, and that the "exclusion list" in the VI Package Builder would be a good work-around. Looking for a stop-gap solution... one thing that I'll commonly do is create a Call by Reference wrapper API around VIs located outside of user/vi/instr.lib that I need to call. For example, I commonly do this for VIs located in the "resources" folder. How many Variable Manager VIs do you need to call?
  9. I agree with Ton that: A) this is a great feature request (and one that is on our radar) there might be a better way to solve the problem, since depending on VIs outside of vi.lib, user.lib, and instr.lib is generally going to cause you problems at some point. One thing that you might consider doing is creating a VI Package of the Variable Manager VIs and have your "API code" depend upon that package.
  10. Hi Ton, Sorry for the trouble. I've send you an email with a newer, pre-release version of EasyXML to test -- it should fix the problem that you're having. Thanks, -Jim
  11. Hi Dave, I'll email you some details. Thanks, -Jim
  12. Just so you both know, this dialog is a little misleading. It actually catches a few problems, but doesn't report them well. It catches the following problem situations: VI Package Source VIs in memory before the build starts Duplicate VIs in the VI Package Source Folder Cross linkages to VIs outside your VI Package Source Folder with the same name as VIs inside your VI Package Source Folder In the next version of VIPM, you'll find that this dialog is better in a couple ways: It will tell you which VIs have a problem It will tell you what the problem is For now, hopefully the above information is useful to you, in trying to figure out which problem is causing the dialog to show. Thanks!
  13. Hi Bob, The # character cannot be used in XML names, according to the specification, here: http://www.w3.org/TR/REC-xml/#sec-common-syn As such, EasyXML will delete it from names. Of course, interpreting the XML specification can be a bit of a "treasure hunt", unless you have a really good understanding of regular expressions Thanks, -Jim
  14. These are good ideas. And, we're actively working to make this better. I'll ping you off-line when we're ready get some feedback on our plans.
  15. This is a good idea. In the long run, what I'd like to see are some features that made it easier for you to scan your project, while you are working on it. The time to scan isn't right before a build. We got some ideas in the works and we'll keep you posted.
  16. Hi Fraser, Did you try my suggestion, below? Thanks, -Jim
  17. Richard, I'm glad to hear that it's working for you, now. Thanks,
  18. Hi Richard, You're right, in that there isn't a way to specify a data structure in LabVIEW that generates XML data where empty elements are optional (and omitted from the XML). One way to achieve this would be to dynamically generate the variant input to Easy Generate XML function using the OpenG LabVIEW Data Tools library. Another option might be to post-process the XML data (as you suggested). You can remove empty tags, fairly easily using the "Find and Replace String" function in regular expression mode, using a regular express for valid empty tags. Removing empty attributes would be a little bit more difficult. Thanks, -Jim
  19. Hi Richard, I'm not sure why opening EasyXML causes LabVIEW to look for registry VIs. If you do a Save All, does it do this again, the next time you open EasyXML? Thanks, -Jim
  20. Hi Bob, Your use case sounds like it's exactly what we're working to address with VIPM Enterprise (here's a quick glimpse). If you'd like to participate in the private beta, we'd love your feedback and help in putting the product through the ringer. -Jim
  21. Hi Tim, We haven't released this improvement, yet. However, EasyXML customers can contact us for a pre-release version of the new version. Thanks, -Jim
  22. Hi Norm, I think it's a great idea to add Package Name and Version to the parameters passed into the build hooks. You should be able to parse these parameters from the "Output Package File Path", which is accessible in the post-build hook parameters. Would that work for you, in the short term?
  23. Hi Ben, I like this idea! I don't see any reasons not to add this feature. -Jim
  24. That's actually an image in the lower-right corner of the VI front panel. I've asked the VIPM developers to write a blog article about this, showing how they did it.
×
×
  • Create New...

Important Information

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