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

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

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

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

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

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.

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?

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...

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

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 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

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

I have in the past few months steadily worked on a network library for LabVIEW with following features: - Be as close as possible to the functionality, operation and semantics of the built in LabVIEW library - Support IPv6 operation - Support SSL encryption - Support ping operation right in LabVIEW (through use of raw sockets) - and of course be better than the built in functions The included library does most of these things already but will need some more work over the next few months to fully have all these features. As such it is clearly in a preliminary state and not yet ready for released software. Please be adviced that this library will cease to operate after end of June because I expect to have new releases out there before that time. In spite of the preliminary state it does work and does do already quite a few things and it even implements the LabVIEW TCP read modes exactly as the native functions. I have included an OpenG package of the library. To install it you best use the VIPM application from JKI Software as it will take care to place everything where it should be. Due to some features I'm using it will be necessary to restart LabVIEW after installation of this library in order for the library to work properly. When installed you should see a new ESI-CIT logo in the main function palette and in there a network icon. In that network palette are all the new and exciting functions. The functions have for a large part already some online help information inside, which you can see by opening the floating help and hovering over the icons or front panel control elements. I'm working on an online help file to install along with the library but it is not yet finished. This help will also outline some of the more low level operations which at the moment may appear a bit obscure. This release is only for Windows 32 Bit systems. Sorry to the Linux and Macintosh users but porting such a library is a true pain in the a** and especially for the Macintosh I'm not yet sure how to go about it, as there are several ways to skin that cat The library will work in LabVIEW 7.1 and newer versions. readme.txt citlib_lvNetCon-0.9-1.ogp

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

Dearest LabVIEW, Sometimes there are simply no words that can adequately express the depth of a person's feelings that are plagued by regret, guilt and sadness for a wrong done. I know it can't undo what has been done and it won't ease the pain in your heart. Instead, let me write this to let you know that I regretted my actions, and cheating on you is certainly an unforgivable mistake. I totally deserve any the anger and resentment from you for what I have put you through. I was tempted by text-based programming, and I was weak. Not because the love between us was weak, but because I was coerced by another - let's just call her "the customer". I knew at the time that it was wrong, but she was so purseuasive. She bought me gifts, she told me I was handsome, she laughed at my lame software engineering puns, she made me feel special. I know now that these were all underhanded tricks so that she could have her way with me. She didn't care about me, ahd only cared about herself, and how I could help her. It pains me to see you suffering as a result of my misbehavior. Guilt burns in my heart thinking of all the hurt that you must have felt because of my recklessness. Each time that I think of you, I get angry with myself, my blindness and foolishness, and my indiscretion. I know there is still a strong love for you glowing in my heart. I truly want us to be happy again with me still being a part of your life. I know I don't have the right to ask anything from you when I have foolishly betrayed your trust in me, but I hope you can find it in your heart to forgive me and give me another opportunity to prove to you how much I love you. Give me another chance and I have faith that, one day, we will look back at this and laugh, albeit uncomfortably. Loving you always, crelf

Protohuman instantiation complete! Just cross-posting the birth announcement of our daughter on the NI Breakpoint forum! (Higher res photo at the link above)

One of my UIs has a problem where it can chug down if you throw too much data at it. The underlying problem is formatting I'm applying to a native LabVIEW multicolumn listbox (MCLB). I'm not aware of any way to get events out of the MCLB when an item is scrolled into view, etc, so the application just blindly applies formatting to the entire list. Not a problem when I wrote the application because the data set was at most bounded to perhaps 1000 rows. Being in R&D, we're never happy though and my colleagues who use the application started throwing data sets at it that can have something like 100 000 rows. Yeah, the UI bogs down for minutes at that point, even with UI updates being deferred etc. Simply performing hundreds of thousands of operations on the MCLB even with no UI updates takes patience. Now ideally I'd like to have better support for the native MCLB, but for now I need to work with what I got so I figured I'd kludge together a pseudo virtual MCLB in native G-code. Here's a proof of principle: virtual mlcb lv10.vi If you run the VI and generate some stupidly large data sets, say 100000x8, you'll see that the render time hopefully stays constant as you scroll through the data, and with a little luck is reasonably fast. Now if I could make a virtual tree view...

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

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

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).

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

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).

Here is my proposition. Inspired by recent LAVA activity... However I haven't read that all And alternative version for the front, which is even more pure:

Here's what I use. You feed in the string to word wrap and how it is formatted (font, size, etc.) and it returns the string with line breaks. Bruce Word Wrapping.vi Word Wrapping (Entire Column).vi

Meet Lilah Kring, the newest member of the Kring family: Born Monday, 10/5/2009, at 11:30 PM GMT -7 I can't guarantee she'll use LabVIEW, but I'll do my best [insert object-oriented programming puns, here]

You can check out the code here. I have also attached some code to calculate the XMODEM CRCs as well as the normal CRC-16.I have also attached the XMODEM-VISA.llb that I used. I am pretty sure this is the same llb referred to in the link I posted but if I recall I added the support for 1K transfers. Calculate CRC-16 (File input).vi Calculate CRC-16.vi Calculate XMODEM CRC-16 (Buffer input).vi Calculate XMODEM CRC-16 (File input).vi Get CRC-16 Table.vi Calculate CRC-16 (Buffer input).vi Xmodem VISA.llb

One of the main differences is that there are very few support VIs needed (as compared to other by ref patterns) when you are using DVR LVOOP (namely you'll want a constructor and destructor for each class, including descendants). Also, prior to DVR LOOP, most patterns used LVOOP as a wrapper around a reference (e.g. Queue) to data. With DVR LVOOP, this gets flipped on its head -- you have a reference wrapper around an LVOOP object. This is the first thing that really strikes you as different and unintuitive, but once you start using it you'll see that it makes a lot of sense (and, of course, you see some areas where things still need to be further improved). Dynamic dispatch only works on by value methods, not by reference methods. It would be nice if you could pass a reference into a by value method and LabVIEW would dereference and rereference behind the scenes. So, you'll find some duplication is required if you want users of your by reference class to call into by reference methods. You'll need to decide whether you want your users to 1) dereference/rereference the data themselves and then call your class' by value methods or 2) have a by reference method in your base class that calls the by value method. Also, it would be nice if you could wire a DVR LVOOP object into a Bundle by Name and Unbundle by Name and have LabVIEW automagically dereference/rereference the data behind the scenes. Right now, when you want to just get a value of an element of a DVR LVOOP object, you have to use an Unbundle by Name inside an In Place Element Structure. This is too much work for the programmer and makes the code look unnecessarily sloppy. The programmer's tendency will be to create a non-locking Get/Preview data method, but this isn't a great idea, because it makes a complete copy of the data -- by using an IPE Structure with an Unbundle by Name inside, you only copy the element. Those are the main things I've noticed. The bottom line is that if you do by ref LVOOP this way, you're going with the grain and you'll find things to be much easier now and in the future as more native features and usability improvements get added to DVR+LVOOP. Oh, one more thing that I noticed is that edit-time performance seems much better, which is probably due to a combination of: performance improvements in the LabVIEW IDE, WRT projects/classes/etc. fewer support VIs in the by ref classes

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.

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

I was writing a login screen for a recent project that required me to verify that the password met certain criteria, i.e. at least eight characters, at least one cap, at least one number or special character, etc... I came up with the attached piece of code using regex, which, surprisingly for me, actually worked. I'm planning on leaving it this way, without any comments so when I find it five years from now I'll spend at least an hour wondering what the hell I was thinking. Anyone else have any utterly ridiculous code? Not spaghetti, just off the wall, makes no sense but works perfectly kind of code? -Ian

HEY!!! I have a perfect example for everyone of stuff to not go poking around in! The "Get LV Class Default Value.vi" ... if you pop it open with your favorite password cracker, you'll find a Call Library Node. You pass into that Call Library Node a path and an app instance refnum and out comes the LV class. And now you're thinking, "HEY! Aristos Queue didn't put that app instance refnum on the conpane of the VI! He's hiding functionality from me! I can use this to get the value of a class in another application instance!" And so you wire up a different application instance. And you run your VI. Now, sometimes you crash right away. Other times, you don't crash until you try to close the project. Other times you just get a crash on exiting of LabVIEW. In any case, you've thrown off the reference count for LV class data because -- ha -- it is an ILLEGAL OPERATION TO PUT CLASS DATA FROM A CLASS INTO THE WRONG APPLICATION INSTANCE. You have to marshall the data from one app instance into the other app instance, because the *class itself* might not exist in the other instance, or might exist with a different definition (i.e., in one app instance you loaded c:\x.lvclass and in the other you loaded d:\x.lvlclass). And, hey, if you want to go indexing off the end of a pointer into undefined memory, this is a great way to do it. I swear, by all the nodes and wires in Heaven, none of this stuff has any business being on any block diagram except for the one that it is on and that we password protected. It is either useless to you or subject to change in a future version of LV because we're still refining it and have no intention of supporting the current version (unless it passes testing and we decide to make it official, but we might not have time to do that in a given release, so it may take a while, so just because it has been there and private for a few releases doesn't mean it will be there forever).

iEmilie: I haven't really been worried about the "hate LV" blog post. I kind of enjoy reading it. In my eyes, LabVIEW seems to come out pretty well in that thread. I figure there's always going to be someone angry at us, so the existence of the thread itself doesn't bother me. What I like is that in all of the pro-LV comments, whether from NI or not, people reply with calmness, reasonableness and helpful advice. I've read that thread a few times over the years and thought perhaps we should start an advertising campaign: "LabVIEW: Using it will make you a nicer person." :-) Various folks have said that reading that post was deflating. It shouldn't be. My list of "things I hate about LabVIEW" would be waaaaay more than just 10 things, and I guarantee some of them are far blacker marks against us than anything jshoer mentions. I cannot believe how incredibly stupid we have been over the years on some features (yes, I include features I created and now regret), and how long it is taking us to get certain upgrades. But I don't view these deficiencies as reasons to be depressed. LabVIEW is a growing language, adapting over 25 years to the changing technologies and customer bases. Doing what no one has ever done before sometimes means you get a less than optimal solution and you have to fix it up in round 2. Do we have more we can do? Yes. And we continue to work to improve. But the backbone of LabVIEW remains strong. Graphics is the only manageable way to express parallelism, and parallelism is the name of the game in the future. Have you guys seen the parallel keywords that Microsoft has been introducing into the other languages lately? Everything needs to be parallel, but procedural programming is a dead end. There is only so far you can go with compiler analysis of procedural code and manual control of mutexes before you hit a wall and flat out say, "No, I need a system that is designed for multicore from the outset." Between our parallel expression on the desktop and our ability to target FPGAs, I'm thrilled about LV's future, and all the complaining is just the list of tasks we need to be tackling on our way there. When I started at NI, on my first day, I saw a sign by Jeff K's desk: "You know you have built a successful product when people use it for things you never intended and criticize you for being short sighted." The "hate LV" post is just one of the sign posts of our success.

http://www.eaipatterns.com/docs/IEEE_Software_Design_2PC.pdf

At best, the Events are a bit like an occurrence, not a replacement for polling, just a good hint at what might be a good time to poll. The problem as AQ hints at, is that it can be tricky to catch all of the ways that a user can change the scale range. For example, what if I paste a new value, and then make another window active and then return to the FP. The new value is entered via this process without a key press or mouse click. Polling is a robust method to catch these changes. And since I started using LV long before the days of the Event Structure I will pass along a tip from the old days: a simple way to throttle the polling loop is to use the "Wait for Front Panel Activity" function with a long timeout (500 msec). Keeps it responsive when necessary, and out of your way when nothing is happening. In many instances I do not display the Marker values for a slider, and I actually use separate controls to set the range. This makes it very easy to detect the value change.

I recently took the CLA (on the 2nd of this month). My proctor did tell me they changed the format for the CLD in giving the front panel. That could have saved me a good 10-15 minutes back when I took it. For the CLA, I was given the sheet of requirements and a blank USB drive for submission. I thought the CLA was one of the hardest tests I've ever taken, mostly due to the 4 hour requirement. And for what it's worth, I got my results yesterday and I passed!

It is not only important where to bend a wire, but also HOW to do it: Here is RCF plugin which does the job. Seriously, the Invoke Node you are searching for is "Create Described Wire": "Wire Desc" input is tricky one, because you have to specify coordinates of wire nodes in opposite way - as an array of (y,x) pairs...

Hi All This thread has been created to blog about information relating to the OpenG 4.0 Release. It will contain what we did and why we choose to do it and anything else we find interesting. Please feel free to add in any comments or feedback about the release. I will just keep adding to this thread. Cheers Jonathon Green OpenG Developer

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

I just realized I'm about to hit 500 posts on LAVA. I would have probably preferred if #500 was a deep treatise on some esoteric feature of LabVIEW that will change the programming world as we know it. But we all know that ain't happening anytime soon. Maybe post #1000... So instead, I would just like to express my heartfelt thanks to all of you here at LAVA. To those of you who have helped me out over the years (and will hopefully not tire of helping me out in the future). To those of you whose irreverent words have made me laugh out loud at some inappropriate times. To those of you who ask questions and make me think outside of my own little programming box. And of course, to the (real) Moderators who keep the Wonderful World of LAVA going. I love all you guyze!! Cat

I am proud to announce the birth of my Daughter Josephine Mae Shangraw 7lbs 14 oz

Hrmm... well as I'm the other developer who make the abstraction layer comment I hope y'all don't mind if I offer a contrasting viewpoint. If you don't agree that's okay, no harm no foul. *shrug* The meaning of "abstraction layer" is highly dependent on the context in which it's being discussed. From 50,000' up, Paul's four layers make sense. They're very thick layers, but typically you want to be talking about the big pieces from up there. However, when you zoom in on any one of those layers you'll find they're each made up of their own abstraction layers. Device drivers aren't written as one giant piece of monolithic code. They are built up in layers that start somewhere down in the kernel and work their way up through the OS HAL, security layers, and who knows what else. If you tell a software engineer writing kernel mode drivers that he's not using abstraction layers he'll disagree. As software developers everything we do revolves around creating abstractions. Every public vi we write is a layer of abstraction other developers working on the project need to understand. It may not a very big layer, but it's there. Good abstraction layers are highly cohesive and clearly defined. They tend to be relatively thin, but not always. They are designed so that the public methods all offer about the same level of abstraction. It's because they are well-designed and offer about the same level of abstraction that we can zoom out and think of it as one big layer. Bad abstraction layers (and I'm as guilty of writing them as anyone else) are not. They often have an unpredictable mix of high level and low level functions. I've run into several cases where I've had to bypass it and go to the layer below (you know, the one that was supposed to be abstracted away) to get the functionality I needed. Instead of focusing on one particular thing, they end up doing a little of this and a little of that. In my experience they often do not have clear boundaries and may offer overlapping functionality with other abstractions. They are too thick, too wide, soft around the edges, and incomplete. (Imagine trying to use VISA if you had to make Win32 api calls to fetch a Windows security token with every prim.) I try to follow a programming model similar to what Mikael posted. I confess I don't understand why Paul thinks that is too complicated. I think it's much, much easier to understand an application when it's layered and modularized than when there's a disorganized clump of vis all making calls to each other and offering different levels of abstraction. Maybe our brains are wired differently? Maybe you really do have cohesive abstraction layers in there but don't realize it? Anyhoo, that's my . Metaphorically speaking, yes. You're telling the rest of the world, "You don't need to know if I'm wearing Superman Underoos, WalMart Tighty-Whities, or going commando. You just need to know that everything is taken care of and none of my private methods will be exposed."

Just to prove that it is technically possible: Yes, programmaticly: Sorry for not closing references, etc.