01-28-2021 09:52 AM
Hi All,
I've been working on a project in work and when building the executable one of the dynamically loaded VIs throws up error 1003 (Note there are 2 Dynamically loaded VIs).
The 2nd dynamically loaded VI works fine. I've gone through many threads that have been posted previously and none of the solutions seem to work for me.
When attempting to run the executable the Sub-VI in question appears with a broken arrow (message shown in attached image). I am wondering if it is a deeper issue relating to the Write to XML File(array).vi? If so, is this something I will need to contact NI about?
Unfortunately, as this is a work based project, I am unable to upload a snippet of the code and haven't yet had chance to duplicate the issue in a dummy code format.
Also, this is my first post so if I have missed any details that are required, let me know and I will do my best to get them.
Solved! Go to Solution.
01-28-2021 11:22 AM
Are you including static references to these dynamically loaded VIs anywhere? Doing so will make sure that when you do a build the VI is included in your EXE.
Are you making sure that the VI path is correct in your EXE? Most methods that can be used to locate a VI on disk fail when trying to load a VI compiled into an EXE.
Does the VI with the broken arrow possibly have dependencies that didn't get included? For instance, a DLL might be missing or in the wrong relative path now.
01-29-2021 02:50 AM
Thanks for your reply Kyle,
I've attempted 2 methods to dynamically call the VIs (images attached) one of which uses a strictly typed VI reference. The result is the same no matter which method is used.
Regarding the paths, this was my initial thought for what the problem may be but having extensively debugged, I can confirm that the Paths written to the dynamic calls are correct. When initialising the paths for the 2 sub VIs, the code that strips and builds the path is identical. This is why I am confused that one Sub VI works and the other doesn't.
This is also what leads me to believe that the 'Write to XML File(array).vi' is the issue as per the image attached to the original post. I think also answers your last point as the Sub-VI in question does have a broken arrow.
Note: The case structure was included when debugging to see if either method worked better than the other. It is not going to be included in the final version.
01-29-2021 03:05 AM - edited 01-29-2021 03:07 AM
LabVIEW has no way to know at compile time that you want to call that VI. So it can not track that dependency. Accordingly the dependency can not be automatically included during build.
Your method two is only using a strictly typed refnum. That tells LabVIEW the connector pane of the VI but not which VI to load (That is determined by the path you pass to the Open VI Reference node).
There is another node which is called a Static VI Reference. It looks similar to the Strict Typedef Reference but really loads the specified VI into memory. If you use that then the VI will be automatically in memory and the Open VI Reference will succeed (but unless you use special flags for Open VI Reference such as Call and Forget or similar for use with the Asynchronous Call Node, you could also simply use the reference from the Static VI Reference without needing an Open VI Reference.
Another approach is to add your dynamically called VI as an always included VI to the Application Build. But that can be cumbersome since the path will change when the VI is included in your application build (but that problem can also arise if you use a Static VI Reference). Which is why I prefer to just use that reference directly without Open VI Reference when it is possible. And if you need to use Open VI Reference with the Static Reference, you can simply connect the VI name only to the Open VI Reference node. Since the Static Reference already loaded the VI into memory, the fully qualified VI name is enough to open a reference to it.
01-29-2021 05:30 AM
Thanks for clarifying that. I haven't had any experience with using the static VI reference but have now implemented that and it works.
Thanks all for helping me with this.