Jump to content
News about the LabVIEW Wiki! Read more... ×
Jim Kring

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

Recommended Posts

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 :)

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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).

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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,

Share this post


Link to post
Share on other sites

 

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 by MarkCG
  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

By using this site, you agree to our Terms of Use.