LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Separating compiled code when aiming for an executable?

Solved!
Go to solution

Hi,

I am trying to improve my SCC game: I've been using git with my projects, but when I make something that might involve an object called by multiple VIs, everything that is involved will be marked dirty and needs to be checked out even if I did not change those directly. The I found the option "separate compiled code from source" which is made to deal with this issue. However, when looking at the support pages I have found something that I can't understand properly: "Do not separate compiled code from VIs that you intend to load or run using the LabVIEW Run-Time Engine."

 

Does this mean that if I intend to build an executable in the end it won't work with separating the compiled code? Or does it mean that I can't call these VIs as raw VIs from the RTE? If the latter, I guess, I can deal with it, if the former, I guess I'll need to let this option go.

 

Thanks

__________________
Engage! using LV2015
0 Kudos
Message 1 of 7
(3,591 Views)
Solution
Accepted by topic author jeanlucpicard

Hi Jean-Luc,

 


@jeanlucpicard wrote:

Does this mean that if I intend to build an executable in the end it won't work with separating the compiled code? Or does it mean that I can't call these VIs as raw VIs from the RTE?


This only applies to VIs you want to call from an executable using VIServer methods, "separate code" will not affect building executables…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 7
(3,589 Views)

That sounds good for me

Does this also mean that if I have for example an optimizer which calls the goal function via a VI ref, that should also work, right?

__________________
Engage! using LV2015
0 Kudos
Message 3 of 7
(3,565 Views)

Hi Jean-Luc,

 


@jeanlucpicard wrote:

Does this also mean that if I have for example an optimizer which calls the goal function via a VI ref, that should also work, right?


That depends how you provide that VI reference: when the VI is placed separately from your executable file (i.e. not using a static reference), then this VI must include the compiled code to be able to run by RTE…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 4 of 7
(3,563 Views)

I also include those in the project and hardcode the VI to be used with a static ref, so then it should be fine, right?

__________________
Engage! using LV2015
0 Kudos
Message 5 of 7
(3,553 Views)

@jeanlucpicard wrote:

I also include those in the project and hardcode the VI to be used with a static ref, so then it should be fine, right?


Then it should be included, yes. It's easy enough to build and test. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 6 of 7
(3,518 Views)

The only time separating the compiled code from the source is an issue is if you are dynamically calling VIs from the executable AND distributing those VIs separate from the executable itself, that is using plugins. You can still distribute plugins separately and manage your SCC by using packed project libraries. Those are compiled code and can be called dynamically from an exe and be distributed independently of the exe itself.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 7 of 7
(3,478 Views)