Dynamically called VI becomes broken inside an executable. Error 1003 from "Open VI Reference".

Here's the problem. Dynamically called VI becomes broken inside an executable in debug executable mode Error 1003 is occuring from "Open VI Reference" Block. The computer has all of the necessary drivers, NI-VISA and NI-DAQmx. This executable is a new release of software that currently works on the PC in question. I can using NI-VISA Remote Server control the instruments from my PC using the executable. But when I put the executable on the PC I am getting this error. The only way I have been able to get this to work properly is to build the executable from the console I believe the project was created in, note that the project file has been moved to a network drive and it still works. All of the stations I have opened the project in show the VI that is being called is runnable. I've tried building the executable from the console I am deploying to and the same thing happens.
I am honestly at a loss for ideas why this is occuring. Is this something about the way LabView works internally that may be causing this problem?
I have trolled this forum for idea's and none have made sense to me.
Any input would be greatly appreciated.
-Nate

Two ideas:
Mass compile the project to ensure all linkages are ironed out
Include the dynamically launched VI's into the "Always Included" section of the build spec
Report back on if either of these actions solves your problem.
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

Similar Messages

Why would a vi that deals with xl become broken during an executable build?

Why would a vi that deals with excel spreadsheet become broken during an executable build? Excel vi's fine in soft copy. But during executable build the vi's dealing with opening an excel spredsheet (open specific workbook and set cell value) become broken.

You have to include some dynamic files while building your executable. The files are listed on the Report Generation Toolkit CD. I believe it is _excelsub.llb, but am not sure.
Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas
LabVIEW, programming like it should be!

SubVI not executable error only when opening another VI in same instance of LabView

I have a VI (ill refer to as "A")that I have written for some of my components of my system, one of them being a loop that polls a pump controller to pick up the data (pressure, volume, etc.) coming from the pump. Now I have been able to get a VI (Ill refer to as "B")from that manufacturer that allows me to not only get the data, but write a command to my pump controller to control my pumps from labview. So, my goal was to just open both VI's (A and B), "copy and paste" (from B to A)so to speak, so that I could have controls incorporated into my existing VI (A) that has the controls for the rest of my components. However, when i open both VIs in the same instance of labview, i always get errors from the second VI that i open. Keep in mind that when running just one VI in an instance of labview, it gives me no errors. The furthest ive gotten was to open my "B" VI first, then open my "A" VI, in which the "A" VI only gives me "not an executable error" After investigating the source of the error, it says that it's coming from the loop inside my "A" VI of which polls my pump controller to get the data. So basically what im thinking is that the programming thinks that one VI is coming up with the data, and one is controlling it, so it gets confused as to whats actually going on.
Any help or suggestions would be greatly appreciated. I can attach some of the VIs if need, figured Id try to get some ideas first as to maybe what is going on...
Thanks in advance!
Matt

What errors? Do they have an error number? Do they have a description?
Since you said communication, I'm going to assume that it is serial communication and is using VISA drivers.
It is very likely the two VI's are stepping on each other's communication while they are trying to communicate with the pump.
Why don't you post the two VI's so we can see what you are doing?

HT204570 Your photo library is either in use by another application or has become unreadable. I the error message from iPhotos after the so called upgrade to Photos which left me with a blank screen

Photos upgrade a disaster. No images appear in Photos. Able to re-establish all images in iPhoto only to have the app crash after uploading new photos from iPhone. Impossible to reload photo library as it needs 161 GB of space. The non functioning Photos library is 107 GB and the original iPhotos library from which it was created is 118 GB. I only have 146 GB available on this 1 TB drive but I am reluctant to trash Photos library in case iPhotos is truly damaged.

And your question is?

How to call a function defined inside a module loader

I wanna know...the method of calling a function defined
inside a module loader component?
Th
<mx:ViewStack id="myViewStack" >
<mx:Canvas id="Mgmt1">
<mx:Label text="Gopher"/>
</mx:Canvas>
<mx:Canvas id="Mgmt2" >
<mx:Label id="gopherlbl" top="-2" left="0"
height="40"/>
<CustomComp:MgmtGrid id="ManageCom"/>
</mx:Canvas>
<mx:Canvas id="Admin">
<mx:ModuleLoader id="adminModule" url="{adminModUrl}"
width="100%" height="100%" />
</mx:Canvas>
where adminModUrl="admin.swf";
Thru the MangeCom id reference,I am able to call the fucntion
defined inisde the CustomComponent File MgmtGrid...But I am unable
to call the funciton defined inside adminModule
ModuleLoader...(using id reference).Anyone pls suggest a solution
for this..

Ensure the module is loaded before calling the method in
particular if you are calling it at the initialization of your
app.

Open VI Reference Error in the executable version only

Hello folks! I am having a strange issue since I updated to Labview 2014: I have a vi that uses "Open VI Reference" in order to programmatically open the desired vi. It worked flawless also in the compiled version (.exe) of the program until yesterday, when i compiled it again for the first time since my update to Labview 2014. It compiles with no problem, but when i start the exe and load the first vi it already gives me an error "Built Application or Shared Library (DLL): Missing".
The point is that all the VIs that i want to open are inside an LLB that is supposed to be compiled inside the .exe: infact the path that i use to open is:
D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi
And i get error number 7:
Open VI Reference in Seq_Function_Interface.vi->Sequenzer_Main_2.0.vi<APPEND>
VI Path: <b>D:\LabVIEW Data\builds\Sequenzer\Sequenzer2.0.exe\com_lv_sequenzer\trunk\Sequenzer_Functions.llb\Seq_Connect_to_Database.vi</b>
Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library.
LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets.
The vi Seq_Connect_to_Database.vi is included in my built (as you can see in the attached screenshot and as it has always been).
Do you have an idea of why it is not working anymore?
Thanks a lot in advance!
Dario Cassaniti
Solved!
Go to Solution.
Attachments:
sequenzer.png ‏86 KB

OK, here is where I am confused. You talk about including the llb in the build, but in the screen shot you show a bunch of individual VIs being included. Next, in source file settings where are you telling the app builder to store all those individual VIs? Because they are VIs LabVIEW will, by default, want to put them in the executable somewhere.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Error 1003 when loading a VI dynamically on LabView Run-time ini file configuration

hi all,
I have a problem with my runtime excutable.
On 4 systems, all running XP it runs fine.
On 2 systems ( one a new install of just LVRT 2011 SP1 ) I have:
Error 1003 when loading a VI dynamically on LabView Real-time
Or more spoecifically the error code is 1003 and the error source is Open VI Reference.
When the RT app runs correctly I get these paths:
Path Sent to Open Vi Reference: Yeast_Grower.exe\Tecan_talk_Control.vi,
Path Returned from Open Vi Refence: C:\Program Files\Yeast_Grower\Yeast_Grower.exe\Tecan_talk_Control.vi,
On a system that does gets the 1003 Open Vi Refence error I have the same Path Sent but of course no path returned as it does not open.
To be sure that the vi Dyanmically called vi is compiled and valid at runtime I also include a copy of in the main.vi.
To be extra sure I have also installed the runtime versions of VISA and DAQmx.
I have compiled it with and without the "Use LV 8 calling hiaracy"
My conclusion as this stage is that either the installation of LVRT 2011SP1 misses something the earlier LVRT installtions make.
or is there a MyApp.ini or LVRT .ini that controls how the RT dyanim calls are handled.
Help very welcome how to solve this puzzle.
thanks
michael

I understand that all the PCs (6 of them) have LV 2011 SP1, runtime or the development system installed. Right?
How many of these PCs have the source code available on them?
-> Only one of them has the source code.
I am not sure I understood 'I also include a copy of in the main.vi'. Does it mean you placed the subvi in the main.vi?
-> I meant I have included in main.vi the actual vi that is called dynamically - but only where it is not called.
Did you try including the sub vi which is called dynamically, as 'Always included' in the EXE build?
-> No, I did not know of this option - but the above I did this by default.
Edit: Did you verify the software versions of LV RT, VISA etc on all the PCs? Are they same?
-> I did verify even added DAQmx just in case
There is lots of material available on this forum for error 1003 and dynamic vi calling. Did you find anything useful to try among the forums threads?
-> I did view many of them.
I did finally find the answer.
I have a subvi (callNet.vi ) in the dynamically called vi (dynamic ) that calls .Net libraries.
Now the thing is that this subvi callNet.vi is coded out by enclosing it in a Disable structure.
In fact this subvi ( callNet.vi) does not even compile - ie it has a broken arrow
however if enclosed in a Disabled structure and disabled, the enclosing vi compiles OK.
However I have discovered that even with the .Net calling subvi (callNet.vi) in the Disabled state of the Disabled structure
the enclosing vi (dynamic.vi ) does NOT run - although it compiles just fine.
Once I installed the .Net libraries (I actually did include them with my app installer ) with the vender's supplied installer
then my app now successfully calls the dynamic vi.
So the Summary and warning is: Even if the dynamic called vi is included in Main.vi and Main.exe runs ( but does not call the dynamic vi - except when called dynamically at later some point ) and even if, in this case, the .Net calling subvi is disabled out ie no .Net calls are made the dynamically called vi will not run when called dynamically.
I hope that is not too confusing. In summary it seems the Disable structure does not entirely disable.
Michael

Error 1003 when building executable

Hi, I'm using Labview 2010 on Windows 7 and I'm getting an error when I try to build an executable:
Error 1003 occurred at Open VI Reference in AB_Engine_EXE_Call_Write_Icons.vi->AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK.vi->AB_Create_Build_Application.vi->EBUIP_Global_OnCommand.vi->EBUIP_Global_OnCommand.vi.ProxyCaller
Possible reason(s):
LabVIEW: The VI is not executable. Most likely the VI is broken or one of its subVIs cannot be located. Select File>>Open to open the VI and then verify that you are able to run it.
VI Path: C:\Program Files\National Instruments\LabVIEW 2010\vi.lib\Platform\icon.llb\Read Icons from ICO File.vi
This happens even when I try to build a simple vi, like a random number generator.

Same problem here. Error 1003 and error 8 I encoutered often.
For error 8 during build process, I needed to save the executable on a higher level in the file hierarchy.
For error 1003, I did not find a solution. Restarting LabView does not help. Sometimes (but not always) restarting the computer helps. Sometimes I need to reinstall the labview system.
More details: I have a first vi, starting the actual vi with a hidden front panel (second vi). This vi can also be started directly. Sometimes, the build process runs smoothly then when I include the second vi as main vi to start the program.
The program runs fine when the build process succeeds, and it runs fine in LabView.

Why does Build Application vi work in development environment but not in executable; error 1025

Hello,
I have an application ("A") that I am trying to build using another application ("BuildA").
I can create an application for A manually from its project using the Build Specification, and it works fine (A.exe).
Also, when I run BuildA.vi in the development environment it calls the "Build.vi" correctly and again builds application A.exe just fine.
Then, when I make BuildA an application (manually) and run BuildA.exe, I would expect it to also create A.exe just like BuildA.vi did in the development environment.
However, it fails with the error:
Code: 1025
Open VI Reference in NI_App_Builder_API.lvlib:Build (path).vi->BuildA.vi<APPEND>
VI Path: <b>C:\TEMP\AppBuild\BuildA\vi.lib\AppBuilder\BuildTarget.vi</b>
I noticed this thread , which looks like a similar problem, but no conclusion was reached.
Why does BuildA.vi work fine in the LabVIEW environment, but the application BuildA.exe does not work? All paths are hard-coded, so it shouldn't be a path issue.
Thanks,
-john
Solved!
Go to Solution.
Attachments:
AppBuild.zip ‏175 KB

Interesting code. I'm curious how you came to decide 324ms in your while loop, and 58 in the other, and then 5136ms at the end. In any case I suspect this has to do with this line of text in the help of the Build.vi.
If you plan to run a build specification on the LabVIEW Run-Time Engine, do not include the Build VI in any of the VIs for the build specification.
I don't fully know what this means but it might be why it isn't working.
The Build.vi opens all Context (application instances) and then looks for the one named "NI.LV.MxLvProvider". This I assume is a application instance NI uses to build applications. It then uses this and opens some other VIs in this instance for the building. The error you are getting is "Application Reference is invalid" meaning it couldn't find the NI.LV.MxLvProvider instance it needs to build. Again I believe this maybe because you are in a run-time environment and that instance doesn't exist there.
At the end of the day I'm guessing since Application Builder is not free, NI probably doesn't include it in the Run-Time engine, which is free. So you can't build the way you want. You could have and EXE running in the run-time open an instance in the development, then run your VI from there if you must make this an EXE. It maybe easier to just edit the BuildA.vi to have a "Run When Opened" so that you double click the VI and it runs which behaves like an EXE sorta.
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

Why a VI has a broken arrow when I open it when labview is open but becomes executable when it is opened by double clicking

I have a VI with some subVIs from a dynamic link library. When I open the VI using "open" or "open VI" in labVIEW, the VI is broken. In the error list,it saids one or all the subVIs from the dynamic link library are not executable. However, if I exit labview and open the same VI by double clicking it, it becomes executable without any change being made. Sometimes I can fix the broken arrow by configuring the "call library function node" in the subVI and saving it. But when I open the VI again, the same problem and error message appear. I am using labVIEW 6.1 for the top level VI and those subVIs from the dynamic link library could be developed in a different version of labVIEW. Is this the cause of the problem? Another possible reason I can think of is that somebody installed another application developed in labVIEW on the same computer. Is it possible that some settings were modified during the installation that cause this problem to occur? I am suspecting this because I first notice this problem after the installation of the other application.

Since the problem started ocurring after installing another application, I would suspect something with that last installation. Without knowing more about the installations, I would not be able to help much. Did the other installation perhaps install another DLL of the same name? Try uninstalling the last app to see if the problem goes away.
- tbob
Inventor of the WORM Global

Dynamic calls from executable

Hi all,
I used to have LabVIEW application, as executable, which does dynamic calls to any VI. Until now it was done and built with LV2009 and worked fine as long as the vi.lib folder was copied to same of folder than the executable (this was needed for dependencies).
I've now moved to LV2012 and my application does not work anymore. It seems that dynamically loading any VI in vi.lib which calls an LLB is not possible and leads to an error. Is this known ? Is it a bug or a new limitation in LV2012 ?
Thanks,
Alex

Here is how to reproduce this issue :
First, open the attached GetVIDependencies.vi in the LV2012 development environment. In the "VI Patch" field, enter the path of the attached "Test.vi" and then execute the VI.
You should get 38 found dependencies and 0 missing. Then do the same with the exe version of GetVIDependencies. You should get 1 dependency which is missing. This is normal because the runtime does not know where <vilib> is placed. If you place the exe in the LabVIEW.exe directory (where vilib stands), you will get the same result.
Then, if you have LV2009, try the same with the 2009 executable version and "Test_LV2009.vi". It will work as soon as you place the executable in the LabVIEW.exe (2009) folder, no matter where "Test_LV2009.vi" is placed.
Attachments:
GetVIDependencies.vi ‏24 KB
Test.vi ‏7 KB
GetVIDependencies_LV2009.vi ‏23 KB

Dynamic call for a ref cursor: ORA-21779

Hi,
Here is an environment:
create or replace
PACKAGE PKG_GETDATA AS
TYPE cursor_type IS REF CURSOR;
Procedure SimpleGet (cData In Out Cursor_type);
Procedure DynamicGet (cData In Out Cursor_type);
END PKG_GETDATA;
create or replace
PACKAGE BODY "PKG_GETDATA" AS
Procedure SimpleGet (cData In Out Cursor_type) As
Begin
Open cData For
Select 1 from Dual;
End SimpleGet;
Procedure DynamicGet (cData In Out Cursor_type) As
Begin
Execute Immediate 'Begin PKG_GETDATA.SIMPLEGET(:1); End;'
Using In Out cData;
End DynamicGet;
END PKG_GETDATA;
So- first simple get works fine:
Declare
cData PKG_GETDATA.Cursor_type;
aNumber Number;
Begin
PKG_GETDATA.SimpleGet (cData);
LOOP
FETCH cData INTO aNumber;
EXIT WHEN cData%ROWCOUNT > 5 OR cData%NOTFOUND;
dbms_output.put_line (aNumber);
END LOOP;
close cData;
End;
BUT dynamic call does not works at all!:
Declare
cData PKG_GETDATA.Cursor_type;
aNumber Number;
Begin
PKG_GETDATA.DynamicGet (cData);
LOOP
FETCH cData INTO aNumber;
EXIT WHEN cData%ROWCOUNT > 5 OR cData%NOTFOUND;
dbms_output.put_line (aNumber);
END LOOP;
close cData;
End;
It throws ORA-21779 exception; what is more- it does work on 10.2 db version but does not work on 11.2 version! Could anyone explain that?
Regards
Bartlomiej D.

Hi,
Believe me, it may be very handful while working with handlers.
Anyway- could anyone help me on that?
Regards
Bartlomiej D.

Dynamic call of a vi with a reference stored in a global variable

Hello,
I am trying to program a VI which calls DAQmx functions in some cases, in other cases DAQmx may not even be installed. To prevent a broken arrow on machines where DAQmx is not installed, I want to use a sub-VI containing the DAQmx function calls which is called dynamically by a main VI. For speed I want to prevent continuous opening and closing the VI reference, so I want to store the reference to the sub VI in a global variable. In this variable I also want to store the Analog Input Task. I want to use an initialization VI to write the VI reference of the sub VI and to configure and start the Analog Input Task and write the Task ID to that Global, too. In that way I was hoping to be able to improve the performance of the dynamic calls and the Task calls. BUT - when I write the refererence and task to the Global and read it out from another VI, the reference is not valid anymore and the Analog Input task is also not valid, even if both the initialization VI and the Global are still open (but not running). Does somebody have an idea how to solve that? It is a bit difficult to describe, so here is what I want to do in a shorter description :
- run a initialization VI which
defines a reference to a sub VI which will be called dynamically later on
and a AI task ID definining a DAQmx physical channel configuration to use for subsequent read cycles
and writes both (VI reference and AI task) to a global variable
- run another VI which
reads the VI reference of the VI to call dynamically from that global
runs the corresponding VI dynamically
the dynamically called VI performs an AI task corresponding to the DAQmx task ID read from that global (it reads an analog value for instance from the
physical channel configured by that AI task)
Why all that? To prevent creating and destroying the VI reference for each call of the sub VI for speed. And to use the configured DAQmx channel for subsequent read tasks only if the subVI is called dynamically - if it is not, then the application will not see the DAQmx calls and therefore no broken arrow will occur if no DAQmx is installed on the machine.
Can somebody help me with this? Why can't I store and read out the reference to the sub VI to/from a global, and why is the AI task not valid when read out from the dynamically called sub VI? I am somewhat lost with all that...
Thanks in advance,
Gabs

Uh - I am almost getting crazy with that
Kevin, that solution is the right one for programming an application. In that case everything will work fine. But during testing, it is more convenient to call all VIs from their front panels one after another. That's how I'm doing it for everything that needs to be exchanged between such VIs: store them either in a global or in a functional global variable. In that way the user can "play around" with the VIs without wiring them together in a main VI. Therefore, after some thinking I liked Davids idea with that daemon VI (I solved that by adding a boolean in the initialization VI to choose if that daemon is necessary - during testing phase - or not - when using the VIs in a main application). BUT:
David: It does not work!!! I have exactly done what you proposed and this daemon VI is really running, having a True/False frame with a constant of False wired to the selector and holding both the functional global and the dynamically to call VI in the True frame. In that way, after initialization is finished, both VIs are still running but idle. Anyway, when I read back the value of the reference or the DAQmx task, it is invalid again!
That really costs just too much time. Does anybody have any idea what to do now? David, I was hoping that your suggestion would solve the problem, because it would be logical that it would - why then is LabVIEW destroying the reference and task anyway even if that daemon VI containing the functional global is still running???
Regards,
Gabs

Dynamic Call to VIT that is a member of a LabVIEW Library (LVLIB)

Application is too complicated to post, so I will describe this in basic terms ..
Consider these VIs as members of an lvlib.
   Template.VIT
   Template Launcher.vi
   func1.vi
'Template.VIT' and 'Template Launcher.vi' are public members of the lvlib.
'func1' is a private member of the lvlib.
'func1.vi' is a subVI on the block diagram of 'Template.VIT '
'Template Launcher.vi' calls 'Template.VIT' dynamically. It gets a path to the VIT, uses that to Open a reference, then runs it with the 'Run VI' method.
Whenever you launch a VIT this way, it creates a new named instance (because it is a template) by appending a number to the VIT name. In this instance, let's call it 'Template 2.VIT'.
Here is the Problem: 'Template 2.VIT' is not executable because it does not have access to the private member of the llvlib, so it cannot call 'func1.vi' from the block diagram. It seems that the instance 'Template 2.VIT' is not a member of the lvlib. Block Diagram error reads...
"SubVI is private and cannot be accessed from this VI."
My question: Is there any way to make the new instance a member of the lv library?
I don't need a workaround, I need to know if this is possible. Perhaps a particualr switch when Open VI Reference is called, or a particualr property that can be changed?
Message Edited by ADAC on 01-16-2007 11:14 AM

Hi ADAC,
The short answer is no, you cannot do this. If you set the "Open VI Reference" option to 2, you can open the template itself and this will not have this problem. But if you need to create new instances of the template this will not work for you. You may be able to "work around" this (even though work around is a dirty word). It might be possible to programatically make a copy of this VI on disk and then programatically edit the lvlib file such that your new file is a member of the library. I haven't tried this myself so I'm not positive this would work but it might.
I hope this helps,
Justin D
Applications Engineer
National Instruments

DCs becomes broken. How to repair it?

Hello SDN! I strongly need your help.
Well, it was necessary to change track parameters (just change DTR and CBS server from name to IP).
After that I faced with disappearing of my dev workspace. In SDN i've found that I have to reimport SCs for development and consolidation systems. Reimport has been done and projects for DCs has been imported in NWDS. After that it was successfully building and deploying on the remote test server. Next I was change settings of development runtime system to other server and after changing I've got a build error:
"       Analyze request DC BV... started at 2008-06-19 11:28:25.150 GMT
                'sap.com/crm/isa/web/b2b' variant 'default'
                'sap.com/crm/isa/web/b2b' variant 'default' cannot be built. ACTIVATION will fail.
                INVALID dependency is declared
                DC 'sap.com/crm/isa/web/b2b' in SC 'sap.com_SAP-SHRWEB_1' USES Non-existing DC 'sap.com/crm/tc/core' [public-part: assembly] AS Build-Time Dependency [validity: USED COMPONENT OR PUBLIC PART IS UNKNOWN OR UNDEFINED]
But local build was ok.
Well, I tried to resolve this error with "Sync used DCs", "Sync sources", "Initialize" for every SC in CBS. After that all my DCs become broken. Next I tried to reimport 3 standart components, restart NWDS (after restarting NWDS asked me for update configuration and delete current local content) and recreate projects for needed DCs.
Now in CONS DC has state OK, in DEV not every but many DCs still broken. And I can't find required DC 'sap.com/crm/tc/core' neither in DEV nor in CONS.
What I should to do for repairing my track?
Please don't ignore my question...
regards, Lev

Hi Lev,
"through this serach you can find under which SC this DC is present and then check if you have imported the archives of this SC" What do you mean? Imported to whcih?
I mean --> DCs are contained inside SCs. So if you find under which SC this DC is present then you can check in CBS if the SC displays DC counts (SC will show the number of DCs in CBS when the sources are imported). If the respective SC shows 0 DCs then you have to manually check in the archives of that SC and fill it. If not the SC would be displayed empty in the CBS.
"try filling the SCs with the sources"
How I can fill SCs?
--> I meant chekin and import of the SC here. After this the SC should show the total number of DCs. and then DC would be recognized and CBS will not throw the error "unknown component"
The above case is true w.r.t required SC. If it is a developed SC then initializing the required compartment should help.
Akshatha

Dynamically called VI becomes broken inside an executable. Error 1003 from "Open VI Reference".

Similar Messages

Maybe you are looking for