GLA Summit

Usually setting up a plugin-based architecture using Packed Project Libraries (PPLs) requires multiple steps and makes the source code difficult to debug and maintain. But using LV Solution Builder, you get to keep your source code open and simple like a normal LabVIEW project and still get all the benefits of Packed Project Libraries (PPLs) at the executable level.

Do you have a toolkit that would benefit the community but don't have the resources to finish it? Do you have an awesome idea for tools that would solve problems facing the community but don't know how to bring it about?

Introducing GCentral's G Idea Exchange where you can kudo an idea by helping to sponsor it. Help get money to polish off that tool or get someone with the right background to create it and pool our resources to maximize everyone's return on investment.

Like a "choose your own adventure" novel, LabVIEW provides the ability to create nodes that allows the developer to choose, at edit time, how the node will execute at run time. These nodes are called XNodes and they allow a developer to create new LabVIEW "primitives" for use in other developer's code. These potentially save the developer time by simplifying tasks, making code easier to read and develop, and enabling the reuse of code.

In this example, I show how an XNode solves the problem of allowing a LabVIEW Class to access and execute its methods in an "Invoke Node-like" way similar to how it can already access its properties through a Property node.

All manufacturers struggle to some degree on how to connect their manufacturing lines to systems that provide end-to-end traceability, autonomous supervision, and quality control.

Most commercially available solutions, often bundled as Manufacturing Execution Systems (MES), are typically large enterprise-wide systems that are complex and prohibitively expensive for small to medium sized (SME) manufacturers.

Integration effort is also a huge barrier to most SME manufacturers when considering off-the-shelf solutions. By the end of the investigative process most opt to just use paper travellers, spreadsheets or ad-hoc database that get (re)developed far too frequently. These solutions do not scale very well. And for those operating in regulated industries, such as medical device or automotive manufacturing, there isn’t much time before paper record keeping processes will no longer be accepted as part of an approved quality management system.

Medulla has developed a cloud based MES that fits the needs of SMEs in both regulated and unregulated industries. It provides auditable traceability, workflow management as well as secure real time visibility into production line metrics and production data from anywhere you happen to be. It is inexpensive and easy to configure with simple APIs that allow direct interaction between the platform and your test and manufacturing equipment. You can also set the level of operator integration, from low-touch webforms running on tablets or touchscreens to full machine level integration.

This presentation will provide an overview and demonstration of the Medulla manufacturing platform interacting with test systems running Medulla’s LabVIEW test executive and MES connectors. Our test executive and MES toolkit are both part of our soon-to-be open-source ViPER framework. Refer to Kurt Friday’s presentation to learn more about ViPER.

When I interviewed for a previous role, the question came up how I would deal with the conundrum of manufacturing floor deployment. I would class this indeed as one of the most challenging problems test software developers face in their jobs. The challenge being that in a growing business you do not have the luxury to interrupt revenue driving work, going from one test station to another and bit by bit updating all machines in question and at the same time keeping track of which machine is running what.

As part of this presentation, I will be giving background about Continuous Deployment (CD) and demonstrate how SystemLink, an off-the-shelf solution by NI, can help (fully/semi) automate the deployment process as well as help manage your assets. I will also demonstrate how this will link into your Continuous Integration strategy which effectively closes the loop from development to deployment.

I would not wish programming in LabVIEW without the Quick Drop on my worst enemy. Since 2009 LabVIEW developer experience (DX) increased rapidly, thanks to the Quick Drop shortcut. Ten years later, we've got a similar tool in TestStand. Did the introduction of this tool have the same effect on working with TestStand as its counterpart in LabVIEW? What techniques can we use to speed up sequence development?

In this presentation, I will try to answer these questions and present techniques that will allow you to improve DX in TestStand. It will cover simple techniques like customizing toolbars, creating custom "menu tools" or managing Sequence Editor UI configuration as well as more advanced techniques, like Sequence File View customization or overwriting Sequence Editor user events using TestStand Managers.

A comprehensive presentation on how to create your own fully native IOS and Android application with LabVIEW web modules.

No longer will you be limited by the limitations of web applications. Accessing sensors, filesystems etc on your phone is now easy and scalable.

Adding another tool to meet your customers demands or to even create your own personal applications at home.

Introducing picoG, a free (open source) tool for deploying G Dataflow (LabVIEW) code to microcontrollers!

Now, you can use the free NI G Web Development Software Community Edition (formerly LabVIEW NXG Web Module) to deploy G code to a RaspberryPi Pico microcontroller! picoG uses a port of the NI Vireo open source runtime engine for (a subset of) LabVIEW.

Today picoG supports the RPi Pico and, with your help, we can expand it to other great targets like ESP32s and the new Pi Zero 2 W!

The key to be able to design modular and scalable software is the way information is exchanged between its components (e.g., data acquisition module, data logging module, user interfaces etc). Essentially, it is the answer to the question: What information is available where and when?

This need for information exchange also creates dependencies or coupling between the components. Such issues are commonly resolved through the use of queues, notifiers or user events but these implementations are often specific to the software being developed and have to be recreated for each new software. An alternative tool is the Actor Framework, which is a great generic solution but it's also quite hard to master and has a steep learning curve.

I will be presenting a much simpler and more intuitive alternative to the Actor Framework, called the Application Messaging Manager or AMM, which is based on the principle of a network with star topology and addressing using the nodes' names. It comes in the form of a library which contains a single class through which all functionality is implemented. Each component of a software instantiates an object of this class and specifies an AMM name. All components which specify the same AMM name will become nodes in the same network, managed by that AMM. Each component goes live in the network by registering with the AMM and specifying its own name and optionally, a list of notifications to which it wants to subscribe. After this, each component can perform point-to-point communication by using another component's name (Command and Response messages), send Broadcast messages intended for all registered components or send Notification messages intended for all registered components which have subscribed to a particular notification. The communication protocol (attributes of messages, including type of data they carry) is completely user defined.

Using the Application Messaging Manager, it's possible to easily create fully independent components which can work as part of a software, without them having to be aware of what other components are part of that software. This allows for modularisation of the software and ease of adding additional components when new functionality is required.

NI is investing in supporting industry standard gRPC as a remote communications transport in a variety of products. This presentation will cover:

• An overview of gRPC

• How NI is using gRPC

• The LabVIEW gRPC support today and future direction

• How members of the community can get involved

Requirements are often written by individuals who are not experts in requirements definition. Most commonly, requirements are written in unstructured natural language (NL), which is inherently imprecise.

During software development, unclear requirements inevitably propagate. This creates unnecessary volatility and risk, which impact delivery time, customer satisfaction and cost.

This presentation will discuss on the basis of unsuitable requirements a guideline how to rewrite these requirements so they are clear for developer and all stakeholders.

Learn about the many traps that one can endure whilst developing LabVIEW RT applications, with a focus on using the DQMH framework, and how to use it best on RT targets. In this presentation, Chris Farmer will share a host of challenges that he recently experienced in developing an RT application, and walk through the solutions for each issue (or the work-arounds). Whilst the subject matter has a DQMH focus, there are plenty of ideas here that apply just as equally to RT development in general.

Last year we presented ViPER which is a Dependency Injection Framework for LabVIEW.

We are now in the process of releasing ViPER and the Medulla Test Executive to the community as open source.

ViPER was originally developed to significantly cut the risk, time, complexity and expense of implementing change to test system software used by medical device manufacturing. Conventional deployed systems usually consist of a monolithic executable containing all dependencies, implementing change no matter how small requires extensive top to bottom system verification, an activity that can take months. By implementing Dependency Injection a system is assembled at runtime from a collection of pre-verified components, verification activities only need to focus on the new or changed components not the entire system.

Over the past year we have put significant effort into refactoring ViPER so that it is capable of running on Windows and RT, and have used it to build several medical device manufacturing systems. One in particular runs on an NI Industrial controller, is capable of parallel testing up to 100 medical devices and serves out HMI’s to operators with tablets, I’ll give a brief overview of that system.

I’ll also give an overview of the Medulla Test Executive which is built using the ViPER framework and show how to build a test system using it.

Deployment to run-time environments is why developers have used build specifications for a long time. One challenge that arises is the actual delivery of the installer as its size occupies ~1GB.

This presentation demonstrates how we can use the Package build specification and include dependencies to create small packages for NI Package Manager, and even publish them to a SystemLink Server Feed for SystemLink client deployment for both LabVIEW and TestStand systems. SystemLink then will have awareness of all the deployed systems and their configurations.

Come and see what capabilities we are considering for a future release of TestStand.

Majority of the scientists, engineers, and students use LabVIEW to fulfill their test, measurement, and automation requirements. At the same time it is widely seen that most people have not seen LabVIEW as mainstream programming language. Due to this reason, they are both unaware and unwilling to unlock the full potential of what LabVIEW is capable of offering such as large scale architecture development with full fledged software engineering principles. Thus they and their customers end up with codes that are mostly unrecognizable thus difficult to reuse and maintain. This presentation aims to shed light on challenges on how LabVIEW is still not adopted as full fledged mainstream programming language.

Many advanced software processes and tools that are standard in other programming languages lack adoption in the NI ecosystem. Either due to actual technical limitations, because of team size and proficiency, or because of the way a typical LabVIEW project is run. Throughout the NI ecosystem, the terms CI, CI/CD and Continuous Integration are often used as wildcards for anything related to triggering processes by / through source code control. This presentation aims to introduce the LabVIEW community to more precise definitions as they are accepted in the greater SW development community.

Topics include examples of why automation (or "continuous integration") is useful and which benefits it brings; proper definitions of the vocabulary used (and explaining it in detail); Continuous Integration vs. Branch-Based Development (and describing how both can be used together with server-side or local automation of processes); different CI providers and supporting technologies (to give an overview of the current state of affairs in the LabVIEW world).

Finally, the HSE way of working - i.e. the processes and tools HSE uses in their daily customer work - shall serve as one example of a well-established set of best practices and their automation.

OpenGDS features including the UML Modeller and the new Interface support functions.

This presentation will show how to quickly generate code documentation using Antidoc 1.2.1 and focus on what's new since v1.0 was released.

- Better UI

- Improved HTML navigation

- UML class representation

- DQMH custom error list

Events appear in LabVIEW 7.0, but they are still not appreciated as they deserve by lots of LabVIEW developers. In this presentation, we will speak about 10 things you should really know to get the best from this old LabVIEW feature.

To state or not to state, that is the question.

Whether tis nobler in the module to suffer

The dings and interrobangs (?!) of outrageous error,

Or to make code against a sea of bugs,

And by opposing, end them? To program: to state;

No more; and by to state to say we end

The hangs and the thousand natural issues

That QMH are heir to, ‘tis a implementation

Devoutly to be wish’d. To program: to state;

To state: perchance to control flow: ay, there’s the rub;

For in that statelessness of QMH what bugs may come

When we have de-energized our electromagnetic coil,

Must give us pause; There’s the QMH flow bugs

That makes the deadline slip so long a time;

Together, VIPM and Dragon allow packages of LabVIEW tools to be installed locally inside a LabVIEW project's source code folder, instead of into the global LabVIEW installation folder. This is preferable because it makes it easier and faster to switch between LabVIEW projects and also helps ensure the right libraries and tools are installed for each of your projects, independently. Additionally, Dragon provides a powerful yet easy command-line interface for project-based installation and management of packages.

Jenkins is an established CI tool that allows being extended via plugins. We used this possibility to configure Jenkins in an easy way to build and test our LabVIEW applications in different versions. In addition, the plugins allow the use of Pipeline Scripts. No command line hacking, just configuring.

The toolkit you need for your next project already exists but is trapped in a text based dimension! It's time to bring it home to LabVIEW.

This presentation will demonstrate how we can capture functionality from any C++ library into LabVIEW with advice on development tools, debugging and dependency management as well using LabVIEW's C-integration library for data exchange. Tips, techniques and further resources will be provided to encourage you to dust off those keyboards and expand LabVIEW's functionality even further.

Zyah Solutions presents 3 utilities to help developers with their Actor Framework development:

- A Msg Constructor utility

- A tool to help more quickly navigate your project/VIs

- An update to the "Zyah AF Msg Forwarding" utility that was first presented at GDevCon

Python has become simplest language anyone can learn and for LabVIEWers its a candy. Millions on Apps are bombarding and APIs are becoming norm for interfacing with those Apps in connected world. Here I'm going to present about how we can develop a LabVIEW application which can interface with those API world?

This presentation shows how to design deep learning object detection models and deploy them in LabVIEW applications to achieve complex computer visions tasks such as defect detection, product counting, and object tracking.

I would like to talk about a new free mobile App and a new flavor of DQMH® module coupled, both using MQTT protocol to allow the mobile app Sniff what is happening on the LabVIEW side, this allows us as developers to be able to work apart from the computer screen and watch string messages of what is LabVIEW receiving and doing.

This mobile app is like WhatsApp but for DQMH® modules, you add modules as “contacts” and can call them, once the connection is established, you can trigger some DQMH® default events such as “Show Front Panel”, “Show Block Diagram for Troubleshooting”, “Stop Module”, also you can see the “Status updated” Broadcast event in the palm of your hand.

The new DQMH® flavor is based on a Cloneable one, so, this mobile app can call individual clones or just send the message to all of them.

The objective of this presentation is to show how to obtain the needed knowledge to automate your versioning and all the steps you must go through to achieve that, and automate your releases within Gitlab. This presentation is based on series of posts from my blog: https://felipekb.com

gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems. It is a perfect match for microservices or independent LabVIEW modules to enable interprocess communication. In this presentation we will be looking at core gRPC principles and how you can create a gRPC server with LabVIEW using an open-source project from NI (grpc-labview). Along the way we will discuss other use-cases and scenarios where gRPC can be useful.

It has became a standard among LabVIEW developers to use SCM solutions, among which, the git is one of the most popular. At the same time, many developers and teams decide to use self-hosted or cloud-integrated git repository managers like GitLab or GitHub which provide many more functionalities than git server. In this presentation I am going to show how to use a "merge request" to boost the performance in team-collaboration, code review process, and providing an enabler for incremental integration of CI/CD.

NI will be presenting on the lessons we learned in building and discontinuing LabVIEW NXG. This session will cover as many of the lessons we learned as we can fit into a session. This is meant as both an educational review for people to learn from as well as a session to provide insight into NI and some of the projects we work on. We will share:

* technical, professional, and operational aspects to the project

* the things that went well, and how we will continue applying them

* areas that we struggled with and how we worked through the struggles, both successfully and unsuccessfully

* problems we encountered and what we learned from them that influence how NI will continue to grow and develop

This presentation will walk through NI’s installer technology and the role of NIPM. If you use NI software, there is a high likelihood that you have interacted with NIPM in some capacity, either through an installation or through building a deployment. This presentation will talk through some of the motivation behind why NIPM was created, what NIPM is used for today, and what direction NIPM and its installers are heading in the future.

Test executives are frameworks that help maximize code reuse as well as minimize the time it takes to write automated tests. Having the right test executive can save companies a lot of money. The question is: should you write one or buy one? What makes a good test executive? This presentation discusses these questions and much more related to test executives.

This presentation covers the proper way to use TestStand with DQMH. Attendees will see a brief introduction to DQMH. In addition they will understand the different types of events and how to handle them in TestStand properly. We will discuss TestStand libraries for DQMH modules and how to organize your sequence files.

This presentation walks through the steps to create a TestStand UI using LabVIEW. It demonstrates the necessary components that make a TestStand UI and how to start and properly stop the TestStand UI.

Workers is a new QMH based framework for LabVIEW, which combines LVOOP with the LabVIEW QMH template style of development, and has been developed for use by anyone at the Core 3 level and above. This presentation will present the main features of the framework, introduce the framework’s scripting tools and API, and provide a short demonstration how to create a small Workers application.

Most of NI embedded systems such as cRIO or PXI needed to run long periods and perform continuous datalogging for measured values however, there always possibility to power cut off, so the system will restart again but without closing files references in proper way such that it will lead to either damage of files or bad behaviours of files.

In this presentation I am trying to transfer my practical experience of how to deal with this such trouble and explain how it goes.

In this presentation, we will examine network communication in a distributed control system, where a LabVIEW executable built in Actor framework manages component applications built in different languages: C++, C#, Python, and Structured Text. We will explore how Network Endpoints were extended to support communication with nodes not written in LabVIEW, and how the JSONtext library from JDP Sciences was used to serialize LabVIEW objects simply and extensibly. The resulting infrastructure provided our component developers with a unified, straightforward, actor-like mechanism for exchanging messages with the LabVIEW executable.

How a good User Interface should be developed, and how much is important the user experience on LabVIEW

Extending existing code by implementing the new Python node in LabVIEW or integrating the new Python Adaptor test steps in TestStand brings a new set of challenges.

First comes the challenge of selecting the right Python interpreter supported by LabVIEW or TestStand, and installing that consistently.

The second challenge is the increasing complexity of using Python virtual environments for environment isolation. In Python, it is common practice but when using TestStand and LabVIEW this is handled differently across versions.

On top of that, comes the challenge of defining the content of the Python environment and making sure that the custom functionality behaves consistently.

Then you are ready to use the Python functions.

A developer may be tempted to use the manual installation approach where the challenge becomes keeping the Python environment consistent and up to date, perhaps across multiple systems. This talk presents another and perhaps better approach.

By leveraging the NI Package format as a tool for orchestration of both the installation order and installing the Pythons environments dependencies, you gain the following advantages:

1. Using NI Packages to version and install the Python interpreter on the target PC.

2. Environment synchronization on both the development machine and test system or production system, through package installations.

3. Contained environments supporting offline installations

4. Leverage existing technology to provide direct dependencies from both LabVIEW and TestStand deployments.

Since NI Package Manager currently only supports Windows, the talk will focus on handling Windows-based Python Environments. The concepts are transferable even though the NI Package Manager is not supported on non-Windows platforms.

User Experience has evolved not just over decades but over centuries and the magical journey continues. And it is directly connected with User Interface design. LabVIEW is one of the best tools around for helping scientists and engineers build incredibly innovative systems. When we create such applications, we need to give equal importance to UX and UI design along with the other functionality aspects to make the product useful and beautiful. That will enhance the user experience. This presentation aims to discuss the foundations of UX and UI design and tips to improve LabVIEW UI to better User experience.

Unit testing is a fundamental routine in software development. To effectively use unit tests for test driving LabVIEW development, good tools which integrate well into the workflow are essential. In this presentation a new open source tool is introduced and its key features are demonstrated. You will learn how you can reduce code duplication when testing class hierarchies and how to quickly run tests from the LabVIEW project explorer. You will also get an introduction to how execution of unit tests may be parallelized and run in a continuous integration environment.

In this presentation, based on the great environment of the unfortunate LabVIEW NXG, I will go through the design and prototyping of my seven concepts for the future of LabVIEW user interface/experience as below:

1. Expandable terminals stack for connector pane; for a clean look and easy wiring.

2. Two-level (and fixed) zoom for block diagram: default view and extensive view of elements and layers with dedicated commenting.

3. Thicker wires for detailed wire data-type exposing and easy to grab. Wire thickening can apply only to the horizontal part of it.

4. Single tab approach for both front panel and block diagram. Clicking on the same, but visually different, tab would change it to the block diagram or front panel.

5. Section-view of the front panel indicators and controls inside the block diagram would be specifically useful by providing “notebook-like” programming for students and researchers.

6. Curved wire and up-down connection pattern for synchronization data flow, like massages and queues, to give a third-dimension flow feel of parallel computing.

7. AI-assisted code autocompletion and prediction overlay in the block diagram to keep up with this latest programming technology.