LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dynamic call VIs biuld

Hello,

 

I have application that calls some functions dynamicly. In development code runs fine as expected. After build I got error 1003 saying that dynamic call vi is broken.

This vi is  added to always include (option to remove FP and BD is also disabled) before build. This vi also has other subvis and typedefs inside that are not included in main build, but since top level vi is added to include compiler should know about them?

I have made 1 vi that includes all dynamic vi's and all subvis that they use and made it to always include. Results are the same.

 

 

What else can be done?

0 Kudos
Message 1 of 12
(2,618 Views)

We need to see the code.  I'm guessing you have paths setup to open a reference to a VI but the path in the EXE isn't the same as from source.  The solution to this is to not use the VI path at all and to reference it by name, and ensure it is in memory using a static VI reference.  Here is an example that was posted a while ago as a way to get away from the VI Templates method, which was popular in the 7.x era of LabVIEW when trying to do this type of thing.

 

http://forums.ni.com/t5/LabVIEW/building-an-executable-with-vits-with-Labview-2011/m-p/2384984#M7404...

0 Kudos
Message 2 of 12
(2,609 Views)

Path to vi is correct both in development and in exe.

What is the diffrence between using static reference and add vi to always included during build?

As I understand static call will place this dynamic vi in memory during build. So when I edit this dynamic vi on disk what will exe do? 

 

0 Kudos
Message 3 of 12
(2,600 Views)

@pawhan11 wrote:

What is the diffrence between using static reference and add vi to always included during build? 


Well one is better, and the other is always include Smiley Tongue

 

After re-reading your issue I think the static VI reference is not the solution for you.  Still here is my explaination on what the usage of the static VI reference is, then I'll mention why it isn't right for you.  The last paragraph where I mentione debugging an EXE is probably what you need to try.

 

To me having to remember to add the always include is an extra step that I (or someone who is going to replace me) might not know is required.  Using the static VI reference you are telling LabVIEW this VI is a dependencies, and needs to be included, just like all other VIs in the application.  Then using that you can read the VI name (or path) and use that instead of having another link to code that might not be obvious.  If I were to rename the VI, move it on disk, or add another VI to be included, then other things need to be changed.  That could be updating text for the VI name as a string constant somewhere, updating the path to the VI (which can be semi-arbitrary and change between versions of LabVIEW), and need to add the always include.  If you use the static VI reference there is far less issues that could come up which make it just not work.  If I rename the VI, change the path, or add new VIs to include the only thing I need to do is have a static VI reference to it, where the VI name is returned as a property node.  No need to update string/path constants, and no need to add the always include.  It's more modular, and more simple.

 


@pawhan11 wrote:

Path to vi is correct both in development and in exe. 


This is the most common mistake when this type of error comes up, how do you know the path is correct?  It isn't working so it is possible the path isn't correct.

 


@pawhan11 wrote:

 

As I understand static call will place this dynamic vi in memory during build. So when I edit this dynamic vi on disk what will exe do?  


Oh, okay that wasn't clear before.  With the technique I describe LabVIEW will include a copy of the VI specified in the static VI reference, and it won't use the one from disk.  In these types of situations I usually turn the code into an EXE but enable debugging so I can probe around and see why it is breaking.

 

http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/debug_apps_dlls/

0 Kudos
Message 4 of 12
(2,586 Views)

thanks for fast reply.Smiley Wink

 

Path is correct because I checked that in debugging. I get error 1003 that says that this vi is broken ( no more details in error) so I think something from inside is missing. 

 

Static reference works but after that my vi is no longer dynamic... It is the same as placing this vi in false case structure that never executes and then just calling it by name. So after I make changes in dynamic vi on disk it will run according to that one compiled in exe?

 

 

AIf I understand correctly dynamic vi will run if all its components and functions are known to EXE. If i edit and make small changes to dynamic vi like changing constant and so on EXE will still run it.

0 Kudos
Message 5 of 12
(2,571 Views)

Anyone?

0 Kudos
Message 6 of 12
(2,494 Views)

Hi Pawhan,

 

I'm interested to know if you were calling any LV Math/Stat palette VIs dynamically?! Could you take a look at this thread?!

 

https://forums.ni.com/t5/LabVIEW/Issue-in-calling-a-class-and-VI-dynamically-from-exe/m-p/3773771

 

My friends over there are also getting Error 1003.

 

 

- Partha ( CLD until Oct 2021 🙂 )
0 Kudos
Message 7 of 12
(1,662 Views)

The problem was resolved some time ago.

 

If I recall correctly, I deleted some vi from class and from disk. There were no dependencies left. 

While doing something else I found question mark vi in diagram disable structure. When I double clicked there was the message like: ''vi X not found''. This was the same vi I have removed from the project. I did some more tests and I came to the conclusion this was the reason for the broken build (from source code worked and executed fine)

To me this is IDE bug. The programmer should be somehow informed this VI still exists in diagram disable structure and break this VI.

0 Kudos
Message 8 of 12
(1,641 Views)

@pawhan11 wrote:

 

To me this is IDE bug. The programmer should be somehow informed this VI still exists in diagram disable structure and break this VI.


 

Looks like it is NOT a bug! Check out Point#2 in this KB article.

 

Error 1003 Occurs When Trying to Create an Executable

 

"If you are using any Conditional Disable Diagrams in your program, check each subdiagram and ensure that the code in each case is not broken.  If a subdiagram that only executes under the Run Time Engine setting contains broken code, the run arrow for the top level VI will not appear broken in development mode, but Error 1003 can occur upon building .".

 

- Partha ( CLD until Oct 2021 🙂 )
0 Kudos
Message 9 of 12
(1,630 Views)

Good to know it works like that. I thought content of dds is not included in build...

 

Is there a way to find all diagram disable structures in proj? If I have 10k vis checking all of them is not a fast process. I can create simple script tool for that if no other option is available.

0 Kudos
Message 10 of 12
(1,612 Views)