Presenters

In a time where it becomes ever more complicated to get an executable installed on a business computer, web applications offer a compelling alternative. NI offers two webserver applications to make VI’s into HTTP endpoints that can serve structured data as well as HTML. But more needs to be done before you have an application that can be deployed to customers. The following topics will be covered:

– An introduction to LabVIEW Web Services and NI Web Server

– creating a webservice (Restful API)

– creating a website

– Deploying a website online, security and authentication

– Splitting the server application into independent microservices

– leveraging functionality with other webservices and commandline executables

– An alternative endpoint routing mechanism

– Making a website into an app (without JavaScript)

Every day, programmers confront claims that Large Language Models (LLMs) are fundamentally reshaping software engineering, with reports of AI replacing junior developers or entire teams. Yet, the programming landscape spans from e-commerce to space missions, each demanding distinct risk tolerances and verification rigor. This presentation examines how the optimal skill set for LabVIEW developers is evolving amidst the AI revolution, with a specific focus on the Testing & Measurement (T&M) domain. Do strict metrology standards and safety-critical validation needs render a resistance to AI automation, or does the developer’s role shift from coding to AI-augmented orchestration? The talk contrasts generalized software AI adoption with the constraints of industrial automation (in LabVIEW), questioning whether AI will fundamentally transform T&M or leave its core practices largely untouched. 

Why attempt to run LabVIEW FPGA code on hardware that isn’t a cRIO or a PXI FlexRIO device?  Can it actually be done?

All code should be thoroughly simulated and verified before it is compiled and downloaded to an actual FPGA, since debugging on the FPGA itself can be a very difficult process.  LabVIEW FPGA code is much faster to write and test than traditional text-based FPGA code such as VHDL or Verilog, and can now be exported into other projects.  This talk will demonstrate some of the less well-known, but extremely useful and effective, LabVIEW FPGA simulation and visualisation tools.

Running LabVIEW FPGA code on other hardware has a few caveats and gotchas, which will be explained, before the process of integrating the code into a VHDL project for use on another FPGA device is shown.  Finally, fully integrated LabVIEW code running on a Red Pitaya DAQ device, will be presented.

LabVIEW teams have long relied on heavyweight virtual machines for CI/CD – but slow spin-up times, gigabytes of overhead, and brittle environments are holding LabVIEW developers back from the fast, reliable automation that modern software teams expect. Containers change everything.

In this session, you’ll discover how NI’s official headless LabVIEW container images unlock a new era of CI/CD automation. We’ll start from first principles – demystifying containers, how they differ architecturally from VMs, and why LabVIEW is uniquely positioned to benefit. No prior Docker experience required.

From there, we go hands-on. You’ll see how to pull NI’s pre-built LabVIEW images from Docker Hub, mount VI source directories, and invoke LabVIEWCLI to automate Mass Compile, VI Analyzer and Unit tests – all headless, no GUI, no licensed workstation in the loop. We’ll wire this into a GitHub Actions pipeline and demonstrate a complete CI workflow live, in under 15 minutes.

Going further, we’ll explore how to build custom LabVIEW container images bundled with your project’s exact dependent softwares, giving your team full toolchain control without sacrificing reproducibility.

We’ll close with best practices that separate a fragile proof-of-concept from a production-ready pipeline – structuring volume mounts cleanly, keeping images version-controlled, and designing pipelines that fail fast and report clearly.

You’ll leave knowing how to replace VM-based runners with lightweight containers, automate builds and static analysis on every commit, craft custom images for your toolchain, and apply best practices for scalable, maintainable pipelines. LabVIEW DevOps is here – and it’s more accessible than before.

Docker is the industry standard for CI. Python, .NET, Java—they all have official container images that just work. LabVIEW and TestStand are still stuck with local VMs and “works on my machine” problems.

In this talk, I’ll cover installing and configuring TestStand inside a Docker container, automating the Sequence Analyzer without a GUI, and running sequences in the cloud. I’ll introduce TestStandCLI—an open-source tool we built to make TestStand containerization practical and repeatable.

I’ll also cover our experience with the official LabVIEW Docker image, VIPM CLI limitations and the workarounds needed to get cloud builds running.

Because it’s all Docker, the approach is platform-agnostic—it runs on GitHub Actions, GitLab CI, on local PC or any pipeline that supports containers.

Sometimes LabVIEW doesn’t work the way it should or the way you want it to.

These “rusty nails” can stop the development of a cool add-on or toolkit dead in its tracks.

In this light-hearted session we will explore some of the most frustrating behaviours and the hackiest of hacks (also known as creative solutions) that we have employed over the last decade in order to get our project or tool over the line.

LabVIEW is a cornerstone of test automation, but can it serve as a primary platform for regulated medical device software? This session shares a real-world, MDR-certified Class IIa neuromonitoring system to demonstrate how the answer can be yes.

We present a pragmatic, field-proven approach to bringing LabVIEW into compliance with key medical standards, including IEC 62304, ISO 14971, and IEC 62366. Topics include configuration management, unit and integration testing strategies, risk management, and the integration of cybersecurity and usability practices within the LabVIEW ecosystem.
 
On the architectural side, we explore how to design “safe-by-design” systems using modularization (PPLs), process isolation, and message-driven architectures, balancing performance, determinism, and fault containment. We also touch on the realities of scaling to large, multi-developer LabVIEW projects in regulated environments.
 
Finally, we cover deployment, licensing, and long-term maintenance considerations critical for compliant medical products.

This talk is aimed at experienced LabVIEW developers who want to move beyond test systems and build fully regulated, safety-critical applications using the LabVIEW.

A key advantage to programming in LabVIEW is the ability to create parallel code easily and idiomatically. An application consisting of two parallel loops is rightly introduced as early as the first lesson of LabVIEW Core 2.

While creating simple multithreaded code is easy, creating highly multithreaded, high-performance, computationally optimised applications is an art that requires mastering concepts such as VI reentrancy, priority, and preferred execution system.

This talk will explain the aforementioned settings found in the “Execution” category of the VI Properties window, will recommend when to use each setting, and will present experiments that illustrate the effect of various settings configurations. All experiment code will be shared in a public GitHub repository. Additionally, the talk will refer to ideas found on the LabVIEW Idea Exchange that highlight potential improvements to LabVIEW itself.

The talk will recommend certain best practices that may seem unusual at first, for example why reentrant VIs are to be preferred to non-reentrant VIs (the default) in most situations.

Understanding VI execution settings helps even when working with small or medium sized applications, and helps us develop an appreciation for the complex work done by the LabVIEW compiler and/or scheduler behind the scenes.

The backplane of a PXI chassis is one of the unique features that the platform offers to build advanced  test systems. The use of the backplane however is not always strightforward, especially if modules of different driver families are used together. While DAQmx typically uses explicit routing other drivers use implicit routing. How can the trigger connection on the controller be used or when is reserving a trigger bus necessary?

 This presentation will cover the basic principles of the pxi backplane, practical use cases shared between driver, the role of the system timing module and extending triggers across multiple chassis.

The presentation will include my personal experience gathered from building an control system for a plasma physics experiment as well as research done to understand as much as possible about PXI Triggers.

Ideally after the presentation we would collect mistakes and missing information mentioned by the audience as well as feedback to NI for improvements of the driver implementions and documentation. 

Legacy systems are unavoidable—and mishandling them is one of the fastest ways to stall a project. This session introduces a practical framework built around two critical questions: Should you replace or refactor? And if you keep the system: how do you work with it effectively?

The first part tackles the most consequential decision in legacy work: replace or refactor. We walk through a structured approach to understand the system, develop solution options, and evaluate them using effort, risks, and total cost of ownership. This enables you to make defensible decisions instead of only relying on gut feeling.
The second part focuses on working effectively with systems you choose to maintain. We cover techniques for understanding and documenting unfamiliar codebases and show how NI Nigel and AI-assisted workflows can accelerate this process. We make the case that rigorous testing is non-negotiable and demonstrate how AI can speed up test case and test data generation. Finally, we show how to integrate obsolescence management into your maintenance cycle — before it becomes a crisis.

Attendees will leave with a clear decision framework, and a set of practical techniques can be applied immediately to make legacy systems more maintainable, predictable, and future-proof.

In this short presentation, I’d like to explain why years of LabVIEW development don’t always translate to expertise and why growth matters more than longevity.

I’ve been developing in LabVIEW since 1998 and have almost never stopped.

Does this make me a LabVIEW Jedi? Probably not.

What do CERN, LEGO, Graftek, DIAdem, the MOD, and the Politecnico di Milano have in common? They all helped move LabVIEW forward in ways that would not have happened without them.

This session explores how LabVIEW evolved through these European contributions, combining technical innovation, collaboration, and a bit of luck. They highlight lessons that continue to shape LabVIEW’s future.

They also underscore a central truth: LabVIEW’s success is inseparable from the ecosystem that grew alongside it. These include Partners, Educators, Champions, and Customers who extended its capabilities. Collaboration between users, partners, and NI created a multiplier effect, transforming LabVIEW into more than just a product.

The same principles that have sustained LabVIEW for 40 years – collaboration, openness, and a graphical systems approach to science and engineering – will help define what comes next. Just as we could not fully anticipate where the personal computer (PC and Macintosh) would take us, we now stand at a similar point with AI.  LabVIEW and its ecosystem are positioned to help shape that future.

State machines are a cornerstone of LabVIEW applications, with 95% of developers relying on them for robust control logic. However, traditional design patterns—such as the Classic State Machine—quickly reveal their limitations as projects grow in complexity. While effective in early development, these patterns often obscure the clarity of state and transition modeling as new features are added. Developers lose visibility of the overall logic, buried under layers of nested case structures or convoluted event-driven code.

This presentation begins with a comprehensive review of state machine implementations in LabVIEW, comparing their strengths and weaknesses.

It then introduces an open-source toolkit designed to overcome these challenges, with it’s now possible to:

• Graphically design state machines directly within LabVIEW’s block diagram, maintaining clarity from initial architecture to final deployment.
• Decouple business logic, control logic, and UI management, enabling cleaner architectures and easier maintenance.
• Animate states in real-time (including during runtime), with visual highlighting for intuitive debugging and validation.
• Create Sub State Machines, enabling abstraction and re-usability.
• Leverage actor-oriented frameworks (DQMH, Actor Framework, or Workers) to manage concurrently active states while preserving readability.
• Systematically test using built-in tools, reducing errors and accelerating development cycles.
• Embed documentation directly within the code, making the state machine self-descriptive and simplifying long-term maintenance.
• Dynamically load or reload State Machine at runtime to modify or correct system behavior on the fly, without restarting the application.

As an open-source project, this toolkit offers free access for students, education purposes, and LabVIEW Community Edition users, fostering collaboration and innovation within the community.

MCP is the future for AI-Connected Systems. It enables LLMs like ChatGPT to call functions in a Programming language. This is now possible with the MCP toolkit for LabVIEW. Imagine uploading a new non-standardized PDF about a DUT, and your LabVIEW Application is configured/run automatically.

MCP (Model Context Protocol) is the standard for AI connected systems. It enables LLMs like ChatGPT to call functions in a programming language. The MCP Toolkit for LabVIEW now enables you to have a Large Language Model call LabVIEW VIs based on their description and connector pane. Use cases:
-Automatically configure Test-Apps from non-standardized DUT datasheets
-Execute Actions or retrieve Data from your LabVIEW Apps in natural language
-Talk with your Testapplications through Speech-To-Text and MCP
-Integrate your LabVIEW Applications to AI Automation Tools like N8N

The European CRA is coming fast. A critical part of the CRA program is to adopt secure-by-design principles into your development process, even for your test systems. This session presents a practical, developer-focused approach to establishing a secure development framework for LabVIEW that aligns with NIST SP 800-218 and support compliance with the EU Cybersecurity Resilience Act (CRA).

Attendees will learn how to harden the VI pipeline by integrating secure-by-design practices directly into everyday LabVIEW development workflows. Topics includes threat modelling for test systems, secure architecture patterns for VIs and libraries, source control and build hygiene, dependency and reuse risk management, static analysis and testing considerations, architecting for ongoing security updates, and generating the evidence auditors want to see.

The presentation will coincide with a paper we are writing with the cooperation of LabVIEW R&D teams, integration partners, and Champions. Rather than abstract concepts, this presentation will focus on concrete, actionable practices that teams can adopt immediately, and tools that work with LabVIEW to manage secure development.

Let’s face it: creating modern, visually stunning User Interfaces in LabVIEW is notoriously challenging. But what if your LabVIEW applications could look as sleek and intuitive as modern web apps? In this presentation, we will shatter the myth that LabVIEW UIs must look dated by revealing our complete toolchain—from raw client requirements to a polished, deployed application.

We take a deep dive into the UI development process, focusing on how we overcome native LabVIEW limitations. You will discover how we leverage a custom framework based on subpanels to dynamically load and manage UI components for a modular, seamless user experience. To push beyond standard boundaries, we demonstrate how we integrate WebViews into our applications, enabling features, animations, and aesthetics that are simply impossible with standard VIs alone.

Furthermore, we’ll explore our cutting-edge design workflow. We will show how we utilize Google Stitch and AI to accelerate the conceptual phase, how we transition those ideas into Figma for high-fidelity design, and finally, how we translate those Figma designs into a functional LabVIEW UI.

Attendees will leave with new insights on dynamic subpanel architecture, AI-assisted design, and WebView integration. This session provides the blueprint you need to deliver LabVIEW applications that truly impress.

“Shift-left” means catching security issues early, during design and implementation, not later during audits or deployment. It’s a cultural shift other industries have embraced, where security isn’t bolted on at the end but embedded throughout the development lifecycle. With the EU Cyber Resilience Act (CRA) phasing in, vulnerability reporting obligations beginning September 2026 and full compliance required by December 2027, shifting left is no longer just good practice. It’s a regulatory requirement.

This session introduces shift-left principles and shows how to apply them to LabVIEW development. We’ll explore secure design practices like data protection, minimizing attack surfaces and layered security. You’ll see tools that can be used for early detection (static analysis and vulnerability management starting with SBOM generation) which are both mapped to CRA Annex I requirements.  You’ll also learn strategies for building security culture on teams without dedicated security staff.

The cost of discovering vulnerabilities late is high. Let’s shift left together in 2026.

Security has become a paramount concern in software design today. As global conflicts intensify, the internet environment grows increasingly hostile, accompanied by the emergence of stricter regulatory frameworks such as NIS2 and the Cyber Resilience Act (CRA). Moreover, previously air-gapped systems can be compromised through the integration of even a single IoT sensor or data-collection router within a digitalization initiative. In such contexts, user management and communication encryption are no longer optional enhancements but critical components of solution architecture.
 
This presentation details a real-world case study on securing LabVIEW applications, including the integration of OAuth 2.0 authorization against a customer’s server and the transmission of SOAP requests over TLS. We examine the unforeseen pitfalls, dead ends, and design trade-offs encountered during implementation, as well as the concrete architectural patterns that ultimately proved effective. The objective is to provide attendees with practical guidance and reusable strategies.

As test, measurement, and industrial automation systems continue to evolve toward distributed, connected, and software-defined architectures, observability has become essential for ensuring reliability, maintainability, and operational insight. This presentation explores how observability concepts can be applied within the LabVIEW ecosystem using OpenTelemetry, an open standard for collecting and correlating telemetry data across modern applications and infrastructure.

The session introduces the three pillars of observability – logs, metrics, and traces – and explains their relevance in LabVIEW-based systems used for automated testing, data acquisition, and industrial control. Attendees will learn how OpenTelemetry can be leveraged to instrument LabVIEW applications, capture runtime behaviour, monitor performance, and improve visibility into distributed workflows and hardware-software interactions.

Practical demonstrations and architectural examples will illustrate methods for generating telemetry data from LabVIEW applications, exporting it to observability backends, and integrating with contemporary monitoring and analytics platforms. The presentation will also discuss implementation considerations, including interoperability, scalability, deployment strategies, and the challenges associated with bringing modern observability practices into engineering-focused environments.

By combining LabVIEW with OpenTelemetry, engineering teams can gain deeper insight into application behavior, accelerate troubleshooting, reduce downtime, and build more resilient and maintainable systems. The presentation is intended for developers, system architects, and engineers interested in modernizing monitoring and diagnostics in LabVIEW-based applications.

Writing test code often feels like yet another chore for busy developers. Poorly designed tests become fragile and difficult to maintain, especially in large LabVIEW applications. When done well, however, testing can dramatically reduce development time and debugging effort, and may even be turned into a real competitive advantage.

In this talk, we will explore practical strategies for effective testing in LabVIEW, with a focus on patterns that hold up as applications grow. Using real-world examples, we will look at how to structure code so that testing becomes natural rather than forced, and how to get fast feedback without drowning in maintenance.

We will also show how effective testing creates real business value by de-risking development projects, shortening delivery times, and simplifying long-term support. Most importantly, we will show how testing can become a productive and rewarding part of development, rather than just another tedious chore.