Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. For some reason I am currently getting this message when I try do build my project: Error 1 occurred at A VI broke during the build process from being saved without a block diagram. Either open the build specification to include the block diagram of that VI or enable debugging to include the block diagrams of all VIs in the build. Report this error to National Instruments technical support. C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\JKI\JKI SMO\SMO\Private\LaunchProcess.vi Click the link below to visit the Application Builder support page. Use the following information as a reference: Error 1502 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi Possible reason(s): LabVIEW: Cannot save a bad VI without its block diagram. Possible reason(s): LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @. The VI is perfectly fine outside the build process. Any ideas what could be the issue here?
  2. In none of the text controls in the package builder the 'Delete' key works. Is this a bug or is this by design? It is definitely highly annoying :-(
  3. I am using the community version for VIPM 2010.0.1 on XP-32bit. I created some packages where I manually specified the package dependencies. Now I want to update the package dependencies. Unfortunately when I select a dependency and click 'Edit' it only shows me the same version number, none of the higher ones installed since. When I try to remove the dependency, nothing happens, except that the dependency gets de-selected in the list. When I try to add the same dependency with a higher version number, nothing happens. I tried changing the version number in the .vipb file, but it seems like you have a checksum on that file. I attached a sample file that has these problems. .vipb
  4. With the increase of packages offered through the package network it would be very nice to be able to hide packages from view. For example I have no interest in the Biometric Fingerprint packages so I would like to be able to hide them from view. Of course that would also require a function to show hidden packages in case I do want to see those packages later.
  5. Hi guys, I just added LV2010beta to the version list. When I clicked OK I was shown the list of packages with all packages that were installed in LV2009 as installed in LV2010. This persists after a restart of the program. This is VIPM 3.0 (build 1280) on Win7 (64bit). I did find an error file: March_04_2010.txt The worst part is that when I went to "delete" the 2010 packages, VIPM opened LV2009 and deleted all the packages in the 2009 repository. So somehow it finds 2010b in the registry and can also launch it from the Port Config test dialog but the repository seems to get short circuited to the 2009 repository. Any ideas? Heiko
  6. Hi guys, I am trying to package a set of device drivers that are LV classes. I have each of these classes in its own LLB in the package source in order to avoid name collisions. Unfortunately VIPM tries to put everything into a single DLL before packaging. From what I remember from OpenG package builder this is not a necessity. I understand why you do it and I have no problem with that most of the times, but could you give users the option of turning this off? Thanks, Heiko
  7. I would love to create packages from 2009 that are saved as LV8.0, which is as far back as I can save from 2009. I have a build script that converts the package source to LV8.0 but when I run the package builder it mass compiles the package source to LV2009. I know I can install LV8 and then run package builder from LV8.0 but I was wondering if there was anything in the package build process that would absolutely require the MassCompile? Doesn't OpenG Builder just zip everything up and rename the file (more or less)? Could we just have an option to have the pre-build mass-compile optional?
  8. I figured as much but had not had time to do it before I wrote the post. I changed it and everything is building fine now.
  9. I am unable to build packages using VIPM 2.0.3 and LV2009. I have tracked the problem to OpenG Builder, specifically to the Filter Illegal File Names_ogb.vi. It looks like NI changed the connector pane of the Is Name Multiplatform.vi in LV2009. Since Filter Illegal File Names_ogb.vi uses a strictly typed refnum to call Is Name Multiplatform.vi this throws an error and aborts the build process. Is there another version of OpenG Builder that I am not aware of? I have version installed and VIPM shows no newer versions. Here is the output from OpenG builder: Error 1031 occurred at Error 1031 occurred at Open VI Reference in Filter Illegal File Names__ogb.vi->Generate VI Building Info__ogb.vi->Build Application__ogb.vi->OpenG_Builder__ogb.vi Possible reason(s): LabVIEW: VI Reference type does not match VI connector pane. Error Conditions: VI Name: ViPropertyNode.vi VI Path: C:\Users\Heiko Fettig\Documents\Code\RivardFettig\ReUseLibrary\Released\ApplicationControl\Source\ViPropertyNode.vi VI Path: C:\Program Files\National Instruments\LabVIEW 2009\vi.lib\Utility\libraryn.llb\Is Name Multiplatform.vi Possible reason(s): LabVIEW: VI Reference type does not match VI connector pane.
  10. Hi guys, I was trying to apply a package configuration that I created on my main machine using LV 8.6 to my test machine with the LV 2009 beta. I got a message that VIPM needs LV 8.6 to apply the configuration. Is this expected behaviour? Is this related to my having packages embedded in the configuration file? If so, how do I change a configuration file to the latest LV version? Or do I have to install everything manually and then create a new file for the new version? Thanks, Heiko
  11. Hi folks, This was fixed by uninstalling and re-installing VI Tester but you might still want to know. Could be a palette refresh problem. After I installed VI Tester for the first time I did get the palettes for VI Tester but the only things populated were the sub palettes. I un-installed and re-installed and now it works fine. Maybe the palette refresh was called too early? Cheers, Heiko
  12. hfettig

    Mass Compile Bug

    Hi, When I opened the Tester the first time it popped up with the mass compile dialog. It compiled all 374 files into LV 8.6 in 28s and then nothing happened. The dialog is still open, the panel close button and the abort button do nothing. I can also resize and maximize the dialog front panel. However, I can click back on the VI Tester GUI and run that without problems. Maybe you forgot to close a window? Cheers, Heiko
  13. Hi, I am evaluating EasyXML and ran into the following problem. Even after naming my Array and the first scalar in my cluster the same (Value) the output gives me a node. Anything I am doing wrong here? I am actually trying to parse the XML file and everything works except reading the value content, e.g test. Heiko
  14. Hi, I was just wondering if it was possible to apply a package configuration file (which might contain packages), which was created with the professional version, using the community edition. I sent a configuration file to a customer and he reported back that he got a message that this functionality was only available in the professional edition. Cheers, Heiko
  15. So far I have only one use case for the rsc and that one I created using OpenG package builder. Basically I created a package that creates a category for my company in the palettes and points to a DynamicPalette folder in user.lib/_RFpis.lib. This is where I put all the mnu file for the packages I create with VIPM. Incidentally do you have an idea how to create a category in the Control Palette? I put an mnu file into menus/categories and get a category entry on the functions palette, but when I put an mnu file into menus/Controls nothing happens. Other use cases: I have a set of templates that I packaged and install into the templates folder. Those currently have _lib_ but might be more accurately called _tpl_ or something to that effect. I was also thinking of packaging Mark Balla's icon editor to easily install it. Here I would probably use _rsc_. Of course packaging those things are completely different use cases from packaging re-use VIs. There are no palette entries involved and you might want to be able to support multiple destinations. So maybe it is simpler to just continue using OpenG package builder for those cases. Heiko

Important Information

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