Jump to content

Zaphiro Technologies

Members
  • Posts

    15
  • Joined

  • Last visited

Reputation

13 Good

About Zaphiro Technologies

  • Birthday 09/10/1981

Contact Methods

  • Website URL
    https://www.linkedin.com/in/antoinechalons/

Profile Information

  • Gender
    Male
  • Location
    Lausanne

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. sorry, right after posting this I went to check if this issue had already been reported... it seems it has :
  3. 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?
  4. 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.
  5. 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.
  6. 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)
  7. 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.
  8. Everything was fine until I installed Lv2019 SP1 f4 using NIPM And now when I try to launch VIPM, I get this :
  9. 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
  10. 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)
  11. 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.
  12. I had LV 2019 SP1 and then I installed LV 2020 SP1 Never installed 2020.0.0 Sorry for the lack of accuracy.
  13. [ 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 :
×
×
  • Create New...

Important Information

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