-
Posts
51 -
Joined
-
Last visited
-
Days Won
8
Everything posted by Joerg Hampel
-
feature suggestion : VIPM API for Linux
Joerg Hampel replied to Antoine Chalons's question in VIPM Idea Exchange
Hey, JKI, what's the status for this one? -
VIPM API: Allow major version number to be 0
Joerg Hampel replied to Joerg Hampel's question in VIPM Idea Exchange
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. -
VIPM API: Allow major version number to be 0
Joerg Hampel replied to Joerg Hampel's question in VIPM Idea Exchange
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. -
Missing VIs/Libraries with strange paths
Joerg Hampel replied to Jaime Jimenez's topic in VIPM Public Beta Discussion Forum
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 -
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
Done and dusted. -
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
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). -
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
-
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
-
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
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... -
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
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...) -
Feedback for the Mac beta
Joerg Hampel replied to Joerg Hampel's topic in VIPM Public Beta Discussion Forum
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...) -
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
-
Headless mode when calling VIPM through the API
Joerg Hampel replied to Joerg Hampel's topic in VI Package Manager (VIPM)
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). -
Headless mode when calling VIPM through the API
Joerg Hampel replied to Joerg Hampel's topic in VI Package Manager (VIPM)
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. -
Headless mode when calling VIPM through the API
Joerg Hampel replied to Joerg Hampel's topic in VI Package Manager (VIPM)
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? -
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).
-
fixed Error 1012 - dependency BD not found
Joerg Hampel replied to TomMcQ's topic in VI Package Manager (VIPM)
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 -
Missing VIs/Libraries with strange paths
Joerg Hampel replied to Jaime Jimenez's topic in VIPM Public Beta Discussion Forum
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? -
fixed Error 1012 - dependency BD not found
Joerg Hampel replied to TomMcQ's topic in VI Package Manager (VIPM)
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. -
fixed Error 1012 - dependency BD not found
Joerg Hampel replied to TomMcQ's topic in VI Package Manager (VIPM)
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) -
announcement New Dragon Build (2721) Available for Download
Joerg Hampel replied to Jim Kring's topic in Dragon Beta
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? -
Custom VI Package Repository Error
Joerg Hampel replied to Joerg Hampel's topic in VI Package Manager (VIPM)
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. -
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.