Jim Kring

That's strange. I wonder if there's some kind of permission issue. Does "Everyone" have Full Control on the "C:\ProgramData\JKI\VIPM" folder?

Hi Peter, Can you try exiting VIPM, deleting the cache folder, and then restarting? C:\ProgramData\JKI\VIPM\cache

Hmmm... which "list" are you referring to? The main VIPM package list or the Dragon project's Resources tree/list of packages? Also, can you look in the "C:\ProgramData\JKI\VIPM\error" folder to see if there's any error messages logged?

Hi @Yann. Thank you for sharing how IT resolved the issue for you. That's really helpful to know.

Hi @Sam Grayson and @Yann -- I'm also curious to learn more about how to configure Cybereason so that VIPM will work OK for you. Please let me know if your IT departments are willing to share more information.

Hi @Mario. Great question. As @James@Work point to, VI Package Configurations are a great solution for keeping track of the packages in your project. Additionally, JKI has announced the beta for Dragon, which sits above LabVIEW and VIPM to provide high-level management of LabVIEW projects and configurations of packages used by your project.

Fantastic! Glad to hear you're up and running.

I've seen that before -- sometimes VIPM's local package database doesn't get fully sync'ed Please try this: Open the VIPM Main window by clicking on the orange "VI" Then, refresh the package list in VIPM by clicking the refresh button on the toolbar You should then be able to find OpenG Toolkit by clicking on the link again or searching for it in the VIPM Main window.

That’s a great idea to show the build output, Joerg. I assume by “feed back the progress” you mean that you would like to see some progress text output to the standard output, which the CI is showing in the console?

Totally. I've opened a service request with NI to dig into it some more. I'll post updates, once I find out more.

I was able to reproduce the issue with the help of a colleague who has an RT Target. I've written up some info about this issue here: https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ OpenG String v4.1.1.16 should fix this issue (although it's simply working around the LabVIEW compilation bug, which could potentially be causing other issues) I'm going to work to report this to NI, since we can reproduce the issue.

Ah, that's interesting. Maybe it's related.

Also, are you able to reproduce this issue right now? I might have a fix/test for you. If you've fixed it locally, maybe you can reproduce by uninstalling OpenG String from 2019 and then re-install OpenG. Being able to reproduce would really help me test a fix.

Oh, that's very interesting! Thanks. Question: is there any possibility that you opened this code on a Mac? (where the EOL character is a "\n" -- note that the EOL character is "\r\n" on Windows).

Hi Antoine, Thanks for posting this. Question: Do you have LabVIEW 2020 SP1 (2020.0.1) installed or LabVIEW 2020 (2020.0.0)? I'm trying to figure out how to reproduce this bug. -Jim