Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by chrisdavis

  1. If you can install VIPM, you can install the OpenG Packages from a local source (i.e. portable hard drive / flash drive). You still have to download the OpenG VIs from sourceforge yourself, using this link, but once you get them all on disk, VIPM can import them and install them on a machine not connected to the internet. I know because its how I operate.


    You'll also want to look for release notices on the VIPM or OpenG pages to know when new or new versions of packages have been released.



  2. We were able to reproduce your problems so we are changing the minimum requirements to 8.2.1. Thanks for your help in reporting this issue!

    If I don't want to upgrade to 8.2.1 can I test VI's written in 8.2 from withing 8.5? I know its a strange question, but I'm not entirely sure what VI Tester would do. My first gut answer would be yes since I don't believe that VI Tester would actually try to save or modify my VI while testing it. What do you guys think? Is this a crazy idea?

  3. I've added this to the known issues (case #6811) -- the workaround is to create a LabVIEW project file first, and then new create test cases. By default, VI Tester will add your TestCase to the project that you launched the 'New TestCase' wizard from.

    Your workaround works. When I did this I was able to interact with the blank project correctly.


    Can you try opening the TestCase class from LabVIEW and see if you have any issues? Try a save-all and then re-run from VI Tester and see if that helps. I think this is an 8.2 related issue and will look into it further.

    I think I've done what you asked here, to no avail. The same exec.cpp error popped up.


    BTW, I did a quick search on NI's site as well as LAVA and didn't find this particular error mentioned anywhere. I know these errors are EXTREMELY difficult to diagnose, so thanks for trying.


    I'm not opposed to upgrading to 8.2.1, if you think that will solve my problems, I just haven't yet.

  4. I got VI Tester downloaded, but I'm having an issue. I've attached two screenshots with my error. When I first start VI Tester I get a message saying that it needs to mass compile itself, which I let it do. At the end of that I get the following screenshot. Start_up.png


    I thought I would mass compile the directory myself, to see if that would help, and it did. So now I can run VI Tester. When I make a "new" test project / lvclass the project window for that class won't come to the front, so I have to quit LabVIEW to get it to close. Now since there is a sample test in the test class, I thought I would run it through the VI Tester just to give it a shot. Same internal error as before. Running_test_case.png.


    For the record, VI Tester installs and works fine in LabVIEW 8.5 and 8.6.


    I seem to remember quite a few bugs related to lvclasses in 8.2 that were fixed in 8.2.1, but I thought I would post this message to see if others were having trouble before I tried to upgrade my system.


    System setup:

    LabVIEW 8.2 (no 8.2.1 patch installed)

    Windows XP SP2

  5. JKI,

    Thanks for the work on VI Tester! I would like to try it, but I don't have LabVIEW installed on a machine that is connected to the Internet. Could you provide a link in your pinned / locked topic for downloading VI Tester to disk to install on another machine?


    BTW, I didn't see any system requirements. At this point I'm assuming LabVIEW 8.2 is a minimum requirement, but I'm sure others would like to know operating system requirements that might, or might not come into play.



    Chris Davis

  6. However, you can always modify this mnu file and create a package that overwrites it (and make all your library packages depend on it, as described earlier).


    I've been doing just that.


    I also thought I would try out your tutorial above and I've almost got it the way I want it. I am having trouble with, as you have guessed, creating the mnu file correctly. I seem to have it setup just perfectly for the functions palette, but whenever I try to get the controls palette to show up with the same mnu file I run into snags. I'm thinking maybe I need to distribute two mnu files both of which sync to the org\palette mention above. One of these proposed mnu files would handle putting controls on the controls palette and the other would handle putting functions on the functions palette. I just thought I would ask if I'm missing something before I go down this path.


    I think I'm going to keep the method you've "tutorialized" (pardon the coined phrase) above because the group likes it. And, it seems fairly straight-forward to implement.



  7. First off, let's clarify what you're asking for: I assume that what you're wanting to do is create a root-level category in the Functions palette (similar to the OpenG palette, shown below), rather than having your palette installed in the standard locations (User Libraries, Instrument Drivers, Addons) supported by the VIPM's package builder?


    Actually, I was going to be content with putting all of my work under the User Library, but now that you've shown me another way, I will be checking this tutorial out.


    To clarify, currently I navigate to User Libraries, then I have a subpalette there with my org name, then under that several subpalettes that contain my reuse VIs, as seen below.


    I did it this way because no tutorial existed on how to do it another way. If I want to continue doing my reuse library this way, what parts of your tutorial would have to change?


    BTW, thanks for producing this quick tutorial, I'm going to discuss this idea with my other users to see if it will help out.

  8. Jim et al,

    I've got several reuse library VIs that I would like to package into several (15ish) VIPM 2 packages. VIPM 2 has made it mucho easy to put together nice looking palette's. Now I want to make a palette of all my various packages and make the installed items look the same in all installed computers, in much the same way that OpenG does with its packages. Any advice?



  9. I found a cosmetic bug with VIPM 2.0 beta 2. It seems to be reproducible, so I thought I would post it here to get fixed.

    1. Edit the icon of one of your subpalettes in the top level of either the controls or functions palette
    2. Edit the icon at will, then click ok or cancel
    3. When you return to VIPM, you can now go up one level in the functions or controls palette, which is, of course, blank because you edited something at the top level.

  10. It sounds like just a miscommunication on my part. What I meant when I said OpenG packages is, internal company, reuse libraries currently packaged using the OpenG Package Builder. In the future I would like to repackage them all using the VIPM2 package builder because of the numerous advantages of the VIPM2 package building mechanism. Not the least of which is the pre and post package building hook VI's that will allow me to run tests on individual VI's before they are packaged into a reuse library package that will be used within my company.


    Sorry for the confusion.


    My original question was answered by Omar, when I make a VIPM2 package, all I have to do is navigate to the package directory with VIPM2's Package Builder and it will pick up the package in that directory by reading the .vipb and .vipc files in that directory.

  11. The open button on the package builder is dual use. If you click on the right half (with the down arrow) you will see your recent listings. If you click on the left half, you will see a file browse dialog. Browse to the source folder and it will automatically load the build file.

    I understand now, just thought I would post to make sure I understood its design.


    I'm not sure what your use case is for converting the OpenG packages to VI packages. Can you explain what you are trying to do a little more?

    I've just got several internal OpenG packages that I'm wanting to turn into VIPM2 packages (I don't know the official name for these) over time. I was just afraid that picking them via the "recent" menu would be a problem when I get through converting 10-15 packages from OpenG to VIPM2. It sounds like I will just browse to a directory and VIPM2 will pick up the package in that directory.

  12. how does one "open" a VI package build file? There is no "open" from the menu of the VI package builder, just a "recent" listing. I plan on converting all of my openG packages to VI packages when VIPM 2 is done and I don't think they will all fit in the recent menu, assuming it has a limit of packages it will present to the user.


    Runing VIPM 2 beta 2 on Windows XP btw.

  13. Jim,

    I seem to be having a similar but slightly different problem. I've built a package with about 40 VIs and controls and in VIPM the palettes look like I designed them, but when installed, the palettes don't all show up. Some two of my four function palettes do show up, and all of my controls show up (there are four palettes there). The mnu files are installed, and when I go into LabVIEW and link them into the palette I want, so the mnu files contain the information they should, but something about the installation process doesn't link the mnu files into LabVIEW correctly.


    BTW, I'm using Windows XP SP2, so no Vista worries here.


    I'm going to try breaking up my packages into four smaller packages to see if I can get them to install correctly. I'll let you know how it goes.


    I can provide my files in a private email if needed.

  14. I'm sure that there are use cases for community edition folks wanting to build packages, but I haven't heard of any yet. Chris: what's your use case to build packages?

    I'm building packages for internal company use only. I just thought I would mention it, because I've been able to get by with community edition so far.


    I'm currently trying to build a reuse library that has ~40 controls and VIs in it, which I couldn't do with the community edition. Perhaps the package needs to be broken up, but I'll save that for another post.


    All in all, I don't mind buying the professional edition, because I want to be able to edit the palettes, as well as provide custom icons and the like. I thought that the limit on the number of VIs/controls might be tough for someone who wanted to be able to upload a toolkit as a package to LAVA (or the dark side) for people to try out. From what I've heard that probably wouldn't be enough to hold an LVOOP project/toolkit because of the encapsulation needed for OOP project.

  15. Jim et al.

    I was looking at your posted comparison of Professional vs. Community edition of VIPM and noticed something I thought might need explaining. The limitation of 10 VIs in a package for the community edition seems a little unfair. I didn't know if this number was set in stone or if it is still in flux, but 10 seemed pretty small to me. I don't know if you have any explanation for the limit but I'd love to hear it if you do.


    As an aside, I think I will end up buying a couple of copies of the Professional Edition, because of the features it will provide for my group. Do you have any updated pricing for the 2.0 version you could share with us?



  16. Almost. The automatic download part of that page activates to quickly and I get a blocked message. Maybe a (second) button or link from the page where I put in my email to download the "safe" version would work. I could try to speed up my mouse movement, but I'm to spastic already for that to be much of an option.

  17. Today I tried to run my install of VIPM 1.1 Beta 2 (Build 622) and it had expired. A dialog presented itself asking if I wanted to begin using the community edition or continue to use the professional edition. When I selected community edition, I was unable to continue, the dialog kept appearing on two different machines that I've installed VIPM on.


    I decided to go to the download link to make sure I had the most current version. It seems that there is an unannounced release candidate 1 version out now (build 623), which I didn't have. I'll try installing it now and see if it helps.


    FYI, When I install it, it gives me 60 more days of activity. Keep up the good work, just wanted to let you know about the error with the community edition dialog.

  18. EMG,

    As far as I know VIPM was never built with anything less than LabVIEW 8.0.1. Jim can correct me if I'm wrong. You might have used OpenG Commander at some point in the past, which was not a compiled LabVIEW exe and worked within the LabVIEW environment to download and install OpenG packages. As for an older version of VIPM, I'm sure that JKI has them somewhere, but I don't know exactly where. If you don't want to install the runtime, I'm afraid you are out of luck, it is a requirement of VIPM.



  • Create New...

Important Information

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