Jump to content

Colbrunn

Members
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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
  2. 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
  3. 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.
  4. I am having an issue when trying to build a package. I keep getting the exact same error. I have tracked it down to a specific subset of the package. Below is the specific error I get. It seems there is some copy command that puts a '.' before the folder name. See '\.SSCAD Toolkit'. The '.' may be normal, but that it the only thing I can make sense of in the erorr message. If I get rid of the '.' the path is valid and the file opens fine. If I exclude this child-class subfolder from the build (aside from the fact that it is used in other places) I get a similar error with a different child class. Probably just the next one in the list. Any advice? ****************************************************************** There was a problem building SSCAD Toolkit. Error Details: Code: 6 Source: Error 6 occurred at Invoke Node in Library.Save__ogb.vi->Copy Project Library Files__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: Generic file I/O error. ========================= NI-488: I/O operation aborted. Error Conditions: Copy Project Library error: Source: C:\Workspaces\Working vi.lib\.SSCAD Toolkit\Sensor\Classes\Sensor\Digitized Sensor\Single Channel Digitized Sensor\Single Channel Digitized Force Sensor\Single Channel Digitized Force Sensor.lvclass Target: C:\Documents and Settings\colbrur\Local Settings\Temp\vpbtmp\src\LabVIEW\vi.lib\BioRobotics\SSCAD Toolkit\Sensor\Classes\Sensor\Digitized Sensor\Single Channel Digitized Sensor\Single Channel Digitized Force Sensor\Single Channel Digitized Force Sensor.lvclass The Project Library is linked to: Create New Sensor.vi Advanced Sensor Interface.vi Get_List_Item Symbol.vi Read Values_1D DBL Array.vi Write Configuration File.vi Create New Sensor.vi Advanced Sensor Interface.vi Get_List_Item Symbol.vi Read Values_1D DBL Array.vi Write Configuration File.vi Single Channel Digitized Force Sensor.ctl
  5. Let me begin by apologizing for my naivete. I am really interested in what VIPM has to offer, but I am pretty sure I am missing the philosophy of how to use it when it comes to source code control, expected path dependencies, code debugging and testing, and building packages. I could really use a quick primer on how to make this work. I have looked all over the help and videos on this website as well as lava. But I think I am missing something simple. This is a call out to all the super genius VIPMers. Our Situation: We have developed roughly 2500 reusable vi's and they are currently in user.lib and vi.lib. Everything is under SCC and when we create a new system we check out these files into the appropriate spot. As we make refinements and check things in, the other users can just update and have them in the right spot. Everything can be logically broken up into about 19 different packages. We also have developed an application in Program Files (~1000 vi's) we shall call ProgramX and there are calls many of these reusable vi's in user.lib and vi.lib. We are now distributing ProgramX and all of the 19 packages to customers and want to use VIPM to help keep track of all of it. My Flawed Philosophy: I was thinking that I could just build packages from the code on our systems and effectively zip it up for distribution to a customer to automagically place the files in the right spot. I would keep the .vipb file in the folder where the source code is (in the right place in vi.lib and under SCC). Then, if I wanted to make a new package I would build the latest and away we go. As you know, and I recently learned, VIPM won't build files under the LabVIEW 20XX directory. There goes my grand plan! It looks like I have to build the packages from the files when they are out from under this directory. I tried just copying and building, but it complained that I had copies named the same thing under the LabVIEW folder. I then removed the files from the vi.lib folder, but then it complained that the dependencies were missing. So, it looks like I have to actually use some other 'project folder' for development, and then build from there and install into the vi.lib folder so that ProgramX (from Program Files remember) refers to the right files in the vi.lib folder. You might say, duh! that is how it is supposed to work. I get that. However, that makes development and refinement of all these different code groups a pain. Now, if my cube-mate who is jointly working on development with me wants to get the latest, they need to check out or update the project folder; build a new package; install the package before they can get the change that they used to get with a simple SCC update command. Also, if my aforementioned cube-mate has to make a change to that code, they need to copy that change back into the project folder to be able to put it back under SCC. The alternative is that the ProgramX refers to the project folder for development, but then before I build that into a package I need to delete that folder and force labview to find and replace all the references to the installed package in the vi.lib folder rather than the project folder for that given sub-package. This also seems like a pain. My Plea: Though I don't understand it, I am sure there is a good reason that VIPM can't build from folders under the LabVIEW directory. The two alternatives seem manual and prone to error. It is VERY possible that there are better ways to do this that I have not thought of. Can someone please give me the VIPM expected model for developing and maintaining version control, and proper expected call references for multiple packages of code. I am really hoping there is a simple solution. Any advice would be greatly appreciated.
×
×
  • Create New...

Important Information

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