What Does Mass Compile Do in LabVIEW?Primary Software:Primary Software Version: 7.0 Primary Software Fixed Version: N/A Secondary Software: N/A
Problem: I am asked to perform a mass compile in LabVIEW. What does this do? Solution: Mass compiling simply opens VIs up and closes them in an automated fashion. This has a couple of benefits:
The mass compiler gives you the option to cache VIs in memory so that they don't need to be loaded every time a top-level VI is compiled. This can significantly decrease the time spent during a mass compile. Depending on your machine's available memory, the number of VIs you should cache will change, but a good range to try is between 50 and 80 VIs. The mass compiler also gives you the option to save a log of the process. This log is important for the upgrade process since it will tell you in which VIs problems existed. Once you have mass compiled the code in both the original and target versions, review the logs of the mass compiles and look for the load path warnings “the VI expected to be at __ was loaded from __” This warning notifies you of a new linkage in the test environment. Review these warnings to ensure that all new linkages are appropriate. Another warning looks like the following: “Could not load __ because __ in memory” These are true cross linking errors in which LabVIEW may have chose the wrong subVI to link to because there was more than one VI on disk with the same name. Click here for more information regarding cross-linking problems. These load path warnings are typically the vast majority of the entries in the log file, which will happen unless the directory structure of the upgrade machine is identical to that of the development machine. Once these messages regarding moved files has been reviewed, mass compiling a second time will remove these and only reveal problems with VIs that are of greater concern. This is because the linkages were updated during the first mass compile. You should look for the following string in the mass compile reports to identify insane objects that exist in your application. “Insane Object” The log also indicates if these insane objects were fixed by the mass-compile routine. Also look for these characters to find bad VIs. “###” Although rare, the mass compile might crash when working with unstable VIs. This happens internally frequently during early development of a new version of LabVIEW; however, mass compile crashes are rare and taken seriously as LabVIEW begins to stabilize. It is unlikely that you will experience a mass-compile crash unless a particular VI is in a bad state that would also crash LabVIEW when loaded and saved. If the mass compile crashes, the log file will indicate which file caused the crash. Locate and open these files to ensure they are not corrupted, then mass compile again. In rare cases, it may be necessary to remove this file from the folder if the mass compile will not successfully complete a directory due to the bad file. Force Recompile: If you would like to Force Recompile the binary of the VIs in memory, press control+shift and the run arrow of the main VI and then save the VI. While it is typical for nothing to happen after binary recompiling the VIs in memory, this can frequently fix/isolate many errors. Related Links: KnowledgeBase 162BOTVJ: My VI Will Not Run Correctly, but No Errors are Reported KnowledgeBase 214A2JPH: How Do I Mass Compile VIs, LLBs, or Folders in LabVIEW? LabVIEW 8.6 Help: Mass Compile Dialog Box KnowledgeBase 1A99CBIT: How Can I Force a VI to Recompile? Attachments:
Report Date: 12/20/2002 Last Updated: 02/22/2010 Document ID: 2SJDAH2Q |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
