Mass Compile takes a long time to complete

[BillMe]

My AF project is coming along and is now what I would call "medium" sized with about 15 actors in total. What I have found here lately is that a mass compile of my project takes a whopping 35 mins. to complete. Since I've never had other non-AF projects take nearly this long, i.e, normally < 5 mins., I was wondering if this is expected behaviour for AF.

Thanks,

Bill

[bmitc]

That does seem excessive. Of course, as you know, the actor framework uses classes rather heavily, and even medium size projects using LabVIEW classes can become easily corrupted leading to weird issues. Although, a mass compile via the tools menu or a force mass compile via "right-click + control + shift on the run arrow" usually will fix these or identify a compile issue, breaking the offending VIs. Are you pulling in a lot of drivers as well?

This doesn't answer your question really, but why are you mass compiling so often that this is such a problem?

[AristosQueue (NI)]

That is unusual, BillMe.

Do you use a lot of strict typedefs? Are those strict typedefs members of your classes? Strict typedefs do an awful lot of unexpected font work (and font verification) when they mass compile. When they're a member of the class, they churn up a lot more work than you'd expect (than I'd expect, also!). If this fits you, try moving those typdefs outside of classes or making them non-strict.

Obviously a gigantic VI hierarchy can push mass compile times up, but I'm guessing that doesn't apply to you.

Are you constantly recompiling sometimes for RT and sometimes for desktop? Turn on "separate source from compiled code" (the checkbox on the very first page of the VI Properties dialog) on all your VIs. It helps A HUGE AMOUNT. All VIs that ship with LV have this option enabled, and have for several years now.

Do you have a deeply nested hierarchy of inlined VIs (say, four layers of inlining or more) that is commonly used in your hierarchy? I've seen those push times up as LV gets really aggressive about the optimizations that become possible.

[BillMe]

I'm not using strict typedefs. I'm not using RT. I'm not using inline VIs. I am using FPGA (one PXI-784XR running in simulation mode) and I created two niDCPower hardware resources with MAX using the simulation IVI driver. However, unlike the FPGA, the power supply resources are not yet referenced at all in my project.

In Dependencies I have an "Items in Memory" folder with a lot of "mxLv......." VIs (get and set properties) and a "VariantType.lvlib". Are the "mxLv......" files associated with DAQmx? Perhaps this is from my simulated power supply hardware resources?

During the mass compile, I noticed in the progress window a LOT of the same files in vi.lib seemingly being compiled and saved over and over again.

[Craig_]

If you increase the "Cache VIs" option to something like 50-100 does it go any faster?

[bmitc]

Since you are using LV FPGA, that would be my first guess as to the culprit. That also likely explains the VIs in the "Items in Memory" folder. I don't remember the specific names, but since LV FPGA uses XNodes (essentially scripted VIs running on your block diagram while you're editing it), it will have VIs in that folder. That can also explain them not having dependencies. VIs in that folder are usually (maybe always) just VIs in memory that have no direct callers.

In my experience, the problems almost always lie with one of three things with FPGA: Open FPGA VI Reference, Close FGPA Reference, and the typedef reference control that most people create.

Are you using a typedef FPGA reference control? Despite them being very helpful, I have had serious problems with these in the past. Renaming the control, and renaming it back to the original name has fixed it. (Yes, really.) I might suggest even deleting the Open FPGA VI Reference and Close FPGA Reference VIs and then placing them back. Then do a force mass compile on their owning VIs (right-click + control + shift + run arrow).

If it's none of that, then this calls for what I call a "LabVIEW D-Day". Basically, I assault LabVIEW by throwing all the strange techniques I know at LabVIEW until the problem goes away.

Maybe try the following?

• Close LabVIEW.
• Since you're using source control, check out your entire project.
• Open the top-level folders containing your code in Windows Explorer, make everything read-only, apply settings, and then make everything not read-only. Sometimes LabVIEW and Windows get out of sync with the read-only setting. I have had the problem before where I thought a VI was writable (via the setting as viewed in Windows Explorer), but LabVIEW thought otherwise. Thus, every compile change that needed to be saved with the VI wasn't getting done. This can cause huge problems with classes, VIs containing FPGA references, and libraries.
• Open your project. Save all.
• Do the force mass compile with the "right-click + control + shift + run arrow" method on your top-level VIs that have most of your VIs as dependencies. This method generally works for me better than using the LabVIEW mass compile tool. Save all.
• Right-click on the project and select "Find Missing Items" and "Find Items Incorrectly Claimed by a Library".
• Try the steps I mentioned above regarding the FPGA stuff. Sometimes I just delete the Open FPGA VI Reference and reconfigured it again. This propogates changes to the FPGA property and invoke nodes (which again are XNodes). Force mass comple on top-level FPGA VIs. Save all again.
• Try opening the .ctl files of your classes. Place a control in the clusters. Close and then save all. Re-open the class .ctl and remove your randomly added control. Close and then save all.
• Check any class VIs for grayed out class control icons, grayed out class wires, and class control icons surrounded with a black border. These will not always break a VI but are symptoms of some corruption happening.

That's all that I can think of. Despite these seeming random or unhelpful, I can promise that each step here has helped me at one point in time to get rid of LabVIEW problems.

Regarding the VIs always wanting saving, I agree that that is annoying. I do a couple of things to help with this. One, I treat read-only VIs as locked and set my source-control settings to check out VIs when editing them. Thus, when I come across a VI "checked in" to my source-control system (Perforce is my usual), it's locked since it's read-only. Then when I hit "ctrl + m" to edit it, LabVIEW checks it out for me. Depending on the various settings, this can automatically check-out class and libraries and calling VIs that need changed to. It helps with keeping everything saved.

Secondly, the above method will sometimes fail since classes really like to propogate changes through your heirarchy. So sometimes I will simply check out the entire project (I always use projects) and do a save all. That's all that I've ever had to do to get around this problem. I think a mass compile is overboard. The mass compile also has a non-zero chance of screwing up things in your <vi.lib> and other LabVIEW installed locations.

[BillMe]

I had already tried most of what you suggested with no difference. However, with the FPGA, this is the first time in many projects with FPGA targets that I've tried running as "Simulated I/O" (my hardware is not in yet). So I wrapped my "Open FPGA VI Ref" and "Close FPGA VI Ref" with conditional disables. My compile time went from 30 mins. to 7 mins. I can live without using Simulated I/O.

[BillMe]

And now that I'm using actual FPGA hardware, the mass compile is up to over an hour.