Leaderboard

My turn to feed the bears... http://science.slashdot.org/story/10/05/05/0012215/Second-Inquiry-Exonerates-Climatic-Research-Unit

From the CRU press release: "Another area for suggested improvement is in the archiving of data and algorithms, and in recording exactly what was done." So they admit they threw out the raw data. Am I the only one who still thinks this smells like a SCAM? Un frackin' believable.

I moved it to the Quick Drop Plugins category as requested. Mark

Name: Build Script Submitter: jgcode Submitted: 13 Nov 2009 File Updated: 03 Jan 2011 Category: *Uncertified* LabVIEW Version: 8.6 License Type: BSD (Most common) Build Script v1.1.0 Copyright © 2009, Jonathon Green; JGCODE All rights reserved. Author: Jonathon Green LAVA Name: jgcode Contact Info: Contact via PM on lavag.org LabVIEW Versions: LabVIEW 8.6 LabVIEW 2009 Dependencies: jki_lib_state_machine >= 2.0.0 jki_rsc_toolkits_palette >= 1.1 oglib_array >= 2.0 oglib_appcontrol >= 2.0 ogrsc_dynamicpalette >= 0.2 oglib_error >= 2.0 oglib_file >= 2.5 Unit Test Framework (optional) Description: Contains a build script for a LabVIEW Project. Use a build script in your development to automate the task of, and avoid errors when, creating deliverables. A sample project is included that creates an application, installer then archive (.zip) for a project. This build script supports the new 9.x build format by building the specs in a high level temp folder (e.g. C:\dist) to minimise errors occurring from the OS exceeding maximum number of characters in path. NI's Unit Test Framework (UTF) is supported or code can be added for other Unit Test APIs (see Unit Test Framwork.png for demo code). Installation and instructions: The dist folder contains build.vit and a library (.llb) of support code. See Examples section on how to use code. Examples: 1. Open example\Project.lvprj 2. Open and run build.vi, VI should complete execution with no errors 3. Once build script has completed explore example\dist to view all builds (application, installer, zip) 4. Unzip zip folder and install application 5. Run the application 6. "Build Works!" dialog should appear to indicate sucessful build 7. Reuse script a. Use build.vit as starting template for project b. Edit the project details on the block diagram to match to new project Known Issues: No Known Issues Acknowledgements: Justin Goeres (JKI) Joel Spolsky JKI (JKI State Machine) OpenG ICON Technologies Version History (Changelist): 1.1.0 2009 11 15 [Fix] Code saved to LabVIEW 8.6 on request from LAVA member. Unit Test Framework VIs were removed due to build issue. [Fix] SubVIs added to a .lvlib within a .llb. 1.0.0 2009 11 14 [Feature] Initial release of the code (LabVIEW 2009). License: BSD Support: If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the Build Script support page. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file

example BOM file -------------- ClearCase Build Info (Build Start) ----------------- ClearCase Build View : petes-dev-ats-814 ClearCase Config Spec : element * CHECKEDOUT element * /main/dev-ats-814/LATEST element * /main/B591-ATS-2009NOV24 -mkbranch dev-ats-814 element * /main/0 -mkbranch dev-ats-814 create_message_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_message_event.vi,\main\1, create_exit_event.vi,P:\testTeam\ATS\Projects\test_exec_framework\user_events\create_exit_event.vi,\main\1, run_sequence_data_type.vi,P:\testTeam\ATS\Projects\test_exec_framework\general_type_defs\run_sequence_data_type.vi,\main\1, update_symbols_run.vi,P:\testTeam\ATS\Projects\Sandpit\update_symbols_run.vi,\main\1, Open File+.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\Utility\file.llb\Open File+.vi,CC PATH NOT FOUND,file.llb kHz-MHz.vi,P:\testTeam\ATS\Projects\Sandpit\kHz-MHz.vi,\main\1, NI_MAPro.lvlib:ma_Check for Equality with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Check for Equality with Precision.vi,CC PATH NOT FOUND,mamon.llb NI_MAPro.lvlib:ma_Range Check with Precision.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Range Check with Precision.vi,CC PATH NOT FOUND,mamon.llb NI_MAPro.lvlib:ma_Limit Test Outside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Outside.vi,CC PATH NOT FOUND,mamon.llb NI_MAPro.lvlib:ma_Limit Test Inside.vi,C:\Program Files\National Instruments\LabVIEW 8.2\vi.lib\measure\mamon.llb\ma_Limit Test Inside.vi,CC PATH NOT FOUND,mamon.llb As you see starts with the ClearCase Config Spec used for the build then lists all the files used in build. Each line is comma separated look like VI name, full filepath, ClearCase extended path info (if a ClearCase object), llb name if VI is in a llb.

Some comments: Regarding scalability: 1) Performance: I created my own bench test a while back, programmatically creating 1000 SVs and writing 1000 messages to each. I don't remember the exact numbers, but the performance was quite good. 2) Ability to configure SVs easily: What exists: a) Control binding i) Manual configuration of each control ii) Front Panel Binding Mass Configuration tool iii) Programmatically updating the URLs with the DataSocket API b) Configuring SVs i) SV library interface (good but not ideal for a very large number of variables) ii) Multiple Variable Editor (convenient spreadsheet-like interface for each library) iii) DSC SV creation and configuration methods iv) To clone a library (same variables, new library name) one can just use a method to copy it on disk. This may be a personal thing, but I don't like using the DataSocket API for shared variables in general. (The read/write SV methods only use buffering if you pass the reference, unlike SV nodes, which also make the code much easier to read. Moreover, I don't like the concept of using DataSocket methods for all sorts of unrelated communications methods. I think NI should incorporate all shared variable capabilities into a single consistent API--and there has been some progress here.) What we found is that the most common reason we have to want to do things programmatically is when we want to clone a software component (to make multiple instances of an application). Most often we can accomplish this by renaming a SV library before building an executable. I think the builder should support this in the build script (but it doesn't currently). Another common reason I can think of to want to configure SVs on the fly is to change the logging configuration (resulting in more or less frequent logging rates). One can do this by programmatically creating and configuring SVs using the DSC methods, or one can use the Multiple Variable Editor interface. (An outstanding task for us is to see if we can build the libraries with an executable such that we can edit them while an executable is running, as we can in the development environment.)