OllyT Posted December 11, 2013 Report Share Posted December 11, 2013 Hi All, I'm encountering an error trying to build a package in VIPM (2013 Pro). I'm pretty sure I've cause this problem myself, but can't quite put my finger on exactly what is wrong... Firstly I'll give you a brief bit of (probably relevant) background info. I am using LabVIEW 2012 SP1 and for various reasons I needed/wanted to branch off development of a few LVOOP classes that a supplier has provided. So I took the (probably unadvisable) step of saving the classes with different names. This seemed to work fine and I encountered few problems doing so (other than having to make sure the classes had the correct version of VIs inside them and not ones from the old class). Next I created a brand new class (Power Supply Class) and had it inherit from my new classes. Everything still seems to work fine and it all runs ok. So My new class structure is something along the lines of: CDE Root ->CDE SCPI Instrument (child of CDE Root) --->Power Supply Class (child of CDE SCPI Instrument) Both the root and SCPI classes packaged up fine. However whenever I try to build the Power Supply Class I get the following error: There was a problem building Power Supply Class. Error Details: Code: 1357 Source: Error 1357 occurred at Invoke Node in Save VIs to Destination__ogb.vi->Build Application__ogb.vi->Build Application from Build File__ogb.vi->Build Application from Build File__ogb.vi.ProxyCaller Possible reason(s): LabVIEW: A LabVIEW file from that path already exists in memory, or exists within a project library already in memory. Error Conditions: Private Save VI Name: "CDE SCPI Instrument.lvclass:Information.ctl" VI Path: "C:\Users\othomas\AppData\Local\Temp\vpbtmp\src\LabVIEW\vi.lib\COM DEV\Power Supply Class\Information.ctl" Method Name: Save:Instrument (Private) So, Information.ctl is a control that exists in CDE SCPI Instrument but not in the Power Supply Class (it is just used there). Can anyone shed any light on how I might go about resolving this? I've tried the usual stuff of shutting LabVIEW down, rebooting windows but no joy! Thanks, Olly Link to comment Share on other sites More sharing options...
Michael Aivaliotis Posted December 18, 2013 Report Share Posted December 18, 2013 I would take a look here and try the suggestions. But, I think you've already found the problem. In order for you to be able to build the child class as a package, you must first build the parent package, install it, then link the child package source to the installed class. Link to comment Share on other sites More sharing options...
Colbrunn Posted July 16, 2014 Report Share Posted July 16, 2014 I am having a similar issue. The trouble is that I have two approaches that don't work, and a third that is a lousy workaround. Hopefully there is a fourth option that I am unaware of. Failed Option #1: If I try to build something containing the child class while referencing the original (unpackaged source) parent class then I get error 1357. The solution proposed to this issue is: If you are trying to build packages of a class inheritance then there are special considerations: When building a package of a child class separate from the parent class (one package for each class) - the child class VIs (in your source) must call the installed parent package not the parent class in the source. Impractical Option #2: The trouble with this approach is that if I have password protected the original package it asks for me to type in the password for every file it is trying to open and modify from the installed packaged during the build. If I went through the trouble of typing it in a large number of times (and never made a mistake since it aborts the process if the password is mistyped) I suppose it could theoretically work, but this is not really a solution. Limited Functionality Option #3: This approach involves me checking the box for "Do Not Compile on Build". This actually does build a package that can be installed because it doesn't check anything. However, there is no way to batch password protect during the build. I would have to write something to do this ahead of time, but then I just add one more step to the process outside of VIPM. I also haven't tried to see if I can bind the library to a license file when the "do not compile" is checked. Besides, checking this box is not recommended. I would hate to use software in a non-recommended fashion... Practical Solution Option #4: Very interested and open to suggestions. Link to comment Share on other sites More sharing options...
Michael Aivaliotis Posted July 23, 2014 Report Share Posted July 23, 2014 Impractical Option #2: The trouble with this approach is that if I have password protected the original package it asks for me to type in the password for every file it is trying to open and modify from the installed packaged during the build. If I went through the trouble of typing it in a large number of times (and never made a mistake since it aborts the process if the password is mistyped) I suppose it could theoretically work, but this is not really a solution. In regards to the above #2. I think there may be an issue with VIPM here, or my understanding of the problem. I just did two separate tests. One with classes and one without. In both cases I was calling installed package code with a password. I never got a prompt for the password. This is what I expected. Could you reproduce a simple example with this issue (and attach it)? I couldn't reproduce it. Link to comment Share on other sites More sharing options...
Colbrunn Posted August 8, 2014 Report Share Posted August 8, 2014 Michael, Thanks for looking at this. I did what you did and got the same result. No problem. So I expanded my simple 2 package scenario to include more features that more closely matched what was happening the code I discovered the issue in. It took some messing, but I finally identified the things needed to reproduce the problem. I have also attached the source code and the parent package to give you a test bed to help you guys find a fix for it. Scenario 1: Parent class (with methods as part of a library) made into a parent package. Child class (with its methods as part of a different library) made into a child package. Result: No problems with either build. Note that after the parent build I installed the package and deleted the parent source code. Opened the child and remapped it to the installed parent files before building the child. I went through this process each time I built the child. Scenario 2: Parent class (with methods as part of a library) and an oldest child class (with its methods NOT part of the library) made into a parent package. Child class (with its methods as part of a different library) and whose parent was changed to 'oldest child' made into a child package. Result: No problems with either build. Scenario 3: Similar to 2 but I messed around with a few other things like creating a vi in the child package that called some of the vi's from the parent. Still built fine. Scenario 4: Similar to 3 but I changed the Toolkit VI destination in the CHILD to OS Boot Volume Root and I appended the path to get it into a temporary folder I made in Program Files. Still built fine. Scenario 5: Similar to 4 but I changed the Toolkit VI destination in the PARENT to OS Boot Volume Root and I appended the path to get it into a temporary folder I made in Program Files. Result: BAM! This was it. The parent built fine, and I installed it. Then when I went to build the child, it asked for a password of a parent vi during the build process. So it seems like the issue is associated with where I installed the parent package. Attached in the source code to help you guys identify a solution as quickly as possible. Looking forward to any VIPM revisions or work arounds for this issue... Parent-Child Problem_1357.zip Link to comment Share on other sites More sharing options...
Colbrunn Posted September 11, 2014 Report Share Posted September 11, 2014 I know there were some issues with getting this to repeat on 32-bit LabVIEW since I built the previous example for 64-bit. I have attached a version for 32-bit along with detailed instructions in a readme.txt file and a screen shot of the issue. Hopefully this assists with the diagnosis process. Error 1357 or password problem example.zip Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.