Zaphiro Technologies

in 4.2.1b1 the lib path was '/usr/local/natinst/LabVIEW-2020-64/user.lib/_OpenG.lib/lvzip/lvzlib.*' for all CLFNs also another issue, that I also see on Windows as well as Linux is that the LVZip sub-palette is not showing up in the OpenG palette

i manually extracted the lvzlib64.so from the ogp and replaced it in /user.lib/_OpenG/lvzip and renamed it to lvzlib.so then re-selected it in all the clfns then it works...

after re-writing the post-install VI in this way I could get the package to install but then I have other issue with the clfn : dll on Linux doesn't go down too well and when I try to select the lvzlib.so, LabVIEW complains that

I can't install this package on Linux (even after uninstalling the previous version, 4.2.1b1) I keep getting an error during the post-install : I'm using VIPM 2017 and on Ubuntu I have to run it as root to make it work, I suspect that could the the issue.

i enable the "Do Not Compile on Build" option (in Source file settings section) and the package building worked and took a lot less time than before. As I mass compile my source folder anyway before building the package, am I risking anything? Why is this option "not recommended"

side note : I'm still able to build other (smaller) packages successfully

I get this error when building my package, previously the package was building fine, it did taka a long time (~15 to 20 minutes) to build though because it's quite large (~78 classes, 1200+ VIs). Since the last successful build I've only added some methods in the classes. Sources are in LV 2019 32 bit I'm using the latest version of VIPM 2021.1 b2754

I "repaired" LabVIEW 2019 using NIPM Rebooted Uninstalled VIPM, re-install (runnning the install as admin of course) Rebooted now it seems to work again

I've just installed the LV 2019 SP1 patch (f5) from NIPM and now won't launch. The splash screen comes up, then disappears. After that in the task manager I still have VIPM in the back-ground services : Anyone having the same issue?

this solution worked for me on Ubuntu 20 : https://lavag.org/topic/21815-installing-vipm-1702018-linux/?do=findComment&comment=137641

It works, could build my package.

Cool, that was fast Great job!

I've checked, my package does not depend on any other package. There was an vipc file (1kb), I deleted it, forced VIPM 2021 (2745) to check again for dependencies (still none) no *.vipc file created next to my *.vipb file package creation still fails.

sorry, right after posting this I went to check if this issue had already been reported... it seems it has :

I have package (LV source in 2019 SP1 32 bit) that builds just fine when I use VIPM 2020.3 But VIPM 2021 beta (2745) keeps failing with this message : In both cases VIPM Pro license was activated. Any idea what could cause this?

Found a solution : https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ru8SAE&l=fr-FR Luckily, my colleague has the same laptop with similar NI softs installed so he sent me his tdtable.tdr file and then it all works fine again.

Found a solution : https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ru8SAE&l=fr-FR Luckily, my colleague has the same laptop with similar NI softs installed so he sent me his tdtable.tdr file and then it all works fine again.

If I select 2019 SP1, it does mention that it includes f1, f3 and f4, see (the f4 patch seems to be only for English 32-bit)

Can't run VIPM 2020 or 2021 beta anymore In the case of the beta (latest one), here's what I get , I did report this to NI.

Everything was fine until I installed Lv2019 SP1 f4 using NIPM And now when I try to launch VIPM, I get this :

Great job, thanks for dealing with this so fast! And indeed, this kind of issue makes you wander what else you haven't seen ye

I guess a fix would be to use the one from LabVIEW in EasyXML, no? I've just uninstalled - reinstalled the OpenG String package and the bug has not come back. Haven't connected to my Linux RT target though. EDIT : my VIPM is set to mass compile packages after install (has always been configured like that)

Nope, never on a mac but this project can be run either on Windows or on a NI Linux RT target, so I naviguate between Linux RT and Windows almost every day. Will try that.

I had LV 2019 SP1 and then I installed LV 2020 SP1 Never installed 2020.0.0 Sorry for the lack of accuracy.

[ Update: The work-around for this issue is to OpenG String v4.1.1.16 ] Take a look at this "issue" that can appear after installing LV2020 : https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ The video posted shows how to fix it. What happened to me was : - I've been using EasyXML happily for some time in LV2019 (my use include attributes) - I installed LV2020 - EasyXML in LV 2019 started to add an extra line at the end of attributes. I noticed that in Git when my config files had so many modifications. - for a few days, it's been very painful to try and find the error so I dug into EasyXML's inside then notice that the OpenG String VI : "1D Array to String" was adding a "\r" at the end of the delimited string. - then I found the post on LAVA which saved me a lot of time. So... just be careful with this if you use attributes. to give you an example, this : became that :