From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Separated Object code

Hello ,

Recently I have seen at Labview 2010 the “Separate compiled code from source file” option.This make me think of optimization the

program structure,like it possible at C/C++ so that we can deal with so-called "declarations".So for example the input nodes of

VI's didn't change, but internal actions may be altered without the need that higher levels VI even know it.I have seen for example,

how increased the time of saving the VI when inserting some low level classes.

  Is somebody make use of this potentially useful feature? Some tips?

Regards,

Michael.

_________________________________________________________________________________________________
LV 8.2 at Windows & Linux


0 Kudos
Message 1 of 5
(4,713 Views)

I don't understand! Declarations are part of the source code syntax either at preprocessor or compile time. So that is analogue to objects in the LabVIEW diagram and also in C/C++ not changeable on the compiled binary code only.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 5
(3,241 Views)

Hi rolfk,

I explain myself better -

  Suppose we have a vi, we call him Parent, that calls another vi we call him Children.

Let suppose that Parent passes some Object/Cluster/Anything else to Children.Children does some staff with

passed data.Here we get to the point. What happens to the "whole application code" when Children internal

behavior changed? Is Parent recompiled?

  So now, when we have an option of separated object code, may be we control somehow this (actually build)

process?

   Of cause it make no sense to talk about  about app. of two VI's.But it can save time (save/buld time?)  on the big

app.

Michael.

_________________________________________________________________________________________________
LV 8.2 at Windows & Linux


0 Kudos
Message 3 of 5
(3,241 Views)

Even before LV2010, Parent.vi would not be recompiled if, as stated in your example, only the internals of Children.vi changed. The gotcha in many cases is that you can change the block diagram of Children so that the types on the connector pane are untouched but the memory rules for various inputs/outpus change, which does cause a recompile of Parent.vi. For example, if Children takes in an array of integers and in the first version it only reads that array (say, summing up all the elements in the array using Add Array Elements), then the input is marked as a constant and Parent.vi is compiled accordingly. If you change Children.vi to use Multiply Array Elements, that's a change that does not change anything external about Children.vi, so Parent.vi does not need to recompile. If, however, you modified Children.vi so that you append a few items onto the array and then sum the elements, now Children.vi is modifying the array, so it can no longer be treated as a constant and the Parent.vi will have to recompile.

None of this has anything to do with the new option in LV 2010. The new option in 2010 allows the source code (the block diagram) to be saved separately from the object code (the assembly instructions generated by the compiler). The rules for whether or not recompile needs to occur are the same regardless of whether the VI is saved as one file or two files.

Message 4 of 5
(3,241 Views)

Thanks, Nice explaination.

_________________________________________________________________________________________________
LV 8.2 at Windows & Linux


0 Kudos
Message 5 of 5
(3,241 Views)