Jump to content

Steen Schmidt

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Steen Schmidt

  1. Upon further investigation I can see that it's not possible to add components from a packed project library directly to a palette (LabVIEW itself does not support this). Palettes containing LVLIBP methods/VIs has to be created in the original LVLIB. First you have an LVLIB, which you build an mnu-file for. This mnu-file you add to the LVLIB, and the entire thing can now be built into an LVLIBP with LabVIEW. Then it's possible to point LabVIEW at the mnu-file now embedded in the LVLIBP. For this process to be entirely handled by VIPB, you'd have to add "build LVLIBP" into VIPB as well (since that part occurs inbetween defining the mnu-file and building the output vip-file).
  2. Hi, Are there any plans for including support for LVLIBP in VIPB? Currently VIPB does not recognize LVLIBP as a LabVIEW file. A package containing only a LVLIBP requires SYSTEM instead of a LabVIEW version as build target. Even worse is that you cannot create palettes in VIPB with LVLIBP entries in them. The proposed workaround to create wrapper VIs to include in the palettes, that place their content, is no use: For proper documentation in the palettes such wrapper VIs must echo the conpane, terminal configuration, and VI Description as the LVLIBP VI it contains on its BD. But if you set this wrapper VI to place its content, all the wrapper VI's terminals will be placed in the caller as well. That won't work. Why LVLIBP? To do proper components in LabVIEW you need to use packed project libraries (PPL/LVLIBP). This is the only LabVIEW app build output that can be excluded from an executable, and thus the only component type that will alow patching of applications piece by piece. Source distributions cannot be excluded from executables for instance. Cheers, Steen
  3. Perfect Jim, thanks. I'll try the workaround and keep an eye out for the fix. I'm not permitted to follow that link, is the workaround the same as Jens Gräwe suggests here?: https://support.jki.net/hc/en-us/community/posts/360000027103-Error-in-Deactivation-Infos-in-VIPM-Pro Cheers, Steen
  4. Hi, I've noticed that packages will install without complaint when all dependency packages can be found, but even if these dependencies are of lesser version than the minimum required as specified by the top-level package. I thought that VIPM would complain during install of such a package, if the minimum requirements of dependency versions weren't achieved? Why else include version in the dependencies list? Example: A.vip specifies a dependency 'B.vip >='. A.vip will install happily even if B.vip is only available in version for instance. I'd expected VIPM to tell me "Missing dependency" in this case. Cheers, Steen
  5. Hi, VIPM 2014 build 1963. When building a package with licensing and adding palette to the library, this search box comes up during the build: The search doesn't find anything, and we just have to close the search box. The package seems to work ok though - what does this mean? Also, when we enable deactivation in the build spec. we aren't able to deactivate (only supported in LV 2014 and onwards). When attempting to deactivate LabVIEW tells us that the deactivation failed with the following message "Function call contains invalid arguments". NI has confirmed this and can get deactivation to work when using the TPLAT API before building the package (and thus not handle the license binding within VIPB). Anything we can do to get deactivation to work from within VIPB? Cheers, Steen
  6. Hi, When building a package it's really useful to be able to scan it for dependencies, but often I don't want a VIPC file*. Is it possible to use the "Scan for Dependency Changes" button, get that result into the Package Dependencies list of the main build configuration, but without a VIPC file on disk? The only way I have found to achieve this is by adding dependencies manually, but then it's easy to forget a dependency. * Usually we have many packages which all depend on their own subset of packages within the repo. Thus it wouldn't make sense to duplicate large parts of this repo out into a VIPC for each package. Cheers, Steen (GPower)
  7. Now I tried restoring the palette set to default (with the button in LV 2010's palette editor), but that didn't remedy the issue. I also tried a couple of other toolsets that I know installed perfectly earlier (with VIPM 2011). If something has gone wrong with my LV 2010 install, that reverting to the default palette set can't fix, or if it's an issue with VIPM 2012 I don't know. I'm inclined to believe the former, that it's my LV install that is somehow corrupt. I'll see if I can find something out since i need this to work. I unfortunately can't go back to trying with VIPM 2011 right now, as I don't think I have the install file for that anywhere. I'll return here if I find the reason for my problem. Cheers, Steen
  8. Ok, now I updated from build 1814 to 1818 and now I can install the packages - thanks. But the palettes on LV 2010 SP1 still do not update after I install VIPs. On 2011 and 2012 it works, so I must have something amiss with those LV 2010 palette files on one of my machines. I'll take a look at it. Thanks Michael! Cheers, Steen
  9. Hi. Some time shortly after upgrading from VIPM 2011 to 2012.0.1 my VIPs now fail to install correctly. The packages are both scripts that stems from VIPB 2011 and then updated a couple of times with VIPB 2012, as well as a couple of brand new ones created with VIPB 2012 - all behave the same. The issue started with toolsets not showing up in the palettes after install, so I manually had to edit the LV palette set and import the .mnu-files (since it is VIPs I've made myself it was easy for me to find the files in the vi.lib dir, but for a third party this step would've been difficult). Lately this problem has evolved into one of VIPB 2012 just hanging at the "Busy" screen after I've pressed the "Finish" button: The above happens on my development machine which is running Win7 64-bit, and the situation is the same when installing the packages for either LV 2010 SP1, 2011 SP1 or 2012f3 (all 32-bit versions). The VIs are developed in LV 2010 SP1. BUT, when I install the same packages on another machine (I've tried WinXP 32-bit with only LV 2010 SP1 installed) everything goes smoothly. The install runs as expected, the palettes get updated etc. What can be causing this? Could it be something with the palette situation on my dev machine? LabVIEW creates a new set of palette files in the Documents folder when you start editing the built-in palettes (as you're probably well aware), and these files might be harder to update correctly (it can at least be quite tricky to find the correct palette file to update, as they are stored in version and bit-dependent subfolders). Does any of this ring a bell? Cheers, Steen GPower
  10. Hi. I have used VIPM Free for a year and a half for non-commercial use (free toolsets for the LV Tools Network for instance). That might change shortly as I've started my own company (GPower). The current feature division between Free and Pro makes it impossible for me to use VIPM commercially though. Let me explain: Specifically I'd like to publish VIPs to a network location of my own choice, instead of just using the LabVIEW Tools Network. I could buy VIPM Pro and use dropbox for instance, or some other always-online site. That's fine for me. But currently there is the same requirement for any customer of mine, if they would like to access such a repository they would also have to buy VIPM Pro, simply because I've chosen to distribute my tools with VIPM. I've already lost one potential customer from this, as they have 20+ developers that could have used my tools. They are not prepared to fork out 10k USD to access my VIPs, and my margin isn't great enough to purchase the necessary VIPM Pro licenses to give to my customers. So, what to do? I could continue to use VIPM (Pro for myself) and make my customers monitor the network storage for VIP-changes manually, make them download the VIPs manually etc. There goes much of the advantage of using VIPM at all. ...or I could go back to the old way of distributing my tools; a self-inflating zip with mnu-files and so on. All the palette-editor tools are in place with LabVIEW, and self-inflating zips can be scripted in high detail for free today. Wouldn't it be wise to let VIPM Free be able to at least access remote repositories? You could still need Pro to build and upload the packages perhaps. Best regards, Steen
  11. Ok, so VIPM isn't modifying the palette files, but is relying on LabVIEW to autopopulate the palettes? I could possibly add an install (and uninstall) VI to the VIP to modify the proper palette files myself? /Steen
  12. Hi Michael. It's just the folders, no file content in them. And not all the folders, just some of them - and it differs which ones are left behind. Cheers, Steen
  13. Hello again. I have a couple of questions regarding the palette editor of the VIPB (using 2011 Community Edition of VIPM). 1) Is it possible to edit the short names of palette items? 2) I can put a sub-palette into 'Functions\Data Communication' for instance, but is there a way for me to define the exact position of my sub-palette therein? 3) How do I put my own palette or VIs into the 'Programming\Timing' palette for instance? This location (and many others) don't show up when I browse the Functions Palettes from VIPB. Cheers, Steen
  14. Hi. I've just made my first ever VIP of one of my toolsets that I'm thinking of submitting to NI Tools Network. In this respect I'd just like to hand out some mega Kudos to you for a job well done with the VIPM, and especially for making the package builder available in the Community Edition too. Thanks! I notice that some empty folders are left in vi.lib when I uninstall my VIP again. In this case using LV2009 SP1 on Windows XP SP3. My package is installed to vi.lib\GPower\VIRegister 1.3\, and it installs and uninstalls with no errors from VIPM. It differs which folders are left behind after uninstall. In one case it was these: vi.lib\GPower\VIRegister 1.3\Doc\ vi.lib\GPower\VIRegister 1.3\SubVIs\write\ ...and in another it was just this one: vi.lib\GPower\VIRegister 1.3\Typedefs\TypeDefContainers\ I wonder if the uninstall process quits early, or if it's something in my system that makes it fail? I can without problems delete the leftover folders using the Explorer myself just after the uninstall finishes, so if they are locked by some process making uninstall fail, it's not for long. I've attached the VIP file, and can of course provide the VIPB if necessary. Cheers, Steen gpower_lib_viregister-
  • Create New...

Important Information

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