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'm going to learn LabVIEW. So I can come to NIWeek with you.

Hello I have just passed the architect exam, and I just wanted to say that I have learned a lot from the posts on this site. Many thanks all. A special thanks to the lava member FAB to came over to the UK from the US to do the advanced architectures course at NI and was by far the best lecturer that I have had there.

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

I'm having a separate GChat about this issue, and will copy what I just wrote moments ago: "the main prob is that filenames (rather than embedded GUIDS) are used as identifiers in class hierarchies. it's frustrating. same thing bites you with Dynamic Dispatch VIs -- they must have the same filename (which I personally find annoying)... filenaming convention should be abstracted from class functionality" So, I think we're independently coming to the same conclusions here, crelf *** EDIT: and this is not a bash against the current convention, I'm sure it exists for good reason. It's just that I'm running into problems, and just trying to flesh out the best practice ***

--- UPDATE 2012-08-05: Ticket pre-sales are now closed. If you need to buy a ticket at NIWeek, this post has what you need to know. --- It's that time of year again! Are you coming to NIWeek 2012? Do you want to enjoy cold beers and hot mesquite BBQ with your friends from LAVA, OpenG, and the whole LabVIEW Community? Then come to the 2012 LAVA / OpenG NIWeek Bar-B-Q! Year after year we bring together all your best online (and real-life!) friends from LAVA (LabVIEW Advanced Virtual Architects), OpenG (home of LabVIEW's open source community), and even the leaders in NI LabVIEW R&D. Come enjoy great barbecue with great people away from the hustle & bustle of the convention floor. Menu*: Mesquite BBQ beef brisket, chicken, and pork ribs. Potato salad, pinto beans, and coleslaw, and iced tea. There'll be a cash bar, and they have a great selection of brews. Date: Tuesday, August 7th, 2012, 7:00 PM (after the NIWeek "Block Diagram Party") Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78701 Cost: $30 per person How to buy a ticket: Ticket pre-sales closed. See here to buy a ticket at the conference. *Vegetarian food is available on request -- PM Justin here for info. What to Wear: A LAVA T-Shirt, of course! Door Prizes Galore: Everyone is in the running for one of there super door prizes donated by other LAVA members. (You're welcome to offer up a prize too - hint, hint!)

How about this?

It's just tu pun together some pics from this topic and little bit more... So we already saw that wires may go diagonally: Then that they may have almost any shape: Michael showed us how execution dots propagates on such wires: Link Sources for creating such wires here. Now I'm getting crazy. Sit down, fasten your seat belts, hold your breatch and watch this. Although it does not run too fast (no more than 10 fps on my computer) but Jing slowed it down even more, so in real everything happens much more smoothly. If you would like to play with this: controls or nodes which have labels are fixed to backgroung. Don't change damping too much. Don't put too much objects on BD. Always wire both inner and outer terminals in tunels. Sources attached. spring-wires.zip

Howdy Attached is a tool that automates the creation of a Child Class in the LabVIEW Project Environment. This is my first foray into LabVIEW Project Integration, and was a good example as it is a simple one. There are no example VIs in package yet, but here is a video: <!-- copy and paste. Modify height and width if desired. --> <object id="scPlayer" width="470" height="625" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/jingswfplayer.swf" > <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/jingswfplayer.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/FirstFrame.jpg&containerwidth=470&containerheight=625&content=http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/LVOOP%20Assistant%20-%20Create%20Child%20Class.swf&blurover=false" /> <param name="allowFullScreen" value="true" /> <param name="scale" value="showall" /> <param name="allowScriptAccess" value="always" /> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LVOOP%20Assistant/media/2d60299d-20fc-47df-ae5d-da3987577dc2/" /> Unable to display content. Adobe Flash is required.</object> For things like this - Project Integration has a more natural workflow than '>>Tools' The package is LAVA namespaced as I plan to release this on LVTN and also to release more LVOOP helper tools. Feedback welcomed! lava_rsc_create_child_class-1.0.0.14.vip

Well, I've tracked this down to an issue being brought on to using classes within a LabVIEW library. The two kinds of libraries (.lvlib and .lvclass) just plain do not work together. My little project's classes became plain uneditable, they were contained in an lvlib. In a fit of frustration, I dragged the entire lvlib hierarchy out of the library scope, and magically everything just works as intended. This is a shame, for lvlibs offered a lot of control and namespacing which really helps with code reuse. Please to any at NI who are reading this thread, fix this. Well, it's a good thing I got this working. I'm literally down to the last hours, about to be gone for two weeks and this code has to work by end of day. Meanwhile, I just lost two hours trying to add a simple primitive to one of my classes. Since there's no way I'm going to drop my use of .lvclass objects, I'm done with lvlibs for now.

I had almost finished composing a message last night when I accidentally hit the "Back" button on my keyboard. Ah, the joys of browser-based text editors. Note that "QSM" means different things to everyone. I don't use what *I* consider the QSM, but I do use queued message handlers. QMHs look a lot like QSMs, but the difference is in how they're used and what's expected of it. In this post I'm primarily referring to a dual loop "producer-consumer QSM" Absolutely not true. The QSM is the most common implementation seen because that's all most people know. And truthfully, it probably is sufficient for most Labview users. There are lots of architectures and patterns available. Though Labview is different from common text-based languages, it's still software. The patterns and architectures that apply to those languages can apply to Labview as well. As an aside (and I'm probably in the minority) I don't think the QSM qualifies as an "architecture," though people often refer to it as such. The QSM is an implementation, not an architecture. Calling it an architecture is kind of like saying my house is built using a screwed butt joint architecture. A "screwed butt joint" (and the QSM) is a construction technique, not an architectural description. So when someone says their app uses a "QSM architecture," I read that as, "My app has no architecture." Usually I'm not far off. There's nothing inherently wrong with state machines. When used appropriately they are very useful. Queued State Machines, however, aren't state machines at all. They're a convenient construct for sequencing code segments. Your question implies you're looking for a single, general purpose design that works across all requirements. So no, there is not *a* architecture that works well. Like Ben said, there are lots of architectures and design patterns, each with their own strengths and weaknesses. The software engineer's job is to pick those that meet the requirements. Pick one that's too complex and you have to implement a lot of useless code. Pick one that's too simple and you have to resort to hacks to support functionality the architecture isn't well suited to provide. My apps are composed of several different architectures/patterns, depending on what level of the code you're looking at. Event based, Model View Controller, object state machines, active objects, etc. Lately I've been moving towards highly decoupled components that use messages to send and receive information with a mediator handling all message routing and translation between the various application components. 1. I got tired of the messes that resulted from using QSMs. 2. They are fragile. Many implementations have inherent flaws that can't be fixed. 3. They are hard to follow. QSMs are a lot like GOTO statements in text languages. 4. They don't provide any structure. Good architectures are designed with clear extension points for adding functionality. 5. There's often no easy upgrade path to something more suitable when the requirements outgrow the QSM's abilities.

It's very simple in LabVIEW: Create a gun.vi with a nice gun icon and an indicator (wired to ConPane). Create a foot.vi with a nice foot icon and a matching control (wired to ConPane). Place both vi's on an empty vi and wire them. Run the vi in highlight execution mode. Felix

My story made NI'sInstrumentation Newsletter Q2 2010 See page 24

I have been toying around with a more radical UI design change. First of all, I am not a big fan of tab control. Secondly, I want to try to get a UI customizable enough that it can cater to as many people as possible. Here is what I came up thus far (note: this is mostly just a UI mock up and it has very little functionality). <object width="1068" height="546"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/FirstFrame.jpg&containerwidth=1068&containerheight=546&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/2009-08-30_1137.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="1068" height="546" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/FirstFrame.jpg&containerwidth=1068&containerheight=546&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/2009-08-30_1137.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/14a79ed5-ef03-4870-94f1-66a1b789dd21/" scale="showall"></embed> </object> Please comment. PJM