Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by fab

  1. I reported this a couple of months ago via Twitter.  At that time Jim responded that the reason packages built using VIPM 2017 do not work with earlier versions of VIPM is due to adding support to malleable VIs.

    Would it be possible for VIPM to have a way to package the packages the old way when they do not include a single malleable VI in them?

    Our main toolkit, DQMH, is available via the LabVIEW Tools Network, and we don't want to impose a VIPM version requirement for our users. We are having to stay with VIPM 2014 or 2016 in order to build DQMH packages if we want to ensure that everyone is able to install them. This is the main reason why we will not renew our service plan with JKI.  It does not make sense to pay for a renewal when we are forced to use an earlier version of the product. 



  2. Hi Ashish,


    Thanks for your answer. Using the System target is not the best approach for us. We are developing a library that will work on several platforms. We were planning to create a VI package for each platform that will contain the board files (so NI MAX can install the library in the board) and a LabVIEW project as an example on how to use the library.

    For the files for NI MAX, we could go with a System target. The LabVIEW project, on the other hand, needs to be installed in <LabVIEW version>/examples. For that, we need to use the LabVIEW target when generating the package.


    Is there a workaround we could use?





    I am getting the same error, but I am trying something different...


    However, when I saw what you are trying to do, it seems to me that you could create a Project Template, check out if you have not already:


  3. We had a similar error when installing a package.

    However it worked the second time we tried it.


    We are going to try to reproduce it and if we get more information we will let you know.


    I thought I would share in case other have seen this, that at least in our case, attempting installation again worked.


    And yes, the machine had an antivirus: AVG 2013.0.2899.




  4. For this project I am using LabVIEW 8.2


    When I use "Easy Write XML File__JKI EasyXML.vi" with the path to an existing file, I get the following error:



    Error 10 occurred at Open/Create/Replace File in Easy Write XML File__JKI EasyXML.vi

    Possible reason(s):

    LabVIEW: Duplicate path.



    I would like to have access to the Open/Create/Replace command so I can set if I want to replace the existing file.

    • Upvote 2

  5. I'm pretty sure (but not 100% positive) that your work-around, using control references, won't work. The VIs will probably still have their front panels, but I think that they won't be loaded into memory and you'll get an error.



    Unfortunately we were right :) I was able to test this code in a cRIO and I get error 53 coming out of the "To More Specific Class"...


    So, either I will have to dive into the variant manipulation or I will write a less generic code that works only with my XML Schema. Given the amount of time I have for this project, unfortunately, I will have to go with the less elegant option. :)


    Thanks again for the help and I will be anxiously waiting for the new release of EasyXML with default values :)




  6. An option to use the input data type as the default values for the output sounds like a great feature addition, to me. We'll certainly add this to the list of feature ideas for a future release (and, I've heard this suggestion at least once or twice from other people). I've filed an official feature suggestion, in our tracker:Case 10191: Need an option to use the input data type as the default values for "Easy Parse XML"


    Thanks! That will be great. How can I find out when this gets implemented?


    Regarding your solution (it's great, BTW!), I would probably use variant manipulation instead of control references, since control references requires the front panel to be loaded into memory and can cause some complications during the application build process and also can cause some performance issues. However, doing that requires recursion, which is a bit more complicated :)



    You got me thinking. One of the systems we are going to implement this on uses LabVIEW Real Time. I don't have the Real Time system here right now to test, but I have a feeling my workaround won't work there. What do you think?


    When you mention "variant manipulation" are you referring to the OpenG VIs that give out the type descriptors inside the variant?





    PS: I like the new forum theme :)

  7. I had to modify my workaround so it would work as a subVI.


    I added a "hack" to make sure the output would be updated with the latest value. (Note that I did not do a snippet this time, because it messed up the references and now it wanted to add a property node for the local variable.)




    Find attached the VI.



    Any help on making this easier/better would be much appreciated.




  8. This is the work around I plan to use:




    Please let me know if there is a better way or a feature that I don't know about in Easy XML.


    If this is not present in Easy XML, it would be nice for a future version to have a boolean to set if the output cluster should "use LabVIEW defaults for empty elements" or "use values wired to the 'LabVIEW Data (Type)' input".




  9. I am using EasyXML for the first time and I love it.


    One problem I have is that the XML messages I will be getting might not have every single element in the XML schema. I was hoping that the output of the "Easy Parse XML" would return my default values for the empty elements as opposed to returning the LabVIEW Defaults for the empty elements.


    So in the example below, I would get for the vehicle OUT: ver =2010, pitch=-91, roll=-91.


    Is there a way to identify the empty elements?


    post-2936-1288215635.png post-2936-1288215639.png

  • Create New...

Important Information

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