Jump to content

Daklu

Members
  • Content Count

    36
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Daklu

  1. Is there a reason PassIfError.vi doesn't have the ability to check for specific error codes? (By reason I mean a "that's not an appropriate way to do unit testing" kind of reason.) When I'm using PassIfError.vi, often I want to make sure the correct error is raised. This is especially true with reuse code packages that define specific error codes. It would be nice if there were an optional error code input for PassIfError.vi that would do that checking internally. It's not difficult to work around, just a bit more duplicated work. Here's my current workaround: Thanks for the great product! Dave
  2. Problem solved... it was completely my fault. Apparently there is a small app that needs to be installed on computers to be able to make certain connections outside of the corporate network. Thanks for the help! (Feels good to have OpenG again...)
  3. Nope, no proxy server. Network issues are outside of my area of knowledge so I'm just shooting in the dark. I copied over a mirror list from another computer and can't get packages. Unblocking VIPM in the firewall settings didn't help. The error log says "The network address is ill-formed." I ran an ipconfig and noticed some IPv6 settings. Could that have something to do with it?
  4. I installed VIPM on new computer (Vista) but the mirrors list is empty. Refreshing the mirrors list results in "You mirror list is up to date. Nothing has changed." I had this happen once before over a year ago and I resolved it by copying the mirror list from another computer. Unfortunately I don't have another computer with VIPM installed on it available here. I tried adding the first five mirror names found here, but that gave me an error. (Error file attached.) I'm guessing I didn't format the mirror information correctly. Can you tell me what format the mirror list should be in? June_09_2009.txt
  5. I completely understand not being able to devote a lot of time assisting a non-paying customer... bills still have to be paid. I blame my PHB. The good news is after spending some quality time with Process Monitor and a test installation package I was able to figure out the problem. I started a new thread with a title that describes the issue better.
  6. This is an issue that I hadn't gotten around to bugging since I wasn't sure it was a bug. Then I discovered it as the root cause of a recent issue I had. VIPM does not delete package files that have been marked read-only. This has two effects: 1. Packages receive a false uninstall. VIPM shows them as uninstalled, but the files themselves are not removed. 2. If using OpenG Package Builder scripts and the scripts are read-only prior to creating the package, they will not be deleted from the temp directory after the first install finishes. The first installation works fine but any subsequent installation attempts of packages that use the undeleted scripts will fail with no indication why. Deleting PreInstall.vi, etc. from the temp directory allows you to install the package correctly again. Use case: I typically use an OGB post build script to mark my built code read-only. This prevents me from accidentally making changes to released code. The OGPB scripts will be shared among several projects and will be under source control, so they will be read-only as well. Issue 1 might be able to be worked around using a PreUninstall.vi script, but I haven't tried it yet. (Is the package information, such as installation directory and installed files, available to the scripts?) Since the script files in the temp directory always have the same name, I imagine using a standard preinstall script that deletes those files from the temp directory would work around that. I've attached a screenshot of the Process Monitor capture showing the error and a small test package that demonstrates the problem. The Test Package includes Pre/PostInstall and Pre/PostUninstall scripts and is installed to c:\Test Package. As each script executes an entry is made in c:\Test Package\install.log. (If anyone else installs this package, don't forget to delete the VIs from your temp directory!) tp_ReadOnly_CDEF_1.0_1.ogp
  7. Update I completely uninstalled VIPM and all NI products and deleted the folders left in Program Files. Rebooted and reinstalled everything from scratch. Still can't install ogrsc_dynamic palette. (nirsc_html_help_common failed as well.) Any other ideas? I noticed VIPM isn't showing up in the Add/Remove programs applet. I did remove any "JKI" and "VIPM" registry references I could find during one of my early troubleshooting sessions. It's certainly possible I missed one or more. If during installation VIPM finds a pre-existing registry entry, does it cancel all remaining registry entries assuming they are present as well? If so, does the post-install scripting ability rely on a registry entry that, if missing, would abort/revert the installation? Can you tell me if VIPM has any other external dependencies? I can always dig them out and reinstall them. Are there particular LV settings that must be configured, aside from the VI Server options? I'm willing to try almost any ideas you have. (Can't flatten my hard drive...) I've been converting my reuse code into packages and this issue puts a big kink in that idea. I do have a workaround; I edited both of the guilty packages and renamed PostInstall.vi to _PostInstall.vi. That allows VIPM to install them. However, it's not clear to me how not running the packages' postinstall script affects their operation. Since my packages will ultimately need postinstall scripts the workaround doesn't address the main problem.
  8. Rats. I was hoping you could decode the error message and at least point me in the direction of the problem. I removed all packages, uninstalled VIPM, removed all "jki" registry entries I could find, deleted the JKI folder in Program Files, and did a Labview repair installation. After rebooting I reinstalled VIPM with a fresh download and tried to reinstall the dynamic palette package. It failed with the same symptoms. The package was already installed on LV 8.2 and 8.5, but of course since I deleted all the VIPM data none of the packages showed as being installed for those versions either. I saw the same failure when I tried to 'install' the package for both of those versions. That the problem persisted through a complete VIPM reinstall implies an error in a Labview library, but persisting across all Labview versions implies an error in VIPM. I guess a complete NI uninstall and reinstall is next...
  9. I've been experimenting with OGPB and building packages using a postinstall script. There seems to be some quirkiness when installing these packages but unfortunately I can't narrow it down any more than that right now--somewhere along the way something became corrupted and I can no longer install any packages that uses a postinstall script, including ogrsc_dynamicpalette. By watching the VIPM status bar closely I can see the vis are being extracted and for a split second I can see some vis are being replaced. Immediately following that "Uninstalling <something>" appears in the status bar very briefly and all the files just installed have been deleted. I've included the text of the error code below. In the meantime I'll try reinstalling LV and see if that solves the immediate problem. Error Text ========= START of VIPM Error Message ========= An internal VIPM Error has occured on: Tuesday December 09, 2008 at 04:15:00 PM = Automated Message Start = Error 7 occurred at Get File Size in 4A9EADB12D85602702B014FFA149C099.lvlib:E58007D8CDD9B380F9E708A4DA17CFE1->4A9EADB12D85602702B014FFA14 9C099.lvlib:5B7A384030B242299059CB12A19655D8->4A9EADB12D85602702B014FFA149C099.lvlib:79D0103627FA9CA 9CBBAF8DA6F94B3ED->F7926906AD43D9BBDAE4777C9B18C4A7->VIPM Main Window.vi Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux. Verify that the path is correct using the command prompt or file explorer. ========================= NI-488: Nonexistent GPIB interface. = Automated Message End = = Call Chain Start = VIPM Main Window.vi = Call Chain End = ========= END of VIPM Error Message =========
  10. I often use the info box to review all the different packages that are available, but since it is modal I can't select the packages I'm interested in installing. I either have to remember the ones I want or close the box, select a package, and reopen the box. How about making the info dialog non-modal so I can switch between that and the main application window so I can select interesting packages as I find them? Or include an checkbox in the info dialog allowing me to select/de-select packages from there instead of the main app window?
  11. Let me start of by saying I love VIPM and all the free packages you provide to the Labview community. Thank you! I just did a fresh install of VIPM Community Edition (build 0665) on a new computer. When I went to install packages, I received a timeout error stating VIPM could not connect to Labview. After that I went to the Edit Port dialog box and tested the connection, which I had not done previously. Following that I was able to install packages correctly. The option to automatically adjust Labview settings was checked when I ran the port Test so this probably is not a bug. I assume there are default Labview options that need to be changed for VIPM to connect. However, it did take me several minutes of head scratching before I resolved the problem since the port setting was correct. It might be beneficial to direct users to the port test function when that error occurs. My only other request is to provide a little more details in the description of the various packages, including the date it was released and whether it has been depreciated in favor of other packages from JKI or NI. Thanks again!
×
×
  • Create New...

Important Information

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