Leaderboard

Following in the tradition of LAVAr's from around the globe, I am very pleased to introduce... Digby and Dexter! Dad sure has his hands full Mad props to Jack for the outfits.

I just discovered by accident that if you copy a primitive VI (like add) then edit the icon of a VI and paste , you get the icon of the primitive? I am sure a lot of you already knew this, but I thought I would share, because it was a nice surprise to me. Now it will be easier to create new icons. Fab

LLBs and LVLibs solve different problems (and create different problems), and are not interchangeable or really related beyond sharing the word "library" in their acronyms. Here are some characteristics and comparisons of the two: LLB provides physical packaging containment of members, and does not address namespacing (nor scoping). LVLIB provides namespace containment of members (and also scoping), and does not address physical packaging. Both LLB and LVLIB impose static linkages that can be incidental and undesirable. These negatively affect load times (IDE and run-time), build times, and compile times. Anecdotally, it's greater than O(n) time complexity, especially when circular linkages exist between multiple such hierarchies, and most especially if the library hierarchy is nested (e.g., LVCLASS within an LVLIB, or nested LVLIBs) An LVLIB can be built into an LVLIBP. An LVLIBP is different from an LLB in that an LLB packs writeable, cross-platform* VIs capable of mutating to future LabVIEW versions, while an LVLIBP is a read-only, platform- and version-specific byte code distributable (which may contain the block diagram for debugging, except still remaining platform- and version-specific). An LLB may be used to pack libraries/plugins for deployment as application plugins, or as reusable libraries in development. An LVLIBP effectively is only used for the former. Neither LVLIBP nor LLB can pack non-LabVIEW-source filetypes as resources. Be mindful to account for both renaming/name-mangling resources, and also changes in relative path. LVLIBs (and LVLIBPs) render nicely in the LVProj tree, while LLB members appear indistinguishable from POVIs (plain ol' VIs). LLBs cannot pack two VIs of the same filename. This prevents packaging multiple LVCLASS hierarchies that use dynamic dispatch methods. This represents a few LabVIEW design limitations: 1) LLB's lack of an internal directory hierarchy for organization and packing of two filenames, and 2) LVCLASS using OS filename as the only unique identifier for method identification in a class (filename represents a good default value, but we need one more degree of indirection as a field within the LVClass XML; it's another discussion why this is so highly desirable to decouple source from OS convention). For actively-developed libraries, LLBs are bad because they exist a monolithic binary file. LVLIBs are bad because there exists no diffing or merging capabilities (this also applies to LVPROJ, LVCLASS, XCTL, XNODE filetypes. This is especially insidious, because popular DVCS clients autodetect the file format as XML and think "Aw yeah dude, I got this!" MERGE FAIL. Corrupted source. Be sure to turn off this autodetection for these filetypes.) LVLIBs can apply icon overlays to members. LVLIBs may be carefully designed to include strategic static linkages, including non-LabVIEW source files. This is one strategy to avoid managing the "Always Include" section of AppBuilder for distributables, especially as a convenience for end-user-developers of re-use libraries. But this fails by default because of the setting "Remove unused members of project libraries". Unchecking that often causes failure to build for non-trivial-sized applications linking to gargantuan LVLIBs shipping in vi.lib and as add-ons. So, the strategy may or may not work (it's coupled to whether or not you're keenly aware of and properly managing all application static dependencies) The reason I want to like LLBs is their ability to provide packaging constructs that provide higher performance on actual hardware. It's faster to load 1 file of size 100 units than 100 files of size 1 unit. It's also a more convenient distribution format -- a single file. (Also, I can't think of another language that effectively enforces a 1:1 relationship between method and physical file. LabVIEW requires substantially more clerical work to develop and refactor, for this reason) The reason I want to like LVLIBs is to enable namespacing and scoping beyond the LVCLASS level. Though, this namespacing always comes with the cost of static linking, which is perhaps the #1 problem for codebases of non-trivial size (do you see busy cursors while editing and wiring? long build times? load times? type prop errors? corruptions from application refactoring? heartache and heartburn generally?) Also, LVLIBP is neat in practice, but so narrowly scoped to specific deployment scenarios where it's acceptable to target version- and platform-specfic targets (version-specificity is definitely the bigger problem. every 12mo, we are afforded the opportunity to choose between obsolecense/migration/revalidation or just-plain-outdatedness). And without arbitrary namespace composition (namespace B and namespace C may both declare using namespace A; with namespace A unaware and none-the-wiser), it's not necessarily a compelling feature to begin with. (Corollary: an LVCLASS's ability to namespace and scope its members is desirable and good; but it becomes less necessary and more-likely-incorrect to continue namespacing and scoping at higher abstraction levels without namespace composition) Do LVLIBs Scale? Using LVLIBs in source on an actively-developed project raises barriers to both team scale and application scale. The cost of not using them is loss of scoping, which is avoided through communication and convention, and easily-detected if any actual problem were to exist. Another cost is loss of namespace, easily avoided through filenaming conventions (which is incidentally an industry standard on the web; prefixing library APIs with library-specific prefixes to avoid collision). Said another way, ROI diminishes and reverses to negative at scale, and opportunity cost has simple workarounds. I choose the opportunity cost. But... LVLIBPs! Another apparent opportunity cost of avoiding LVLIB in source is the inability to have LVLIBP as a distributable. Though, if you treat build/distribution as a second toolchain from the dev toolchain, the dev source can remain unencumbered by LVLIB, which is only added as part of the build process. I have mixed feelings on ROI here, but if LVLIBP makes sense for you, consider this strategy to make your dev experience noticeably more pleasant. Here's a real-world case study. This is from a Wirebird Labs client who gave permission to release this screenshot of a bird's eye view of their application analyzed using Links. What we're looking at in the screenshot below is an application with over 8000 application VIs (not including third-party dependencies). Libraries are identified by labels. Nodes represent a source file (mostly VIs, but also including LVLIB and LVCLASS and CTL), and connections between nodes represent static links as detected by the LabVIEW linker. This is a static screenshot of the application, but while running the physics engine lays out nodes as a force diagram. The strength of the force is based on number of static links existing between nodes, and a negative force is applied to nodes with no static links. This causes nodes to form clusters in space where strong coupling exists. What is the value of analyzing the application like this? Here is a list of issues we needed to solve: It took a long time to build. This made iterating costly, both in time and morale. Oftentimes, the build failed (anecdotally, a fresh warm boot of LabVIEW helped) The IDE was painfully slow during development; the cursor continually was "waiting" during wiring operations. The way we solved both problem was simply by taking a pair of "scissors" and snipping links between nodes. The types of links that we snipped were these incidental links introduced by packaging and namespacing facilities in LabVIEW: removing LVLIBs altogether removing VIs from LLBs calling concrete instances of polymorphic VIs rather than the parent removing public type definitions and utility VIs from LVCLASSes Within a couple days, we went from "kick off a build and go grab lunch" to "kick it off and get a coffee". The application and application framework had not changed to see these improvements; just the logical and physical packaging of dependencies. (In addition to solving the main performance pain points, additional areas for architectural consideration are easily visualized; that's beyond the scope of this conversation) Without LVLIBs, how do I avoid name collisions? I prefer this filenaming convention: Project-Class-Method.vi or Application-Class-Resource-Action.vi ... or generally, LeastSpecificNamespace-...-SpecificThing-...-VerbActingOnASpecificThing.vi For instance, Deploy-UpdateService-CheckForUpdates.vi or FTW-JSON-Deserialize.xnode. The name of the owning class just drops the -Method postfix. Is it ideal? It's neither terrible nor great. Some benefits are that filenames sort nicely, and it's easy to spot anomalous linkages. Semantic naming makes it easier for development tools outside the IDE (SCC client and provider, build toolchains). One downside is that your hand is forced on naming Dynamic Dispatch methods in classes (again, I desire to see this coupling separated by a degree of indirection in future LabVIEW versions). Conclusion? This area of LabVIEW does not have a general solution or general best practice. Be aware of tradeoffs of different strategies, and ensure they map successfully to your application space, stakeholder's needs, and team's sanity. Standing offer: Send me a message if you feel some of the scaling pain points: busy cursor while wiring build times lasting longer than 10min mass compile times lasting longer than 10min LVProj takes longer than 1min to load and within 2hrs of screensharing I reckon we could substantially improve your LV dev experience. I'm interested to further build tribal knowledge and provide feedback to NI on taking LabVIEW applications and teams to scale.

OK, I finally finished a version of a document I have been promising to write. We put it on our site: OOMessagingCommandPatternStatePattern. In it we present examples of the following in LabVIEW: messaging with LabVIEW objects Command Pattern (with XML configuration files application example) State Pattern Hopefully the examples will be helpful to some readers, and promote further discussion on scalable application architectures.

During my time at NI Week I decided to bring my video camera and record the presentations, Tech Theater and LAVA BBQ. Please see this link for Video downloads The IT department of my company was also kind enough to setup a ftp server so I could share them with the community It took a while to figure out how to compress the 5GB HD .mts files to a more distributable avi format but with the help of crelf I finally got them compressed and uploaded to the ftp sites. Vi Engineering and Distek Integration have also volunteered their ftp servers to help distribute the videos Thank you Chris and Ed for your help. The avi files can be downloaded from one of the 3 ftp sites they range in size from 150 to 300MB. I would strongly recomend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple viedos the ftp client makes things much easier. To download videos from Distek they are requiring you to use an ftp client. My ftp client of choise is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found here The video files are .avi and have been compressed using DivX If you player isn't able to play the videos you will need to install the free DivX codec found at http://www.divx.com/...plus/codec-pack to access the videos via Use this log in information ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Use this log in information ftp://tahoe.viengineering.net login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Username: NIWeek2012 Password: f7aPadl6 Please Note: You will not be able to access the FTP through a web browser! You MUST use an FTP Software Client to access the FTP. To access the ftp.distek.com please use your FTP software client: Client FTPS settings Hostname: ftp.distek.com Port: 990 Client Settings for SFTP using ssh ftp.distek.com Port 22 if you are using Filezilla your site manager window will look like this. If you have any issues downloading the videos or you are unable to view them please post to this topic. Enjoy, and hopfully the videos will help you learn something new about LabVIEW Mark

The NIWeek 2013 Videos are compressed and ready for down load from Tecnova's ftp server All of the videos are files and are around 400 to 450 MB for an hour presentation. I would strongly recomend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple viedos the ftp client makes things much easier. My ftp client of choise is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found here Thanks to my IT department at Tecnova for giving me the space. V I Engineering has also volunteered the ftp server to help distribute the videos. Thank you Chris for your help. Use this log in information ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Use this log in information ftp://tahoe.viengineering.net/LabVIEW_Videos login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. I compressed and uploaded these videos in a rush and didn't have time to look through them all so if you find issues please post to this thread. Please enjoy and share the videos with anyone you can. Mark

How about adding a captcha to the "create lavag account" that shows a LV BD and asks a CLAD-type question?

I've decided to try a new improvement on the LAVA reputation system. You can still give positive reputation points to individual posts. This has not changed, however now It is called a "Like" and your name shows below the post to indicate you like it. I think this is a better way to show support and encouragement to a user's post and increases networking between community members. I "like" it!

Name: lvODE Submitter: vugie Submitted: 03 Nov 2010 File Updated: 02 Mar 2011 Category: General LabVIEW Version: 2009 License Type: Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Author: Wojciech Golebiowski (vugie), w_golebiowski at tlen dot pl Name: lvODE Type: Library LabVIEW Version: 2009 Description lvODE is a set wrappers, an interface to ODE (Open Dynamics Engine) library written in C and used to simulate dynamics of rigid body systems, including interactivity and in real time. In the present state lvODE allows you to use almost the full functionality of ODE in the LabVIEW environment using object-oriented programming (LVOOP). Such simulations may be used, among others, for programming the control systems of robots and manipulators (as well as in the control systems themselves, i.e. for trajectory planning), for development and testing of artificial intelligence systems, for modeling of complex mechanisms and other physical systems, etc. lvODE is not a strict set of ODE wrappers. Although it uses the same concepts, the same terminology and most of the ODE functions are reflected, many of them have been grouped, data structures have been simplified, all in a user-friendly manner and taking into account specifics of LabVIEW environment. There are also few features not present in the original library which greatly facilitate programming – i.e. Object Manager. Further extensions (i.e. 3D Picture Control integration) are planned. Short preview movie: Briefly about the ODE ODE is a free and widely-known library designed to simulate systems of rigid bodies. The programmer defines the layout of bodies, their physical parameters and types of connections between them, the role of the library is to calculate the forces acting in the system and to determine position and velocity of all bodies in the next time step, while satisfying all defined relationships. Programmer is able to interfere in simulation in full range while it goes on. It allows for the accurate analysis of its results (access to all the physical parameters) as well as programming any degree of interactivity. ODE is designed specifically to perform real time simulations – it uses a first order integrator (the procedure to solve a system of differential equations), which is a compromise between speed and accuracy. Results generated are not as accurate as they would be using higher-order integrators, but it is stable, fast and flexible. The basic features of ODE include: Rigid body with arbitrary mass distribution Types of kinematic pairs (joints, constraints): ball, slider, hinge, suspension, universal (Cardan), linear and rotary actuators, contact, and combinations that are already listed Types of geometry used for collision detection: sphere, cube, cylinder, capsule, plane, ray, any shape in the form of triangle mesh, convex, heightfield Three types of spaces for fast collision finding Equations of motion derived using Lagrange multipliers Choice of integration method: the "full" method – slower, but more accurate, and quick iterative method An advanced model of contact and friction Installation The contents of the archive folder ("lvODE") should be extracted to directory \user.lib. After restarting LabVIEW the sub-palette "lvODE" appears in the User Libraries section, where all the necessary functions may be found. Or use the VIPM package. Documentation The documentation is located in the subdirectory 'doc' and it consists of the following files: ODE Manual.pdf - The original guide to the ODE. At least brief knowledge of it is necessary to understand the main concepts and mechanisms of library. Due to the use of the same terminology, it can also be a sufficient source to use the lvODE. The main difference from the original is the simplified naming convention. lvODE Class Hierarchy.pdf - graphical representation of a lvODE class hierarchy of classes library - not necessary to start programming, but it may help to understand certain concepts. lvODE Function Reference.pdf - a list of all public lvODE functions with descriptions and organized by class. Descriptions of the functions derive much of the original ODE manual, however, cover all the differences of the conventions and LabVIEW specifics. This document is definitely to be polished (better grouping, more detailed descriptions of each section, etc.) Files *. png - map of all pallets An integral part of the documentation are also descriptions in of context help for each VI. In large part they fit the descriptions in the file "lvODE Function Reference". Private functions are documented as well. Examples Example applications are located in "examples" subdirectory. There are few examples with varying degree of complexity, and with comprehensive comments in the code. These examples, supported by context help and (in difficult cases), reading a few chapters of the original manual should be sufficient to start programming in lvODE. Comments lvODE is not a finished project. Once the ODE itself is still being developed, second, not whole its functionality is currently implemented in lvODE. The major differences include: no support for trimesh, heighfield and convex geometries, the lack of a 2D Plane constraint, lack of gyroscopic mode for the bodies, single precision floating point numbers only. Few words about licensing. I publish lvODE under such a restrictive license (see below), because this is still experimental phase. I’ll appreciate any feedback which could help to make this library better and more stable. My further plans are to provide less restrictive free version and full-featured commercial one. Please contact me if you are interested. Comments on this approach are also appreciated. Version History v0.1.0: Initial release of the code. 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 "lvODE" support page. License This work is published under the Creative Commons BY-NC-ND license (description and text of the license here and in license.txt) ODE library is distributed under BSD license (www.ode.org) Copyright © 2010, Wojciech Golebiowski Click here to download this file

I normally don't post on LAVA, but lately I have been experimenting with the WebSocket protocol, ecmascript, and the SVG DOM for creating animated browser displays with data streamed from LabVIEW. The technique is surprisingly simple. All you have to do is create a script to change the attributes of the SVG elements using the Document Object Model. The WebSocket protocol has a built in message event handler that allows you to create your own script function which executes when messages are received. The browser connects to the socket server and sends a handshake when you create the WebSocket object in script. All you need do is put a TCP/IP listerner in your diagram and return this handshake as described in the wikipedia article on WebSockets. Once the connection is made, you can stream bidirectional data between your LabVIEW application and any bleeding edge browser (Firefox 4, Chrome 9, Safari, IE9?). You can use the DOM to set the transform attributes of SVG elements using the streamed info (rotate, scale, set heigh, width, line points, etc.). Now that we can all design our own GUI objects using Inkscape (free), I suggest a concerted effor to develop a standard SVG format, streaming protocol (based on WebSockets) and open-source script library. The very best thing about this is that it is all FREE, and runs on any platform that has an HTML5/SVG/WebSockets supporting browser (I'm keeping my fingers crossed for the next firmware revision of the Nintendo DSi), and requires NO PLUGINS. So all you folks with iOS and Android who feel left out by the WebUI Builder, or those of us who are infurated by it's $1500/yr price tag (after spending $ on LabVIEW RT/FPGA), Cheer Up! Here are some screenshots of my efforts. The files are opened in the OS, but will also work when served by the old-fashioned "non-webservices" LV web server (you gotta add an SVG mime type to the mime-types file). You can also use RGraph Library and the HTML <canvas> tag if you want to implement a non-SVG browser solution. The library is free for non-commercial use. I suggest a community effort the create the standard SVG formats for UI elements, and a free, open-source ecmascript library for handling the messaging and DOM animation tasks. If there is interest, I will upload my script as a starting point, but I must warn that there is much improvement needed. sm

Neil, I've found this procedure to fix this problem, and a host of other issues with source/object code asynchronization: Ensure you have no outstanding changes in your working copy; everything is committed to the repo Ensure for multi-developer teams you effectively have a mutex on the entire repo; you're likely about to make a widespread commit that touches lots of source. It's especially imporatant to have no outstanding changes on .lvclass, .ctl, .xctl, .lvlib, .xnode, or .lvproj files, because these cannot be readily diffed or merged in LabVIEW. (Perhaps a good time to do this is on the weekend, where all team members know to have changes committed before then.) Shut down LabVIEW completely Open all classes in XML Editor (on windows, Notepad++ is good, associating lvclass files as XML in the Style Configurator) Find the <Property> tag for "NI.LVClass.Geneology". Delete this entire tag. This removes any stale mutation history. **Careful here!** The entire tag is likely to span 9 lines. Be sure to delete them all. (I've not yet found or developed a reliable API for this operation; lemme know if one exists.) Find the <Property> tag for "NI.Lib.Version" -- reset this to the value 1.0.0.0 Open LabVIEW to the Getting Started Window; "Tools >> Advanced >> Clear Compiled Object Cache ..." then clear the cache for both User and App Builder Shut down LabVIEW completely Open the project and offending VIs to see if this fixes things. Maybe so, but you're not done yet. If you have not done this yet, ensure every single source file is marked as source-only (e.g., not a unifile). Right-click the root node of the project, "Properties" menu item, "Project" config page Ensure "Separate Compiled Code from new project items" is checked "Mark Existing Items..." button, select all items in the tree, then "Mark Selected Items". Wait for the operation to complete, then close this dialog. Open this dialog once more; visually scan the entire list, ensuring all statuses are "marked" Right click on the root node and "Find Missing Items". Resolve these bad linkages, probably by just deleting them from the project. If you have not done this yet, find all diagram disable structures in your project (this is simple if all VIs are in LVClasses -- since all VIs are in memory -- or with the legacy VI Tree hack). One way or another, ensure all VIs are in memory, find all disable structures, and analyze the disabled cases for links to missing VIs. Do that again for Conditional Disable Structures. Mass compile the project (from right click context menu from root node of project tree) Might as well take the opportunity to fix all the errors that are returned by the mass compile. If you have insanities, search the phrase "labview heap peek insane" for instructions how to fix these. If you can't get the keyboard commands for heap peek to work (e.g., if you're developing in a VM), there exists an undocumented VI Server App method to toggle heap peek visibility. Shut down LabVIEW completely Goto Step 7; rinse and repeat until zero errors are returned Ensure the application still runs from source; e.g., you've not accidentally broken something. If this smoke test passes, commit all changes to your local repo. This is your first checkpoint. Goto Step 7, and follow all steps again back to here. If some source files have been modified (e.g., there exist modifications in your working copy), this means will probably benefit from cross-link and circular-link tips below. Especially, if during the mass compile, you see the dialog repeating what appears to be the exact same operation over, and over, and over, and over, and over, and over, and over, and over ... Try implementing the tips below. Goto Step 7 Goto Step 3, and follow all steps again back to here. You should be able to complete this entire process with zero modifications to the codebase. Commit changes to local repo. Goto Step 3, and follow all steps again back to here. If you're happy, push to central repository. Have all developers/contributors clear their compile object caches. No really; witness that operation. It's vital. Have all developers pull the project. Ensure no corruptions exist; ensure the project can be opened and closed immediately with no "dirty dots". If these dots exist, your environments are somehow different (different versions of LabVIEW?), and should probably be resolved. I've tried to codify this procedure accurately above, but drop a line if it doesn't work or correct it with a response to this thread. Tips for the future to avoid these problems (from extensive at-scale experience with LVOOP spanning LV2009-2013SP1f2+): Refactor to avoid all typedef'd clusters in Class Private Data definitions. If they must exist, ensure that if they ever recompile, all LVClasses linking to the type are also saved to disk, especially if it's just one of those 'recompiles' that we've conditioned ourselves to ignoreOne overlooked place that typedef'd clusters can hide is as sub-types to some native labview objects, such as Queues, Events, etc... Avoid type defining primitive types such as strings/numerics/bools (You:"but..." me: "I know, me too. But it is what it is.") If you are using reference types (e.g., .NET) as elements in your class private data, you may run into unique issues that require other resolutions. One resolution is storing the reference as a flattened type, then creating accessors that cast to/fro the desired type. (Avoid even having elements in your class private data. Statelessness and immutability are desirable anyway for a functional style and synchronous dataflow.) When refactoring and changing the scope of types, ensure that both owning library files (lvclass, lvlib, xnode, xctl) are saved to disk. Else, corruption, sometimes tough to detect immediately, and may not even show up until build-time. Usage of LVOOP property nodes voids the warranty of LabVIEW altogether for applications of non-trivial scale. Don't use them in any version up to the time of writing, 2013SP1f2+ (You:"but..." me: "Good luck with that") Avoid circular linkages between classes. It's not uncommon for the type-propper to give up recursing if too many circular linkages exist, sometimes ending in a "VI failed to compile" error.To analyze these linkages, open classes one-by-one in an empty project. Inspect the "Dependencies". Click on classes/libraries and say "Why is this item in Dependencies?" to highlight the static link. Though, on codebases that have hidden corruption, this feature crashes LabVIEW -- instead, "Find Callers", which is slightly less convenient because it may highlight other Dependencies. To fix the dependency vector, refactor. Strictly avoid nesting of lvclasses within lvlibs; consider avoiding lvlibs altogether. The problems they can cause (edit/build/load/run-time performance, accidental corruption) are typically not worth the benefits (scoping/namespacing, common icon, LVProj loading members for API convenience...) (This is one key offender for the "endless" loops while mass compiling, and can drastically degrade edit/build/load/run-time performance.) Avoid polymorphic VIs; these "convenience" wrappers are just overloaded functions that carry static linkages to stuff you don't need to be linked to. (This is one key offender for the "endless" loops while mass compiling.) XNodes are a better alternative, but quite tricky to develop. The moment you or a developer colleague says to the other "i'm not seeing that in my environment", clear both your compiled object caches and re-start whatever you were first talking about. (Mass compiling is not sufficient, since the cache is not always invalidated when it should be, but this has gotten steadily better from 2009-2013) To sum up; avoid static linkages, and ensure dependency vectors between all code modules are unidirectional and don't form cycles. For multi-developer teams and/or codebases of non-trivial size; may the force be with you. And may you have an experienced colleague or consultant periodically auditing and transparently fixing the codebase to keep all productive and healthy and happy. Open offer: if you've ended up on this thread at your wit's end, send me a message and let's screenshare and fix it.

That was only the start... Attached what it was created with. No description, no comments, no even icons - I warned you. wired-wires.zip

Please see the above link to download the videos The NIWeek 2014 Videos are compressed and ready for down load from Tecnova's ftp server I would strongly recommend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple videos the ftp client makes things much easier. My ftp client of choice is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. A big thank you to Dan Bosdech for recording the sessions on Thursday as I was attending a private all day session. Enjoy and let me know if there are any issues. Mark

I don't think it takes too long after deciding to do an actor based project to run into the case where you have an actor spun off without a way to kill it. You'll figure that out and get your solution working so you can pass it off to someone else and forget about it. Soon after, that someone else will come to you and say something like "yeah, those actors are cool and all, but they're really hard to debug" I ran into some of these problems a while ago, so I decided to write a little tool to help with it. I decided to call it a monitored actor. Here were my design criteria: I want a visual representation of when a monitored actor is spun up, and when it is shut down. From the visual representation, I want to be able to: stop actor, open their actor cores, and see if they're answering messages The visual representation should give you an idea of nested actor relationships. Implementing a monitored actor should be identical to implementing a regular actor. (meaning no must overrides or special knowledge) Monitored actors behave identically to Actors in the runtime environment. It turns out that you can pretty much accomplish this by creating a child actor class, which I've called Monitored Actor. A monitored actor's Pre-launch Init will try to make sure that the actor monitor window is made aware of the spawned actor, and Stop core will notify it that the actor is now dead. The actor monitor window contains ways to message the actors and pop up their cores and such. I think it's fairly obvious what each button does except pinging. Pinging will send a message to the actor and time how long it takes to get a response. This can be used to see if your actor is locked up. The time it takes to respond will be shown in the ping status column. if you want to periodically ping all the actors, set the "poll Frequency" to something greater than 10ms. This will spawn a process that just sends ping messages every X ms. Where I didn't quite meet my criteria: If you were to spawn a new actor and Immediately (in pre-launch init) spam it with High priority messages, the Actor monitor window will not know about the spawned actor until it's worked through all the High priority messages that got their first. You probably shouldn't be doing this anyways, so don't. Download it. Drop the LVLIB into your project. Change your actor's inheritance hierarchy to inherit from monitored actor instead of actor. You shouldn't have to change any of your actor's code. The monitored window will pop up when an actor is launched, and kill it's self when all actors are dead. Final note: This was something I put together for my teams use. It's been working well and fairly bug free for the past few months. It wasn't something I planned on widely distributing. A co-worker went to NI week though and he said that in every presentation where actors were mentioned, someone brought up something about they being hard to debug or hard to get into the actual running actor core instance. So I decided to post this tool here to get some feedback. Maybe find some bugs, and get a nice tool to help spread the actor gospel. Let me know what you think. Monitored Actor.zip

Everybody knows the problem: We need custom VIs to compare floating point values using a tolerance. I just discovered something via scripting: The Floating Point Equal? primitive which does exactly that. Can anyone imagine why it is missing from the standard palette? It's in LV since version 8.0 ... FloatingPointEqual_LV80.vi

I came here looking to see what the G experts have done wrt timing probes and found this discussion of High Resolution Relative Seconds.vi (HRRS). I am the person responsible for putting this VI in vi.lib/Utility. It calls back into a utility function I put into LV, which uses the same API that is used by the Desktop Execution Trace Toolkit. I intended it to use the highest resolution clock available on all of LabVIEW's supported platforms. On Windows this means QueryPerformanceCounter, which, in modern versions of Windows, takes into account multi-core/processor issues as well as variations in clock rate due to power management. (Up to date and authoritative docs on this are hard to find, but from the googling I've done, I believe my claim is correct.) This I discuss some of the behavior of HRRS at this site at ni.com: https://decibel.ni.com/content/blogs/EvanP/2010/10/04/tick-count-us--microsecond-timing-granularity-on-windows (I notice some of the picture links are busted there - I'll try to fix them.) As some of you noted, the Wait (ms) primitive is the inaccurate/inconsistent culprit in the Mr. Balla's benchmark. It uses a less accurate clock API, but one that uses the same clock as the "Get Date/Time in Seconds" and "Tick Count (ms)" primitives. Rob Dye LabVIEW R&D

Well references and error wires could default to shift register terminals when wired into the loop? Much like arrays default to auto-indexing. This would also be useful for counteracting the auto-indexing of references and errors when exiting the loop.

Well, since this is kind of the "Don't use classes in your CLA exam solution" thread, I figured I'd chime in with my $0.02 CDN now that I've passed... I spent a long time thinking about whether I'd use classes going in to the exam. I received strong advice from a few people not to, but also bought into Steven's statements above about his experience. In the end, I decided to go with classes for 2 reasons: Firstly, because I'm now way more comfortable using them than not using them (and I hate the sample exam solution's use of "action engine"-type VIs, with tons of non-required inputs), and secondly on principle - Architects should use classes, and if the examination mechanism can't handle that then it needs to be challenged. My use of classes was quite straightforward, and seemed obvious (to me at least). All of my VIs and controls belonged to a class except my top level VI. The only issues the markers took with my architecture were to note the areas where it wasn't complete or properly documented, which was completely fair (since it wasn't - I ran out of time). I'd say my biggest mistake was getting sucked into too much "implementation", at the expense of completing the architecture. I am certainly grateful for this thread though, since it raised the level of discourse about this issue before I wrote my exam, and Zaki spent a lot of time addressing this in the exam prep session I attended. I would say, however, that using classes probably takes more time. There's a lot of "background" work to creating a good class hierarchy, with icons, documentation, data member access VIs, access scope, etc. If you're confident in your ability to create a non-OOP solution, you might consider this. Time was a huge factor for me, and four hours of hard-core, non-stop LabVIEWery is exhausting. And here's a tip I struck upon the night before my exam: Create a quick-drop plugin to prompt you for a requirement ID and automatically create a "[Covers: XX]" free label. This only took me about a minute (I memorized the steps before the exam), and probably saved me 20. Make sure you turn on scripting in Tools-Options, then copy "C:\Program Files\National Instruments\LabVIEW 2010\resource\dialog\QuickDrop\QuickDrop Plugin Template.vi" into the "plugins" folder, rename it, and edit it to create a Text decoration with the appropriate text. You can even use the "Prompt User for Input" Express VI . Then assign an unused key (hit Ctrl-Space, click on "Shortcuts...", then the "Ctrl-Key Shortcuts" tab, and your VI should show up in the list). For me, adding a "Covers:" free label was only a few key-clicks. Jaegen

In my experience the terms "reference" and "pointer" are often used interchangably. How are you differentiating the terms? They both essentially do the same thing--they refer to a location in memory that contains either the data of interest or the next memory location in the chain. Having parallel wires refer to the same piece of memory is done all the time with refnums, be it named queues, events, fp controls, etc, so it's obviously possible. Branching a DVR results in two parallel wires referring to the same piece of memory. Is this a limitation of dataflow languages in general or specific to Labview's implementation. Obviously there are still aspects of dataflow I don't fully understand. Data on the parallel by-value wire has to exist somewhere in memory. It don't get why a pointer to that memory location would not be meaningful. It would violate the principle of data flow, but there are lots of things within Labview that do that already. --------- Many Hours Later ----------- I had to look at this for a long time. When I first read it I envisioned all sorts of weird schemes under the hood that used the upstream prim to modify a value after it has been sent downstream. Here's a summary of the conversation I had with your alter-ego, Evil AQ (pronounced "evil-ack"), in my head. Evil AQ explained a lot of things to me, but I question his accuracy... you know, what with him being a figment of my imagination and all. (Note: My conversations with Evil AQ tend to be rather caustic.) Me: "Huh? The prim that created the value is what actually performs operations on the value downstream? That implies that rather than the data being passed around between prims, the data remains with the orignating prim and downstream prims are passed to it. How... odd. That seems kind of like functional programming. I thought you used C++ under the hood." Evil AQ: "No you dolt. That wasn't a comment about perpetually persistent primitives. Look, when have you ever seen a value on a wire change? Me: "I see it all the time. Wire an integer through an increment function inside a while loop. The value on the wire changes with each iteration." EAQ: "Let me rephrase... when have you ever seen a value on a wire change without that section of code executing again? Me: "Well, the value on the wire has changed after going through the increment node." EAQ: "Uh uh. That's a different wire. Another rephrase... when have you ever seen a value on any single wire, defined as all branches starting at the source terminal and ending at each destination terminal, change without that section of code executing again? Me: "Never. Duh." EAQ: "It's good to know you're not a complete maroon. This would be tougher to explain if I were restricted to finger paints and monosyllabic words." Me: "Monobillasic... monosymbolic... monosy... what?" EAQ: "Never mind. What would happen if you had a raw pointer to a value on a wire?" Me: "I could have Interfaces!" EAQ: "Slow down there Flash. Think about this for a minute. What would happen to the value on the wire?" Me: "Ohhhh... it would change." EAQ: "Very good. You pumping a full 100 Watts through that brain or is your dimmer switch turned up a little too high?" Me: "What about control refnums? They change values." EAQ: "There's a reason they're called 'control' refnums. They refer to controls, not wires. Control values can change. Wire values cannot." Me: "Oh. Right. Well queues can change the values of items that exist somewhere in memory. What about them?" EAQ: "Yes, but they are changing the value of an item the queue refnum refers to. They are not changing the value of the queue refnum itself, which is what actually exists on the wire." Me: "I see. But in reality by-val wires don't contain the data itself, do they? If they did memory allocations would take place at the moment the wire branches and I've know that's not right." EAQ: "Correct, wires do not contain the actual data." Me: "It actually refers to data that resides elsewhere in memory, right?" EAQ: "Sort of correct. Wires don't refer to a piece of data so much as they refer to a specific terminal on VIs and primitives. A terminal** is essentially something that can define the values of a piece of data, such as a control, indicator, constant, etc. and includes input and output terminals to prims." (**Evil AQ didn't know the correct terminology for this so he used the word 'terminal.' Luckily I knew what he meant.) Me: "So shouldn't it be possible to create a refnum that simply refers to the same memory location that a wire does? Ha!" EAQ: "Well yes, but it won't work in the way you're thinking. Try looking at it this way... by val data exists only in terminals. Wires are simply a graphical representation of how the terminals are mapped to each other. Ostensibly every time data "flows" across a wire a data copy is made and placed in the memory location that represents the destination terminal. While in principle you could have a refnum that refers to the same data the wire 'refers' to, effectively it would be just like a value property node for one of the terminals. (It doesn't matter which one, since they all contain the same data values.) That scheme would consume LOTS of memory, so the Labview compiler is smart enough reuse memory when it can. For example, since all the terminals a wire connects to must contain the same data values after executing, the memory locations that are represented by the terminals are actually pointers that refer to a single piece of data. Sometimes the memory location of that data can be reused by other terminals further downstream. Sometimes it can't. Ironically, obtaining a reference to that memory location is one way to guarantee it can not be reused." Me: "Really?" EAQ: "Well yeah. You're referencing the value in the terminal, which doesn't change until that section of code executes again. If downstream operations change the value a new copy must be made to avoid corrupting the old copy, which you have a reference to." Me: "I get it now. Thanks Evil AQ. You're the greatest." EAQ: "You sound like my mother. Now beat it punk, I'm trying to sleep." So did Evil AQ do a decent job of explaining things to me?

Hi everyone A couple of weeks ago i had the need to put a small suite of applications i made in the tray area, but the VIs i could find to do this wasn't really very intuitive or was lacking the functions i needed. The solution? Another one of these put-your-LabVIEW-app-in-the-tray toolsets .. but this time, a little better wrapped than the example code you can find on NI's site.. ;-) (no offense) So here it is for you to evaluate .. it's not anything near final, and one can always find a number of small features lacking, but hey..it's event based, and its pretty easy to add more events if ever needed :-) Notes: Code is currently for LV8.6 and requires at least .NET Runtime 2.0, but i know for a fact that it runs on Win7 and LV2010.. Installation: Unpack / Extract contained "Notify Icon" folder into your user.lib and refresh palettes or restart LabVIEW.. Examples: Browse into your user.lib -> Notify Icon palette and drag the "NotifyIcon Class Example" VI to your block diagram (or open it by browsing into the "user.lib\Notify Icon\Example" folder) License: Since i made this code in my sparetime, but planned to be using it at work, i've made arrangements with the grand-old-boss and put a BSD License on it.. Feel free to send me any comments / questions AND bugfixes / error-reports Thanks Stinus Well..since FF4 doesn't want to play nice.. here is the code uploaded using good old IE :-/ Notify Icon.zip

Hi guys; Check out what we are doing with LabVIEW and Arduinos. http://www.tsxperts.com/arduino-compiler-for-labview/ We created an actual LabVIEW compiler for Arduino targets that allows Arduinos to be programmed in LabVIEW. Figured to share this with the community. Cheers Filipe

The topic came up here that LabVIEW should have a way to open VIs from disk without bringing up file dialogs for every missing subVI. The idea on the Idea Exchange is still a good idea, so go give it kudos. But, in the meantime, here's my gift to you for today... The attached "Open VI Without File Dialogs For Missing VIs.vi" will, given a path to a VI, open the FP of that VI. If there are any missing subVIs, those subVIs will be searched for on disk (unless you disable search in Tools>>Options), but if they are not found, no file dialog will appear to prompt you for where to find them. The diagram of this VI is password protected -- even though Scripting is now released, I put this together using features that are private. The VI is saved in LV 8.0... I tested it in LV 8.5 and 8.6, but I think it works all the way back. Open VI Without File Dialogs For Missing VIs.vi

I have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others. We have published a PDF version of the paper: StrategyPatternWithLabVIEW and a zip file that also includes the source and model: StrategyPatternWithLabVIEW--WithModelAndSource. You can comment on the paper here, if you like. Paul

When designing block diagrams, I tend to spend way too much time making sure things are aligned perfectly, down to the pixels. It's really annoying. This is most noticeable with bends in wires. I don't like having "uneven" bends, or bends where they aren't necessarily needed, or wires that cross unnecessarily. For instance: Now you might wonder why I have bends there if I can just move the wires so they look straight. Well then they won't be perfectly aligned with the node's terminal. For instance: Of course, when there are bends, I want them to be even. For instance, these are the steps I might take to "fix" this sequence of property nodes (that I wouldn't likely put together in practice to my knowledge): Does anyone else have issues with trivial things like this? I find myself using the arrow keys a LOT on the block diagram to fix these kinds of things. Am I alone in that?

I just upgraded the LAVA server, so the response should be even better than the already pretty fast previous server. Enjoy.

National Instruments has created a GitHub repository to community source G libraries. This move is intended to be a test of a mechanism to enable customers to create customizations of NI source code and share those customizations with each other and for NI to be able to adopt some of those customizations into its core products to benefit the entire LabVIEW community. We are beginning with just three libraries: The Actor Framework, a library in vi.lib since LV 2012 The NI-GOOP Development Suite, a free toolkit add-on for improving LabVIEW class development The AQ Character Lineator, a library not yet in vi.lib to support serialization/deserialization of LabVIEW classes If this experience working with the community proves fruitful, NI may expand the number of our APIs that are part of this sharing. For more information, including instructions on how to access the GitHub repository, please visit this community: https://decibel.ni.com/content/groups/community-source-of-ni-code For details of how to get access to the GitHub repository and the license agreement covering this project, please visit here: https://decibel.ni.com/content/docs/DOC-37195 I want to make a personal comment on this new development: Opening up LabVIEW to more community participation is something I and a few others have worked on for many years. This is a major advance in that quest. We know that requiring a license agreement for participation is not a typical "open source" arrangement, but this is the best idea we have found to balance the desire of our users to improve LabVIEW while acknowledging that LabVIEW is for-profit software that gets used in sensitive industries. If you have particular objections to the license agreement, please open a discussion thread in the community linked above so we can discuss them. We believe most users will find this arrangement acceptable, but not everyone. I hope, though, that this can be a successful venture, and perhaps will serve as a first step toward more.

I'm going to learn LabVIEW. So I can come to NIWeek with you.

So, I am here in France for the Euro CLA Summit. Took a side trip out to The Palace at Versailles today. I saw a sign that made me smile. In bold letters: "RESPECT THE QUEUE!" :-)

That's the one! Of course the VI just makes a call to a bunch of system DLLs, so I don't think it would work on Linux/Mac/Etc. Ultimately you're really not gaining anything over .NET other than you don't need to deal with it directly. The snippet above probably doesn't require the file/directory info primitive, but I've always used it as such and not found with any trouble. I'd love to play with some scripting or use j's code to have version info in the IDE, but that's so low on the priority list since ultimately the application is always distributed in built form.

Here are the VIs we use for Windows authentication and domain groups. Validate Username and Password.vi takes the username and password and returns a TRUE if it validates against the domain controller. User in Group.vi takes a username (or current user if left blank) and a Domain Group name and returns TRUE if the user is a member. User Groups.vi takes a username (or current user if left blank) and returns an array of Domain Groups to which the user belongs. We only use these on our internal network, so I can't guarantee they work in every situation. Still, they may give you a starting point if you need something similar. Pat P.S. LabVIEW 2010sp1 User Groups.vi User in Group.vi Validate Username and Password.vi

Wow, guys, make drjdpowell feel bad, why don't you?

Here is my favorite mathmatical identity: I now have a second favorite: What has been seen can't be unseen...

Meh, I hate LabVIEW as well. C/C++/C# too. Also hate PHP, VB, Perl and most every other language I've used. Hate databases too! While we're at it CSV files suck as well. Point is while I have reasons for disliking all of the above, I also have as many reasons to like each of them as well. Each has their place. LabVIEW, like any other language, has its strengths and weaknesses. I find myself paying little attention to the text-based zealots who refuse to acknowledge there might be another way of going about doing things, and similarly I don't pay attention to the all-out LabVIEW supporters who refused to acknowledge its limitations and weaknesses.

I had the same weird thing with the dialog disappearing - my solution was to throw together this little VI to recursively set the property on all VIs in a folder - it's a little quick and dirty but does the trick Mark as Source Only.vi

Daklu, the style of my writing below is fairly terse and occassionally EMPHATIC. I've done this to emphasize key points that I think you've missed in How Things Work. Some customers in the past have felt I'm insulting them writing this way, but it is the only way I know through the limited text medium to highlight the key points. My only other option is to post just the key bits and leave out a lot of the exposition, but that doesn't seem to be as helpful when communicating. So, please, don't think I'm calling you dumb or being disdainful. I'm trying to teach. The problem is that you're almost right. Customers who are completely off-base are easier to teach because they need the whole lesson. Here, I'm just trying to call out key points, but presenting them in their full context to make sure it's clear what fits where. Throughout the post, refer to the graphic at the end of the post as it may clarify what I'm talking about. Dalku wrote: No. If there is, that's a bug that needs to be reported to NI ASAP. Think about what you just asked for... ignore the DVR part for a moment. You just asked for a PARENT object to invoke a CHILD class method. That cannot ever happen. You cannot pass a parent object directly to a function that takes a child object. The parent object in question IS NOT a child -- the parent object does not have the child's private data, nor does it have all the methods that may have been defined on the child class. For this reason, LV will break the wire if you try to wire a parent wire to a child terminal -- the wire is broken because there are zero situations in which this can successfully execute. You CAN pass a child object to a parent terminal. That is because a child IS an instance of the parent -- it has all the necessary data and methods defined to act as a parent object. What you can do is take a child wire, up cast it to a parent wire and make a Parent DVR out of that. Alternatively, you could take a child wire, make a Child DVR wire, and then upcast that to a Parent DVR wire... these two processes produce the idenitical result: a parent DVR that contains child data. Upcast and downcast DO NOT create new objects EXCEPT when they return an error. The point of a cast is to say, "I have an existing object. Please check that it is this type and approve it to go downstream if it passes this test." You use this only when you need to do something for a specific type of object and you do not have the ability to edit the parent and child classes in order to add the appropriate dynamic dispatch VIs to both. Preserve Run-time Class (PRTC) is the same thing. "Allow this object to pass downstream if it passes this test, otherwise create a new object that does pass the test." The test in this case is "Does the object in have the same TYPE AT RUN TIME as the OBJECT (not the wire) on the target object input?" If the left object is the same or a child class of the center object then there is no error. You will ALMOST NEVER WIRE PRTC WITH A CONSTANT FOR THE CENTER TERMINAL. I would say "never" because I can't think of any useful cases, but maybe someone has something out there. If you are wiring the center terminal of PRTC with a constant, something is wrong in your code. You use the PRTC to assert that the left object, which comes from some mystical source, is the right type to fulfill run-time type requirements of dynamic dispatch VIs, automatic downcast static VIs, and the Lock/Unlock of Data Value References. In all three of these cases, there is some input (either the input FPTerm or the left side of the Inplace Elt Struct) that must be passed across to the output (either the output FPTerm or the right side of the Inplace Elt Struct) WITHOUT PASSING THROUGH ANY FUNCTION THAT CHANGES THE OBJECT'S TYPE. You're free to change the object's value, but not its type. Sometimes you pass the object to functions where LV cannot prove that the type is maintained. Easy example -- pass the object into a Global VI and then read the Global VI. You'd never do this, of course, but it demonstrates the problem. LV cannot know that the object you read from the global is the same object you wrote in -- some other VI elsewhere might have written to the global in parallel. But you, as the programmer, know that there are no other writes to the global VI, so you use the PRTC to assert "this is going to be the right object type." You wire the original input (as described above) to the center terminal, and the output of the global to the left terminal, and pass the result to the original output terminal (as described above). Does that make sense?

At the (fantastically awesome) LAVA/OpenG BBQ, someone (apologies to whoever it was, I forget who - sometimes I think I'm the Dory character from Finding Nemo) asked about getting more recent projects in the GSW. Stephen Mercer / Aristos Queue had provided modified versions of the VIs to do this in 8.6. I added a config token for this in LV2009, so you no longer need the modified VIs. It's MaxGSWRecentProjects=10 (or whatever other number you want. We never display more than 10 recent files, though). - Christina, aka "Miss Eyes on VIs," LabVIEW R&D

I've managed this. It deleted 100 files in only a few seconds (and put them in the Recycle Bin).

I would like to offer my SHA-1, SHA-2 HMAC and AES files to OpenG to add to the MD5 library (I suppose we need to rename that palette). You can find these functions currently in the LAVA Code Repository. The code is currently in 2010, but I can backsave to 2009. Ton

The hallmark of an experienced LabVIEW developer is the usage of their or others templates which prevent the ubiquitous blank block diagram symptom where time is wasted doing the same thing that they have done before. Attached and linked you will find the TLB` (prime) template which, after a little learning what the parts are, can take you from zero to 60 in no time the next time you need to create a Top-Level application or interface. This template can be used from the ultra simple UI to a fairly complex application. Many questions and comments have been made about the original design (TLB) which is located here http://lavag.org/topic/14164-discuss-tlb-top-level-baseline/ This reason for the update in this design is detailed in the presentation "Rebirth of the LabVIEW State Machine" which is accessible here http://lavag.org/topic/16091-ni-week-2012-videos/page__view__findpost__p__97844 Installing and Creating http://screencast.com/t/vtlFgLhQqT Review of Examples http://screencast.com/t/XLIN0yjS Structure of Code http://screencast.com/t/5RtMhPVujS Basic Flow of Operational Code http://screencast.com/t/1QGFRRuSf0nT Adding a control to the system http://screencast.com/t/IJTxEQ28 Adding an action to the system http://screencast.com/t/5984lGlMjM <More to come soon> QSM Evolution.zip Code used in presentation video detailing why the typical QMH is fraught with issues that we have all run into Credit to Daklu for it's creation and sharing ni_tool_tlb`-1.2.0.23.vip Most up to date version of TLB` Rebirth of the LabVIEW State Machine.pptx TLB` Application Template.vipc

Ok. first off. Windows is not a real time OS so it isn't deterministic. I know that, you know that but your project manager probably doesn't so that was for him. Second. I bet you are so close, that if we can just optimise what we already have a little better, we will be home and dry. Sure. Then in 6 months the spec changes to every 7 ms and the project manager says "you did it before, now do it again - it's only 1ms". So. What is the problem? Ahh. Just poking over the 8 ms in places. Lets see if its what all the girls say that size does matter and bigger is better. Ah yes. No problem with under 8ms. The girls are half wrong and half right. Size does matter but smaller is better. (In fact it is linear. 400,000 will yeild about 3 ms, 200,000 about 1.5 ms etc). Easy answer 1. Reduce the data size in the global. But why so slow? Is it the array disassembling? Is it the reading from the global? Does it need more coffee? Oooh. Microseconds. My spidy sense tells me its the global. Easy answer 2: Don't use a global for big arrays if you're time constrained. That about wraps it up for reading. In the next issue we will cover: Oh my god. It all falls to crap when I write data.

I'm rather fond of applying behaviours en masse via callbacks. Ctrl CB.zip

There are easier ways...

I took my CLD at NI Week and just got my results. I passed with a 96%. 15 on Style, 13.5 on Functionality, and 10 on Documentation. I'm quite pleased. I just wanted to say thanks for the great discussions here; they have certainly helped me along the way. -Chris

Wikipedia and many other websites are unavailable today to protest and to educate about the dangers of two bills now being considered by the US Congress: PIPA and SOPA. The Stop Online Piracy Act and the PROTECT IP Act both aim to reduce violations of copyright online. The problem is they do this by attacking First Amendment rights, removing judicial safeguards and placing huge amounts of power in the hands of copyright holders. The net effect of this would be to make it nearly impossible to run sites that allow user-posted content, such as LAVA. Under these bills, the volunteers who run LAVA would have to vet every post, check every VI uploaded, and somehow prove to their own satisfaction that the code posted really is clear of any copyright problems *before* they allowed other users to see the post. Why? Because the LAVA site would be legally liable if anyone in the world complained that their IP had been illegally posted, and the whole site, not just the offending post, could be blacklisted, without judicial review. The burden of proof is on LAVA. Even links to other sites would have to be vetted to make sure that they didn't link to a site that did not also have this sort of prior review. So today, I won't be answering any questions on LAVA or ni.com, and I am encouraging others to also not post content online (other than SOPA and PIPA discussions). Let today give the experience of a world as we had it before the World Wide Web made knowledge so easy to share. Let it be a call to action because these bills are not some abstract thing off in Washington DC, but legislation that would have a very real impact on the day-to-day operations of anyone doing tech support or relying on a community for help. The SOPA bill has been, for the moment, withdrawn by its authors, but they promise to bring it up later, presumably when the tech community isn't paying so much attention. PIPA is still being considered in the Senate. And although our current president has said he will not support these bills, there's no telling what the next president might do or whether Congress might override a veto. An excellent write up of these two bills is here, written by the Electronic Freedom Foundation: https://www.eff.org/deeplinks/2012/01/how-pipa-and-sopa-violate-white-house-principles-supporting-free-speech

How about this? It may require more testing to eliminate things like String controls that contain the search text, but that's easy enough (depending on the application).

I had created a task manager a while ago to address precisely these issues. I'm attaching the LabVIEW 2009 code for it. Please feel free to take this as the starting point and expand it further. I'd also love to work on this one more. Currently it: Lists all VIs in memory Displays basic information like VI state, path, data size, code size, FP Behavior, Reentrant? Reentrance Type, etc. Let's you select multiple VIs and open FP or BD Let's you select multiple VIs and Abort let's you select a refresh rate and updates the lsit sort by any column let's you filter file types like vi, vit, and ctl What other functionality would you like to see in it? select application instance? Should this be submitted to the repository or should we keep attaching versions to this discussion? Cheers! LabVIEW Task Manager.zip

Anything that can be undone should not have a dialog, period. Get rid of it altogether. No checkboxes or ini settings.

I've had a few evenings to work on another XNode, this time to unbundle an array of elements from a Cluster Array (as per this Idea). As much as possible, I've tried to mimic the functionality of Unbundle Cluster by Name. There were a few tricky things to get this to work, and I'd be interested if I missed an easy way to achieve any of them: traversing a cluster hierarchy to build the pop-up menu not permitting the XNode to be shrunk past any connected wires correctly wiring outputs again if the XNode is extended upwards Comments welcome! Requires: LabVIEW >8.6.1 Gavin Burnell's Scripting Tools (thanks again!) OpenG LabVIEW Data and String Libraries Unbundle Cluster Array.zip

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG 4.0 release is now available for download. OpenG 4.0 is a synchronised release of all packages that form the OpenG Library: The release includes the following features: Fix to all outstanding bugs (at design time). Package sources upgraded to, and tested in, LabVIEW 2009. Packages now built using VIPM 2010. I will be posting more about this release in the near future. On behalf of Jim Kring and OpenG.org, thank you. Jonathon Green OpenG Developer Installation Open up VIPM 2010 and if not configured to do so press Check All Package Repositories for Available Packages, then choose one of the two options below: Install the OpenG Toolkit package - this package will configure your system to install all the latest packages as well as remove any non-Library packages no longer required (don’t worry it won’t remove any VIs you are using). This is recommended for new or basic users. Manual installation - upgrade required packages on a package-per-package basis. Note: OpenG Builder is not part of the OpenG Toolkit and therefore will need to be manually upgraded (if required).

I see there are some new options for "Voting a post up" and giving a star rating to a thread. Each user also has a "reputation" count. How are these things tied together? The reputation appears to be tied to the number of votes a member receives on his/her posts. Does the star rating also contribute to reputation? Gone are the days of making many useless posts to make myself appear useful. -Toby Edit: On a side note...I am able to give a star rating to my own post. That seems odd to me.