-
Posts
25 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Zaphiro Technologies
-
-
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...
-
-
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 bitI'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.
- 2
-
-
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.
- 1
-
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)
-
4 minutes ago, Jim Kring said:
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).
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.
3 minutes ago, Jim Kring said: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.
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
:
unable to install oglib_lvzip v5.0.0-1 on Linux
in OpenG LabVIEW ZIP Library by OpenG
Posted
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