Presentations GDevCon#2

The need for dynamic, scalable and reconfigurable test & measurement equipment is becoming more and more prevalent in a range of industries and applications from production test to R&D, to fulfill these ever changing requirements a strong foundation of abstraction and standardisation is required. In this session we will explore a range of abstraction techniques including hardware and measurement abstraction as well as the benefits of providing a standardised platform across multiple ATEs.

Many rescue jobs we see seem to have similar issues, this presentation takes a close look at state machine design. Areas covered will be: State Diagrams, State Machines, Difference between QMHs, Transitions, State Design, Uses and abuses.

Programmers who are at LabVIEW Core 3 / CLD level are able to programme a completely functioning executable. But what happens when they are asked to develop a system with up to fifty independent and asynchronous modules? Such a challenge may seem daunting to a mid-level programmer.

An architecture is proposed that uses Producer Consumer Loops to create individual, autonomous code modules that are able to operate independently and yet can also communicate with each other. It introduces the concept of classes and dynamic dispatch, not only to simplify and speed up programming, but also to create consistency across modules. In this way it aims to be an Actor Framework for the mid-level programmer who wants to move up to producing larger, class-based systems. There’s even a trip to McDonalds and the cinema thrown in for good measure!

When I develop code, I want the process of converting idea to code to be as streamlined and convenient as possible. This protects against context switching (and in my case: forgetting). With this in mind I have been working on introducing tools to the LabVIEW environment to better workflows and improve the development experience. Take for example Object Oriented Programming, we spend a lot of time switching between the project explorer and the block diagram, but as programmers, we want to stay in the block diagrams where the code lives. In this presentation, I will take you through how to extend the LabVIEW IDE in multiple ways and pinpoint exactly where and how to implement scripting to improve the LabVIEW developer experience.

This is the story of my journey trying to implement TDD. I had played around with Unit Testing and CI before, but this is my first time trying to put it all together. I picked a small side project and thought I would try to implement TDD. This presentations documents the results.

A journey from basic database communication in LabVIEW, how I do things at the moment, how other languages tackle it (e.g. ActiveRecord) and a look at some potential tools/scripting to bridge the gap.

Rebar (https://github.com/ni/rebar) is an open-source graphical language addon to LabVIEW NXG that incorporates the concepts of value ownership and reference safety from Rust (https://www.rust-lang.org/). This presentation will cover how Rebar allows the developer to write memory-efficient graphical code and implement data types with capabilities reserved for refnums in G; it will also preview other language features that Rebar might enable beyond G.

SQLite is a powerful fully capable database-in-a-file that can be embedded as the data-driven core of a LabVIEW application. This talk will cover practical details of how to build an advanced application around SQLite, and will introduce a range of advanced techniques.

Git submodules is an alternative method for reusing source code between projects while maintaining full traceability and change history. After using submodules for code reuse within my last few projects, I feel this method has some advantages over the current reuse offerings. I aim to discuss and demonstrate how I use git submodules within my projects and some of the tools I have developed to make this easier, mainly a Project Provider addon that integrates into the LabVIEW project.

Programming in the FPGA LabVIEW environment is subtly different. In this presentation we aim to summarise our 13 years of developing flexible and robust FPGA LabVIEW code into our top 5 tips. This will have a particular focus on building code to minimise development time and maximise re-use.

At Argenta we recently started utilising continuous deployment, I will be sharing our experience so far and how we plan to extend
our use of it in the future. This will include the tools we are using, the challenges we've had and I'll also discuss the benefits that we have seen as a result of the implementation.

I will also be inviting a few members of the community, with experience of continuous deployment, to join me to share their experiences and the benefits they have seen.
 

The user interface is a window through which users experience your application. Even the most sophisticated application can fail, if it lacks user friendly interface or not properly thought out user experience.
Convenient and intuitive user interface bridges the distance between the user and the product. It makes the user feel familiar with the product just from the first launch, guiding him through it, making it easy to use.
The session covers the best practices of designing user friendly and intuitive user interfaces for applications developed in LabVIEW environment. The session presents several examples showing the main differences of the UI design depending on an application and intended user.

Ever heard the phrase "if the only tool you have is a hammer, every problem looks like a nail?" In this presentation I aim to show that there are many hammers for many problems and you don't always need the biggest one to solve it! I?ll also add in some stuff about being nice to people and let people know that sometimes, silence is golden.

LabVIEW NXG Web Module now allows LabVIEW programmers to develop web applications in pure G. However, creating a powerful Web application using NXG is not as straightforward as creating a "Measure, Analyze, Display" application with LabVIEW, especially since NXG is quite at an early stage of development. In this presentation, we're giving you all the keys needed to implement a complex and secured Web application that talks to Web Services and Databases, saving you weeks of troubleshooting and research.

Adding new members to an existing team of developers has a series of challenges and incorporates requirements such as: ensuring the team follows established practices, providing suitable opportunities for development for the members and ensuring the team is productive and valuable to the business. The nature of these challenges can be significantly different depending on the skills and experience of the individual and the solutions to the challenges may unique for each person. Example problems are :

​

• Is it worth allowing a new developer to "waste" time doing a bad job of solving real-world problems but learning from their mistakes if the work they produce will have to be re-done?

• How do you create personal development opportunities for a good developer with a very broad knowledge of coding practices?

• Should you allow a very experienced developer to work outside the team's standard practices if they are producing good quality work?

• Can relaxing standard practices provide a more flexible environment for a team with a range of experience?

A panel, with varying levels of experience, will discuss the pros and cons of adopting different approaches to these challenges.

LabVIEW's strongly-typed nature practically removes the risk of data-type mismatches at runtime. The problem? Most architectures implement some form of data flattening and crucially, unflattening to pipe information around an application; Think of the variant-type message field of the Queued Message Handler or the non-trivial casting of Actors to more specific classes in the Actor-Framework. Conventions and careful testing can help to avoid and eliminate the bugs that arise from these issues but a "broken Run Arrow" is the best defence against these kinds of problems. This presentation aims to explain one possible route back to this strongly-typed nirvana and to show how an event-driven model for inter-process communication lends itself well to the task. Methods of using tooling to remove associated repetitive programming tasks are demonstrated and the possible future for this type of framework is discussed.

All of us are experts when it comes to developing successful LabVIEW-based test, measurement and control systems. But it is my experience that connecting external signals to an acquisition system is where many systems can falter.

This talk will explain the importance of correctly configured cabling and how to avoid problems due to (mis)matching. I will also demystify the 'floating/grounded source and single-ended/differential' connection diagram at the end of almost all DAQ-card datasheets, and explain what all those ADC parameters really mean. The talk is packed with practical demonstrations (using signal sources, oscilloscopes, ADCs, weird cables) emphasising how to connect signals properly, and importantly, how to recognise when the DAQ section has been "badly" connected.