"Separate Compiled Code From Source"? (LV 2014)

[Jim Kring]

Back in the early days of LabVIEW, the Separate Compiled Code From Source feature had a lot of quirks (and we discussed them in this old thread). I'm wondering what are people's current feelings and practical experiences with this useful feature. Do you trust it (e.g. to not corrupt your code)? What are the current issues/quirks (e.g. occasional broken VIs)? How do you work around them (e.g. object cache flushing)?

 

Thanks for sharing. I'm working to put together a set of best practices for using this feature and I'd like to know everyone's... well... best practices

[MarkCG]

Still not quite there when working with with projects involving different execution targets in same project, like compactRIO. Deployment errors  when running in interactive mode on remote target, build problems, forcing recompile doesn't always work. I'd rather just deal with the excess changes in source control than have to do work arounds.

[ak_nz]

We make extensive use of this feature - but unlike MarkCG our deployment scope is much more limited (Windows targets only). Besides deleting the cache when the occasional "odd" thing happens we very rarely ever get corrupted VIs now (unlike 2012 - looking at you buddy).

[crossrulz]

I've been told that NI is using the Separate From Compiled for any VI they develop.  For Windows only projects, I have never had an issue (working in 2013 and 2014).  We had a small hiccup when trying to use the same VI in a project on Windows and cRIO RT.  Cleared the object cache once and it was fine again for the rest of the project.

[Jim Kring]

Thanks for the info, everyone!

 

My takeaways are:

 

- NI is eating its own dogfood and using this feature internally to a very great extent (I'll see if I can verify this and learn more).

 

- For projects that do not have multiple targets (e.g. Windows desktop only, and no Real-Time targets in the same project) this seems to work very well in 2013 and 2014 (but, there were lots of problems in 2012 and earlier)

 

- For simple projects that have multiple targets (e.g. Desktop and Real-Time targets in the same project) this seems to cause issues ("small hiccups" and "odd things") that can usually be resolved by clearing the object cache.

 

- For larger and more complicated projects with multiple deployment targets there can be (A) deployment errors when running in interactive mode on remote target, as well as (B) build problems. Unfortunately, forcing recompile and clearing the object cache doesn't always work to resolve the issues. For some users, this is too big of a pain and they have abandoned the use of Separate Compiled Code from Source on these projects.

 

Did I get that right?

 

Anyone else have good/bad experiences or input to the topic?

 

Thanks,

[PiDi]

- For larger and more complicated projects with multiple deployment targets there can be (A) deployment errors when running in interactive mode on remote target, as well as (B) build problems. Unfortunately, forcing recompile and clearing the object cache doesn't always work to resolve the issues. For some users, this is too big of a pain and they have abandoned the use of Separate Compiled Code from Source on these projects.

 

I'll add to this case: project currently contains ~3000 VIs and ~300 classes. The code, written in LV2013, is shared between PC and RT PXI target. We've separated compiled code when the project already contained significant amount of code. The reason for this was irritation whenever someone tried to commit some minor changes into SVN, but found out that this minor change triggered changes to half of the project hierarchy. It was especially problematic when 3 people was making some heavy developmement on different modules and LV decided that it should recompile some libraries that didn't even had any apparent connections to each other (well, I think there are few to none people in the world currently who fully understand the ways of LV compiler ;P ).

So we've separated code. I don't have any solid metrics to it, but we've concluded that our commits became clearer and number of conflicts dropped (ok, there is one metric - number of "wtf is this VI that is marked changed? I swear I've never even known it existed" dropped drastically).

 

Now for the most interesting thing: the effects on deployments and builds. We have absolutely no evidence or even feelings that separation has made anything worse. By this I mean the deployments to RT were just as buggy, unreliable and painful as before separation, but not more. I remember at some point we've even tried to reattach the code (of course, with whole cache clearing, recompilation, etc) to check whether it would help with deployments and it didn't help at all. As far as I remember, we've even reverted the repo to the point before separation and first thing we saw when tried to run the code on RT was "Deployment completed with errors"

 

You're absolutely right about problems in versions before 2013. I know from my collegues that they tried it in 2011 or 2012 in smaller project and failed.

 

Summing-up: code separation seems to be very convenient for the team developement (but as I said - I have no metrics, just the general overview of changes commited to repos and feelings in the team). The deployments and builds of code which is shared between different targets are just generally broken, they don't seem to be more broken with compiled code separation as of LV2013. The apparent deployments fix when reattaching the code is probably just due to some recompilation happening in the process and is not connected directly to this option.

[MarkCG]

 

Now for the most interesting thing: the effects on deployments and builds. We have absolutely no evidence or even feelings that separation has made anything worse. By this I mean the deployments to RT were just as buggy, unreliable and painful as before separation, but not more. I remember at some point we've even tried to reattach the code (of course, with whole cache clearing, recompilation, etc) to check whether it would help with deployments and it didn't help at all. As far as I remember, we've even reverted the repo to the point before separation and first thing we saw when tried to run the code on RT was "Deployment completed with errors"

 

Hmm, for me, to the contrary everything has worked without a hitch since unseparating source for that particular project-- it solved the deployment problem I was having. It was in 2014 too.

 

I have a feeling  cause hiccups when you have dependencies shared by both the windows target and the real time target- for example you have a class that works on the RT side, and a typedef control within that class that gets used somewhere on the windows/HMI side. That's a no-no, disconnect from typedef always if you have too. I don't have conclusive evidence to back it up though.

 

I wish I had a clearer picture on how the whole dependencies / multiple targets / compiling worked to better understand why things like this might happen

Edited December 13, 2014 by MarkCG

[GregSands]

I've been using "separate compiled code" in 2012 for some time, and for the most part it works without a problem.  The only thing I recall is getting out of sync with an RT deployment, but clearing the cache and starting over got things working.  One point not yet mentioned is that it's also very useful for code that is used in both 32 and 64-bit LabVIEW.

[smithd]

I have a feeling  cause hiccups when you have dependencies shared by both the windows target and the real time target- for example you have a class that works on the RT side, and a typedef control within that class that gets used somewhere on the windows/HMI side. That's a no-no, disconnect from typedef always if you have too. I don't have conclusive evidence to back it up though.

 

I've been using source separate since 2011 and it seems to work 95% of the time. If you use any of my group's libraries which have been updated recently (much of the stuff on ni.com/referencedesigns), you are also likely using source separate code.

 

However because of other issues we've taken to using at least two classes or libraries to help resolve the situation you describe. One is responsible for any data or function which has to be shared between RT and the host. Then there is one class or library for the host, and one for RT. I think my colleague Burt S has already shown you some of the stuff which uses this with an editor (PC), configuration (shared API), and runtime (RT) classes. This pattern works really well for us and we've begun applying it to new projects (or refactoring ongoing projects to get closer to this, relieving many of our edit-time headaches). While there is still shared stuff, it all seems to update correctly and labview doesn't appear to have any sync issues.

 

Where I have had annoying issues are with case sensitivity (kind of an odd situation but the long and short of it is that LabVIEW on windows ignores case errors while LabVIEW on RT rejects case issues -- but I haven't confirmed this is related to source sep) and with modifying execution settings (for example if you enable debugging you sometimes have to reboot the cRIO to take effect, even worse if you use any inlining). Both of these issues are documented.

[hooovahh]

I think I've mentioned this before, but our entire reuse from 2011 (and it is quite big) and all Windows based projects from 2011 to 2013 have has separate compiled code on every VI. Haven't seen an issue that was traced to this feature. We haven't used 2014 on any real projects yet.

[dannyt]

I starting using separate compiled code from LV2010 when it first came out and am still doing so in LV2014.  I have never had any problems with this feature, to the contrary it totally changed my option of LabVIEW and how it has become a 'real' programming language  that is usable in a team  development environment using proper source control tools.

 

I admit I have only been using it on Windows based platforms and though the projects have been big in number of VI's they have been quite simplistic compared to what a lot of you guys do.

[OlivierL]

We have been having the same interrogation that Jim brought up (almost a year ago) at our firm for a few months and I finally got around to read on the topic this morning. After reading a few other interesting threads, I found this one and thought I would bring it up again to know how 2014 (sp1) and 2015 (so far) have fared for other developers, if some of those issues have been resolved or if any new issues have been discovered.

 

Thanks to all of those who contributed and shared their experiences. Based on all this information and the known problems with the RT (the posts seem to only point to cRIO, not PXI RT failures...), I think we will move forward and benefit from the easier SCC management and smaller commits.  For those who have had the issues with the cRIO, was it with the newer Linux based RT or with the older VxWorks (& Pharlaps)? Does the OS (and the compile chain) make any difference in the amount of issues that you faced?