Leaderboard

I tend not to edit Wikipedia myself, I find my technical prose is usually inadequate. However, I just took a glance at the LabVIEW entry on Wikipedia and I am horrified. There are inaccuracies, irrelevancies, it's choppy, and generally poorly gathered. Too many cooks here I feel. I wonder who is responsible for this content? I understand that the general public are required to maintain these pages, but is there a core group of enthusiasts that like to keep this page accurate? I suspect not, because the leading paragraph still stated that the current release is LabVIEW 2012 - which tells me there are no LabVIEW enthusiasts who are also keen on keeping this page up to date. (I changed it to 2013 - my first Wiki alteration!)

LabVIEW Programmer – Enable Integration Enable Integration (a division of Enable Training and Consulting, Inc.) is seeking a LabVIEW programmer to join our integration team and immediately be a core part of several projects. Today, we are a team of 20 employees and have a diverse range of clients: Bosch-Rexroth, FIRST Robotics, University of Waterloo, LEGO Education, National Instruments, and Solid Works. We are a dynamic employer with a flexible working environment and atmosphere. Our integration team specializes in consulting and providing custom hardware and software solutions for test, measurement & automation applications for worldwide clients in a variety of industries. Our team has over 65 years combined programming experience and have worked on projects both large and small, and have recently been recognized as a National Instruments Alliance Partner with exceptional technical resources at NIWeek 2013. Please visit www.enabletc.com for more information about the company. Duties & Responsibilities: We are looking for a self-motivated LabVIEW programmer who will excel in a fast-paced consulting environment, will excel to meet deadlines and ensure the success of our customers. We are looking for someone who has recent experience developing application using LabVIEW. Your primary efforts will encompass all stages of software engineering application design, including: · Requirement definition and gathering, Specification writing · Systems Design & Architecture · Algorithm development · Documentation (Code and Project Management) · Unit, Functional, Validation & Verification Test · Deployment & Application Support This is a full-time position and candidates will be expected to work out of our Milton, Ontario head office. Desired Skills & Experience · 4-year technical degree, or 3-year technical diploma from accredited colleges or universities · Experience programming hardware and/or software applications using LabVIEW o CLAD/CLD/CLA certifications are an asset · Discipline and organization with respect to software maintenance and version management · Experience with source code control & source configuration management tools a plus (TortoiseSVN ideal, however will consider applicants with working knowledge of Perforce, ClearCase etc.) · Strong troubleshooting and debugging skills · Understanding of basic signals and systems concepts o Sensors and actuators o Analog and digital signals o Data acquisition concepts and hardware o Communication protocols · Ability to work both alone and with colleagues to solve problems and to weigh the merits of differing approaches · Self-motivated team player · Effective time management · Strong written skills in English o Code documentation, Project management & Progress Reports o Team communication/updates · Immediately eligible to work in Canada at time of application Pay is commensurate with skills and qualifications of the applicant.

I hereby dub thee "LabVIEW Enthusiast Ambassador To Wikipedia #1". Go forth and edit!

In times like that, I give my wires nice round bends. Ctrl-space, Ctrl-w calls my Quick Drop implementation of Vugies Wired Wires.

Yeah, I sometimes like to align functions inside multiframe structures too, so they are at the same place in all frames. But usually only if they do similar things and as form of meditation, while thinking about the rest of the algorithm.

No, definitely not! 4*2*2*4 should be the standard and strictly enforced for all LabVIEW programmers, if I had a say in this! And anyone using the 6*4*4*6 for a VI that is not private to the library should be banned from writing LabVIEW programs.

I apologize for not going back and editing my original post but I think everything got the point regardless. I'd like to add another aspect to this thread: viz, I strongly suspect that the majority of LAVA members who want to keep the FGV|AE distinction "grew up" learning OOP in a CS degree program and most probably with a focus on C++ and/or JAVA. I didn't. In fact, I never went to CS courses and I learned to program in PL/1, then onto C and Unix. I even remember when Linus's Unix (or LI-nix) first came out. So why am I asking about what you "grew up" learning? Because I think it's exactly on target that the overwhelming majority of LV programmers are domain expert (or domain specialists) and not CS degreed professional programmers. LV is easy to learn; and, yes, it's easy to learn badly. So why learn/use (what I'm calling) FGV instead of other solutions? 1. There is an extensive "library" of already developed code in the larger LV community based on them. 2. They are clearly dataflow and by-val, unless one violates the encapsulation (as what happens when an originally lean and tight FGV gets "overloaded" inappropriately. 3. They are easier to learn and utilize IF you're a beginning to intermediate LV programmer who is a domain expert/specialist and NOT a programmer who has learned to base their fundamental paradigm around by-ref implementations. Yes, this is LAVA -- so everyone here is presumably "advanced" and, having been programming in LV for more than a decade and doing things with the language that others thought impossible, I believe I'm also advanced; and, perhaps most importantly, I believe that it is critically important to remember the core market of LV. And that is domain expert/specialist who are NOT CS degreed professional programmers who provide LV (and other language) based implementations for others as their primary business. And, yes, I am strongly considering becoming CLA, primarily so that I can attend the CLA summits. I only program for myself (my own company) and have no desire to become a LV consultant or wiring business for hire so the CLA as a credential doesn't hold any particular meaning for me, except that it would allow me to fully participate in very interesting discussions! Anyway, sorry to be long winded about this. Climbing down off the soapbox now so I can have some . Did uou know that WORM was the original construct that was implemented as CD-Rs? It was originally aimed at being Write Once Read Many as a "real world" persisting physical record that could NEVER be written to again, not just within one instantiation of a running program.

New - Event Inspector Window (you're gonna love this!) - Never had a need for this, but it may come in handy if you don't know what events you are firing . New - High Priority events - Don't have a use case at the moment. But I can see edge cases where it may be useful. New - Flush Event Queue Function - I've always considered flooding event queues as bad and lazy programming, so I think this will just let bad and lazy programmers off the hook. New - VI Scripting methods and properties for events - Good for tool-chain developers. But no real use case for me. Improvements to the Edit Events Dialog: - Didn't notice Will look again You forget the big one - MOUSE WHEEL . By far the most useful, just a shame it's the only one.