Presenters

Does it take a week to load your project? Are your builds interminable, and prone to obscure failures? Does LabVIEW load a bunch of files before it lets you probe a wire? These and other IDE pain points are often symptoms of excessive coupling between our libraries and classes. Drawing on real-world examples, this session will explore the role of module dependency in our software designs. We will show excessive coupling complicates engineering tasks like unit testing and overly burdens the LabVIEW IDE. Then we’ll demonstrate the techniques that solve the problem, and apply them to common coupling scenarios. The result will be cleaner code, a more efficient IDE experience, and happier developers.

Allen C Smith has been using the NI platform to solve complex engineering challenges for over 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 Guild and community.

InfluxDB is a large-scale, clustered time series database used as a datastore for Big IIoT, DevOps, Fintech and other big data markets. It has a surprisingly simple single instance, free open source version. It is a NoSQL database that requires no upfront schema creation and comes with a stack of optional components including a web UI used for creating queries and viewing raw and derived data. If you value the code not written, this could be a good session for you. I will discuss use cases that I’ve encountered, how to setup an instance on Linux, how to use the API to query and write data with LabVIEW, and how to connect to InfluxDB and display live data with a Grafana web interface.

I’ve been an Alliance Partner since 1991. I have a multidisciplinary background and I’m always scanning for things to leverage. I first met NI at the 1990 Macworld Expo in San Francisco and got a demo of LabVIEW 2 that blew my mind. I love TestStand and I’m a CTA and CPI. I’m good at LabVIEW, LVRT, LV FPGA, and Veristand. I have a certificate in network security and I’ve done LAMP stack web apps. I currently work at an aerospace company in Boulder, CO streamlining the deployment of systems and workflow, and use Ruby alongside LabVIEW.

The increasing demand for integrated measurement, motion, and safety systems necessitates seamless convergence on common platforms. Building on last year’s presentations, I will demonstrate a sanitized application combining these systems.
Implemented through TwinCAT and EtherCAT, which form the base for LabVIEW, this setup allows motion, measurement, and safety to converge seamlessly.
I will showcase real hardware representative of the deployed solution, illustrating how EtherCAT via TwinCAT enables measurement through Beckhoff and NI hardware on the same bus as motion and safety operations. Attendees will gain insights into EtherCAT’s role as the backbone of our integrated system and appreciate how TwinCAT simplifies complex tasks, fostering innovation.
The talk will focus on the underlying technology and the LabVIEW interface, demonstrating seamless transfer of measurements, motion feedback, and safety status. We’ll discuss best practices for interfacing with LabVIEW, ensuring smooth data flow, converting TwinCAT types to clusters, and visualizing data effectively for users.
Additionally, I will cover how these controls leverage the TwinCAT/EtherCAT backbone to perform motion tasks, control motors, and manage safety operations over the same fieldbus.

I’m an Automation Software Engineer, I deal with technical challenges with customers, creating solutions to cool problems. I see a huge variety of systems and technologies, so I can keep my inner geek happy, indulging in programming and technology. I love programming, its concepts and implementation and making samples others can use or tell me what I did wrong. I’m a big believer in the community helping each other along. I spend the rest of my time with my kids, enjoying their imaginative play, just waiting for the day I can teach them Dungeons and Dragons.

Actor Framework, DQMH, Aloha and others have taken the LabVIEW community by storm but have their productivity benefits made you lazy? Do you know how and why they work, why their various design decisions were made and even more importantly when to use them and what their limitations are?
In this presentation, we will consider several of the most popular community frameworks and ask the questions “Do you know how they work and should you?” “Do you know why the core design decisions were made and should you?” and “Are you missing out on valuable learnings by not rolling your own at least once?”. We will look at issues such as reference ownership and lifetime management, reentrancy, extensibility, developer experience and the semantics of intra / inter-process communications.
We will consider some of the anatomies of these frameworks and their semantics, for example, the essential pairing of Start Module and Wait on module synchronisation in DQMH and why we need to wait for the module to start in order to “own its events”
As somebody who has deep knowledge of DQMH , Simple Actor Models and Message Brokers I will be asking if it’s ok to simply use a framework blindly or if you should have tried to create such a thing yourself to understand their benefits and importantly, when not to use them!

I’ve been graphically programming since the mid-90 having started with HP-VEE and having moved to LabVIEW. I play golf, do recreational LabVIEW including publishing tools to the LabVIEW Community and enjoy travelling with my family. I’m a father to two children who are both mad-keen on engineering (including my daughter whoop whoop).

Clean Architecture’s pillar is the Dependency Rule. Consistently practicing this rule results in design of application’s Business Logic Code decoupled from Frameworks and other ‘details’.

Why to Decouple Code:
- Frameworks are not Architectures: good Architectures must be centered on Use Cases without committing to Frameworks
- Framework Authors solve their own problems – not Yours
- Your Team has no control over the Framework Life Cycle
- Once coupled to your Business Logic Code, the Framework isn’t coming back out
When to Decouple Code:
- Large-scale Applications (over 1000 VIs)
- Applications with longer anticipated lifetime (1 year or more)
- Applications with rapidly changing Requirements (startups)
How to Decouple Code:
- Using Dependency Inversion Principle (DIP) is the key. It instructs to create a Dependency API for each class/library along with a ‘plug-in’ implementing such API
- Never call Framework APIs directly from your Business Logic Code. Create a ‘Framework Dependency API’ based on your application needs instead
- Never derive your Business Logic Classes from Framework Base Classes. Derive Proxies instead
- Call Business Logic methods from Message/Event Handlers. Never leak your Business Logic details into Message/Event Handler Code

Dmitry Sagatelyan is a hands-on Software Architect with a Master’s Degree in Computer Science. He switched to using LabVIEW in 1998 and is currently a full-time LabVIEW Consultant in the San Francisco Bay Area. Dmitry is a Certified LabVIEW Architect, a LabVIEW Champion and a regular presenter at NI Week and CLA/GLA Summits.
Dmitry is passionate about bringing Contemporary Software Engineering Methods and Practices to the LabVIEW Community. His main areas of interest are Actor Programming and Using Agile Software Design Principles (a superset of SOLID Principles) for developing lean and scalable LabVIEW architectures and code.

Did you know that TDMS files are awesome? The Technical Data Management Streaming format combines the ability to stream data to disk in a very efficient manner and a hierarchical structure to assign names and properties to your channels.
While the standard palette is a great way to get started and is suitable for many applications, in this talk we’ll dig into the Advanced API and perform a lower-level manipulation of the files’ content. We’ll see how we can easily find ourselves pulling our hair out if we’re not being careful enough.
After an overview of TDMS files’ benefits and internal structure, we’ll create a black-box recorder able to log data over a long period of time without interruption. Then we’ll find out how to decimate a large set of data spanning across multiple files to fill a waveform graph.

Emmanuel started his career with LabVIEW 7.1 back in 2008 and has been a Certified Architect since 2015. In 2011, he moved to Vancouver, Canada where he worked for the world’s leader in fuel cell testing equipment. In 2023 he moved back to France and founded his consulting company, Ebersoft.

For 10 years in a row he spent his summers rock-climbing in the Canadian Rockies, one of earth’s natural wonders! If you’re not the outdoorsy type, you can also talk to him about motorcycles and amber ales.

A post-mortem on making a big life change for financial security, and the resulting costs and rewards. Three years ago, we made the scary decision to close our company and join a large company’s test department. I will share lessons learned that could benefit business owners, employees, and anyone with a life goal, and whether I would do it again.

I will cover things like:
- Having an FU fund offers the freedom to make our own decisions. However, selling our business accelerated our goal of financial independence by at least 10 years.
- It is good to have goals, but they need to be general and not narrowly defined.
- As a woman in engineering I was used to working extra to be heard. Once I joined the company, I realized using influence to achieve my goals was very difficult. I got much more done using authority! As a consultant, I was used to being in a position of authority. No so in a mega-corp!
- I was aware of possible mental health costs, but I did not know how large they would be.

Fabiola is the lead architect for DQMH, one of the most popular LabVIEW frameworks. She is the co-author of “LabVIEW Graphical Programming”, is a CLA, CPI, CLED, and has been named a “LabVIEW Champion” by National Instruments.

In this presentation we will delve into modular software development with LabVIEW by using packed project libraries (PPLs) as standalone software components. I will touch on several important topics, especially:
• The life of a software component: Version, independence, and dependencies.
• The benefits of, and differences between, shared components and plugins.
• Differences between what you need from a software component in the development environment and in your application’s runtime environment.
• Why are PPLs a tempting choice for shared components and plugins, and why can they be difficult to use?

Software components in the form of reuse libraries have been distributed as VI Packages for years. VI Packages Manager lets you install such reuse code into your development environment, which in turn lets the LabVIEW Application Builder include it within your built applications. But shared components and plugins must be built independently of your application, and they must be distributed with NI Package Manager. I will be talking about how PPLs can be used for this, how PPLs can easily be made to depend on each other, and how you can go about using the same component both in the development environment while you build your application, and in the runtime environment when you run your application. I will demonstrate how we can use NI Package Manager and some additional tools to install the PPLs, including building palettes to make your PPLs’ public APIs accessible in the LabVIEW development environment.

I am 50 years old and live in Hinnerup (Denmark) with my wife and two children. In my spare time I practice and teach Aikido at a local dojo. I have done so for 36 years.
I am a certified LabVIEW architect with over two decades of experience. I have expertise in system design, ranging from large applications over complete test systems to reusable tools. I am also a certified TestStand architect and CPI.

gRPC is a modern and high-performance Remote Procedure Call framework that allows a number of programming languages to talk to each other reliably. This talk is about how it can be easily integrated and used with DQMH to provide powerful communication channels to other programming languages.
Communicating between different systems developed in different programming languages over a potentially insecure network has always been a very difficult task. There are different open source protocols and approaches for different purposes, not to mention all the self-invented TCP-based protocols that tend to do more harm than good. gRPC is a modern and promising Remote Procedure Call framework that is already integrated in many NI products and has an open source implementation for LabVIEW. Learn how to use gRPC with LabVIEW and how it fits into a DQMH-based application. Communication between LabVIEW and the programming language of your choice has never been easier or more elegant.

I've never been able to keep my hands off computers. I studied chemical engineering and after working in that field for about five years, I came into contact with LabVIEW and Hampel Software Engineering. More than seven years later I'm a CLA and give LabVIEW trainings for NI. Besides LabVIEW, I like to code in Python (machine learning), TypeScript and Rust.

Creating a reliable deterministic control loop in a Windows environment may sound unattainable. But it can be achieved by applying techniques I’ve learned over the years. In this presentation, I’ll outline how to set up a framework for testing your code using a “lab” environment and the Desktop Execution Trace Toolkit (DETT) to find the timing culprits and optimize your code. By the end, you will feel empowered to stamp out the timing gremlins in your code and achieve a quiet and reliable control loop.

I’m currently a software engineer at JKI. Prior to that I spent over 6 years at SpaceX at their engine test facility in McGregor Texas. With over 30 years programming in LabVIEW, I’ve worked in applications in medical, automotive, aerospace and semiconductor.
I live in Richardson, Texas with my wife and daughter. My hobbies include comic collecting, physical fitness and travel.
This is my third year attending GDevCon and first year presenting. (Eek!)

What started as a test of G Web Development Software capabilities quickly became quite a time-consuming project. After 2 years of having fun with printing and modifying my 3D printer I’ve ended up with an app (with some limitations) to control my printer over an OctoPrint server, a separate app to control my AC smart plug and a pretty basic printer’s UI in a form of a text display with one encoder. After a few hours of testing G Web Development Software, I’ve realized I can create my own uniformed, personalized system/GUI to control my whole 3D printer ecosystem and acquire data from the printing process. At first it looked like with my 8 years of LabVIEW experience making a WebVI is gonna be a piece of cake. After a few days I’ve realized how wrong I was. During my presentation I want to talk about how my system works, how I’ve made “one WebVI to rule them all” and how to integrate all the hardware (3D printer, smart plug, webcam, LED lights controller) with the help of some Python code, standard LabVIEW VI’s and WebVI’s. My talk will also include a real-time presentation of setting up and printing some 3D objects (all done remotely from the conference centre assuming that Murphy’s law will be gracious for me). I’d also like to discuss some challenges I’ve encountered, mainly because of a really poor documentation for the G Web Development Software and ask the audience if they had similar problems when using this environment.

I'm an EMC engineer working in an electromagnetic compatibility lab trying to make a custom (and mostly bug-free) software for every possible measurement procedure we do. I've been using LabVIEW for the past 8 years. In my free time I ride my road bike (not as often as I would like) and I constantly modify my 3D printer (sometimes I also model and print something useful in between modifications). Recently I tried my best in an online 3D CAD speed modelling tournament.

LabVIEW presents unique challenges when integrated with standard DevOps tools like Azure DevOps. Not an easy start, but to make things harder: Dependency management in LabVIEW, as in any other programming language, is not straightforward. And the standard tools in the LabVIEW toolchain are not supported, like VIPM. However, NuGet offers a viable solution as it works with any file-based system, effectively managing dependencies. This talk will focus on making the developer experience as smooth as possible, while leveraging the capabilities of Azure DevOps.

Niko studied chemistry, and got his PhD in Biophysics in 2014. During that time when working on super-resolution microscopes, he unintentionally found himself drifting into the enchanting realm of automation. With a short detour in Berlin for Picoquant (a laser and research equipment manufacturer) and the ETH Zurich for Microfluidics, he joined National Instrument Switzerland as Applications Engineer in 2016 where he got (and gave) lots of LabVIEW and TestStand training. He changed to the Systems Engineering department, which was shortly thereafter renamed to Applications Engineering, so he became an Applications Engineer again until they closed the Swiss branch of NI. Niko joined Zühlke Engineering in 2019 as a Systems Engineer, originally working on test systems with his focus shifting more into the med-tech and consulting direction. Along this path, he had an epiphany: what if we could borrow some secrets from our rockstar DevOps colleagues in software engineering and apply them to our non-DevOps world? And just like that, a new passion was born: exploring how we can infuse our little corner of automation with the awesomeness and buzzwords that make up DevOps.

As a LabVIEW developer, I’ve witnessed the incredible benefits of open-sourcing my work. In this talk, I’ll share my experience of how publicly sharing one of my LabVIEW APIs has led to significant improvements, including new features and bug fixes.
I’ll take you through the development of this small LabVIEW API, from the initial idea to the latest release, pointing out where sharing code has been beneficial. I’ll also share some valuable insights about open-source practices that will help you take the first step in this world.
My ultimate goal is to encourage other LabVIEW developers to adopt open-source practices for their projects. This will create a culture of collaboration and knowledge-sharing that will definitely benefit all of us.

Olivier is the founder of Wovalab and a board member of the DQMH® Consortium.
Since the beginning of his career, more than twenty years ago, he's focused on teamwork and automated processes.
His favourite topics include designing and developing LabVIEW applications, setting up CI/CD processes, and finding better ways to write documentation.
Olivier is contributing to the LabVIEW community as the lead developer of several open-source projects, such as the Asciidoc for LabVIEW toolkit and Antidoc.

We all learn about errors early in our LabVIEW journey, for example when studying LabVIEW Core 1. Moreover, errors seem like a simple concept – how much more can be said about a cluster that contains a Boolean, an I32, and a string? It turns out, quite a lot!
This talk will describe:
Why errors/exceptions are a useful concept, and hence why every modern programming language implements this concept. The raison d’être of errors will be revealed. This will guide all further understanding of the concept.
How LabVIEW errors compare with exceptions in a few other popular programming languages. Similarities and differences.
How working with errors could be improved in future LabVIEW versions by implementing a few ideas posted on the LabVIEW Idea Exchange.
Practical error handling tips and tricks that can help applications execute more correctly and robustly.

Petru is a Test Systems Engineer that has experience with LabVIEW, TestStand, C#, SQL, and with NI and non-NI hardware devices. He has been using LabVIEW since 2013, and is a CLA, CTD, and CPI. Petru helps customers implement test and control and measurement systems through his company, Robusto Systems. Petru is the author of three free, open-source tools – “Free Label to VI Description”, “New VI From Template”, and “Error Manager” – the latter having been the focus of his presentation at GDevCon#4. Petru is an amateur chess player and enjoys reading about history and technology.

Traditional unit testing falls apart when validating complicated outputs. It also falls apart when dealing with legacy code where you aren’t sure what the correct output should be. Approval Testing is an easy to use solution to both of these problems that works with all existing testing frameworks.
I’ll talk about some really useful features like paramaterized tests, combination tests, and scrubbers. I intend to highlight the use cases for all these and how approval testing can be really helpful when working with legacy code.

I help teams create healthy, human-centered software development processes. Together we discover better ways of working through experimentation. I also help them to bridge the communication gap between the business and the developers through empathy and building a better understanding of the economics of software development.

Orbion Space Technology, Inc., produces Hall-effect thrusters for the small satellite market. Because our warranty repair program for our products on-orbit is necessarily poor, we must have near 100% confidence that every unit that rolls off our manufacturing line is built to spec and reliable. Therefore, Orbion employs a battery of test systems developed in LabVIEW and controlled, built, and deployed by Azure DevOps.

An important part of building confidence in our product is our ability to track what software version was used to execute tests and process data. Another critical need in such a production environment is the ability to keep test machines up to date with the most recently tested and released versions of software in a controlled and timely manner. To solve these issues, we leverage tool suites such as Azure DevOps to develop, release, build, track, and deploy versioned LabVIEW software. In addition, we also use tools such as YAML pipelines, Python scripts, and Azure Deployment artifacts. The result is a workflow that starts when a developer pushes code to a git repository and ends when a semantic versioned .exe is deployed to a target test machine in a controlled, documented, and automated fashion.

I am a test systems team lead at Orbion Space Technology and have been developing/teaching with LabVIEW for 17 years. I got my start in LabVIEW programming test systems in the power generation industry before returning to academia to pursue a PhD. Thought my graduate work, I employed LabVIEW to create a variety of in-situ absorption spectroscopy test systems. I also leveraged LabVIEW as an interactive teaching tool in my instrumentation courses at UW-Platteville. With my recent transition to Orbion Space Technology, I have been focused on developing software for automated testing, cross-network inter-operation of LabVIEW .exes, and creating software used by manufacturing technicians.

Details make a big difference when dealing with strings and arrays.

Copies of large data should be avoided. Sometimes the compiler is smart about this, often it’s not. However, LV doesn’t really give feedback.

I’ll show some techniques (other than benchmarking) to optimize your array\string code.

In this engaging session, we’ll dive into the nitty-gritty of optimizing your strings and arrays related code.

LabVIEW does not show all it’s compiler tricks, but we’ll reveal techniques that ensure the compiler is doing what you think it is doing . Buckle up for a sublime ride!

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…