Jump to content

Marc Blumentritt

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Marc Blumentritt

  1. Please zip up your source folder (which should include a file called .vipb) and attach to your reply. I will take a look at it.

    If you like for faster service please use our support form here:




    Here it is.






    Just found a bug in my source. There was a broken control, which could not be opened. I fixed this and everything is working fine now.



  2. Hi,


    I have around 20 packages, placing them inside a VIPC-file, which is saved on the file server of my company (Novell Netware) for my colleagues. When I try to install the packages from the VIPC-file directly from the file server, it takes ages to load the list of packages inside the VIPC-file. Copying the file to my local disk and installing from there just takes seconds, if at all. What could be wrong there?


    Thanks for any help in advance,


  3. Hi,


    I do have another solution (tested with VIPM 2.0.3): instead of choosing in the menu "File -> Apply a Package Configuration" you can use "File -> Add Package(s) to Package List" and than choose the .VIPC file. This lists you all packages inside the .VIPC and allows you to install these, even if the .VIPC file was made for 8.5 and you want to install the packages in 8.6.


    I d'ont know if this is an intended feature.




  4. Hi,


    I have LV8.5 installed and all my packages are created with LV8.5. I bundle my packages in a .VIPC file for sharing with my colleagues. But I have a problem: some colleagues use LV8.6. They cannot use my .VIPC files, since they are made for LV8.5. I changed manually the version in the config.xml to 8.6, but than VIPM says, that this is not a valid .VIPC file (I changed the version via unzipping with WinRAR, editing the file, and adding it again to the .VIPC file).


    Therefore my question is, how can I create .VIPC files for not installed LabVIEW versions or modifying an existing .VIPC file?




  5. I'm also trying to create a "meta" functions palette like the OpenG and JKI palette to put all the company re-use code in, can you help out please?


    I can tell you how I made this. I'm using LV8.5, therefore I have to create the meta palette by hand, since with LV8.5 you cannot create palettes with VIs. I used the palette editor to create my palette at the planned location (<lvfolder>\menus\categories) and set it to synchronize with the folder, where I place all my reusable VIs and palettes. Then I used the OpenG Package builder to create a package, which only contains my .mnu file. I make all my packages to depend on this palette package.


    I also did this for my control packages.


    Hope this helps.




  6. We are working on a solution to this problem which we've called 'VIPM Enterprise'. VIPM Pro customers can contact us for a private Beta copy to evaluate it. Basically, with VIPM Enterprise, we help to create a 'Package Repository' where you can publish your packages. When you have published them, your colleagues can see the new packages by doing a VIPM 'Check for Updates' just like VIPM currently can check to see if JKI has released packages to the VI Package Network.

    As a Pro Customer I would like to evaluate the enterprise version. But since I will be three weeks out of house, I will contact you in the middle of August about this.

    Yes, this is correct. The way that your colleagues will 'get' the updates is to 'apply' the package configuration. Additionally, you should create the VIPC file on a per project basis so that each project can be managed on a different configuration from each other, this insulates changes to packages in one project from impacting other projects.

    OK, thanks for the info.

  7. Can you explain a little more about what you'd like to see VIPM do here?


    The idea is, that I build packages and place them in a folder on a network drive. My colleagues start VIPM, VIPM scans the folder, bingo, there is an update.


    VIPM can scan folders to see which packages (that are currently installed) are being used (in the Package Configuration Edtor window). It let's you use this information to create and manage a VI Package Configuration (.vipc) file. When you open the VIPC file, you can easily see which packages have newer versions available (they have a star overlay on the package glyph).


    If I do understand you correct, I create a VI Package Configuration (.vipc) file, which includes all my packages. My colleagues use this file to install all packages. If I update any package, I update the .vipc file, too. My colleagues open the updated .vipc file and bingo, they get all updates?




  8. This is something that we're currently evaluating internally at JKI. You might notice that JKI delivers some of its own packages in both demo and paid versions. We have internal tools for doing this, but they're not part of the product. When we get to a point where we're ready to start testing, we'll be sure to let you know -- we'd love to have your feedback.


    I would be happy to test this.



  9. 2) If users don't want to install VIPM, we (JKI) want to know why so that we can address those problems. What issues/hesitations do you see?


    I can only describe my situation:


    1.) My company must check every new software, before it is installed on a pc. Therefore I have to go to IT, tell them I have this cool tool called VIPM and want it to be installed on my pc. Then I have to wait for them to give it free for installation. Of course in my case I just installed it anyway, because I d'ont want to wait for the always overworked IT. But officially I'm not allowed to use it right now.


    2.) My company has restricted policies regarding software. Our customers are worse... But if I can say to them: Guys, you want our software, here is an installer, which installs some libraries which are required... . It would be easier to convince them.


    3.) There is another point. My customer wants my software. In many cases just my software and not a meta tool to manage VI packages. It just feels a little bit more professional, if I give out an installer, which is run once and then every required library is there for use. No more running of tool foo to install lib bar.


    Well, I think this sums it up.




  10. Hi,


    I had this idea while writing another one. VIPM is a cool tool to create and distribute packages, but if I want to share packages with someone, who doesn't want (or is allowed) to install VIPM, I have a problem. Therefore it would be nice if I could create an installer, which installs (and uninstalls) the packages for me. This could be build upon a package configuration file (vipc).




  11. Hi,


    I use VIPM now for about a month and have build quite a lot of packages. Of course I want to share these with my colleagues, but my customers should not get the full code. We often have projects, where we sell our customers the source code, but this does not include our company library. Therefore it would be nice, if I could build from one spec file two packages, one with and one without block diagrams. In this way I could give my packages (and the VIPM installer) to my customers and protect the IP of my company.


    Of course I know, that I could build a Hook VI, which removes the block diagrams for me. But then I have to change my spec file everytime I want to build a package with or without block diagrams, which is quite tedious.




  12. I think that you could create a post-build hook VI (download template here) that removes the underscore from the LLB file name. Take a look at the docs and let me know if you have any questions. I'd be happy to try to help you out, as I've got some experience with creating build hooks.


    Using a hook VI was my first idea, too (s. attachment). It did not work for me.

    Any idea?




  13. Sorry - this is kind-of a repost: I swear I posted on this topic previously, but I can't find it (may it was in a previous beta subforum that's now closed). I'd like to be able to install packages into existing palettes. For example, I'd like my array package to install into the programming->array subpalette in LabVIEW. This would be a huge usabiliy improvement IMHO as it'd mean one less place for software engineers to have to remember to look for stuff (ie: at the moment, the process is look in standard LabVIEW palette - if you don't find it there, look in OpenG palette - if you don't find it there, look in internal reuse palette). I'd like both OpenG and my internal reuse package to both appear in the LabVIEW array palette.


    Cool idea. +1 from me.



  14. Hi,


    I have some templates, which use many type defs of controls. These type defs are templates, too, and should be changed by the programmer during creation of his applikation (e.g. type def enum for state names of a state machine). Therefore it does not make sense to install these VIs and CTLs inside of the LabVIEW folder. I could change these to real template files (.vit and .ctt), but then the programmer has to go through a lot of save file dialogs (I have more then 20 files in one of my templates), which is quite bothersome.


    Therefore it would be cool, if I could create a package of my template and install it inside a custom location I can choose during the installation process (e.g. my project folder). Even cooler would be, if VIPM also asks me, if the package files should be added to a project. VIPM should not mark a package with a custom destination as installed. Perhaps it does make sense to create a new package type for templates?




  15. Hi,


    I would like to see the possibility to list the content of a package inside VIPM. The users should have the option to see, what will be installed, before they actually install any package.


    This could also be handy in case of a broken uninstall of a package, because with this option I could to a manual uninstall (deleting by hand).




  16. Hi,


    I tried to create a package consisting of custom probes. But since the VIs are placed inside a llb, which starts with an underscore, LabVIEW does not add these VIs as custom probes to my right-click menu.


    Therefore I would like to see the possibility to have more control over the final file names inside the package. Perhaps this could be an advanced setting inside the namespace options? And while we are at it, I would like to choose to install the VIs inside a folder instead of a llb.




  17. Hi,


    it would be cool, if I could add to my packages support files like DLLs, help files, error definitions and self-made mnu files. The destination folder should be configurable for every support file seperatly. E.g. DLLs could be placed in system folder of the OS (system folder should be supported automatic folder, which VIPM detects itself).


    It would be really cool, if I could build packages constisting only of support files (e.g. for creating meta palette functions, etc.).




    • Upvote 1

  18. Update: This issue has been resolved in the latest version of VIPM. If you are still experiencing issues, please read this troubleshooting guide. You can also contact us with your code here.






    I'm trying to build a package, which includes 2 classes foo and bar, where bar is a child of foo. The build process stops with the following message:


    There was an error building your package during the source distribution step.

    Please make sure that you have properly installed OpenG Builder and that you have run it by selecting Tools>>OpenG Builder from LabVIEW menu.


    OpenG Builder is running fine, since I have build several packages with it (before and after the error message). Only this package does not work and I think, the reason is the inclusion of the 2 classes.


    I'm using LabVIEW 8.5 (German version). All OpenG packages are up to date. The classes are using standard VIs (mainly TDMS palette) and some of my self made package VIs.


    Can you confirm this behavior?




  19. Hi all,


    I'm new to VIPM and have a lot of questions. My first is: how do I create a "meta" functions palette like the OpenG palette?


    I have already build a lot of reusable VIs organized more or less in the same way as the standard LabVIEW VIs (Array, Numeric Element, and so on). Now that I have my fingers on VIPM I want to build packages of these VIs and give access to them in the same way as OpenG does: A new palette directly in the functions palette and below it the palettes of my packages. I know how to do this by hand in LabVIEW (and I already have done it), but now I want to do this in VIPM.


    This is certainly something others have asked before, but I could not find it with the search function.


    Thanks for any help.


  • Create New...

Important Information

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