LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

distribution build unsuccessful error copying files

Error copying files.
Source: C:\Testsys\SOFTWARE\UTILS\CALCULATE DP.vi
Destination: C:\Testsys\Software\Distribution\CALCULATE DP.vi

Invoke Node in AB_Source_VI.lvclass:Copy_SourceItem.vi->AB_Build.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
<APPEND>
Method Name: <b>Set Path</b>

Error 1357 occurred at AB_Source_VI.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.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.

 

How do I resolve this?

0 Kudos
Message 1 of 3
(3,342 Views)

Are you copying files with the windows explorer? If so, make sure LabVIEW is closed. 

 

I'm uncertain of your steps here. Could you detail the process?

Verne D. // Software R&D // National Instruments
0 Kudos
Message 2 of 3
(3,322 Views)

Thanks for the reply.  I was able to solve this particular issue by renaming the specific file that was causing the hangup.  Unfortunately it leaves me bewildered as the name WAS "CALCULATE DP.VI" and now IS "CALCULATE_DP.VI".  This was the only difference that allowed the build to go forward, even thought the original name does not violate naming conventions.

This was while building a .llb distribution.  On a related note, even though this build was successfule, the subsequent build of an executable went through without error, however some dynamic VIs, were not functioning and others were, when the executing the application.  The dynamic VI causing the problem was also the caller for the above "CALCULATE DP.VI".  Two of four dynamic VIs would respond to their call, and two would not, one of which was dependedn on "CALCULATE DP.VI" caller.  All dyanmic VIs were placed in the .llb and set as always included, etc.  The solution was to place an explicit call to the .llb to guarantee that it could be found by the application at run time. 

0 Kudos
Message 3 of 3
(3,311 Views)