Leaderboard

After I made this post I decided to bring the LabVIEW Wiki back online. It was not easy and took several days of server upgrades and hacking. The good news is I was able to bring up all the original pages.. The even better news is I talked with @The Q and @hooovahh and we are all on the same page as to how to move forward. @The Q did a great job of stepping forward and trying to fill the void that the LabVIEW Wiki's absence had left. He's agreed to migrate all the new content he created over to the LabVIEW Wiki, from Fandom and continue to develop new articles and content moving forward on the new site. He will also help in moderating the Wiki and will be promoted to Admin rights on the Wiki. His help is much appreciated. The LabVIEW landing page created here on LAVA is awesome but the forums don't lend themselves to static content creation. Instead @hooovahh has agreed to move the old landing page to here. That will be the new home for the landing page. This will become a valuable resource for the community and I hope all of you start pointing new people in that direction. With many editors, it can only get better and better over time. Where do we go from here: Logging in. - The old accounts are still there. If you're a LAVA old-timer, then you can try to login using your LAVA username. If the password doesn't work then reset it. You can also create a new account here. I'm going to announce a day when new accounts can be created. I'm limiting it for now because of all the spam accounts that can be potentially created. There's an issue with the current Captcha system. if you are super-eager to start creating content now and want to help, send me a direct message on LAVA and I can manually create an account right away. - New account creation is now open. Permitted content: - I'm not going to put restrictions on content at the moment. Obvious vandalism or offensive\illegal content will not be tolerated of course. However, the guidelines will be adjusted as time goes on and new content is created. There's just not enough content right now to be overly concerned about this. We need content. Discussions about the Wiki. - Each article page has an associated discussions page where you can discuss issues related to that article. Please use that mechanism (same etiquette as wikipedia). General Wiki issues\questions and high level discussions can be done here. So now, if you need to add content, you can do it yourself. Feedback as always is welcome.

Dear Santa NI I am now in my 40s with youngish kids, so despite the fact that all I got for Christmas this year was a Pickle Rick cushion I am not actually complaining. However, I would like to get my order in to the Elves as early as possible. This is my wishlist, in no particular order. I expect this list will not be to everyone's taste, this is ok, this is just my opinion. Make LabVIEW free forever. The war is over, Python has won. If you want to be relevant in 5 to 10 years you need to embrace this. The community edition is a great start but is is probably not enough. Note: I accept it might be necessary to charge for FPGA stuff where I presume you license Xilinx tools. NI is and has always been a hardware company. Make all toolkits free. See the above point. Remove all third party licensing stuff. Nobody makes any money from this anyway. Encourage completely open sharing of code and lead by example. Take all the software engineering knowledge gained during the NXG experiment and start a deep refactor of the current gen IDE. Small changes here please though... we should not have to wait 10 years. Listen to the feedback of your most passionate users during this refactor. NXG failed because you ignored us and just assumed we would consume whatever was placed in front of us. I am talking about the people like those reading this post on Christmas day and their spare time because they are so deeply committed to LabVIEW My eyes are not what they used to be, so please bring in the NXG style vector graphic support so I can adjust the zoom of my block diagram and front panel to suit accordingly As part of the deep refactor, the run-time GUI needs to be modernised. We need proper support for resizable GUIs that react sensible to high DPI environments. Bring the best bits of NXG over to current gen. For example the dockable properties pane. (Sorry not much else comes to mind) Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here. Get rid of the 32-bit version and make RT 64-bit compatible. You are a decade overdue here. Add unicode support. I have only needed this a few times, but it is mandatory for a multicultural language in 2021 and going forward Port the Web Module to Current Gen. All the news I have heard is that the Web Module is going to become a standalone product. Please bring this into Current Gen. This has so much potential. Stop adding features for a few years. Spend the engineering effort polishing. Fix the random weirdness we get when deploying to RT Open source as many toolkits as you can. Move the Vision toolkit over to OpenCV and make it open source Sell your hardware a bit cheaper. We love your hardware and the integration with LabVIEW but when you are a big multiple more expensive than a competitor it is very hard to justify the cost. Allow people to source NI hardware through whatever channel makes most sense to them. Currently the rules on hardware purchasing across regions are ridiculous. Bring ni.com into the 21st century. The website is a dinosaur and makes me sad whenever I have to use it Re-engage with universities to inspire the next generation of young engineers and makers. This will be much easier if the price is zero Re-engage with the community of your most passionate supporters. Lately it has felt like there is a black hole when communicating with you Engineer ambitiously? What does this even mean? The people using your products are doing their best, please don't patronise us with this slogan. Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools Remove all hurdles to hand-editing of these files (no more pointless hashes for "protection" of .lvlibs and VIs etc) Openly publish the file formats to allow advanced users to make toolkits. We have some seriously skilled users here who already know how to edit the binary versions! Embrace this, it can only help you. Introduce some kind of virtualenv ala Python. i.e. allow libraries and toolkits to be installed on a per-project basis. (I think this is something JKI are investigating with their new Project Dragon thing) For the love of all that is holy do not integrate Git deeply into LabVIEW. Nobody wants to be locked into someone else's choice of SCC. (That said, I do think everyone should use Git anyway, this is another war that has been won). That is about it for now. All I want is for you guys to succeed so my career of nearly 20 years does not need to be flushed down the toilet like 2020. Love you Neil (Edited: added a few more bullets)

The content on this page will go away soon. It's currently being migrated. > New Location < Read about the wiki here This thread is intended to be a place for all things LabVIEW to be able to be found. If you have a resource for LabVIEW feel free to reply with your own content. We are interested in things like person blogs, forums, training information, and anything a user of LabVIEW might want. Several links and sections have been lifted from another resource available over on NI labeled the Content and Communities for LabVIEW Application Development. I'm New To LabVIEW and Need Help Basic Training Information NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction (Alternate Google Drive) 6 Hour LabVIEW Introduction (Google Drive) Self Paced training for students Self Paced training beginner to advanced, SSP Required Rookie Mistakes in LabVIEW by Digilent State Machine Design Pattern Basic Tutorial Wikipedia Article Sixclear Video Event Driven Design by NI Beyond Basic Training These are topics that are useful but not for those new to LabVIEW or software development. Topics may cover things a novice may have a hard time following. Object Oriented Software Design NI FAQ on Object Oriented Programming Creating Classes When Should you Use Classes Abstraction Abstraction Distraction Introduction to Object Oriented Programming and HAL by Elijah Kerry (Video), Plugin Framework JKI Hardware Abstraction Video Actor Framework Community Introduction Framework Basics Error Handling Basics by NI David Maidman’s Blog Post SOLID Error Handling by Dmitry Structured Error Handler Express VI by NI I Have Questions LAVA Forums - Independent community, with less NI oversight, and generally less new users asking basic questions NI Official Forums - NI's official forum, monitored semi-regularly by NI and the best place to find official support LabVIEW on Reddit - Smaller community but has Reddit features like voting on posts and comments causing interesting topics to get more attention LabVIEW on Stack Overflow - Q&A style community I'm Looking to Find Example Code and Toolkits NI Tools Network - Polished released code distributed as VIPM packages. LAVA Code Repository - Place for Verified, and Unverified code allowing for discussions, in addition to hosting NI Code Exchange / Community Documents - Similar to LAVA but NI's site licensing means less flexibility if you are posting code and want a custom license. NI Reference Designs Portal GitHub - Trending LabVIEW Projects, and All LabVIEW Projects GitLab - LabVIEW Projects BitBucket - LAVA Projects on BitBucket I'm Looking for Blogs There are lots of LabVIEW blogs, covering lots of topics. Some blogs go cold after some time, so below is a table of blogs, highlighting the last post made. At the moment this is updated manually so this will need to be updated periodically. NI's Blog NI's official blog, updated very frequently System Automation Solutions 10/24/2018 Sam Taggart's Blog JKI Blog 9/13/2018 Blog often highlighting JKI's activity including VIPM and other LabVIEW tips DMC Blog - 9/10/2018 LabVIEW category of DMC's official blog Steve Watts Random Ramblings on LabVIEW Design - 10/23/2018 Random Ramblings says it all but often good insight into designs and discussions we don't think about but should question why we use them and how Delacor Blog - 9/4/2018 The Daily CLAD - 9/4/2018 Hooovahh's Blog - 8/24/2018 Brian Hoover's blog focusing on LabVIEW and CAN The LabVIEW Lab - 10/22/2018 Eric Maussion's blog Bloomy's Blog - 8/13/2018 LabVIEW category of Bloomy's official blog Ajay Blog - 10/10/2018 Ajayvignesh's LabVIEW blog Wiresmith - 9/25/2018 James McNally's Blog LabVIEW Craftsmen - 7/3/2018 Wineman Technology Blog - 10/10/2018 LabVIEW category of Wineman's official blog MGI Blog - 6/5/2018 Moore Good Ideas blog Eyes on VIs - 5/25/2018 Christina Rogers blog often focusing on LabVIEW's visual design UI's and UX's QControls - 5/15/2018 Blog series on QControls, and open alternative to XControls Walking The Wires - 5/11/2018 Chirs Roebuck's Blog Not a Tame Lion - 5/5/2016 LabVIEW Artisan - 2/5/2015 Darren Nattinger's LabVIEW blog often highlighting lesser known features of LabVIEW Culverson Software's Blog - 9/20/2014 LabVIEW category of Steve Bird's Blog VI Shots - 7/31/2014 LabVIEW video podcast by Michael Aivaliotis Brian Powell - 12/26/2013 I'm Looking for Videos Similar to blogs, video channels can be hit or miss, and content can become dated. But if you are more of a visual learner these channels offer a chance to learn by watching others. NI Week & CLA Conference - Username: LabVIEW_Videos, Password: LabVIEW GDevCon Conference LabVIEW Architects Forum Delacor's Channel System Automation Solutions LLC Dr. James D Powell NI's LabVIEW Channel LabVIEW ADVANTAGE LabVIEW MakerHub Looking For Certification Help Certification Nugget: CLAD - Certified LabVIEW Associate Developer Certification Nugget: CLD - Certified LabVIEW Developer Certification Nugget: CLA - Certified LabVIEW Architect Connecting With Other LabVIEW Developers User Groups Online communities are a great way to connect and contribute. In addition to online there are Local LabVIEW User Groups which meet regularly to present and understand LabVIEW and NI topics. Find one close you you and subscribe or monitor topics. NI often supports local user groups, but they are in most cases ran and organized by the community. NI Week NI Week is another great way to connect with and learn. Hosted in Austin Texas once a year it is a week long conference with training, discussions, keynotes and other activities. Many previous NI Week videos can be found online but no single source is available which aggregates all marketing, keynotes, and technical sessions in one location. The best resource for content is a site setup for video hosting done by Mark Balla over the years. Summits If you hold a CLA or CLD there are specific summits for you that are free. These are often tailored presentations for a specific skill set with the focus on technical discussion and problem solving. There are two CLA summits, one in Austin Texas, and one in Europe both held once a year. CLD summits happen more frequently and locations change from year to year. Consult their specific discussion forums on NI to see when the next one is. Just like NI Week Mark Balla has several videos available here. Needing Professional Help If a project is getting out of hand and is beyond the skill level of your team, NI suggests looking at one of their Alliance Partners. Contact one in your area, and they will help try to best guide you on your project. I Want To Contribute to the Community Developing Code For Others Arguably the most difficult thing about sharing code, and reusing code, is the mind set and considerations associated with other developers using software you wrote. It is a type of mental exercise where you need to put yourself in the mind of the developer using your software. NI's Reference Deign Portal is a good resource for understanding various coding structures, and best practices for designing code for others, and can help with standardizing code for other developers. TBD (Expect this to be a section on various forums, and code repositories that can be added to along with helping out local user groups, and presenting at NI Week and Summits) Other Important Software Topics Source Code Control (SCC) Recommended SCC for LabVIEW Software Configuration by NI Code Management at Center of Excellence VisualSVN - Free SVN Server Software Delacor Blog with SCC Category -SVN Setup for LabVIEW By Delacor (Video) -Git Setup for LabVIEW By Delacor (Video) SOLID Principals Agile Software Development Principles, Patterns, and Practices (book) How Applying Agile Object-Oriented Design Principles Changes Designs and Code by Dmitry SMoReS development Unit Testing NI Unit Test Group VI Analyzer (Automated Code Inspection) The VI Analyzer is a tool by NI that is included with some versions of LabVIEW and allows for automated inspection of LabVIEW software, to check for various conformity or nonconformity to software practices. The VI Analyzer comes with many useful code checking steps but others can be added. Checkout the VI Analyzer Enthusiasts for more community made tests. LabVIEW Style Checklist Center Of Excellence - Learning VI Analyzer LabVIEW Style Guide Rules to Wire By Part 1 Rules to Wire By Part 2 Virtual Machine Usage TBD

Please see the above link to download the videos The NIWeek 2016 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444

I did not know. That possibility was not even on my radar. Even though the drumbeat of bad news had been going for a while, most corporations refuse to change direction on a bad decision. NI showed more sentience than I usually expect from massed humans: the sunk cost fallacy is a trap that is very hard to get out of. I figured the very good engineers on NXG would either surge through it and make it fly or we would bankrupt the company trying. That's the pattern established by plenty of other companies. Mixed. I spent 4.5 years directly working on NXG (2011 to 2016) and countless hours in later years working with the NXG team to design a future G. I really wanted it to fly. There is so much good in that IDE, including some amazing things that I just don't see how we ever do in the LabVIEW codebase without just shattering compatibility. But at the same time, I was watching good friends toil on something that the market just wasn't adopting. The software had some problems that were going to take a long time to solve. The issues were all solvable, but the time needed to fix them... that was harder and harder to justify. NXG gave us a GREAT platform for other software: Veristand, FlexLogger, etc. That code is extremely modular and can be repurposed for all sorts of tools. We also learned a heck of a lot by building NXG -- some things that I thought we could never do in LabVIEW now seem possible. NXG gave us a sandbox to learn a whole lot about modern software engineering without putting the delivery schedule for mature software at risk, and those practices [have been|are being] brought back and applied to LabVIEW -- that will decrease cost of maintaining older code. All in all, NXG was valuable -- the expenditure was not a complete loss. I am very sorry to the few customers who did migrate to NXG. We don't have a reverse migration tool, and building one would be absurdly expensive. Leaving those folks stranded is going to hurt -- I hate letting our customers down and just saying, "We have no solution to help you." There aren't many of those folks (that's essentially the problem), but they do exist, and they are basically stuck having to rewrite their NXG apps in some other tool. I can only hope that they pick LabVIEW. I don't know if this will help us or hurt us with customers in the future... on one hand, people may say, "Well, you let us down on NXG, why should we trust you will be there for us on any new products?" On the other hand, this decision was clearly made listening to customer feedback, and it takes a lot of humility to swallow a loss that big, which may make customers trust our judgement more in the future. And, really, there's nothing to compare with the scale of NXG -- an entire computing platform -- so this does seem like something that needs to be judged in isolation. I really like programming in G. I like being able to expand G to make it more powerful. I wanted NXG to succeed because it had the potential to be a better G. It failed. Its failure means more resources for the existing LabVIEW platform, which will directly help our customers in the short run. It leaves open some big questions for the long run. So, in summary: I think it was a decision that had to be made, and I'm happy to work for a company that can learn from new data, then admit a mistake, and then figure out how to correct it.

Hello everybody! During a few last years I received multiple appeals to release AES library that I developed in 2011 into open-source. So, I've just done exactly this: https://github.com/IgorTitov/LabVIEW-Advanced-Encryption-Standard I released it under MIT license (which means that there are no restrictions whatsoever). No VI passwords, no uglification. LabVIEWishly Yours, Igor Titov.

The NIWeek 2015, 2016, 2017 Videos are compressed and ready for down load from Tecnova's ftp server I would strongly recommend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple videos the ftp client makes things much easier. My ftp client of choice is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found 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. Please Let me know if you find any issues with the videos

“There was this fence where we pressed our faces and felt the wind turn warm and held to the fence and forgot who we were or where we came from but dreamed of who we might be and where we might go...” -- Opening lines of “R is for Rocket” by Ray Bradbury I spent 20 years building this G language of ours. It’s time for me to go enjoy the fruits of that labor as a user! I will still be employed by NI, but I will be working full time for Blue Origin. As part of the NI “Engineer in Residence” program, I will be on loan to Blue Origin to revise their engine and support test systems. They wanted a Certified LabVIEW Architect with deep knowledge of LVOOP, multiple years of experience with Actor Framework, and deep knowledge of cRIO and PXI. I asked, “Can we negotiate on that last part?” They said, “Yes, yes we can.” Turns out, based on the interview, I know more than I thought – apparently some hardware knowledge does rub off just by sitting near it for a couple decades. This new job runs for six months, but it is extensible through the end of 2021 at the discretion of myself and Blue Origin. When I come back, I do not know if I will be returning to LabVIEW. Spaceflight has long been a passion of mine. Over my 20 years with LabVIEW R&D, I have had the chance to help out with various Mars rovers, large telescopes, and rocket launches. It has been awesome, and I’m proud of the language advances I brought to LabVIEW that helped so many users along the way. Now, I am going to focus on just one customer for a while... a customer with very large rocket engines! My last day will be Friday, October 23. I will not have the same availability to respond to posts as I have in the past, but Aristos Queue will still be around on the forums. “And, walking, I went beyond the fence.” -- ending of “R is for Rocket”

View File Flatline Controls A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network JDP Science Tools group on NI.com. Submitter drjdpowell Submitted 06/13/2016 Category User Interface LabVIEW Version 2011 License Type BSD (Most common)

I had a LabVIEW user group meeting last week talking about embedded platforms and when I got home I saw the Intel Edison collecting dust on my desk: Since it is x86, I thought I would try to deploy a Linux LabVIEW executable to the Edison and run it in the Run Time Environment. Here is what I did: 1) Install Ubilinux, based on Debian Linux, from: https://learn.sparkfun.com/tutorials/loading-debian-ubilinux-on-the-edison 2) Install xvfb, a virtual framebuffer display server (no video on this device), fluxbox display manager and x11vnc: apt-get install xvfb fluxbox x11vnc xterm 3) Install the prereqs for the LabVIEW RTE (this was already installed with the above, but good to check): apt-get install libxinerama1 libgl1-mesa-glx 4) Download the RTE and unzip it, I put it in /home as /root gets pretty full wget http://ftp.ni.com/support/softlib/labview/labview_runtime/2014/Linux/LabVIEW2014RTE_Linux.tgz tar zxvf LabVIEW2014RTE_Linux.tgz 6) the RTE is an rpm and we need deb so get alien: apt-get install alien 7) convert the rpm to deb (this takes a while): alien -k -c labview-2014-rte-14.0.0-1.i386.rpm 8) Install the RTE: dpkg -i labview-2014-rte_14.0.0_1.i386.deb 9) Install some missing fonts: apt-get install xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic ttf-mscorefonts-installer At this point, I compiled the "UDP sender" from the examples using LabVIEW for Linux 2014 with my desktop hardcoded as the destination IP address. I copied the executable over to the Edison, ran it as follows: xvfb-run ./send and a few seconds later on my desktop: I am getting UDP packets from my Edison to my host computer sent from a LabVIEW application! I was pretty excited by this. At this point, I decided that I wanted to see if I could get a GUI running. I started up a virtual display and launched fluxbox using: Xvfb -screen 0 800x600x16 -ac & DISPLAY=:0 fluxbox & And from a linux VM, I created a SSH tunnel and started a VNC connection ssh -l root -L 5900:localhost:5900 192.168.222.90 'x11vnc -localhost -display :0' vncviewer localhost I was greeted with a desktop so I launched a terminal and executed the send program. Here is the result: So there you have it, LabVIEW executables running on a headless Intel Edison with remote desktop support. Oh, and once the VI is running from the remote desktop, you are free to disconnect and reconnect without terminating the running VI. As to resource usage, I show while running everything: root@ubilinux:~# free -h total used free shared buffers cached Mem: 960M 174M 786M 0B 9.0M 100M -/+ buffers/cache: 64M 896M Swap: 0B 0B 0B htop: 1 [##** 9.6%] Tasks: 35, 12 thr; 1 running 2 [##*** 12.7%] Load average: 0.15 0.20 0.11 Mem[|||#**** 65/960MB] Uptime: 00:07:25 Swp[ 0/0MB] PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2018 root 20 0 16132 5428 2772 S 5.0 0.6 0:19.94 x11vnc -localhost 2047 root 20 0 4380 1580 1204 R 5.0 0.2 0:00.83 htop 2033 root 20 0 120M 39620 27756 S 5.0 4.0 0:16.89 ./send 1987 root 20 0 52136 14608 5016 S 3.0 1.5 0:17.00 Xvfb -screen 0 80 2016 root 20 0 12540 6300 2436 S 0.0 0.6 0:02.85 sshd: root@notty 1 root 20 0 2200 716 616 S 0.0 0.1 0:00.81 init [2] 202 root 20 0 2540 1108 716 S 0.0 0.1 0:00.28 udevd --daemon 360 root 20 0 2536 816 428 S 0.0 0.1 0:00.01 udevd --daemon 366 root 20 0 2536 820 428 S 0.0 0.1 0:00.00 udevd --daemon 1552 root 20 0 5760 1424 1040 S 0.0 0.1 0:00.14 /sbin/wpa_supplic 1752 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.17 /usr/sbin/rsyslog 1754 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.01 /usr/sbin/rsyslog 1755 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.01 /usr/sbin/rsyslog 1747 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.23 /usr/sbin/rsyslog 1801 root 20 0 2424 608 520 S 0.0 0.1 0:00.00 /usr/sbin/udhcpd 1837 ntp 20 0 5304 2020 1572 S 0.0 0.2 0:00.11 /usr/sbin/ntpd -p F1Help F2Setup F3SearchF4FilterF5Tree F6SortByF7Nice -F8Nice +F9Kill F10Quit The VI is using about 5% CPU as well as 5% on the the VNC server and 3% on the virtual framebuffer. Here is the disk usage: root@ubilinux:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 1.4G 1.3G 78M 95% / /dev/root 1.4G 1.3G 78M 95% / devtmpfs 480M 0 480M 0% /dev tmpfs 97M 300K 96M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 193M 0 193M 0% /run/shm tmpfs 481M 12K 481M 1% /tmp /dev/mmcblk0p7 32M 5.3M 27M 17% /boot /dev/mmcblk0p10 1.3G 125M 1.2G 10% /home It's pretty tight, you will definitely run out if you do not do the RTE installation from /home. As to IO, I have not played much with doing anything with the IO ports, that's next on my list. I wanted to share my progress so far and get people's feedback. Thanks Jon

To all things there is a season. Jeff Kodosky helped found National Instruments and invented LabVIEW. He inspired hundreds of us who shapes its code across four decades. But Jeff says it is time to change his focus. Today, NI announced Jeff’s retirement. He will probably always be noodling around on LabVIEW concepts and will remain open to future feature discussions. But his time as a developer is done. Maybe you didn’t know that? Jeff still slings code, from big features to small bugs. He’s been a developer most of the years, happy to have others manage the release and delivery of his software. I spent over two decades working at his side. He taught me to look for what customers needed that they weren’t asking for, to understand what problems they didn’t talk about because they thought the problems were unsolvable. And he built a team culture that made us all collaborators instead of competitors. Thank you, Jeff, for decades of brilliant ideas and staying the course to see those develop into reality. Your work will continue on as one of the key tools on humanity’s expansion to Mars.

June 3 will be my last working day at NI. After almost 22 years, I'm stepping away from the company. Why? I found a G programming job in a field I love. Starting June 20, I'm going to be working at SpaceX on ground control for Falcon and Dragon. This news went public with customers at NI Connect this week. I figured I should post to the wider LabVIEW community here on LAVA. I want to thank you all for being amazing customers and letting me participate vicariously in so many cool engineering projects over the years. I'm still going to be a part of the LabVIEW community, but I'm not going to be making quite such an impact on G users going forward... until the day that they start needing developers on Mars -- remote desktop with a multi-minute delay between mouse clicks is such a pain! 🙂

How Software Companies Die – Orson Scott Card The environment that nurtures creative programmers kills management and marketing types - and vice versa. Programming is the Great Game. It consumes you, body and soul. When you're caught up in it, nothing else matters. When you emerge into daylight, you might well discover that you're a hundred pounds overweight, your underwear is older than the average first grader, and judging from the number of pizza boxes lying around, it must be spring already. But you don't care, because your program runs, and the code is fast and clever and tight. You won. You're aware that some people think you're a nerd. So what? They're not players. They've never jousted with Windows or gone hand to hand with DOS. To them C++ is a decent grade, almost a B - not a language. They barely exist. Like soldiers or artists, you don't care about the opinions of civilians. You're building something intricate and fine. They'll never understand it. Beekeeping - Here's the secret that every successful software company is based on: You can domesticate programmers the way beekeepers tame bees. You can't exactly communicate with them, but you can get them to swarm in one place and when they're not looking, you can carry off the honey. You keep these bees from stinging by paying them money. More money than they know what to do with. But that's less than you might think. You see, all these programmers keep hearing their fathers' voices in their heads saying "When are you going to join the real world?" All you have to pay them is enough money that they can answer (also in their heads) "Jeez, Dad, I'm making more than you." On average, this is cheap. And you get them to stay in the hive by giving them other coders to swarm with. The only person whose praise matters is another programmer. Less-talented programmers will idolize them; evenly matched ones will challenge and goad one another; and if you want to get a good swarm, you make sure that you have at least one certified genius coder that they can all look up to, even if he glances at other people's code only long enough to sneer at it. He's a Player, thinks the junior programmer. He looked at my code. That is enough. If a software company provides such a hive, the coders will give up sleep, love, health, and clean laundry, while the company keeps the bulk of the money. Out of Control - Here's the problem that ends up killing company after company. All successful software companies had, as their dominant personality, a leader who nurtured programmers. But no company can keep such a leader forever. Either he cashes out, or he brings in management types who end up driving him out, or he changes and becomes a management type himself. One way or another, marketers get control. But...control of what? Instead of finding assembly lines of productive workers, they quickly discover that their product is produced by utterly unpredictable, uncooperative, disobedient, and worst of all, unattractive people who resist all attempts at management. Put them on a time clock, dress them in suits, and they become sullen and start sabotaging the product. Worst of all, you can sense that they are making fun of you with every word they say. Smoked Out - The shock is greater for the coder, though. He suddenly finds that alien creatures control his life. Meetings, Schedules, Reports. And now someone demands that he PLAN all his programming and then stick to the plan, never improving, never tweaking, and never, never touching some other team's code. The lousy young programmer who once worshiped him is now his tyrannical boss, a position he got because he played golf with some sphincter in a suit. The hive has been ruined. The best coders leave. And the marketers, comfortable now because they're surrounded by power neckties and they have things under control, are baffled that each new iteration of their software loses market share as the code bloats and the bugs proliferate. Got to get some better packaging. Yeah, that's it. Originally from Windows Sources: The Magazine for Windows Experts, March 1995

You know how you can change the wire appearance for a class in the class properties? As it turns out, LabVIEW internally allows for more flexibility than that dialog gives you. So I made an advanced wire editing tool...and unlike a lot of stuff I post, you can actually use this for serious projects, because it does not use any private/unsupported LabVIEW functionality! With this tool, you can set wire size without limits (with results similar to this), customize both wire layers with any 8x8 monochrome pattern, and also mess with different draw options. Strangely, a few of these settings seem to have no effect, and many of the options for one of them actually crash LabVIEW. (These ones are disabled in my tool, but you can re-enable them by editing a typedef.) Given that this is actually a documented, supported property that's officially supposed to work, I've reported this as a bug to NI; if any NI engineers see this and feel like investigating, you can refer to service request #7762024. Latest version: Wire Studio 2.zip Old versions: Revision 1

Hi, I figured people here may be more interested in this project. I have some cool graph extensions I'm building in an open source project, which make some nice graphical overlays for XY graphs and waveform graphs in LabVIEW. I've got a github page where you can grab the code, support the project or just have a look at some of the same screenshots. Everything updates live in the graph, so you really need to see it, to get how it all works, so here you go: https://github.com/unipsycho/Graph-Extensions-LabVIEW Please star follow the project if you want to see this developed and I'd appreciate any feedback or ideas to extend it further. The markers are very much IN development right now, so no where near finished, but the tools can still be seen working. THANKS!

Update to this post: My sabbatical has ended. I went from Blue Origin to Microsoft, but as of a couple weeks ago, I have now returned to LabVIEW development. At some point, I may put together a public summary of my experiences as a full-time G dev. For now, be assured that I am feeding that experience back into the feature backlog priority list!

Note: G Code Manager is now available at GitHub: https://github.com/veritechpl/gcm G Code Manager GCM is a tool that makes the properties of Project Items in Project Explorer window more accessible, removing unnecessary waiting times and modal windows. In runs in window next to the Project Explorer window and shows the items properties immediately after selecting new item in the explorer. GCM also allows you to create your own plugins to access those Project Items! Requirements The package was built in LabVIEW 2014, it should also run in LabVIEW 2015. How to start In the Project Explorer window click on the Tools menu, then select G Code Manager -> Run GCM… Download IMPORTANT NOTICE This tool was made using some internal LV APIs which are not fully tested and documented It is in very early stage when it comes to stability It may cause LV to crash! I strongly advise using source control - if you're not using one, do not even install this tool! (Above statements are really for your own good - I'm using this tool in my everyday work and I don't have any major issues. However, you might accidentaly clear your VI description or icon, or something like that, so be prepared for it by using source control like SVN or Git to revert the changes). Current Version Version 1.14.0.71 Download: veritech_labview_code_manager-1.14.0.71.vip - Added GCM settings screen - Added option to automatically open GCM with the project Older Versions Verstion 1.13.0.67 Download: veritech_labview_code_manager-1.13.0.68.vip - Interface cosmetics. Smaller window size - GCM remembers last selected plugin for the project item type - Dock button added, which makes GCM window always on front - Added support for build specifications: EXE, Installer, RT Exe, FPGA - Added VI Window Properties plugin (beta) - Added VI Execution Properties plugin (beta) Version 1.11.0.61 veritech_labview_code_manager-1.11.0.61.vip - Icon Editor: Added "Default Font Settings" which sets the font to 8 pt, centered, capitalized. - Fixed the synchronization issue between plugins (icon edited in Icon Editor was not updated in Basic Documentation). - Added new incoming events for plugins to better handle items selection/deselection and plugin activation/deactivation (see the attached documentation) Note: The plugins API was changed in this version. If you've made your plugin in previous versions, please refer to the updated documentation. If you have any problems, just contact me Documentation: GCM.pdf Version 1.10.0.58 veritech_labview_code_manager-1.10.0.58.vip - Added Icon Editor for VIs, which currently allows editing the icon text or clearing the icon completely Documentation: GCM.pdf Version 1.9.0.54 veritech_labview_code_manager-1.9.0.54.vip See this document for more information: GCM.pdf

Please see this link for Video downloads The NIWeek 2017 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444

I want to let LAVA know about a feature of LV 2016 that may not get much press. The In-Place Element structure has a new pair of border nodes to let you access the attributes of a variant without copying them out of the variant. This will VASTLY improve the performance of tools that use variant attributes as lookup tables. I strongly encourage everyone who works on this to look at the shipping example: labview\examples\Performance\Variant Attribute Lookup Table\

TDF team is proud to propose for free download the scikit-learn library adapted for LabVIEW in open source. LabVIEW developer can now use our library for free as simple and efficient tools for predictive data analysis, accessible to everybody, and reusable in various contexts. It features various classification, regression and clustering algorithms including support vector machines, random forests, gradient boosting, k-means and DBSCAN, and is designed to interoperate with the Python numerical and scientific libraries NumPy and SciPy from the famous scikit-learn Python library. Coming soon, our team is working on the « HAIBAL Project », deep learning library written in native LabVIEW, full compatible CUDA and NI FPGA. But why deprive ourselves of the power of ALL the FPGA boards ? No reason, that's why we are working on our own compilator to make HAIBAL full compatible with all Xilinx and Intel Altera FPGA boards. HAIBAL will propose more than 100 different layers, 22 initialisators, 15 activation type, 7 optimizors, 17 looses. As we like AI Facebook and Google products, we will of course make HAIBAL natively full compatible with PyTorch and Keras. Sources are available now on our GitHub for free : https://www.technologies-france.com/?page_id=487

Nice! While you are there please convince Elon to buy NI and turn it back into an engineering company 🤣

he information formally listed in this thread is no longer valid. The site is now offline. All the videos have been moved to dedicated event pages on the LabVIEW Wiki. https://labviewwiki.org/wiki/Events - LabVIEW Wiki https://www.youtube.com/channel/UCUiBucUImKZERoTzaOtHB5g/featured - Youtube Channel

So I wasn't there but there was a public announcement at GDevCon about a new edition of LabVIEW called Community Edition which is the LabVIEW Professional version (I read that as application builder included), and completely free with no watermarks for non-commercial use. NI hasn't made any post about timelines, or other details yet but I hear those are in the works. This is obviously a huge thing for LabVIEW as any monetary barrier to entry will discourage new developers from experimenting with LabVIEW. And then there is the fact that those that are familiar with LabVIEW, can keep up with the newest version outside of their company, or when they are between jobs.

Hey folks. this year we're trying something new. All Videos for NIWeek 2019 can be found here: https://labviewwiki.org/wiki/NIWeek_2019 Feedback welcome. Thanks to @Mark Balla and other volunteers for recording the videos. Edit: We're starting to add the back catalog to YouTube. NIWeek 2018 videos are also up.

UPDATE: These first few revisions are more or less broken. The first fully working version can be found here. 8 Years ago the first version of the XNode Manager was posted to the code repository, and it hasn't seen an update since 2009. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. I didn't spend too much time on it, and I don't think it replicates all the XNode Manager functionality, but it does have some major improvements. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. Saved in 2013, but could probably back save earlier if requested. If I get more time I'll add some features, and add it to the Code Repository. XNode Editor.zip

I put together a series of articles while working on an AF 101 presentation for our local CLD summit. Check them out and let me know what you think or if you have any questions/improvements. Part 1 – The Background Part 2 – The Actor Part 3 – Launching and Communicating Part 4 – Being Productive With Actors Basic Walkthrough – Creating a Logger

Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.

This is how I clear errors.

LAVA has won an NI award for LUGnuts at NI Week, the largest independent online user group. Thank you everyone for making the online community something to be proud of.

Nice try, NSA.

Usual disclaimer. Method described below is strictly experimental and not recommended to use in real production. N.B. This is based on .NET, therefore Windows only. This text is sorta lengthy, but no good TL;DR was invented. You may scroll down to the example, if you don't want to read it all. One day I was stalking around NI forums and looking at how folks implement their callback libraries to call them from LabVIEW. After some time I came across something interesting: How to deal with the callback when I invoke a C++ dll using CLF? There someone has figured out how to make LabVIEW give us a .NET delegate using a dummy event. This technique is different from classic way of interfacing to callbacks, because it allows to implement the callback logic inside a VI (not inside a DLL), but still it requires writing some small assembly to export the event. Even though Rolf said there that it's not elegant, I decided to study these samples better. Well, it was, yeah, simple (no wonder it was called SimpleProxy/SimpleDemo/SimpleCallBack) and very instructive at the same time. It worked very well in both 32- and 64-bit LabVIEW, so I had fun to play around and learn some new things about .NET events and C#. After all I started to think, whether we really need this dummy assembly to obtain a delegate... Initially I was looking for a way to create a .NET event at the run-time with Reflection.Emit or with Expression Trees or somehow else, but after googling for few days and trying many things in both C# and F# I came to a conclusion that it's impossible. One just can create event handlers and attach them to already existing events, not create events on their own. Okay. First I decided to know how exactly LV native Register Event Callback node works. Looking ahead I'll say it was a dead end, but interesting. Ok, the Register Event Callback node in fact consists of two internal functions - DynEventAllocRegInfo and DynEventRegister - with the RegInfo structure filling between them. The first one creates and returns a new RegInfo with a Reg Event Callback reference, the second one actually registers the RegInfo and the reference in the VI Data Space (the prototypes and the struct fields are more or less figured out). But when I started to play with the CLFN's to replace the Register Event Callback node, I ran into few pitfalls. To work properly the DynEventRegister function needs one of the RegInfo's fields to be a type index of (hidden) upper left terminal of the Constructor node. This index is stored in the VI's Data Space Type Map (DSTM) and determined at the compile time. I did not find a reliable way to pull it out of the DSTM. Moreover the RegInfo struct doesn't have a field for the VI Entry Point or anything like that. Instead LabVIEW stores the EP in some internal tables and it's rather complicated to get it from there. For these reasons I have given up studying the Register Event Callback node. Second I turned my attention to the delegate call by its pointer. I soon found out that LabVIEW generates some middle layer (by means of .NET) to convert the parameters and other stuff of the native call to the VI call. That conversion was performed by NationalInstruments.LabVIEW###.dll in the resource folder (a hidden gem!). This assembly has almost everything that we need: the CallbackInfo and CallbackHandler classes, and the latter has two nice methods: CallLabView and CreateCallbackHandlerDelegate. Referring to the SimpleDemo/SimpleCallBack example, when we call the delegate by its pointer, LabVIEW calls this chain: CallLabView -> EventCallbackVICall internal function -> VI EP. All that was left to do was to try it on the diagram with .NET nodes, but... there was another obstacle. Sure that you'll connect the inputs right? You will not. These parameters are not what they seem (at least, one of them). The viref is not a VI reference, but a VI Entry Point pointer. It's not a classic function EP pointer, but a pointer to a LabVIEW internal struct, which eases the VI calls (it's called "Vepp" in the debug info). The userParam is a pointer to the User Parameter as for the Register Event Callback node. The cookie is a pointer to the .NET object refnum from the Constructor node (luckily NULL can be passed). And the type and flags are 0 and 0x80000000 for standard .NET callbacks. Now how and where could we get that VI EPP? Good question. There is a function inside LabVIEW, that receives a VI ref and returns an allocated VI EPP. But sadly it's not exported at all. Of course, this ain't stoppin' us. I used a technique to find the function by a string constant reference in the memory of a process. It's known to be not very reliable between different versions of the application, therefore many tests were made on many versions of LabVIEW. After finding the function address, it's possible to call it using this method (kind of a hack as well, so beware). Is this all enough to run .NET nodes now? For the CallLabView yes. It's simplier than CreateCallbackHandlerDelegate, but doesn't provide a delegate. It passes the parameters to the VI, calls it and returns. The return and parameters could be utilized onwards, of course, but nothing more. To obtain a delegate it's necessary to call the CreateCallbackHandlerDelegate. This method wants the handlerType input wired and to be valid in .NET terms, so proper type must be made. Initially I tried to use .NET native generic delegates: Action, Predicate and Func. Everything went fine except the GetFunctionPointerForDelegate, which didn't want to work with such delegates and complained. The solution was in applying some obscure MakeNewCustomDelegate method as proposed here. Now the GetFunctionPointerForDelegate was happy to provide a pointer to the delegate and I successfully called the callback VI both "manually" and by means of Windows API. So finally the troubles were over, so I could wrap everything into SubVI's and make a basic example. I chose EnumWindows function from WinAPI, because it's first that came to my mind (not the best choice as I think now). It's a simple function: it's called once with a callback pointer and then it starts looping through OS windows, calling a callback on each iteration and passing a HWND to it. This is top-level diagram of the example: I won't be showing the SubVI's diagrams here as they are rather bulky. You may take a look at them on your own. I'll make one exception though - this is the BD of the callback VI. As you could know, EnumWindowsProc function must return TRUE (1) to continue windows enumeration. How do we return something from a callback VI? Well, it's vaguely described here, I clearly focus on this. You must supply first parameter as a return value in both Event Data clusters and assign these two to the conpane. On the diagram you set the return as you need. These are the versions on which I tested this example (from top to bottom). Some nuances do exist, but generally everything works well. LabVIEW 2023 Q3 32 & 64 (IDE & RTE) LabVIEW 2022 Q3 32 & 64 (IDE & RTE) LabVIEW 2021 32 & 64 (IDE & RTE) LabVIEW 2020 32 & 64 (IDE & RTE) LabVIEW 2019 32 & 64 (IDE & RTE) // 32b - on one machine RTE worked only w/ "Allow future versions of the LabVIEW Runtime to run this application" disabled (?), 64b - OK LabVIEW 2018 32 & 64 (IDE & RTE) LabVIEW 2017 32 & 64 (IDE & RTE) // CallbackInfo& lvCbkInfo, not ptr LabVIEW 2016 32 & 64 (IDE & RTE) // same LabVIEW 2015 32 & 64 (IDE & RTE) // same LabVIEW 2014 32 & 64 (IDE & RTE) // same LabVIEW 2013 SP1 32 & 64 (IDE & RTE) // same + another string ref + 64b: "lea r8" (4C 8D 05) instead of "lea rdx" (48 8D 15) LabVIEW 2013 32 & 64 (IDE & RTE) // same + no ReleaseEntryPointForCallback, CreateCallbackHandler instead of CreateCallbackHandlerDelegate LabVIEW 2012 32 & 64 (IDE & RTE) // same + forced .NET 4.0 LabVIEW 2011 32 & 64 (IDE & RTE) // same LabVIEW 2010 32 & 64 (IDE & RTE) // same LabVIEW 2009 32 & 64 (IDE & RTE) // same EnumWindows (LV2013).rar EnumWindows (LV2009).rar How to run: Select the appropriate archive according to your LV version: for LV 2013 SP1 and above download "2013" archive, for LV 2009 to 2013 download "2009" archive. Open EnumWindows32.vi or EnumWindows64.vi according to the bitness of your LV. When opened LV will probably ask for NationalInstruments.LabVIEW###.dll location - point to it going to the resource folder of your LV. Next open Create Callback Handler Delegate.vi diagram (has a suitcase icon) and explicitly choose/load NationalInstruments.LabVIEW###.dll for these nodes marked red: It's only required once as long as you stay on the same LV version. For the constant it may be easier to create a fresh one with RMB click on the lvCbkInfo terminal and choosing "Create Constant" entry. Now save everything and you're ready to run the main VI. Remarks / cons: no magic wand for you as for the Register Event Callback node, you create a callback VI on your own; the parameters and their types must be in clear correspondence to those of the delegate; obviously .NET callbacks are X times slower than pure C/C++ (or any other unmanaged code) DLL; search for CreateVIEntryPoint function address takes time (about several seconds usually); on 64 bits it lasts longer due to indirect ref addressing; no good way to deallocate VI EPP's; the ReleaseEntryPointForCallback function destroys AppDomain when called (after such a call the VI must be reopened to get .NET working) - usually not a problem for EXE's. Conclusion. Although it's a kind of miracle to see a callback VI called from 'outside', I doubt I will use it anywhere except home. Besides its slowness it involves so many hacks on all possible levels (WinAPI, .NET, LabVIEW) that it's simply dangerous to push such an application to real life. Likely this thread is more of a detailed reference for the future idea in NI Idea Exchange section.

This is a weekend project (ok, several weekends now) I've been meaning to share for a while. It's a proof of concept which I'd like to get some feedback on before I invest more time. The idea is to provide a toolkit that uses LabVIEW webservices to serve an interactive HTML5 representation of any application's front panel(s) as an easy way to monitor and control the application (over the internet) without the need for heavy applications or runtime engines. Just a browser. And because not everyone is a also web-developer, the work required to create that website should be done entirely by the toolkit. In my solution it's as easy as dropping a single vi on the block diagram, that registers the VI with the FrontPanelManager which takes care of all the data exchange between the website and the front panel. Here's a screenshot of an example front panel showing all supported elements and its HTML version on chrome: Obviously, there are some cosmetic differences that can be fixed later. Controls on both LabVIEW front panel and HTML site act as controls and are synchronised across the two. By default, the website queries the front panel every 250ms for new data. The refresh rate can be changed with the cog button in the bottom right corner. To run it open the project start the WebService Get the URL of Main.html and point your browser to it start "To Publish/Main.vi" and watch the data appear in the browser As I said this is a proof on concept and it's a long away from being a toolkit. I'm working on functions that appear in the Tools menu to automatically add and configure the webservice and dependencies and many other things. [2014]FPPublisher.zip

I've been surprised today with one of the LabVIEW's most useful functions (imo) which I use all the time. After so many years and only now seeing this behavior/feature. I thought I share it 🙂 I've always used an empty array of N-Dim for my desired type input. only to accidently find out today that I can also use a scalar for the type. ha!

View File Plasmionique Modbus Master This package contains the Plasmionique Modbus Master library for LabVIEW. It supports RTU, ASCII and TCP modes with the following function codes: 0x01 - Read Coils 0x02 - Read Discrete Inputs 0x03 - Read Holding Registers 0x04 - Read Input Registers 0x05 - Write Single Coil 0x06 - Write Single Register 0x07 - Read Exception Status 0x0F - Write Multiple Coils 0x10 - Write Multiple Registers 0x16 - Mask Write Register 0x17 - Read/Write Multiple Registers 0x2B/0x0E - Read Device Identification Other features include: - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout). - Sharing a Modbus session across multiple communication loops. - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order. - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. - Detailed help document available through the "Help->Plasmionique" menu. Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\": MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230 The most recent version of this library will always be released on LAVA first before going through NI's certification process. ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified License Type BSD (Most common)  

The core of our business has changed. Fewer users are developing their own test applications; instead, they're buying something off the shelf like TestStand. Fewer users are developing their own data acquisition software; instead, they're buying something off the shelf like FlexLogger. This trend alters significantly the role of LabVIEW (CG and NXG) in the NI ecosystem -- it becomes far less important to support whole application development (though, of course, we still do and will) and far more important to support "just a bit of customization" when the pre-built tools fail. A lot of software has an endless array of switches and options, but LV provides the ability for a user to write a custom routine to specify the behavior they want in some corner niche of a product. Think like Signal Express, able to generate sine wave, square wave, triangle wave or "pick a VI that generates the wave that you need" wave. What's funny about this is that although the app devs are growing rarer, they're also individually growing more profitable for NI as a whole because the companies still paying to develop custom software are the ones that are generally buying a lot of hardware to do something unique in the world (or not in the world, in the case of SpaceX, Blue Origin, Ad Astra, etc.). So I don't expect the big scale parts of LabVIEW to vanish, but I do expect them to be driven by specific requests from megascale customers rather than from the massed collective. The massed collective will be driving more of the IDE developments. At least, that's my suspicion at this time based on the presentations I've seen.

I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.

Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 21, 2019 Time: 7:30-10:00 pm Location: Uncle Billy's Brewery and Smokehouse, 1530 Barton Springs Rd, Austin, TX 78704 (1.5 miles from Convention Center) Cost: $25 Early Bird (through April 30th) $30 Regular Admission (through May 20th) $35 Door Price (May 21st) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like street corn, cole slaw, and bbq beans. A vegetarian option is available when purchasing tickets. Cash beer bar. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's a covered, outdoor venue in Austin during Spring, so dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. Hope to see you there! Chime in once you buy tickets to let everyone know you're coming. ------------>>------------>> Get LAVA BBQ 2019 Tickets Here <<------------<<------------ The venue is a 30 minute walk from the convention center, or a $6 Uber. Get together and carpool, people are typically gathering at Challenge the Champions in the Expo Hall, which is great fun. There is a free parking garage behind the building. We'd love for you to sponsor a door prize - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. Single item donations work best. If donating more than one item, then multiple identical items is strongly preferred. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. Donations are typically $25-$200 in value. Not recommended: Apparel (hats, t-shirts, underwear, etc.) - never the right size Software licenses (Toolkits, add-ons, LabVIEW) Branded trade show booth type giveaways (mouse pads, pens, keychains, etc.) Jokes or something meant as a gag and not a real prize

We'll grow into it eventually 😋

There are a bunch of objects in LabVIEW that aren't exposed in the default palettes, and are normally inaccessible except through scripting. I made a Quick Drop plugin that exposes all of these. Many of these are no longer supported, and others never were supported in the first place. Hidden ones are displayed with an "X" next to them to warn you: as I often say, be careful with these, and don't use them in any code you care about, as they can cause crashes, data corruption, and who knows what else! Download the LLB below and place it in your <LabVIEW install dir>\resource\dialog\QuickDrop\plugins folder. Then press Ctrl+Space, Ctrl+S to open this dialog. Select an item from the list and click OK, and there you go. There's some interesting/strange stuff in here! EDIT: Couple things I forgot to mention. The first time you open this (and whenever you rebuild the list) it uses two private properties on the app reference, to get the list of controls and indicators in the palette. Since this is just a property read, I'm sure the worst that could happen is a crash when you try to open the dialog, but I can't make any guarantees. Also there's some false positives for hidden items, mainly with front panel controls/indicators that come in different styles. Place by Style.llb

Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Change log for 2018: Prices have been rolled back to a previous, cheaper version New location, see below Date: Tuesday, May 22, 2018 Time: 7:30-10:00 pm Location: Uncle Billy's Brewery and Smokehouse, 1530 Barton Springs Rd, Austin, TX 78704 (1.5 miles from Convention Center) Cost: $25 Early Bird (through May 4th) $30 Regular Admission (through May 20th) $35 At the door (May 21st - 22nd) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like mac and cheese, cole slaw, and potato salad. A vegetarian option is available when purchasing tickets. Cash beer bar. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's a covered, outdoor venue in Austin during Spring, so dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. ------------>>------------>> Get LAVA BBQ 2018 Tickets Here <<------------<<------------ The venue is now a 30 minute walk from the convention center, or a $6 Uber. Get together and carpool, people are typically gathering at Challenge the Champions in Exhibit Hall 4, which is great fun. There is a free parking garage behind the building. We'd love for you to sponsor a door prize - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. Single item donations work best. If donating more than one item, then multiple identical items is strongly preferred. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. Donations are typically $25-$200 in value. Not recommended: Apparel (hats, t-shirts, underwear, etc.) - never the right size Software licenses (Toolkits, add-ons, LabVIEW) Branded trade show booth type giveaways (mouse pads, pens, keychains, etc.) Jokes or something meant as a gag and not a real prize Hope to see you there! Chime in once you buy tickets to let everyone know you're coming.

I just became aware of this thread and I'm not going to go back and comment on all the discussion points that have been made before, except to say: The original code which did not use a shift register was wrong, but happened the work because of a bug in the LabVIEW inplaceness algorithm. Any input tunnel should retain its original value of every iteration of the loop, so it should've stayed not-a-refnum every time, and therefore the dynamic registration should should have been lost where the loop iterated. The issue was that the left dynamic registration terminal (which is always in-place to the right one) was also in-place to the input tunnel, causing its value to be stomped incorrectly. This is clearly a bug and needed to be fixed. It violated dataflow 'rules' for how tunnels are supposed to behave, and could've made some correct programs yield incorrect behavior. This is not a change that would break a correctly written program, so it does not qualify as an "API breaking" change; this usage has always been wrong but happened to work due to a bug. (This is categorically different than changing behavior of correct code or even changing undocumented behavior, which we try strenuously to avoid.)

Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 23, 2017 Time: 7:00-10:00 pm Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78701 (1 mile from Convention Center) Cost: $30 Early Bird (until May 6th) $35 Regular Admission (until May 22nd) $40 At the door (May 22nd - 23rd) Meal Options: Expect to enjoy your choice of meats (ribs, brisket, turkey) with sides like beans, cole slaw, and potato salad. There is always plenty of food. A vegetarian option is available when purchasing tickets. Cash bar, beer and wine. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's an outdoor venue in Austin during Spring. So dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. get tickets on The LAVA BBQ 2017 Event Page Do you want to sponsor a door prize? - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. We would prefer a single item donation. If donating more than one item, then multiple identical items is strongly preferred. So we don't spend our time on a flood of refrigerator magnets, please donate something valued at $25 or more. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. All prizes are acceptable except those listed below (examples from 2015 and 2016): Not recommended: Apparel (hats, t-shirts, underwear etc) Branded trade show booth type giveaways (mouse pads, pens, keychains etc) Software licenses (Toolkits, add-ons, LabVIEW) Jokes or something meant as a gag and not a real prize Hope to see you there! Chime in once you buy tickets to let everyone know you're coming.

The best thing about UDP jokes is that I don't care if you get them or not.

So in a presentation about XNodes I was asked a question about what were the valid "Reply" options for an XNode ability. Some abilities have a reply as a 1D array of string and it appears to work like a QMH where you provide a list of states to go to and it does them one after another. I didn't know the answer but I knew scripting could help. So I scanned a bunch of XNodes for what strings were on the block diagram going to the reply and here are the abilities, along with the reply strings I've seen used. AdaptToInputs UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs Copy GenerateCode UpdateTerms UpdateImageAndBounds FailTransaction DoubleClick FailTransaction UpdateTerms UpdateImageAndBounds GenerateCode GenerateCode PreserveUserCodeGUID GetError Message UpdateTerms UpdateImageAndBounds GenerateCode FailTransaction ForceAdaptToInputs OnFontChange UpdateImageAndBounds UpdateTerms OnOperateClick UpdateImageAndBounds GenerateCode OnResize UpdateTerms UpdateImageAndBounds GenerateCode OnDrop UpdateTerms UpdateImageAndBounds GenerateCode OperateClick ShowMenu RefeeChanged GenerateCode UpdateImageAndBounds UpdateTerms RespondToDrop GenerateCode UpdateTerms UpdateImageAndBounds SelectMenu UpdateImageAndBounds UpdateTerms GenerateCode FailTransaction ReplaceSelf Size UpdateImageAndBounds UpdateTerms GenerateCode UpdateState GenerateCode ForceAdaptToInputs IssueWarning UpdateStateWithRef UpdateImageAndBounds UpdateTerms GenerateCode ReplaceSelf So the unique values that I've seen put into the Reply are the following. I am unsure if only some abilities only support some replies. UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs FailTransaction PreserverUserCodeGUID GetError ShowMenu ReplaceSelf IssueWarning As for what do these do? Well some are more obvious than others, but here is some text I found in one of the XNodes that helps: FailTransaction: LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel. GenerateCode: This will cause a type propagation if appropriate, and will cause the XNode to GenerateCode when type propagation is run. UpdateImage: LabVIEW will call Image and invalidate the XNode. UpdateImageAndBounds: LabVIEW will call Bounds and Image and resize and invalidate the XNode. It will not call Size. Size is only called if the user resizes the XNode (so that you may update your state and return this reply). Make sure that if your terminals need to change size or location, you also return UpdateTerms. This reply will set the transaction type. UpdateTerms: LabVIEW will call Terms and create, delete, and move terms as necessary. ForceAdaptToInput When mutating an old, unconfigured Express VI, we need to ForceAdaptToInputs before code gets generated. AdaptToInputs used to always get called before GenerateCode. But that is no longer the case in LV2011.

Hi all, I'd like to introduce LQ Widgets, a library to bring advanced GUI features to LabVIEW. It is powered by the Qt toolkit plus the Qwt library (Qt Widgets for Technical Applications). This library consists of two major subcomponents that might interest LabVIEW users: A GUI framework that is powerful, flexible, and comprehensive (see demos below). A event-driven, intra-process communications framework. You can establish connections using (i) LabVIEW user events, (ii) callback VIs, or (iii) string specifications. Here it is in action: Why a GUI library? The Idea Exchange has many, many posts about improving LabVIEW's GUI capabilities. However, we likely have to wait several years at least before these wishes are granted (see AristosQueue's post at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-updating-the-GUI-a-priority-in-a-near-term-LabVIEW-release/idc-p/2710511#M26394). The required technologies are actually available right now. In fact, they have been available for many years. All we need is a way to access them easily from LabVIEW. LQ Widgets aims to provide this access. Why yet another communications framework? Providing a comms library wasn't part of my original goal. Nonetheless, the system used by the GUI components can also be used for non-GUI purposes, so it's here for you to try. Where to get it? Downloadable packages: Package for LabVIEW 2014 (recommended; take advantage of the the new web-based documentation) Package for LabVIEW 2013 Quick start guide at https://github.com/JKSH/LQWidgets#usage. The C++ source code is also easily accessible from here, if you're interested. EDIT: Most importantly, you must either extract the package to C:\LQWidgets\, or modify the output of src\LabVIEW\LQ Core\_Internal\Library Path.vi (thanks, mwebster!) Project roadmap See http://github.com/JKSH/LQWidgets/wiki/Roadmap Known Issues This is a pre-alpha release, which means (i) the API will likely change in the near future, (ii) the library is far from feature-complete, (iii) performance is not optimized, and (iv) you might experience crashes. Other issues include: You currently can't free any resources or disconnect signals, except by calling LQCoreEngine.lvclass:Stop Engine.vi QWinThumbnailToolButton cannot be applied to non-Qt windows, such as LabVIEW front panels After you start and stop the engine, QWinThumbnailToolButton no longer emits any signals when you click on it Workaround: Restart LabVIEW There are a few small memory leaks, which will persist until you close LabVIEW. Request for feedback What do you think of the GUI-related API? What do you think of the communications-related API? What is the single most promising aspect of this library? What is the single most frustrating aspect of this library? All comments and critique are most welcome. Thanks for your time!

Two ways to do what the OP is asking. 1. VI Server world: Children have a static link to their parents and Parents have a dynamic link to their children. This means that once a class is loaded into memory, the parent knows about the child. According to the documentation this will NOT work in the runtime environment, but i've used this several times when making IDE Tools. 2. Runtime Reflection: The following code will also give you an array of all of the children loaded in memory, but this time it uses less VI Server so it will work in the runtime environment. I use this when using a plugin architecture. I've not done a lot of performance testing with it, but on a medium-ish size project (one with ~150 classes) it only takes about 50 ms to run, so it's worked well for me so far. Having given you those solutions, I still think your best bet is to use a statically defined array. This will ensure things are loaded into memory when their needed and such. My solutions really only become worth it once you're dynamically loading classes.

I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions. The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets. Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development. After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target. This is a prelimenary package and I have not been able to test everything. What should work: Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too. Todo: In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up. Edit (4/10/2015): Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets. oglib_lvzip-4.1.0-b2.ogp

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