Jump to content

RDR

Members
  • Content Count

    17
  • Joined

  • Last visited

Everything posted by RDR

  1. This may be intentional behavior, but I noticed after installing a new version of LabVIEW on my system the Tools menu entry for VI Package Manager did not show up until after launching VI Package Manager. It appears you're creating the files during VIPM start-up and not during installation? Is this intentional? -RDR
  2. ...Just checking in. This issue still affects us and we've not heard back in about a week. Is there any other information we can provide?
  3. Do you have anything else we can try in order to resolve this issue?
  4. Hello Ashish, This happens on 5 different systems with an EXE calling the VIPM API--no changes were made to the code or OSes besides regular Windows Updates. As for access to the repository, you should have access to the LabVIEW Tools Network repository as we publish it to the NI FTP here: ftp://ftp.ni.com/evaluation/labview/lvtn/vipm/index.vipr This is the repository we're having trouble with when using the API and it is quite large. Here is the internal repo I tested with and did not have any trouble adding a package to using the API (no changes were made to code outside of changing the repository name string for the API call): [self] Self.Name=LV2P Tool Repository Self.URL=file:///c:/dropbox/lv2partner shared/lv2p tools/vipm tool repository Release.Number=1 Release.Date=Wed, 04 May 2016 10:57:47 -0500 Self.ID=a1f737822f4af51af05e180b4ea215dc Client.GlobalAccess=TRUE [Package ni_lib_simple_math_library-1.0.0.1] Package.URL=packages/ni_lib_simple_math_library/ni_lib_simple_math_library-1.0.0.1.vip Icon.URL=packages/ni_lib_simple_math_library/ni_lib_simple_math_library-1.0.0.1.bmp Spec.URL=packages/ni_lib_simple_math_library/ni_lib_simple_math_library-1.0.0.1.spec Package.MD5=e0d8f11764d012aa44f16827b2c95631 Package.Release Date=Wed, 04 May 2016 10:57:47 -0500 Platform.Exclusive_LabVIEW_Version=LabVIEW>=13.0 Platform.Exclusive_OS=ALL Package.Display Name=Simple Math Library Platform.Exclusive_VIPM_Version=2014 -RDR
  5. Also, here is the string passed to the System Exec call within '\LabVIEW 2015\vi.lib\JKI\VIPM API\command-line\support\Run EXE with Command-line Switches_vipm_api.vi'. "C:\Program Files (x86)\JKI\VI Package Manager\support\VIPM File Handler.exe" -- "/command:repository_add_package" "/sources:C:\Users\lvtn\AppData\Local\Temp\lvtemporary_431412.vipm_return" "/repo_name:NI LabVIEW Tools Network" "/return_file:C:\Users\lvtn\AppData\Local\Temp\lvtemporary_333527.vipm_return" "/quiet:TRUE"
  6. Here is what I found in the VIPM error log: =========== START of VIPM 2014.0.2 (build 1976) Error Message =========== An internal VIPM 2014.0.2 (build 1976) Error has occured on: Wednesday May 04, 2016 at 04:42:09 PM = Automated Message Start = Error 1 occurred at (Invalid URL) E6C7850DB8DC443245FEA289ED5599DC in OGPM Class.lvlib:2298EAB45C3ADB6BA393ADD20A1567B2->Repository.lvlib:E4BDF9BD7B76EC63B78E078A2430E6BE->Rep ository.lvlib:412A7FE00073B5B996D6EC522E780BF5->VIPM API.lvlib:5F6CC0C4C5DFEC614D6E5B026429AAF0->2EDC3C81B4A2C6C7E1F2041B75CF3851->VIPM Main Window.vi 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 @. = Automated Message End = = Error Handler Call Chain Start = VIPM Main Window.vi-> 2EDC3C81B4A2C6C7E1F2041B75CF3851 = Error Handler Call Chain End = =========== END of VIPM 2014.0.2 (build 1976) Error Message ===========
  7. Also, I am able to manually add packages to the Tools Network repo without issue--the error is only reported when using the API call.
  8. As an update, I can post to a different repository without issue. This appears to be specific to the Tools Network repository--do you see any issue with the .vipr file? ftp://ftp.ni.com/evaluation/labview/lvtn/vipm/index.vipr -RDR
  9. When using the Publish Packages to Repository.vi from the VIPM API I am receiving the following error text: 10:27:19.871 AM 5/4/2016 Error 1 at VIPM API_vipm_api.lvlib:Parse String Array Message_vipm_api.vi<ERR> Code:: 1 Source:: (Invalid URL) E6C7850DB8DC443245FEA289ED5599DC in OGPM Class.lvlib:2298EAB45C3ADB6BA393ADD20A1567B2->Repository.lvlib:E4BDF9BD7B76EC63B78E078A2430E6BE->Repository.lvlib:412A7FE00073B5B996D6EC522E780BF5->VIPM API.lvlib:5F6CC0C4C5DFEC614D6E5B026429AAF0->2EDC3C81B4A2C6C7E1F2041B75CF3851->VIPM Main Window.vi This is code we've not changed at all--the error started to show up recently and we can reproduce this on multiple machines. Some have VIPM 2014 and others VIPM 2015. Do you have any recommendations for what to try next in debugging this error? Thanks, -RDR
  10. When selecting to build a package for only LabVIEW 64-bit, the package is still displayed in my repository when installing to 32-bit LabVIEW. I noticed in the spec file for the packages there is a tag for: Exclusive_LabVIEW_System="ALL" I assume this is the value intended for 32 or 64-bit LabVIEW, but I do not see this tag update no matter what changes I make to the LabVIEW bitness. I am using the latest version of VI Package Manager Pro (2014.0.2). Kind regards, -R
  11. When selecting to build a package for only LabVIEW 64-bit, the package is still displayed in my repository when installing to 32-bit LabVIEW. I noticed in the spec file for the packages there is a tag for: Exclusive_LabVIEW_System="ALL" I assume this is the value intended for 32 or 64-bit LabVIEW, but I do not see this tag update no matter what changes I make to the LabVIEW bitness. I am using the latest version of VI Package Manager Pro (2014.0.2). Kind regards, -R
  12. When selecting to build a package for only LabVIEW 64-bit, the package is still displayed in my repository when installing to 32-bit LabVIEW. I noticed in the spec file for the packages there is a tag for: Exclusive_LabVIEW_System="ALL" I assume this is the value intended for 32 or 64-bit LabVIEW, but I do not see this tag update no matter what changes I make to the LabVIEW bitness. I am using the latest version of VI Package Manager Pro (2014.0.2). Kind regards, -R
  13. When selecting to build a package for only LabVIEW 64-bit, the package is still displayed in my repository when installing to 32-bit LabVIEW. I noticed in the spec file for the packages there is a tag for: Exclusive_LabVIEW_System="ALL" I assume this is the value intended for 32 or 64-bit LabVIEW, but I do not see this tag update no matter what changes I make to the LabVIEW bitness. I am using the latest version of VI Package Manager Pro (2014.0.2). Kind regards, -R
  14. Using VIPM, if you build a VI package that contains a VI which contains a FPGA Open Reference node that links to a bitfile (*.lvbitx) instead of a VI in the project, VIPM will return error 74 from a Library:Open node. This problem only occurs when building a package using LabVIEW 2012 or later. It does not occur in LabVIEW 2011 or earlier. This issues is caused by a change in behavior of a private Invoke node (Linker.Read Info from File) which is used upstream in the OpenG Builder library. This method returns a list of components (subVIs, controls, TypeDefs, etc.) used in a VI. In LabVIEW 2011 and earlier this method when run on a VI containing a FPGA Open Reference node that links to a bitfile (*.lvbitx), does not include the bitfile in the list of components. Starting with LabVIEW 2012 the bitfile (*.lvbit or *.lvbitx) is included in the list. The type of component returned by the Linker Read Info from File method for a bitfile is XNode Build Dependency. This type did not exist prior to LabVIEW 2012. The Type field from the Invoke node is mapped to the Type (new) field in the Open G Builder cluster, but the OpenG Builder library was not updated to account for this change in behavior. Therefore based on the old code, it incorrectly maps a bitfile (Type: XNode Build Dependency) to Type (new): Ladder Diagram in the OpenG Builder cluster. In addition OpenG Builder contains a more coarse Type field in its cluster, and the XNode Build Dependency type is incorrectly mapped to a Library instead of an External Subroutine in this field. Solution Update Read Linker Info__ogb.vi in the OpenG Builder library (ogb.llb) to account for this change and correctly map a bitfile to External Subroutine. This alleviates the downstream issue of trying to open the bitfile as a library in Library:Open. In VIPM this VI is stored in a support library (ogb_2009.llb) which is located in ..\JKI\VI Package Manager\support. To fix the issue, replace the existing file with the updated attached file and restart VIPM. ogb_2009.zip
  15. I've checked this to see if it relates to another issue where a .ctl from a target-specific vi.lib folder is present, but it looks like the issue Jeff reported above is the result of: having a lvproj included with the source code enclosing all RT-specific vi.lib function calls in conditional disables also having a .lvclass included in the project under the RT target In the attached source code, I cannot build the package as-is and removing the lvlcass from the RT target (either from the project entirely or by moving it to My Computer) appears to resolve the build error. del me.zip
×
×
  • Create New...

Important Information

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