Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by amaggs145

  1. Here's a slightly tweaked version that should work for you:




    Let me know if you need anything else.



    Ah, okay great, thank you. I actually converged on this solution before I even saw the post here. I am noticing a trend, my last issue required the use of that Varray to Vcluster, this seems to be a useful one for XML toolkit :D Is there any documentation that explains why some data types work and others don't?

  2. One of my colleagues that I work with uses Perl to read & write XML files. One on the features that he likes most about this is that the XML files are extensible in the sense that more information can be added to the files later without breaking previous code that was used to write and read the original version of the files before additional information was added.


    I was wondering if there is some tip or trick to having this same capability with the VI's available in the XML toolkit. One way that I was thinking of was instead of using "Easy Read XML File.vi" directly I could read the all the data within the file first with LAbVIEW's file read VI's, then do some processing on the text to extract only necessary data and then use "Easy Parse XML.vi" on select portions of the file.


    There may be some other method that would require less custom coding for each file. Thanks for any input.




  3. In an application that we are using, we have many variables, they are stored in a data structure as variants although their type varies. I would like to be able write their names and values out to an XML file using a string as the name and just the variant as the value. This works for one element, however when I try to write them all out using an array I get Error 1. I have attached the VI. Maybe there may even be a better method for doing this, any suggestions are welcome. Thanks

    Write Variable Name and Value.vi

  4. This feature is not available currently in VIPM. Just to clarify. Multiple packages can definitely target the same category. But in your case, you want to merge the subpalettes. We are working on adding something like this to VIPM since it has been asked by others as well. For now, I would dedicate your package to it's own subpalette within the common category.


    Hi Michael, it has been a few months since we talked about this feature. I am just wondering if this is something that is likely to be available soon or is kind of on the back burner for the moment. I guess I am just trying to figure out if I should put the effort into a work-around (which means rebuilding packages etc..), or just deal with it the way it presently is because a solution will be available soon. Thanks

  5. Every package needs to define the RFI custom category in order for it to work.


    Hi Michael,


    All of my packages thus far have RFI as the custom category. But there is a level below this custom category (the Functions level) that I want VI's to be added from different packages, I am not sure if this is possible or not. I am attaching my source code with the two packages that I am hoping that their VIs can be consolidated under 1 Functions palette.


    The 2 packages with VI's to be consolidated under 1 Functions palette. (The name of this Functions Palette is "RFI Comparison Tools")

    1. rfi_lib_valid_number_expression-
    2. rfi_lib_within_percentage--


    There is also one other package included that is needed for a dependency:

    1. rfi_lib_plus_&_minus_percentage-

    Packages and Source Code.zip

  6. So I have created some reusable VIs, packaged them, and had them install in my palette here: Functions\RFI\RFI Comparison Tools


    This worked great for the first package, but then when I created a another package of a reusable VI's and wanted them to install in the same palette as above, it just created a duplicate RFI Comparison Tools palette and installed these new VIs there. However I would like the previously installed VIs and these newer ones to all install on the same palette.


    What am I doing wrong?


    Let me know if you need me to post the packages or source code.



  7. I would question the reason. The code is already available as a package. Why not use it? What's the problem?



    The issue with the existing package is that if the input is not a predefined LV data type, the VI will morph the input, and the output becomes a variant where I now have to convert back to my original data type. So I have created a package with the same code but it drops the code onto the block diagram instead of the VI.


    But whether or not this is a breach of license I don't think depends on the designer's reason/motive, does it? I guess my question was a general one, rather than specific to this circumstance. But indecently this circumstance is an example of what I am generally concerned about.



  8. I'm suspecting that the issue is the permissions on the LabVIEW folders under Windows 7. I think Windows 7 wasn't officially supported by NI until LabVIEW 8.6. This means that the permissions settings are probably preventing VIPM from installing the packages. This should not be an issue with LabVIEW 8.6 and later.


    One workaround is to force VIPM to run with Administrator privileges under Windows 7. This might get you access to install the package without errors.


    To do this, right-click on the VIPM executable shortcut and select: "Run as administrator" form the menu.


    Then try running through the same package installation process. Let me know how it goes.


    Hi Michael,


    Yes sir, this did it! Thanks for your help.

  9. What operating system version and LabVIEW version are you installing on? Both in the case that worked and did not work.

    For example Windows 7\32bit 64bit\ LV8.5 etc.


    LabVIEW version 8.5 on both machines. On the machine that worked, Windows XP, and on the machine that isn't working, Windows 7. Let me know if you need any other info. Thanks for the help http://forums.jki.net/public/style_emoticons/default/smile.gif

  10. I am somewhat new to using VIPM, thus far I have been enjoying it very much. It feels great to have a clean/streamlined way to create, organize, and manage all of our reusable VI's.


    One of our primary uses of LabVIEW where I work is to communicate with test equipment. We have a good deal of instrument drivers that we have written and also instrument drivers that we have downloaded from various places, mostly from ni.com. These instrument drivers are mostly in the Plug & Play form or the Project Style form.


    I am eager to create packages of these various instrument drivers. I was wondering if there is a how-to somewhere that may outline the "best practices" when converting these types of instrument drivers to packages.


    Besides being concerned with a good overall/general way of doing this I do have a few specific questions.


    If we consider the project style instrument drivers (I have attached one here) all of the VI's are in a .lvlib library. To be honest, I have found these libraries to be quite annoying sometimes, they seem to be very glitchy as far as their internal linkages and things of that sort, I can't recall any specific gripes but I do remember them costing me alot of time when trying to develop some drivers using the .lvlib. When converting this type of driver to a package is there any need or benefits at all to keeping the driver VI's and other files in a .lvlib? I know this is how NI recommends to build instrument drivers, I am thinking it is to prevent cross-linkage with other drivers that may have the same name VIs, but with VIPM we are able to add a prefix or suffix to every VI in our package, I am thinking/hoping this will be sufficient enough to get rid of that .lvlib. Any thouhgts?


    If I keep the same folder structure as laid out inside of the .lvlib, at the top level there is a dir.mnu file that contains all the info to map out the palette (and these .mnu files also include the info for the sub-palettes pictures I think...). Is there anyway to somehow import this file using VIPM to have it set up the instrument driver palettes the way they were designed to be when the driver was built instead of having to manually go through this process which includes removing VI's that are not intended to be visible, moving items around to have a more intuitive palette, and the most labor intensive part is copying all of the sub-palette icons from the original palette into VIPM. Maybe if we can't import this dir.mnu file directly are there any tips/tricks that can make this process a bit easier? Especially the sub-palette icons copying step, the only way that I know how to do this is to (1) go into LabVIEW and go to Tools>Advanced>Edit Palette Set (this takes quite a while to load each time), then (2) right click on a palette icon and choose to Copy Icon, then (3) Cancel any palette changes in LabVIEW or else won't be able to open icon editor in VIPM, then (3) go into VIPM and choose to Edit Icon, then (4) paste icon. I am getting tired just thinking about that process... Don't take this the wrong way, no complaints to VIPM at all, I am sure they are already thinking of a better way to do this if there isn't one already that I don't know about.


    Thanks so much for any help, all comments/input are welcome and greatly appreciated.



    Temptronic TP04300.zip

  11. I am trying to install a package that built succesfully but getting an error at install and the install fails. The same package that is failing to install on my PC installed fine on another PC... I attached an image of the error message, the package that is not installing properly, and also the folder with the source code that was used to build the package.




  12. We are using XML data format to store data that is being used on both a Linux machine and a Windows machine. On the Linux side the XML file is generated using Perl. One of the data types that are being written to the XML file is a hash, the hash is written to the file quite nicely and I would like to be able to write the data in the same way using Easy XML Toolkit.


    The data that is being written is just an array of 1's and 0's, so its really Boolean data in LabVIEW but because we want to see actual 1's and 0's I can just convert my Boolean array to 1's and 0's before writing.


    So I have this array of 1's and 0's, and if I use the Easy XML Toolkit to write it, I get something like the following:














    I lose the array index information. However, however my colleague has his data set up in Perl he has the ability to produce the following:














    what is the way to this with the Easy XML Toolkit?


    I did read the Compound Elements with Attributes section in the Tips & Tricks, but it doesn't seem I would be able to produce exactly what the Perl code is producing with the use of attributes.


    One way to do this is to have a cluster that has the same number of U8 integers as the number of bits I want to print, and name each integer control with the appropiate "bitXX" syntax. But I really don't want to have to deal with custom controls here, as the number of bits in an array could change.


    Thanks so much for any help http://forums.jki.net/public/style_emoticons/default/wink.gif

  13. I see -- so, this issue really only impacts you once, when you're migrating from your old palette MNUs to using VIPM to create packages. Is that right? Or, are you going to need to resync these palette icons again, from the source location into VIPM?


    I am probably going to go through revisions of the source code, and at certain stages will rebuild the packages. I am thinking that I will only have to migrate my icons once though because they will then be embedded in the .vipm file for the next time I go to rebuild the package.

  14. I am new to using VIPM and am exploring all the neat features available. One procedure I noticed to be a bit laborious is creating icons for the different virtual folders in the palette. I am sure that this question has been asked before, but is there some way to automate this? Maybe putting a icon.bmp or .ico file in each directory and this image can automatically be selected for the icon when "Autogenenerate Icon" is initiated. Thanks for any help :D

    • Upvote 1
  15. Hi There. This thread is really only relevant for VIPM 3.0. In VIPM 2010, we added the ability to create/install a custom palette category for your package. Have you tried this? Can you explain more about what you are trying to accomplish, so that we can best help you?





    I would like to be able to automatically generate a palette with my company name in the functions section of the palette. Then under my company name put different categories much like the OpenG palette is organized. Using the VIPM it seemed limited in the sense that you can only go 2 layers deep. For example I have a VI called "Is String Numeric?" I would like to put this VI here: Functions\RFI\Comparison\Is String Numeric. How do I add these extra layers? I know that if Fucntions\RFI already exists then in VIPM I can set the Category to Comparison and then browse to Fucntions\RFI for my functions path, but what if this doesn't exist yet, how do I get it there, is there a way to automate this without using LabVIEW Edit Platte Set?


    Also, the available top level folders in the VIPM Function Palettes in LabVIEW are not reflecting all the top level palettes that are linked to directories that I can see in LabVIEW's edit Palette set, where is VIPM getting this list?


    Is there any information anywhere regarding the pros and cons and the how to about creating a dynamic palette structure like OpenG?

  16. Is this example available in LabVIEW 8.5 also? I had all the VIs downconverted, but the acme_lib_example_vi_package-1.0.1-1.vip is only compatible with LabVIEW versions 8.6.


    Thanks for your help ;)

    Hi Daklu,


    Here's how we do it. Please check out the attached example:




    This includes the following:


    acme_rsc_palette-1.0-1.ogp (file)

    A package that adds an Acme Tools category to the Functions Palette.


    Palette Category Package Source (folder)

    Run "Example - Build Palette Package.vi" to create the "acme_rsc_palette-1.0-1.ogp" package. You can edit the parameters in the constant on the block diagram. Edit "icon.bmp" to change the icon.


    acme_lib_example_vi_package-1.0.0-1.vip (file)

    An example package that gets added to the Acme Palette.


    Example VI Package Source (folder)

    VI Package Source Folder for the " acme_lib_example_vi_package-1.0.0-1.vip" package.


    Other notes:

    • acme_lib_example_vi_package-1.0.0-1.vip has a dependency on the acme_rsc_palette package.
    • the acme_lib_example_vi_package package uses a custom installation location: <vi.lib>\addons\_Acme.lib

    Let me know if you have any questions.

  • Create New...

Important Information

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