Jump to content

Shedding light on Error 1357?


OllyT

Recommended Posts

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

  • 6 months later...

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

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

  • 3 weeks later...

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

  • 1 month later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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