Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Error 1003 when dynamically launching VIs
Benjam
Member
04-22-2005 03:15 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Dear LabVIEW fellows,
we are facing the following issue:
* we created a main VI to treat general tasks, e.g. communication, tracking status information ...
* specific tasks like accessing equipment, performing measurements and the like need further input
* this is meant to be served by users creating their own specialized SubVIs
* users are to place their SubVIs at an appropriate location (on an FP station, see below) writing the path to the SubVIs into a given text file
* main VI is to read those paths from the text file and launch the SubVIs according given strategies (via VI server technology)
* so far everything is doing just fine ... as long as we are launching main VI from within LabVIEW
* now main VI as well as SubVIs are meant to run on an FP 2000 station
* main VI necessarilly needs to be launched automatically when the FP station starts
* therefor a 'startup.exe' must be created out of the main VI and placed on the FP station using Application Builder
* when trying to create an exe-file from the main VI Application Builder reports error 1003
As far as i found out (from NI homepage) its Application Builder won't build any application (.exe, FP station or PC) if not all SubVIs that are to be launched within the application are present at the time of creating the application.
But this is about to kick our plan ... which essentially is to subsequently include SubVIs in a given program flow while name or number of those SubVIs need not be initially defined.
Can anyone give a hint? Thanks in advance.
Ben
we are facing the following issue:
* we created a main VI to treat general tasks, e.g. communication, tracking status information ...
* specific tasks like accessing equipment, performing measurements and the like need further input
* this is meant to be served by users creating their own specialized SubVIs
* users are to place their SubVIs at an appropriate location (on an FP station, see below) writing the path to the SubVIs into a given text file
* main VI is to read those paths from the text file and launch the SubVIs according given strategies (via VI server technology)
* so far everything is doing just fine ... as long as we are launching main VI from within LabVIEW
* now main VI as well as SubVIs are meant to run on an FP 2000 station
* main VI necessarilly needs to be launched automatically when the FP station starts
* therefor a 'startup.exe' must be created out of the main VI and placed on the FP station using Application Builder
* when trying to create an exe-file from the main VI Application Builder reports error 1003
As far as i found out (from NI homepage) its Application Builder won't build any application (.exe, FP station or PC) if not all SubVIs that are to be launched within the application are present at the time of creating the application.
But this is about to kick our plan ... which essentially is to subsequently include SubVIs in a given program flow while name or number of those SubVIs need not be initially defined.
Can anyone give a hint? Thanks in advance.
Ben
04-23-2005 12:53 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Here some thoughts i had meanwhile. Feel free to comment, revise, specify ...
1) Running a VI within LabVIEW allways includes the VI being compiled by LabVIEW before being started.
2) An application, say main.exe created out of main.vi with application builder, runs on base of the runtime engine the functionality of which is different from LabVIEW's.
3) One of the capabilities missing to the runtime engine is compiling VIs.
4) For 3) main.exe cannot run VIs.
5) For 3) all VIs that are to be run within the execution of main.exe must be indicated to application builder when creating main.exe out of main.vi, e.g. on application builder's 'called sub VIs' tab. It's then application builder that compiles the VIs allowing runtime engine to run them.
Possible strategies for running code by main.exe that is not present when main.exe is created:
6) Provide code to be performed by main.exe in a way that does not require VIs to be compiled. This might be:
6.1) *.dll, since LabVIEW is able call dlls (and build dlls out of VIs) and it is actually the operating system Windows to process them ... right?
6.2) *.exe, since LabVIEW is able to launch executables via some kind of operating system call ... isn't it?
6.3) ... ?
7) Design main.exe to launch LabVIEW which on its part runs the VIs compiling them beforhand.
If so, there still remain some obscurities to me ... In our case main.exe is to run on a FieldPoint 2000 station, the sub VIs too (without much doubt).
😎 Can i call dlls when main.exe is running on the FieldPoint station? Whether the dlls reside on the FieldPiont station as well or on a PC on the lan?
9) Can i perform 'operating system calls' to launch an other executable on the FieldPoint station? Doesn't LabVIEW RT play the role of an operating system here?
10) Won't i use 'Open VI Reference' and 'Invoke Node' methods after launching LabVIEW to run the sub VIs. With these methods on the block diagramm application builder refused to build main.exe out of main.vi (error 1003, or has this error been reported after starting main.exe ...).
11) Launching LabVIEW to run VIs should work regardless of LabVIEW already running or not ... will it?
Ben
1) Running a VI within LabVIEW allways includes the VI being compiled by LabVIEW before being started.
2) An application, say main.exe created out of main.vi with application builder, runs on base of the runtime engine the functionality of which is different from LabVIEW's.
3) One of the capabilities missing to the runtime engine is compiling VIs.
4) For 3) main.exe cannot run VIs.
5) For 3) all VIs that are to be run within the execution of main.exe must be indicated to application builder when creating main.exe out of main.vi, e.g. on application builder's 'called sub VIs' tab. It's then application builder that compiles the VIs allowing runtime engine to run them.
Possible strategies for running code by main.exe that is not present when main.exe is created:
6) Provide code to be performed by main.exe in a way that does not require VIs to be compiled. This might be:
6.1) *.dll, since LabVIEW is able call dlls (and build dlls out of VIs) and it is actually the operating system Windows to process them ... right?
6.2) *.exe, since LabVIEW is able to launch executables via some kind of operating system call ... isn't it?
6.3) ... ?
7) Design main.exe to launch LabVIEW which on its part runs the VIs compiling them beforhand.
If so, there still remain some obscurities to me ... In our case main.exe is to run on a FieldPoint 2000 station, the sub VIs too (without much doubt).
😎 Can i call dlls when main.exe is running on the FieldPoint station? Whether the dlls reside on the FieldPiont station as well or on a PC on the lan?
9) Can i perform 'operating system calls' to launch an other executable on the FieldPoint station? Doesn't LabVIEW RT play the role of an operating system here?
10) Won't i use 'Open VI Reference' and 'Invoke Node' methods after launching LabVIEW to run the sub VIs. With these methods on the block diagramm application builder refused to build main.exe out of main.vi (error 1003, or has this error been reported after starting main.exe ...).
11) Launching LabVIEW to run VIs should work regardless of LabVIEW already running or not ... will it?
Ben
Ben
Knight of NI
04-24-2005 10:17 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Part one of two.
Hi Ben,
My replies are mixed in below and are my "off the top of my head" responses. If some of them are wrong hopefully others will step in a correct me. I do not have any FP hardware handy to verify thes responses.
You wrote
"
we are facing the following issue:
* we created a main VI to treat general tasks, e.g. communication, tracking status information ...
* specific tasks like accessing equipment, performing measurements and the like need further input
* this is meant to be served by users creating their own specialized SubVIs
* users are to place their SubVIs at an appropriate location (on an FP station, see below) writing the path to the SubVIs into a given text file
* main VI is to read those paths from the text file and launch the SubVIs according given strategies (via VI server technology)
* so far everything is doing just fine ... as long as we are launching main VI from within LabVIEW
"
When you say "everything is doing just fine ..." I understand you to mean everything is fine as long as you are running under a Windows devlopement environment.
You go on to say;
"
* now main VI as well as SubVIs are meant to run on an FP 2000 station
"
Alarms start going off when you say FP2000, for a number of reasons.
1) As you have discovered, there is no compiler on a FP2000 or any other RT target (possible exception is RTX running concurrently on same platform, but that is splitting hairs). This means everything must be in a compiled form the appropriate RT OS can handle.
2) FP2000's have limited memory! Attempting to load a VI in a FP2000 (or other platform) that requires more memory than the FP2000 has will crash it, requiring a complete restart of the node.
3) RT-OS do not play the memory game like other OS's. If they did, they would not be RT. Be careful here, not to design an applications who's memory foot print changes. This is not a show stpopped for you, just an FYI.
You continue,
"
* main VI necessarilly needs to be launched automatically when the FP station starts
* therefor a 'startup.exe' must be created out of the main VI and placed on the FP station using Application Builder
"
YES sir!
Then you say
"
* when trying to create an exe-file from the main VI Application Builder reports error 1003
"
Error code 1003 = "The VI is not executable." If you just copied a VI that was saved under Windows, this makes sense.
WARNING! memory will now be invoked, check for errors!
If you traget the FP2000 and open a VI that is on the FP2000 and save it, it should be saved in an appropriate form for use by that FP2000. If your main dynamically locates the VI and opens it from that location, AND the "main" was saved using a compatible version of LV (i.e. LV7.0 can open LV6.1 provided shared sub-VI have not been changed such that they need re-linking) The sub VI should run.
You continue,
"
As far as i found out (from NI homepage) its Application Builder won't build any application (.exe, FP station or PC) if not all SubVIs that are to be launched within the application are present at the time of creating the application.
"
Yes, all sub-VI's EXPLICITLY (i.e. the icon appers in the diagram) called by a VI are required to compile the VI (i.e. no broken run arrow). VI's can be called dynamically as you are attempting.
Then you say
"
But this is about to kick our plan ... which essentially is to subsequently include SubVIs in a given program flow while name or number of those SubVIs need not be initially defined.
"
What is going to complcate your like is ensuring the dynamically called VI are compiled for correct target. I know of no way to get LV to build a exe for a specific target without having that target available at build time. Once built the exe could be copied around to the nodes that need them, provided the LV versions are compat.....
Then the is the issue of mixing and matching your plug-ins such that more than one memory hog will run independently but not together.
Continued in part two
Hi Ben,
My replies are mixed in below and are my "off the top of my head" responses. If some of them are wrong hopefully others will step in a correct me. I do not have any FP hardware handy to verify thes responses.
You wrote
"
we are facing the following issue:
* we created a main VI to treat general tasks, e.g. communication, tracking status information ...
* specific tasks like accessing equipment, performing measurements and the like need further input
* this is meant to be served by users creating their own specialized SubVIs
* users are to place their SubVIs at an appropriate location (on an FP station, see below) writing the path to the SubVIs into a given text file
* main VI is to read those paths from the text file and launch the SubVIs according given strategies (via VI server technology)
* so far everything is doing just fine ... as long as we are launching main VI from within LabVIEW
"
When you say "everything is doing just fine ..." I understand you to mean everything is fine as long as you are running under a Windows devlopement environment.
You go on to say;
"
* now main VI as well as SubVIs are meant to run on an FP 2000 station
"
Alarms start going off when you say FP2000, for a number of reasons.
1) As you have discovered, there is no compiler on a FP2000 or any other RT target (possible exception is RTX running concurrently on same platform, but that is splitting hairs). This means everything must be in a compiled form the appropriate RT OS can handle.
2) FP2000's have limited memory! Attempting to load a VI in a FP2000 (or other platform) that requires more memory than the FP2000 has will crash it, requiring a complete restart of the node.
3) RT-OS do not play the memory game like other OS's. If they did, they would not be RT. Be careful here, not to design an applications who's memory foot print changes. This is not a show stpopped for you, just an FYI.
You continue,
"
* main VI necessarilly needs to be launched automatically when the FP station starts
* therefor a 'startup.exe' must be created out of the main VI and placed on the FP station using Application Builder
"
YES sir!
Then you say
"
* when trying to create an exe-file from the main VI Application Builder reports error 1003
"
Error code 1003 = "The VI is not executable." If you just copied a VI that was saved under Windows, this makes sense.
WARNING! memory will now be invoked, check for errors!
If you traget the FP2000 and open a VI that is on the FP2000 and save it, it should be saved in an appropriate form for use by that FP2000. If your main dynamically locates the VI and opens it from that location, AND the "main" was saved using a compatible version of LV (i.e. LV7.0 can open LV6.1 provided shared sub-VI have not been changed such that they need re-linking) The sub VI should run.
You continue,
"
As far as i found out (from NI homepage) its Application Builder won't build any application (.exe, FP station or PC) if not all SubVIs that are to be launched within the application are present at the time of creating the application.
"
Yes, all sub-VI's EXPLICITLY (i.e. the icon appers in the diagram) called by a VI are required to compile the VI (i.e. no broken run arrow). VI's can be called dynamically as you are attempting.
Then you say
"
But this is about to kick our plan ... which essentially is to subsequently include SubVIs in a given program flow while name or number of those SubVIs need not be initially defined.
"
What is going to complcate your like is ensuring the dynamically called VI are compiled for correct target. I know of no way to get LV to build a exe for a specific target without having that target available at build time. Once built the exe could be copied around to the nodes that need them, provided the LV versions are compat.....
Then the is the issue of mixing and matching your plug-ins such that more than one memory hog will run independently but not together.
Continued in part two
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Ben
Knight of NI
04-24-2005 10:18 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
part two fo two
Now to your thoughts!
"
1) Running a VI within LabVIEW allways includes the VI being compiled by LabVIEW before being started.
"
A VI must be compiled to run but if recompiling is not required, it will not by defauly be compiled. I have built applications that call other built applications. No compiling is possible in built apps.
"
2) An application, say main.exe created out of main.vi with application builder, runs on base of the runtime engine the functionality of which is different from LabVIEW's.
"
Yes, different in that it is a sub-set of LV. The File functions etc. are the same. The run-time engines also run in a seperate memory space (?) so there are complications when trying to share memory elements.
"
3) One of the capabilities missing to the runtime engine is compiling VIs.
"
YES, the editing compiling linking stuff is all what you get with the license to LV.
"
4) For 3) main.exe cannot run VIs.
"
Executables can run VI's provided they are compat....
"
5) For 3) all VIs that are to be run within the execution of main.exe must be indicated to application builder when creating main.exe out of main.vi, e.g. on application builder's 'called sub VIs' tab. It's then application builder that compiles the VIs allowing runtime engine to run them.
"
I would say that this is just about correct, with one exception. If you have a sub-VI "sub1" that is called by two exe's "Exe1" and "Exe2" then sub1 will get included in both builds. If Exe1 is started, it will load its version of sub1 when it starts. If Exe1 then dynamically loads Exe2, then the sub1 loaded by Exe1 will be used by Exe2 and its version will not be used.
You then continue
"
Possible strategies for running code by main.exe that is not present when main.exe is created:
6) Provide code to be performed by main.exe in a way that does not require VIs to be compiled. This might be:
6.1) *.dll, since LabVIEW is able call dlls (and build dlls out of VIs) and it is actually the operating system Windows to process them ... right?
"
I can not help you much with the dll stuff.
"
6.2) *.exe, since LabVIEW is able to launch executables via some kind of operating system call ... isn't it?
"
Yes, build an executable that finds and shows its path. You will see that VI's have a path that is inside of the exe.
"
6.3) ... ?
7) Design main.exe to launch LabVIEW which on its part runs the VIs compiling them beforhand.
"
That's the ticket!
"
If so, there still remain some obscurities to me ... In our case main.exe is to run on a FieldPoint 2000 station, the sub VIs too (without much doubt).
😎 Can i call dlls when main.exe is running on the FieldPoint station? Whether the dlls reside on the FieldPiont station as well or on a PC on the lan?
"
SUre, if they are compatable and the network drives are accesable...
"
9) Can i perform 'operating system calls' to launch an other executable on the FieldPoint station? Doesn't LabVIEW RT play the role of an operating system here?
"
The OS is still unique. Never tried to do any FP OS stuff.
"
10) Won't i use 'Open VI Reference' and 'Invoke Node' methods after launching LabVIEW to run the sub VIs. With these methods on the block diagramm application builder refused to build main.exe out of main.vi (error 1003, or has this error been reported after starting main.exe ...).
11) Launching LabVIEW to run VIs should work regardless of LabVIEW already running or not ... will it?
"
I already addressed your #10. As to # 11 LV is smart. It knows what it needs.
I hope thes replies help. I think your biggest issue is going to be memory once you get his working.
Please keep us posted on your final solution.
Ben
Now to your thoughts!
"
1) Running a VI within LabVIEW allways includes the VI being compiled by LabVIEW before being started.
"
A VI must be compiled to run but if recompiling is not required, it will not by defauly be compiled. I have built applications that call other built applications. No compiling is possible in built apps.
"
2) An application, say main.exe created out of main.vi with application builder, runs on base of the runtime engine the functionality of which is different from LabVIEW's.
"
Yes, different in that it is a sub-set of LV. The File functions etc. are the same. The run-time engines also run in a seperate memory space (?) so there are complications when trying to share memory elements.
"
3) One of the capabilities missing to the runtime engine is compiling VIs.
"
YES, the editing compiling linking stuff is all what you get with the license to LV.
"
4) For 3) main.exe cannot run VIs.
"
Executables can run VI's provided they are compat....
"
5) For 3) all VIs that are to be run within the execution of main.exe must be indicated to application builder when creating main.exe out of main.vi, e.g. on application builder's 'called sub VIs' tab. It's then application builder that compiles the VIs allowing runtime engine to run them.
"
I would say that this is just about correct, with one exception. If you have a sub-VI "sub1" that is called by two exe's "Exe1" and "Exe2" then sub1 will get included in both builds. If Exe1 is started, it will load its version of sub1 when it starts. If Exe1 then dynamically loads Exe2, then the sub1 loaded by Exe1 will be used by Exe2 and its version will not be used.
You then continue
"
Possible strategies for running code by main.exe that is not present when main.exe is created:
6) Provide code to be performed by main.exe in a way that does not require VIs to be compiled. This might be:
6.1) *.dll, since LabVIEW is able call dlls (and build dlls out of VIs) and it is actually the operating system Windows to process them ... right?
"
I can not help you much with the dll stuff.
"
6.2) *.exe, since LabVIEW is able to launch executables via some kind of operating system call ... isn't it?
"
Yes, build an executable that finds and shows its path. You will see that VI's have a path that is inside of the exe.
"
6.3) ... ?
7) Design main.exe to launch LabVIEW which on its part runs the VIs compiling them beforhand.
"
That's the ticket!
"
If so, there still remain some obscurities to me ... In our case main.exe is to run on a FieldPoint 2000 station, the sub VIs too (without much doubt).
😎 Can i call dlls when main.exe is running on the FieldPoint station? Whether the dlls reside on the FieldPiont station as well or on a PC on the lan?
"
SUre, if they are compatable and the network drives are accesable...
"
9) Can i perform 'operating system calls' to launch an other executable on the FieldPoint station? Doesn't LabVIEW RT play the role of an operating system here?
"
The OS is still unique. Never tried to do any FP OS stuff.
"
10) Won't i use 'Open VI Reference' and 'Invoke Node' methods after launching LabVIEW to run the sub VIs. With these methods on the block diagramm application builder refused to build main.exe out of main.vi (error 1003, or has this error been reported after starting main.exe ...).
11) Launching LabVIEW to run VIs should work regardless of LabVIEW already running or not ... will it?
"
I already addressed your #10. As to # 11 LV is smart. It knows what it needs.
I hope thes replies help. I think your biggest issue is going to be memory once you get his working.
Please keep us posted on your final solution.
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Aaron_G
Active Participant
04-24-2005 11:16 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Benjamin,
Since Ben already answered a bunch of your questions point by point, I am going to ignore your specific questions and instead talk about the problem in more general terms.
I have written VIs and turned them into executables for FieldPoint targets that launch external VIs that were also downloaded to the FieldPoint target. It is very feasible to do. The key issue, that causes the -1003 error, is that LabVIEW on your host computer is a development system and the LabVIEW in the FieldPoint controller is a run-time version. So the questions become:
1) What behavior is different between the two?
2) How do I program my code to account for the behavior difference?
3) What other things do I need to be aware of for #2?
The answers:
1) The primary behavior difference in this instance is that a run-time engine can not re-link VIs. If the dynamically launched VI has any sub-VIs, it needs to know where to find them. The run-time engine can not search for VIs (including vi.lib VIs) because they are not resident in the FieldPoint controller, and searching/relinking is a Development Environment capability, not a run-time capability.
2) Instead of simply downloading the dynamically launched VIs into the FieldPoint controller by themselves, you need to download a fully executable version of the VI. Open the dynamically launched VI (in the development environment) and choose File>>Save With Options>>Application Distribution. This will create an LLB file with the dynamic VI and ALL of it's subVIs (including vi.lib VIs). FTP the resultant LLB into the FieldPoint controller. You will now be able to launch the dynamic VI from your main program.
3A) LLBs will contain all subVIs, but LabVIEW only allows 1 VI per name into memory. This means that you may have multiple copies of VIs in different LLBs (the startup.exe and dynamic LLBs) on disk, but the first one to load (usually the one in startup.exe) is the one in memory. If you change one of the dynamic VIs subVIs that is also called by the main VI, the new dynamic VI will not work since it will be using the older version of the subVI.
3B) Due to the multiple copies of subVIs, the required flash drive will be larger.
3C) Because the VI will be in an LLB, you will need to adjust the file path used to dynamically launch the VI to include the LLB.
Regards,
Aaron
Since Ben already answered a bunch of your questions point by point, I am going to ignore your specific questions and instead talk about the problem in more general terms.
I have written VIs and turned them into executables for FieldPoint targets that launch external VIs that were also downloaded to the FieldPoint target. It is very feasible to do. The key issue, that causes the -1003 error, is that LabVIEW on your host computer is a development system and the LabVIEW in the FieldPoint controller is a run-time version. So the questions become:
1) What behavior is different between the two?
2) How do I program my code to account for the behavior difference?
3) What other things do I need to be aware of for #2?
The answers:
1) The primary behavior difference in this instance is that a run-time engine can not re-link VIs. If the dynamically launched VI has any sub-VIs, it needs to know where to find them. The run-time engine can not search for VIs (including vi.lib VIs) because they are not resident in the FieldPoint controller, and searching/relinking is a Development Environment capability, not a run-time capability.
2) Instead of simply downloading the dynamically launched VIs into the FieldPoint controller by themselves, you need to download a fully executable version of the VI. Open the dynamically launched VI (in the development environment) and choose File>>Save With Options>>Application Distribution. This will create an LLB file with the dynamic VI and ALL of it's subVIs (including vi.lib VIs). FTP the resultant LLB into the FieldPoint controller. You will now be able to launch the dynamic VI from your main program.
3A) LLBs will contain all subVIs, but LabVIEW only allows 1 VI per name into memory. This means that you may have multiple copies of VIs in different LLBs (the startup.exe and dynamic LLBs) on disk, but the first one to load (usually the one in startup.exe) is the one in memory. If you change one of the dynamic VIs subVIs that is also called by the main VI, the new dynamic VI will not work since it will be using the older version of the subVI.
3B) Due to the multiple copies of subVIs, the required flash drive will be larger.
3C) Because the VI will be in an LLB, you will need to adjust the file path used to dynamically launch the VI to include the LLB.
Regards,
Aaron
04-28-2005 02:05 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Thanks very much for your input. I'll look through and do some more tests. This will take a little time since i am currently quiete occupied.
But i'll be back ... Thanks
Benjam
But i'll be back ... Thanks
Benjam
crelf
Trusted Enthusiast
05-04-2006 07:06 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi Guys,
This topic is being dicussed over on LAVA at the moment (well, I think it's interesting 
). I'd sure appreciate your wisdom if you have any insights about the issues that I'm having - that goes for you NI lot as well!
). I'd sure appreciate your wisdom if you have any insights about the issues that I'm having - that goes for you NI lot as well!Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
