Source Distribution error in LV8

[Derek.Mayer]

Hi all,

Im running LV 8 on WinXP, and it is now giving me problems creating a source distribution (SD):

"Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1 occurred at Invoke Node in ABAPI Update Libraries.vi->ABAPI Dist Build LLB Image.vi->ABAPI Copy Files and Apply Settings.vi->SDBEP_Invoke_Build_Engine.vi->SDBUIP_Build_Invoke.vi->SDBUIP_Build_Rule_Editor.vi->SDBUIP_Item_OnDoProperties.vi->SDBUIP_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW:  An input parameter is invalid.
---NI-488:  Command requires GPIB Controller to be Controller in Charge."

I was able to successfully create SDs yesterday. Then I made a change to my project, which has several, nested project libraries. Several of them were linked to different copies of a Type Def control (cluster with string and variant inside). The link was NOT direct (CTL on FP or constant on BD), but rather the element data type for several queues. I intended to have only one copy of this definition, but I made a mistake in playing with LV8 projects to get started. Since the Find & Replace could not find the instances of the copies, much less replace them, I was stuck. I went to the HD and deleted all copies except the one I wanted. I made sure that the one I wanted was included in the appropriate project library and I opened the top level (and all dynamically called) VI(s). Of course they asked where to find the CTL, and I directed them to the one I wanted. I saved changes, CTL-Shift clicked on the run arrow to force a complete recompile, and saved changes again.

After all top-level and dynamically called code was completed, I updated the source distribution settings and tried to rebuild. I got the error listed above. I deleted the build spec and created a new one from scratch in the same project. Same problem.

Any ideas??

Interestingly enough, the builder was complaining about all the instances I had of the same type def. It warned me not to call them dynamically, as the distribution would act differently than my project. When I looked at the files in the the built directory, the copies were numbered CTL_Name0.ctl, CTL_Name1.ctl, CTL_Name2.ctl, etc.

[AESulzer]

Derek,

I'm a little confused on what exactly occurred to get you to this state. You mentioned that it was "a mistake you made in playing with LabVIEW projects" that led you to this problem, but after tooling around with things myself, I was not able to reproduce it. Do you recall exactly what steps you took to produce this behavior and would it be possible for you to post a simplified example with steps on how to reproduce the behavior in it ourselves? That would be a huge help in diagnosing the problem!

As for your specific project, did you save a back-up version of it before you started experimenting on it? The easiest thing to do would be to revert to a back-up, but if that's not an option, then perhaps creating a new project in LabVIEW for all of the source files would fix the problem. My best guess is that the project has been put in some kind of corrupt state, and if we can figure out how, then at the very least we can make sure to guard against it in future releases.

Kind Regards,

[Derek.Mayer]

Thanks for your thoughts, I tend to agree that it is a corruption somewhere, but I'm not able to flush it out with forced recompiles or be creating new projects
 and adding my code from scratch.

I started by creating my app all in one LLB. I created LV Proj folders and put the different sub-systems in different folders. Then I realized that was NOT
the same as project libraries. At the same time, a co-developer gave me a small set of support libraries to add to my dev system. So, I broke up my one
LLB into a single LLB for each subsystem and made each smaller LLB a project library. Thus, I now have a main proj library that has only a handful
of VIs, and ~ 8 project libs supporting it. When I broke it up into smaller LLBs, I opened the top-level VI(s) for each and made sure they would compile correctly.
When I did that, they each complained about a missing type-def (the one I described earlier). At this point, I think I made ~8 copies of that type def, and
saved 1 copy in each LLB. Oops!

Then, when I tried to make a source distribution, LV gave me warnings about name collisions. If I call them dynamically, it may not work from the SD
since there were so many with the same name, and it decided on a different naming structure. (By the way, I have selected " Include if Referenced" in
the "Source File Settings" for my support libraries. But, subVIs that I was not linked to were being added to my SD, and creating further name collisions!)

So I went about diligently trying to remove the name collisions (that I could). I did not want the different LLBs to each have their own copy of a common
subVI, I wanted them all to point to the same one for obvious reasons. I did that for all statically linked code with no problem. For each one that I resolved,
it was one less warning in the SD build box. Great! I'm on the right track.

Then I tried the type def that defined the data type for my queues and user events. I could not fix the problem in the same way; going to the link on the BD
and forcing a replace with the subVI I choose. I tried several other methods to try to get all references to point to the same CTL, but after much
frustration I finally went ahead and deleted the CTL on disk of all copies and kept only the original. I loaded the code, pointed it to the CTL of my choice
at the search box on startup, and thought the problem was solved. Then the SD refused to work.

Yes, I have backups, but by now they are so old that I'd lose more than a week of work. The work-around is to just copy the whole project to disk and move
it, which is what I have been doing. In a few days I'll be making an EXE to deliver my first version. Still, it's a huge pain.

What can I do? I tried creating a new proj from scratch, adding the support Libraries, then adding my code (actuall, a copy). I made sure all were
properly assigned to libraries, and forced recompiles. No dice.

[AESulzer]

Derek,

I apologize, but I'm still having some trouble following things. It seems that it was a lengthy and involved process that got you to this point. You mentioned LLB's quite a bit and the new project structure is actually intended to replace the LLB structure, so you should not really be mixing the two (although, I'm not even clear if that's what you're doing). Would it be possible for you to post an example that illustrates the behavior or even a simple set of instructions that induces it? Recounting all of the steps that you took is a bit hard to follow, so I think it would be easier to understand if we could simplify things a bit.

Kind Regards,