To remove compiled code or not, that is the question.

[MikaelH]

Hi guys

I'm still stuck with 2010 at work, and we have tried to remove the compiled code from all our shared code, and that seemed to work to start with.

Then all of a sudden (I don't really know what we did to cause it to happen), all enum constants on block diagrams that was linked to a particular type def control, changed to the first value of the type def (index 0).

That was really odd, but after a bit of investigation we blamed the "Remove-Compiled Code" option and put it back, and we've never saw the problem again, until today.

I still had one shared lv-class, with removed compiled code, that got screwed up today.

I checked with my tortoise and the VI had no changes made to it, but still my enums were changed to the first value.

So I closed the VI, and removed the Object Cash (LabVIEW Data\VIObjCache\10.0) folder, and reopened it, and now it was all good again.

Am I the only one that have seen this problem?

//Mike

[mje]

Yes, but I've never been able to track them down. Sometimes after editing enum typedefs for my state machines my constants will change values. It doesn't happen all the time, but when it does it tends to break things in rather spectacular fashion. Very annoying. I don't include compiled code in my LabVIEW VIs.

[hooovahh]

I've yet to use this feature but on my next new project I planned on not including compiled code. I'd like to hear other users sound off on any issues like these, so I know to avoid it for another version or two. I also wouldn't mind hearing people that have used this feature and have had no noticeable issues.

[dannyt]

I could not wait for the option to seperate compiled code and source code and have been using it from day one in LabVIEW 2010, so I have been using it in LavIEW 2010 and then LabIVEw 2011 and have had no problems with it myself.

I do not use Objects and have a sinlge top level with around 1000+ vi in a application I do use dynamic loaded of VIs

[MikaelH]

I do not use Objects and have a sinlge top level with around 1000+ vi in a application I do use dynamic loaded of VIs

And you use of course TypeDefs???

Maybe it's the combination of Removed Compiled Code and TypeDefs beloning to a library/class?!?!

I've never experienced this before I removed the Compiled code, and I have been coding LV daily, between 8-16 hours day for the last 17 years

Yes, but I've never been able to track them down. Sometimes after editing enum typedefs for my state machines my constants will change values. It doesn't happen all the time, but when it does it tends to break things in rather spectacular fashion. Very annoying. I don't include compiled code in my LabVIEW VIs.

Next time it happens close the VI and remove the Object Cash and see if that fixes the problem.

[0_o]

I heard that dynamic dispatched vis has problem with separating compiled code so I wrote a script to exclude them.

I just finished writing the script that goes over all the vis and searches recursively for strings/paths that contain ".vi" in order to remove dynamic loaded vis from a list of vis that will be changed by the script.

However, you stopped me at the last second from pressing run and changing all the vis in the list to separate compiled code since I both use LVOOP classes and typedefs, obviously.

Can this problem be connected to the mutation history and the issue with cluster typedefs in the class control?

Do you know if reentrant vis has problem with separating compiled code or any other issue?

The last thing I need right now is to revert my entire project (>2000 vis and lots of classes) after two month of work since some enums changed and I don't know which or have time to check.

Edited July 2, 2012 by 0_o

[dannyt]

Yes I do use TypeDefs normally strict type's but I do not change them very often. My build scrpts often clean out the compiled code caches maybe that helps.

Seems to work OK for dynamic loaded VI's now that I have moved away from 8.x.x layout

[Aristos Queue]

I heard that dynamic dispatched vis has problem with separating compiled code so I wrote a script to exclude them.

Where did you hear that? It's not true.

[mje]

Next time it happens close the VI and remove the Object Cash and see if that fixes the problem.

Mikael, I owe you big time. I just added a value to an enumeration typedef for one of my state machines, and all of a sudden every instance of the typedef reset to the default (0) value. I shut everything down, cleared the cache, and all was well. Cheers!

[bmoyer]

When using an exe, the VIs that are dynamically loaded need to have their compiled code in them in order to work. I have a program that loads a VI based on the header of a data text file and the VI won't load unless it has non-separated compiled code in the VI.

[MikaelH]

Mikael, I owe you big time.

That's what LAVA is for.

When I thought about removing the compiled code from the VIs of all our Instrument driver(about 200 lvclasses), which the whole company is using, I was very worried, does this new feature work 100%?!?

So to become more confident I contacted AQ, who referred me to a compiled code specialist at NI that gave me the confident of going ahead.

I would like to report this to NI, but first I need to know how to reproduce it, because it happens very seldom, but when it happens everything comes crashing down.

I first noticed it, when I needed to build a new version of my executable, the executable didn't work.

And when I dug in to the driver layers I found one class where all commands to the instrument was reset to the first element.

[0_o]

Where did you hear that? It's not true.

I don't remember where exactly but it is similar to what bmoyer just said.

When using an exe, the VIs that are dynamically loaded need to have their compiled code in them in order to work. I have a program that loads a VI based on the header of a data text file and the VI won't load unless it has non-separated compiled code in the VI.

However, this had a solution while this new problem is much more risky.

I thought it was a class mutation history issue with typedef clusters yet from the snapshot it seems as if they are not typedef at all (unless it is an old LV version which I guess it is not).

[dannyt]

I don't remember where exactly but it is similar to what bmoyer just said.

As I said in a previous post I got dynamic loaded VI working OK in an executable with compile code seperated.

BUT that was only after I moved away from the old LabVIEW 8.x.x layout format. While trying to get my system working I did at some points get an error message when running the executalbe that blamed the seperation of compiled and source code, but in truth I think the error message was incorrect /misleading and the real error was down to my paths finding and loading the VI correctly.

Once I had figured that out everything has been working fine.

[RnDMonkey]

That's what LAVA is for.

When I thought about removing the compiled code from the VIs of all our Instrument driver(about 200 lvclasses), which the whole company is using, I was very worried, does this new feature work 100%?!?

So to become more confident I contacted AQ, who referred me to a compiled code specialist at NI that gave me the confident of going ahead.

I would like to report this to NI, but first I need to know how to reproduce it, because it happens very seldom, but when it happens everything comes crashing down.

I first noticed it, when I needed to build a new version of my executable, the executable didn't work.

And when I dug in to the driver layers I found one class where all commands to the instrument was reset to the first element.

CLS.png

You guys are scaring me away from this feature. Between anecdotal evidence like this and the mark project items to separate... process I just stopped after the 5th hour of processing, I'm feeling pretty nervous. I might still give it a try with Shaun's conversion VI posted at http://lavag.org/topic/12886-experience-with-separate-compiled-code-from-source-lv-2010/?p=77020, but now I seem to be stuck in this operation for good and I'm terrified to kill LabVIEW forcibly. With a project folder containing rougly 850+ vis, lvlibs, and ctls, the project-based conversion dialog says it's at 6736 loaded and counting. I would love to know what is going on here. I assume this is enumerating the files, removing the compiled code, and saving them?

[LogMAN]

You guys are scaring me away from this feature. Between anecdotal evidence like this and the mark project items to separate... process I just stopped after the 5th hour of processing, I'm feeling pretty nervous. I might still give it a try with Shaun's conversion VI posted at http://lavag.org/topic/12886-experience-with-separate-compiled-code-from-source-lv-2010/?p=77020, but now I seem to be stuck in this operation for good and I'm terrified to kill LabVIEW forcibly. With a project folder containing rougly 850+ vis, lvlibs, and ctls, the project-based conversion dialog says it's at 6736 loaded and counting. I would love to know what is going on here. I assume this is enumerating the files, removing the compiled code, and saving them?

screenshot1000138.png

 

There are quite a few items loaded and I'm not sure how the sources will react if you kill LabVIEW (some of them might have their compiled code removed while others dont). It wouldn't be a big issue if you had your code in SVN or something where you could just revert the working copy... (I recommand to create a backup before doing such stuff anyways)

However if you have a single project file and want to remove compiled code from VIs within the project you can do that from the project properties dialog (Seperate compiled code from new project items & Mark existing items) I recommand to use that function as it is shipped with LabVIEW (at least since 2011 afaik) I used it on my recent project with 1000+ VIs and it took just a couple of minutes.

 

Just read the thread you linked: Seems that LabVIEW 2010 had some issues with the removing of compiled code. As you are using LabVIEW 2012 that should be no issue, so why using that VI instead of the build-in function anyways?

[todd]

With a project folder containing rougly 850+ vis, lvlibs, and ctls, the project-based conversion dialog says it's at 6736 loaded and counting. I would love to know what is going on here. I assume this is enumerating the files, removing the compiled code, and saving them?

I'm working on doing the same thing with a project that sounds similar to yours. The thing I'm worried about is having all of the typedefs in memory along with all of their callers - many of which are ACBR. Over the next couple of days I'm hoping to get a little script together that creates a tree.vi to keep everything loaded.

[RnDMonkey]

There are quite a few items loaded and I'm not sure how the sources will react if you kill LabVIEW (some of them might have their compiled code removed while others dont). It wouldn't be a big issue if you had your code in SVN or something where you could just revert the working copy... (I recommand to create a backup before doing such stuff anyways)

However if you have a single project file and want to remove compiled code from VIs within the project you can do that from the project properties dialog (Seperate compiled code from new project items & Mark existing items) I recommand to use that function as it is shipped with LabVIEW (at least since 2011 afaik) I used it on my recent project with 1000+ VIs and it took just a couple of minutes.

 

Just read the thread you linked: Seems that LabVIEW 2010 had some issues with the removing of compiled code. As you are using LabVIEW 2012 that should be no issue, so why using that VI instead of the build-in function anyways?

Actually, I AM using the built-in functionality exactly as you indicated. The fact that you did 1000+ VIs in so short a time does not bode well for me. I left it running over the weekend, I really hope it's all resolved by the time I get back to work tomorrow.

 

 

I'm working on doing the same thing with a project that sounds similar to yours. The thing I'm worried about is having all of the typedefs in memory along with all of their callers - many of which are ACBR. Over the next couple of days I'm hoping to get a little script together that creates a tree.vi to keep everything loaded.

Yes, I have the same concern. A tree VI sounds good at least to help make sure things get updated when the Typedefs change, but of course that means maintaining the tree as the project is modified. What about auto-populating folders in the project tree? Do those make everything get loaded into memory?

[LogMAN]

Actually, I AM using the built-in functionality exactly as you indicated. The fact that you did 1000+ VIs in so short a time does not bode well for me. I left it running over the weekend, I really hope it's all resolved by the time I get back to work tomorrow.

 

 

Yes, I have the same concern. A tree VI sounds good at least to help make sure things get updated when the Typedefs change, but of course that means maintaining the tree as the project is modified. What about auto-populating folders in the project tree? Do those make everything get loaded into memory?

 

My bad, I missed the part where you said 'project-based conversation dialog'.

 

Let me recollect something: The dialog that appears will in fact list all the LabVIEW items in your project:

 

The enumeration process might take a while depending on the number of files in your project but there has never been a loading screen for me. Be aware that all files within the project (VIs, libraries, llbs, auto-populated VIs/libraries/llbs, etc...) will be enumerated (except for files under 'dependencies'). Have you ever reached that dialog at all? It's not clear for me.

 

If you never reached that dialog, it should be rather safe to kill LabVIEW (it's enumerating files) -> I assume your dialog does only say 'Loading:' and not 'Compiling:' as in your screenshot. It seems like LabVIEW is trying to load everything (the entire LabVIEW directory?) into memory (..LabVIEW 2012resourceFramework* is part of the LabVIEW core!). So you could abort that operation and try on an empty project file. If you have the same behaviour again, it would be a good time to contact NI.

 

If you want/have to abort the process, you should check the object cache first. If the size changes, than LabVIEW does remove compiled code. Killing the process then might result in broken VIs.

It is located under:

C:Users<your user name>DocumentsLabVIEW DataVIObjCache<your labview version>objFileDB.vidb

 

So for me that would be:

C:UsersLogMANDocumentsLabVIEW DataVIObjCache12.0.0r4objFileDB.vidb

[MikaelH]

FYI

I have now (since I'm using LV2012 SP1), recently converted all our shared company code/drivers to save the VIs again without Compiled Code. So far no problem.

I just ran this VI overnight, and committed everything the morning after.

[RnDMonkey]

My bad, I missed the part where you said 'project-based conversation dialog'.

 

Let me recollect something: The dialog that appears will in fact list all the LabVIEW items in your project:

Mark Project Items to Seperate Compiled Code.png

 

The enumeration process might take a while depending on the number of files in your project but there has never been a loading screen for me. Be aware that all files within the project (VIs, libraries, llbs, auto-populated VIs/libraries/llbs, etc...) will be enumerated (except for files under 'dependencies'). Have you ever reached that dialog at all? It's not clear for me.

 

If you never reached that dialog, it should be rather safe to kill LabVIEW (it's enumerating files) -> I assume your dialog does only say 'Loading:' and not 'Compiling:' as in your screenshot. It seems like LabVIEW is trying to load everything (the entire LabVIEW directory?) into memory (..LabVIEW 2012resourceFramework* is part of the LabVIEW core!). So you could abort that operation and try on an empty project file. If you have the same behaviour again, it would be a good time to contact NI.

...

LogMAN,

The dialog you pictured is right behind what I took a screenshot of. My loading screen as pictured ccame up immediately after I clicked on "Mark selected items" (after selecting them all in the list).

Edited September 22, 2013 by RnDMonkey

[hooovahh]

FYI

I have now (since I'm using LV2012 SP1), recently converted all our shared company code/drivers to save the VIs again without Compiled Code. So far no problem.

I just ran this VI overnight, and committed everything the morning after.

Compile.png

We did something very similar here about a year ago.  We took our reuse library (2011 and up) and added pre-build VIs for VIPM to use before making the package, to remove compiled code, and turn off automatic error handling, and allow debugging, on VIs that aren't demo VIs or example VIs (these we tend to probe around and see how it works so we want to be able to debug).

 

After a year of usage we've had no issues.  We also invested some time to understand what VIs can be inlined and went through the process of inlining them.  And again after a year no issues yet.

[RnDMonkey]

Ok, in my mind something is DEFINITELY broken here. The "Loading" count is up to 40166. It would seem to be in an infinite loop here. Time to kill LabVIEW.

 

Update: After killing LabVIEW and re-opening my project and going back into the separate source dialog (thinking to try just a few rather than the whole shebang), I discovered that all but about a dozen were showing as marked. I was able to mark the remaining items in no time at all. Of course, I still have the issue of opening all the files and saving them to do the actual separation.

Edited September 23, 2013 by RnDMonkey

[shoneill]

Ok,in my mind something is DEFINITELY broken

 

Well they say that admitting it is the first step towards healing. 

[hooovahh]

Well they say that admitting it is the first step towards healing. 

Is that also the last step?

 

 

Oh I don't want to walk that far. Anything that takes more than 12 steps...isn't worth doing. Eh? 12? Get it... Steps. Hehehe.

Edited September 30, 2013 by hooovahh

[RnDMonkey]

Well they say that admitting it is the first step towards healing. 

HA!

Well they say that admitting it is the first step towards healing. 

HA!

Well they say that admitting it is the first step towards healing. 

HA!