Agenda

Come learn about compiler technologies and how they relate to LabVIEW graphical dataflow (G). We’ll even explore how to could build a compiler for graphical dataflow programs, which would allow us to run our G code anywhere!

We’ve had access to object-oriented programming in LabVIEW since 2006, but not every application needs a fully realized object-oriented solution. For those that don’t, the judicious use of a few simple OO design patterns can simplify our work, improve modularity and testability, and deliver cleaner, more easily understood code, all while preserving the look and feel of “traditional” LabVIEW. We will draw on real-world solutions to explore the Template Method, the Factory, the Aggregator, and the State Pattern, and learn how those patterns evolve from and interact with traditional LabVIEW applications.

Allen C Smith has been using the NI platform to solve complex engineering challenges for 30 years.
*He is a Certified LabVIEW Architect, Certified Embedded Developer, Instructor, and LabVIEW Champion.
*He has been an NI Partner, worked for Alliance Partners, and served as a Systems Engineer with National Instruments. He is once again an NI Partner, offering services as a consulting software architect and engineer.
*While at NI, he developed the software tool support and official training course for the Actor Framework. He remains an AF evangelist and active member of the AF community.

Hunter Smith and Tom McQuillan battle it out in the LabVIEW IDE to decide hot-button coding style issues once and for all. In a fierce battle of wits, skill, and strategy, nothing’s off the table as they duke it out on topics from class outputs, to error handling, and VI icons. Come pick sides and dive into the practical and philosophical implications of coding style.

Hunter got his start in LabVIEW at NI as an applications engineer and K-12 engineering specialist working with myDAQ, LEGO, FIRST and founded the youtube channel WaterlooLabs. Hunter spent 7 years at SpaceX working on everything from rocket engine test stands, to user interfaces for astronauts. Now at JKI, Hunter works with customers in aerospace, biomedical, and semiconductor to solve hard problems with LabVIEW. Hunter is passionate about clean code, UX design, good documentation, and well automated devOps.

Tom is a stinky fart face who only cares about pedantic naming, and has never made a good VI icon in his life.

All started with a tough requirement: “The application needs more than 50 Synoptics” . With such a breath taking number, you need to think in a way of programming User Interfaces that is easily scalable, flexible and maintainable. As a programmer, the last thing you want is to have the need to implement a new feature and have to repeat the same piece of code in 50 different places. This presentation navigates through the process of getting a successful approach, from the idea to the implementation.

I work as Senior Software Engineer at Ulma Embedded Solutions in Spain and I help customers build test and control applications, mostly with NI Tools. I've been working with LabVIEW since 2011, when I started working at NI Spain. As a result of all these years working daily with NI Tools, I am a LabVIEW Certified Architect, TestStand Certified Architect and CPI.

It is standard to create an Application as a single monolithic Executable. However, there are many use cases that are better served with multiple executables that interact (a more “microservices” style). Use cases include having a Remote UI, or a “Watchdog” EXE that monitors the main exe and restarts it if needed, or a “Tester” EXE that puts another EXE through a series of tests, or an EXE that connects to hardware shared between multiple Applications or that has unique requirements, such as running on a separate computer or in a different bitness of LabVIEW. To really take advantage of these possibilities requires that network communication be easy. I will demonstrate how that can be achieved, specifically using the TCP communication features of Messenger Library. I will also discuss design principles, such as messaging patterns and client-server architecture, that support doing this more generally.

Originally from Canada, James Powell was introduced to LabVIEW while working as a Nuclear Physicist at Lawrence Berkeley National Lab in California. He is now a consultant doing LabVIEW full time and working for a range of technology-focused small companies near Oxford in the UK. He is the author of a number of freely-available packages for LabVIEW, including SQLite Library, JSONtext, Flatline Controls, and Messenger Library.

This presentation is one you don't want to miss. We will embark on a quest through the massive Icon Dungeon in the land of LabVIEW. The goal is to slay the dreaded default icon Dragon, which has brought much pain and suffering to LabVIEW developers. We will wander through the multi-level halls of VI icons to search for traps and recover the ancient knowledge of visual grouping. We will be spelunking into the Casm of Class icons. Finally, we will enter the Vault of Glyphs to fill our bags with loot and make a quick getaway through the dimension of Automation.

My name is Jesper Kjær Sørensen. I am a level 5 Systems Engineer aboard the fantastic vessel GPower, hailing from Denmark. I have replaced my character sheet three times over the past 14 years since I graduated from the University of Aalborg. Throughout the years, I have honed my skills in LabVIEW and TestStand and dabbled in the dark arts of Python programming. I have several side quests involving photography, dairy cows, my family, and my love for Dungeons and Dragons.

Most applications don’t need Augmented Reality but we shouldn’t let that stop us. At its heart, this is a classic test and measurement problem - capturing information about the world, processing and presenting it to the user but it provides some fun challenges and perhaps, new concepts.
This talk aims to explain the tools, techniques and provide just a little bit of theory so we can get to grips with cameras, image processing and 3D rendering in LabVIEW before plumbing this all together to make something delightful and maybe even useful.

An electronic engineer and CLA who enjoys building things and loves the chance to collaborate, share his knowledge and learn something new.

Since each software development team faces unique challenges, their processes and practices are tailored to their specific needs and goals. This panel discussion brings together members of different LabVIEW software development teams to share practical advice and real-world examples of what works for them. We will explore how teams arrived at their processes, and the factors they considered when making those decisions.
Panel members: Matthew Colligan (Dyson), Paul Morris (Precision Acoustics), Neil Pate (Philips Engineering Solutions) & Chris Woodhams (Argenta).

Leah Edwards is a Senior Electronics Integration Engineer at Dyson in Malmesbury in the UK. She uses LabVIEW to test new features in early prototypes of Dyson products, alongside 20 other engineers in the team. She is a version control evangelist and has written a docs-as-code tool for the team that she is really proud of.
In the past, some of the more random things she has created with LabVIEW are an electronic instrument that makes music from dry ice, and a robot that never loses at noughts and crosses.

When all the effort goes into calling Python from LabVIEW (NI Python Node), why would somebody familiar with Python not want to control LabVIEW from Python. This question started the search for a dedicated bi-directional tightly coupled interface from Python to LabVIEW. This resulted in a piece of code and architecture that can be reused in many different interfaces inside LabVIEW as well as outside like Python, MATLAB or maybe other? Together we can bridge the gap for one or the other to one and the other!

I’m working with LabVIEW for 8 years now at NI Alliance Partner VI Technologies. Working on design patterns and architecture is my kind of fun! Making application for all our kind of customers using the whole NI toolbox and more. Steady visitor of the DUTLUG. Passed my CLA just before corona missing out on all fun events. Passionate about everything with music; listening, freelance audio engineer, singer in a choir, trying to do some piano, bass and guitar.

LabVIEW is only used in the Test, Measurement, and Automation industries. LabVIEW is for scientists and engineers. LabVIEW is only good with hardware. LabVIEW jobs don’t pay well. No, no, and no! If you love LabVIEW, there are all sorts of careers available for you.

I founded my NI Alliance Partner company 15+ years ago and I’m going to invalidate all these statements by walking you through my own career. I hate dealing with hardware, 95% of my business has nothing to do with Test, Measurement, and Automation, I love my job and I make a good salary.

I’ll show you some of the most unexpected things I’ve done with LabVIEW for my customers, or just for fun.

Matthias is the founder and owner of STUDIO BODs, an NI Alliance Partner company operating in France and Canada. He has been working with LabVIEW for over 15 years and is a worldwide leading expert in LabVIEW applications deployment and licensing, databases, and web technologies. He is a LabVIEW Champion, a Certified Professional Instructor, and loves to share his experience and knowledge at NI Week or GDevCon whenever it is possible. He has also been awarded “World’s Fastest LabVIEW Programmer” in 2015.

G²CPU is designed as a wrapper around the popular opensource Arrayfire library for general GPU computing.
Through G²CPU you will be able to perform high performance computational tasks on any type of computing hardware. During runtime you will be able to choose between your CPU, CUDA device or even any OPENCL compatible compute unit. All while programming in the same way as you are used to with LabVIEW through probes, wires representing the data and much more.
G²CPU will be a crucial library for any team that need high performance computing, no matter the hardware.

I’m a LabVIEW architect with a decade of LabVIEW, computing and mechatronics experience. During which I worked with small and large teams on a wide range of projects. At the same time trying to provide presentations to share knowledge at LUGs and conventions.
Throughout the years I build up experience with external programs, tools and techniques which I try to bring to LabVIEW. This has brought me to many different projects. Ranging from FPGA accelerated computing, to running LabVIEW natively on Android and IOS, to now using ArrayFire within LabVIEW to provide a LabVIEW native high-performance computing experience.

Creating documentation for source code can be a tedious task. You understand the importance of accurate and up-to-date documentation. However, you may not have a proper writing process, and your manager may not prioritize it. The docs-as-code approach offers solutions to break this cycle by introducing methods and tools. This presentation will demonstrate how you can use git, mark-up languages, static website generators, auto-generated content, and CI to produce high-quality documentation for your LabVIEW code with less effort and stress. While every situation is unique, you will gain valuable insights to enhance your documentation process, making it a worthwhile task.

Olivier is the founder of Wovalab. His company offers assistance to individuals and teams who are looking to maximize their usage of LabVIEW.
With over 20 years of experience with LabVIEW™, Olivier helps teams to build well-structured LabVIEW applications using the latest industry best practices.
Olivier is also a board member of the DQMH® Consortium, where he plays a significant role in ensuring that the DQMH® framework remains up-to-date.
He is also the lead developer of several open-source projects, such as the Asciidoc for LabVIEW toolkit and Antidoc, which help developers create documents.
Olivier's goal is to empower LabVIEW enthusiasts worldwide.

NI’s business model has changed massively in the last few years and new offerings designed to get closer to the end customer need are under development, in areas such as ADAS record and replay. Often NI is also working with early access customers to deliver custom solutions based on these projects, meaning we must build customised functionality based on a platform that is changing, and often (usually) testing devices that are also under development from the customer and therefore changing rapidly. Despite this we are working to standardise our development processes and tooling. In this presentation I’ll discuss some of the processes we’ve adopted, experiments we’ve tried (some of which have failed but were still useful) and lessons we’ve learned.

I’ve been at NI for nearly 20 years in a variety of customer facing roles, in the last few years leading the delivery of customer projects through our Transportation business unit, primarily around the new ADAS record and replay offerings.

The Error Manager is a stand-alone, asynchronous LabVIEW module that can help log LabVIEW errors to file, display new error details to the user, and display the chronological or inverse-chronological list of errors that occurred since the module started. The module is framework-agnostic, reusable from project to project, and can keep working even when being “spammed” with many instances of the same error (spam protection functionality). Using the Error Manager in a new application helps ensure out-of-the-box robust and reliable error handling.

I’m a Test Systems Engineer that has experience with LabVIEW, TestStand, C#.NET, SQL, and with NI and non-NI hardware devices. I have been using LabVIEW since 2013, have been a CLA since 2017, and CPI since 2023. I help customers implement test systems through my company, Robusto Systems. I created two free and open-source right-click menu plugins for LabVIEW, available on VIPM: “Free Label To VI Description” and “New VI From Template”. I’m a chess lover and amateur player (around 2100 ELO) and would enjoy socialising over blitz games if the opportunity arises.

Don’t underestimate the complexity of industrial communications protocols, nor the completeness of LabVIEW toolkits for supporting these. This presentation collates crowd-sourced data on the woes and wahays of integrating National Instruments systems into an industrial network, providing any developer with an up to date and pragmatically authored review of the state of current capabilities and maybe a brief look into the future.

Dr. Richard Thomas, a founding member of GDevCon and the ALA, LabVIEW Champion, CLA and CLED, has worked with LabVIEW and NI systems for nearly 25 years, in various roles from Academia, Consultancy to Production Engineering, with experience in several industry sectors.

As software engineers, we often talk about the Software Development Lifecycle (SDLC). In this talk, I will show how we can add ‘Security’ to create an SSDLC - Secure Software Development Lifecycle. I will talk about cybersecurity frameworks, security principles, the steps required to incorporate security into your development process with LabVIEW and some practical ways you can improve the security of your software and development environment. With an increased focus on software security from customers and governments – you can no longer ignore security as part of your development process.

I am an ISC2 member and hold the ISC2 CC (Certified in Cybersecurity) and CSSLP (Certified Secure Software Lifecycle Professional) certifications and is internal Security Champion with my employer. Of course, I am also a LabVIEW Champion, CLA, GDevCon founding member and regularly present at user groups and conferences. I currently sit between the boundary of Software Developer and Security Expert, implementing company security policy into our products.

Searching (finding) in LabVIEW is limited.
Since VIs and projects are graphs, can we use graph technologies to search (and find!) things in our code?
After an introduction to graph databases and how to query them, I’ll show how this can be applied to VIs and projects are graphs. This would allow searching VIs and filter on properties, values, relations between functions, VIs and other entities.

Started programming assembly at age 12, on a C64. Studied physics, forgot about programming except for some C classes and some C++ during internships. Ended up doing one internship at an NI Alliance partner, and started working there as a LabVIEW programmer. A few years later, I co founded Carya Automatisering. That was 20 years ago…