GDevCon brands itself "the user group of user groups" for graphical programmers. Graphical programming - "G" for short - refers to National Instruments' LabVIEW programming language, which is a graphical programming environment used by engineers and scientists to develop measurement, test, and control systems using graphical icons and wires that resemble a flowchart.
The themes
When it comes to its users, the LabVIEW programming language does a kind of precarious split with its feet spread wide apart in different worlds. On one side, you have the more "casual" users. LabVIEW is recognized as a programming language with a low threshold for anyone to learn how to develop something that works in a short amount of time. Drag and drop a few buttons and indicators, connect them to the terminals of your instrument drivers, put it all in a timed loop, and you've made a SCADA program. I would wager that the majority of LabVIEW users only use it to set up fairly rudimentary applications which quickly connect to their hardware in order to collect and present data. If this was the extent of LabVIEW programming, however, we wouldn't need a conference such as GDevCon.
On the other side of the split, you have the "advanced" users. The ever-evolving practice of software engineering demands more sophisticated approaches to software development. Software architects and developers from different industries expect LabVIEW to provide the tools necessary to fulfil the requirements of modern software development. For instance, object-oriented programming (OOP) has superseded procedural programming as an architecture choice in several programming languages. It encourages cleaner interfaces between sections of the code, it is easier to debug, and it scales better for large programming teams. Nevertheless, both the fact that LabVIEWs users often are scientists or engineers with limited exposure to higher-level software development paradigms and the fact that LabVIEW wasn't really conceived with object orientation in mind have prevented OOP from gaining widespread use in the community.
GDevCon is heavily geared towards the more advanced users. Most of the talks during the conference assumed the listener had a high level of proficiency. But the fact that LabVIEW has a reputation of being an "easy" programming language to learn still shines through in many of the talks, as they heavily encourage embracing more advanced tools and paradigms.
Photo Credit: GDevCon 2018
One of LabVIEWs great advantages is the ease with which a developer can create multiple tasks working in parallel via multithreading. This is done simply by drawing two or more parallel "while" loops and connecting them to two separate nodes. This comes in handy when designing applications that are supposed to asynchronously perform tasks such as detect user input via a user interface, read data from an instrument and log this data to a file. However, the apparent simplicity in setting up concurrent tasks within the same application is contrasted with the potential complexity involved in having these tasks communicate with each other. The different modules of your code might be producing and consuming data at different rates, send and require receipts for messages, produce errors, buffer data, and simultaneously require access to shared resources. If every part of your code can be easily set up to run independently and communicate in a many-to-many relationship with every other part of your code, the handling of messages between modules becomes extremely important.
No wonder then, that NI continually emphasizes message handling via good design. Any developer seeking to move past the novice stage is soon introduced to several NI-approved design patterns which encourage rigorous message handling like event-driven user interfaces, producer-consumer patterns, queued state machines and lately the Actor Framework. Over the years, NI and the LabVIEW user base has been involved in developing ever more sophisticated solutions to tackle the problem of message handling.
This problem of message handling seems to loom large over the LabVIEW community, as several talks during the seminar were devoted to frameworks and libraries that provide alternative solutions for programmers facing it.
The talks
Due to the proprietary nature of the LabVIEW programming language, most conferences and seminars usually feature NI in some form or another. GDevCon purports to be the first LabVIEW conference organized by the community of users without any outside dependencies. They claim this gives them full independence and liberty to discuss any subject, free from outside influence. According to their website, "we avoid the marketing pressures of a vendor-driven event, we’re not financially motivated nor looking to sell products or services to you". During the first keynote of the day, the speaker's proclamation that "There is not an I in GDevCon" had the pun-savvy part of the audience chuckling in their seats.
The first talk of the day was from Dr. Richard Thomas, named "Frameworks: An Executive Summary". Dr. Thomas discussed the meaning of the word "framework" in a LabVIEW context (spoiler: it means different things to different people) and launched into a meta-analysis of different frameworks available in LabVIEW, grading them according to different metrics such as "Ease of use", "Technical complexity" etc. The talk provided a context for many of the talks to come that day, posing a question along the lines of "Which tools does the LabVIEW community have to its disposal when dealing with increasingly sophisticated infrastructure, applications and technology?"
Photo Credit: GDevCon 2018
Fabiola de la Cueva of Delacor presented her product Delacor Queued Message Handler (DQMH). Freely available from the LabVIEW Tools network, it is a framework based on the NI Queued Message Handler which ships with LabVIEW. According to Delacor, "the DQMH expands on the NI QMH by providing event-based message handling and scripting tools to make development easy, encourage the same style between different developers on the same project, and improve efficiency". The DQMH also enforces unit testing in projects by automatically creating tests for each module created. Fabiola has produced a large number of video tutorials freely available on Youtube that explain how to easily get started using the DQMH framework. DQMH provides an interesting alternative to NI's Actor Framework.
Dr. James Powell of JDP Science gave a talk named "Practical design of Event and Message Handlers" concerning the philosophy behind his independently developed Messenger Library, also available via the LabVIEW tools network. Dr. Powell describes the library as "an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well as more complex channels such as a TCP server and client."
Allen C. Smith, previously with NI, is one of the original developers of NI's Actor Framework and something of a nestor in the community. His talk concerning "The Actor Framework Project Provider: A Case Study on VI Scripting" provided details on VI scripting.
Next came three talks from Daniel Harryman, Thomas McQuillan, and Samuel Taggart. They were all variations on the same subject, with roughly the same message: Object-oriented programming is both achievable and desirable in LabVIEW applications, and nothing to be afraid of. Harryman contrasted LabVIEW OOP to Python and called for OOP to be introduced already at the lower levels of NI-provided programming courses. McQuillan provided a well-documented example of a project using object and actor-oriented programming. Taggart provided a host of best practises drawn from his own experience.
Mathias Baudot of Studio Bods stressed the importance of creating modular, highly cohesive code with low coupling between modules. He demonstrated how having code organized in packed project libraries (PPLs) decreased load and build time of projects, and how this enabled a plugin architecture. Baudot claims the benefits of this architecture are many, including installing and loading plugins dynamically and independently, rigorous versioning of deployed code, and enabling third-party developers to extend the application. Lastly, he showed how the Studio Bods product "BLT for LabVIEW" offered a new way to distribute and manage stand-alone applications. Matthias' well-structured approach inspired us to look into plugin architectures for our own projects.
The talks of the second day of the seminar had a wider variety of themes. Brian Powell spoke eloquently on his 26 year-long experience of being a software engineer, then architect at National Instruments while developing the LabVIEW programming environment. He emphasized the "soft" skills necessary to lead software development teams to success. Joerg Hampel, Christian Butcher, Wiebe Walstra and Gary Boorman all gave engaging talks regarding best practices, interesting applications and examples from the industry.
Danielle Jobe's talk titled "Using the Right Tool for the Job" was of particular interest to us this day. She gave an outline of the strengths and weaknesses of LabVIEW compared to other programming languages such as Python and JavaScript. In short, LabVIEW is well suited for hardware interface and execution control, while the front-end technologies JavaScript+HTML+CSS are more suited for creating modern user interfaces. Python is a popular open-source programming language with a wealth of libraries, providing its users with wide-ranging opportunities. Python scripts can be called from LabVIEW in several different ways, giving LabVIEW developers access to the diverse and powerful capabilities of Python packages.
Jobe gave a demonstration where a LabVIEW application captured images from her laptop camera, called Python-libraries to perform facial recognition, and presented the result in a JavaScript-developed UI.
This presentation had us buzzing, and gave us new ideas on how to leverage e.g. Machine Learning Python libraries in our LabVIEW applications to create even more value for our customers.
Photo Credit: GDevCon 2018
GDevCon has proven to us that there is a lively, robust community of high-level LabVIEW users out there who are willing to share their hard-earned knowledge. Their advanced applications, best practices, and interesting case studies inspire us and show us that LabVIEW has much to offer Nebb in developing industrial control systems in the years to come.
