Jump to content

Joerg Hampel

Members
  • Posts

    51
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Joerg Hampel

  1. Any chance there will be an official release of VIPM 2022 for Mac, too?
  2. Hey Jim, what's the situation in regard to the VIPM API? Currently, it shows as "not OS compatible":
  3. It would be great if that fix made it back into the official release. If at all possible, we'd prefer to keep using the API from our LabVIEW-based tools.
  4. Jim, you privately shared an unpublished version of VIPM (2020.0.3.80) with us back then, which we've been bundling with our tools ever since.
  5. The one and only @Darren suggested the following (and my colleague Alexander @AlexElb executed on it brilliantly) for fixing that broken lv_icon.lvlibp: NI provides the source code for the icon editor on the NI forums. You can grab the version that matches your LabVIEW version and re-build the PPL with that issue fixed. Here's where you can get Icon Editor source files: https://forums.ni.com/t5/Enhanced-Icon-Editor/bd-p/grp-1168 For the sake of google-ability, here are the error messages and paths in plain text: The following source VIs or Libraries are missing. Click OK to show the callers of these VIs or Libraries. Please correct this problem before rebuilding. The build will now be aborted Load.vi --- e:\builds\penguin\labview\branches\2016\dev\dist\vi.lib\xml\Load.vi The following source VIs or Libraries are the callers of missing files (specified in the previous dialog). Please correct this problem before rebuilding. The build will now be aborted. NI_XML.lvlib. --- C:\Program Files (x86)\National Instruments\LabVIEW 2016\resource\plugins\lv_icon.lvlibp\1abvi3w\vi.lib\xml\NI_XML.lvlib
  6. For added fun, I found an exact duplicate of the "Escape HTTP URL.vi" inside the JKI REST Client API: "Escape URL String.vi"! I created an issue in the REST Client's GitHub repo: https://github.com/JKISoftware/JKI-HTTP-REST-Client/issues/22 (I'd have loved to create a merge request but I don't have LabVIEW 2013 available, 2016 is the oldest version still in use at HSE).
  7. Actually, this "Escape HTTP URL.vi" from vi.lib/wsapi is being used in JKI's REST Client 😉
  8. LabVIEW Professional Development System Version 2022 Q3 (64-bit) 22.3f0
  9. It seems that the webservices library is missing from my vi.lib: As the error message hints at, the whole /wsapi/ folder is missing. I'm not sure about this one. Is there a way to fix this? Edit: The NI System Configuration API (nisyscfg) and vi.lib/Platform/fileVersionInfo.llb:FileVersionInfo.vi also seem to be missing...
  10. The next problem is OpenG - or, rather, the user.lib: So the next command to be executed is: sudo chgrp -R staff /Applications/National\ Instruments/LabVIEW\ 2022\ 64-bit/user.lib/ Now, all the necessary OpenG packages for my project can be installed. (still more to come...)
  11. I'm using macOS Monterey version 12.2 (21D49) on an Intel MacBook Pro. --------------- The KB entry indeed helped resolve the issues with file permissions. Applying .vipc files also works! The one thing I'm stuck at now is installing DQMH 6.1. The process errors out with the following information: The 2nd error message already shows the problem - the KB entry misses a folder that also needs the staff group to be set: /resource/plugins/PopupMenus. So I added the following command: sudo chgrp –R staff /Applications/National\ Instruments/LabVIEW\ 2022\ 64-bit/resource/plugins/PopupMenus Now, the installation of DQMH succeeded! (more to come...)
  12. Not sure if this is the right place to provide feedback - please move the post if not. Feedback for the Mac beta: The first three times I ran it, it crashed (the report mentions an error 8 at Delete in VIPM Splash.vi for the file VI Package Managerrunning.tmp while writing the "is running" temp file in the splash screen When VIPM opens, the status bar does show all sorts of packages it syncs/downloads from various places, but once it's done the package list seems outdated / inconsistent (see screenshot) Mostly, it crashes showing error 10 (duplicate path) while trying to create /Library After re-checking for package updates, VIPM tells me it could not access either the LabVIEW Tools Network (shouldn't that be called the NI Tools Network now?) nor the VI Package Network. Cmd - , does not open the settings window Applying a .vipc file does not work - but maybe that's due to all the other errors occurring before
  13. Jim, that will be good enough for us Thank you! I've created an issue. Once we get around to implement and test this, I'll update this thread with our findings (if any).
  14. Now that you point it out, I see those "quiet?" inputs. Thanks for pointing that out! I can see the "quiet" input for the "Apply VIPC File" endpoint, but not for "Build Package" (and others, like you said). Seeing as it takes quite some time to start up VIPM, we implemented our tools to check if it's running (and start it if not), but not to exit it after finishing. That way, the next pipeline run should be faster as it doesn't need to start VIPM again. The problem here is: If a user starts VIPM on the build server manually, and it's not configured to not check for updates, there's probably not much we can do from our tools after the fact (ie after VIPM has been started). Unless there was an API endpoint for enabling the "quiet" mode globally for all of VIPM. Or would it be possible to add an API endpoint for disabling the check for package and VIPM updates? I think that would be best for our specific use case.
  15. I was not aware of the silent argument! Here is the part of our code that starts VIPM if it's not running already: How or where would we invoke the silent argument? Or is it built into the Open VIPM API call? And as I'm looking at this, I imagine it could happen that a user opens VIPM manually, which would probably result in VIPM running without said argument. Would it be possible to switch the "silent mode" on via API while VIPM is already running?
  16. When using VIPM via its API on our build servers, we're running into problems every now and then with popups VIPM displays for any updates available. The popups will block the process and finally lead to a failing pipeline (timeout). While this can be worked around or avoided by disabling update checks in VIPM's options... ...it would be so much nicer if there was a true headless mode. That way, forgetting to configure VIPM as above would not result in timeout errors. Also, there might be other popups which can not be avoided through the current configuration options. Maybe this headless mode could be automatically invoked when starting VIPM from the API, or be made accessible through an API endpoint (turn on/off).
  17. Hello VIPM team, can you please look at this and let us know if it's an actual bug in VIPM 2021 or how we can solve or work around this in the future? Thank you!! Btw, is this maybe related to the fact that VIPM 2021 now also pulls in edit-time dependencies? See
  18. We're seeing the same behaviour with some scripting code of ours. FWIW, a similar error occurs when trying to create a source distribution of the same VI. In our case, I could track down the error to "Read Icon Data from VI.vi", part of lv_icon.lvlibp: Jaime did you find any solution to this?
  19. I can confirm that with VIPM 2020.3 (build 2540) this problem doesn't occur - i.e. with VIPM 2020 I'm able to build my package from the very same .vipb.
  20. I'm seeing the same behaviour (albeit with a VI with its block diagram removed). Did you find a way to get to the bottom of this, Tom? JKI / VIPM team, any ideas? Edit: I'm seeing this behaviour on VIPM 2021.1 (build 2754)
  21. Hey guys, I just tried to install this version (after uninstalling VIPM 2021) but it now reports that it has expired. Is there a later version anywhere?
  22. While creating some more screenshots for this post, I actually figured out the problem: It's in the URL of the repo! On the VM where I got the error message, I had not provided the scheme (the protocol, https). It is a bit misleading that the error message (as shown above) will actually display the full URL including the scheme.
  23. Hey VIPM team, we're experimenting with local VIPM repositories but running into problems. We're working in a VM running LV2016 and VIPM 2021.0 (2721) We set up a local repository which should be accessible via the URL https://vipm.hampel-soft.com/ (private, only available internally or via VPN) When trying to update packages, VIPM throws an error In the error logs, there actually is an error associated with the file VIPM wants to download from our custom repository: =========== START of VIPM 2021.0 (build 2721) Error Message =========== An internal VIPM 2021.0 (build 2721) Error has occured on: Sunday May 30, 2021 at 10:02:18 AM = Automated Message Start = Error 42 occurred at (http response "HTTP/1.1 400 Bad Request". URL Requested: https://vipm.hampel-soft.com/index.vipr.zip) 52D9A4562D38CB99A669F85011D9D2EE:1310001 in 9B2F9930B5E536BF44B4C52F860D615E->1C6929D1E714EC131EBDBC872009DE5E->6A6376334CDCAB91B9771788751EE7B6 ->OGPM Class.lvlib:E4D4F8782AE9DBB9105BB3D92B765ACC->OGPM Class.lvlib:8C3E06FF1E6C98D9A8E16799D6B3EEEB->7AF8C3BAECF0AACE1A61F9248BAC879A->VIPM Main Window.vi Possible reason(s): LabVIEW: (Hex 0x2A) Generic error. = Automated Message End = = User Defined Message Start = Error downloading from: - https://vipm.hampel-soft.com/index.vipr = User Defined Message End = = Error Handler Call Chain Start = VIPM Main Window.vi-> 7AF8C3BAECF0AACE1A61F9248BAC879A-> OGPM Class.lvlib:8C3E06FF1E6C98D9A8E16799D6B3EEEB-> OGPM Class.lvlib:E4D4F8782AE9DBB9105BB3D92B765ACC = Error Handler Call Chain End = =========== END of VIPM 2021.0 (build 2721) Error Message =========== Wireshark shows that the HTTP request is denied with a strange error message (see screenshot): Both through the browser and via a simple test VI, I can manually access said file on that LV2016 VM. I then tried adding our repo within another virtual machine running LabVIEW 2018 and VIPM 2021.0 (2694); here our repo works fine! After upgrading the installation in the LV2018 VM from build 2694 to build 2721, our local repo still works for that VM. So it's not related to the VIPM version it seems.
×
×
  • Create New...

Important Information

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