Control Systems

Error message

  • Notice: Use of undefined constant q - assumed 'q' in nebb_preprocess_page() (line 132 of /home/62/w143230/nebbd7/sites/all/themes/nebb/template.php).
  • Notice: Use of undefined constant q - assumed 'q' in nebb_preprocess_page() (line 133 of /home/62/w143230/nebbd7/sites/all/themes/nebb/template.php).
  • Warning: Invalid argument supplied for foreach() in nebb_preprocess_page() (line 185 of /home/62/w143230/nebbd7/sites/all/themes/nebb/template.php).

DevReach, Sofia, 2018 Impressions

A few weeks ago, I had a chance to attend the DevReach software development conference, which took place on November 12-14 in Sofia, Bulgaria. This year, the conference was a 3-day event with a pre-conference workshop held on the first day and 2 days of conference sessions.
DevReach strives to be the premier developer conference in Central and Eastern Europe. With more than 800 attendees from nearly 20 countries this year DevReach marked its 10th edition. The conference is intended for IT professionals engaged or interested in application development. This event featured world-renowned industry experts who shared their knowledge in a stimulating, enjoyable and friendly atmosphere. As a conference, DevReach offers the ideal opportunity to enhance your proficiency in software application development and boost your confidence.

I was told that this anniversary edition was going to be special, but before this, I hadn’t had the chance to attend at such a big event. And it lived up to my expectations, there was so much quality content and speakers, that I wished I could have been present in more places at once.

Looking at this year’s agenda, I decided that my focus will be getting updated on .NET technology.

For that reason, I was looking forward to seeing Jon Galloway, who works at Microsoft on ASP.NET, Azure as the Executive Director of the .NET Foundation. I was present at both of his presentations .NET Core Today and Tomorrow and Blazor – A New Framework for Browser-based .NET Apps.
He introduced us with a lot of exiting new stuff in .NET Core 2.1 and .NET Core 2.2. The key focus was on performance improvements and I must say, performance using .NET Core was improved to satisfy different requirements. Also, he presented an early look at .NET Core 3.0 and experimental Blazor project which is set to run .NET code in the browser with WebAssembly.
Blazor is a new experimental web UI framework from the ASP.NET team that aims to bring .NET applications into all browsers (including mobile) via WebAssembly. It allows us to build true full-stack .NET applications, sharing code across server and client, without the need for transpilation or plugins.
There were a few demos, some of them failed during presentation but it was nice to have the chance to look at something new. Jon Galloway presented a modern, component-based architecture (inspired by modern SPA frameworks) at work, as we use it to build a responsive client-side UI. It covered both basic and advanced scenarios using Blazor’s components, router, DI system, JavaScript interop.
In my opinion, the disadvantage of using Blazor I must say is bandwidth, a lot of data was transferred on request between server and client. There was almost 1 MB data transferred between server and client on initial request. Will it be accepted by developers? I guess it will be used in small applications when there is no need for client-side developer experts.

Interesting topics were presented by Jeremy Likness, a Cloud Developer Advocate for Azure at Microsoft. He presented us with one of the most interesting topics these days, Cosmos DB and Serverless .NET technology.
Hiker’s guide to the Cosmos (DB) was presented to introduce us with Cosmos DB. In his experience, developers are daunted by the triple punch of giving up relational databases like SQL, allowing their data to live in the cloud, and moving from hands-on hardware to turnkey solutions. He showed us multi-model structure of Cosmos database and its benefits. With the click of a button, Azure Cosmos DB enables you to elastically and independently scale throughput and storage across any number of Azure's geographic regions. It offers throughput, latency, availability, and consistency guarantees with comprehensive service level agreements (SLAs), something no other database service can offer.
Another interesting topic by Jeremy Likness was Code First in the Cloud: Serverless .NET with Azure.
The popularity of microservices combined with the emergence of serverless based solutions has transformed how modern developers tackle cloud native apps. Microsoft’s Azure cloud provides a feature known as serverless functions (including Azure Functions and Logic Apps) that let developers stand up to integrated end points leveraging the programming language of their choice without having to worry about the supporting infrastructure. Basically, his examples were how to develop serverless .NET apps and connect them with queues, web requests, and databases or seamlessly integrate with third-party APIs like Twitter and Slack.
I must say, his presentation refreshes our memory and understanding about serverless technology. For some time, we have been using Azure Functions in our applications, but it is always nice to have additional information regarding bottlenecks, if this technology is not used properly.

I have always been amazed by the security of applications. Authentication is one of my favorite topics. That is why I decided to see the presentation by Chris Klug, The Whirlwind Tour of Authentication & Authorization with ASP.NET Core.
Authentication and authorization are not fun topics for most people. It is generally that thing that must be there, but nobody really cares about. And on top of that, every time the requirements are a little bit different. Every time we must figure out how to write all the plumbing to get it done properly. It is security after all.
In ASP.NET Core, Microsoft has made it easy to get it all done. In most cases, it is only a few lines of code and some minor configuration, and you are up and going. However, if you don’t know what you are doing, it can be a daunting task.
For me, his presentation was the best, exactly what we all need, working code and examples, simply outstanding. There were different examples of working types of authorizations, how they are configured and used. There were social logins, local logins, even AD-based logins, which can be used in one of our products that we are working on, where we are using users from Active Directory.
Also, he presented us with token-based logins for securing Web API’s. Everything that we need to properly set and run when it comes to authenticating your users in ASP.NET Core.

I am happy to say that I have found the whole conference experience amazing. It was such a privilege for me to be able to attend, and I must express my thanks to Nebb for allowing me to be part of this year’s event.

Written by: Jovica Mitkovski
Category: Control Systems

Nebb Joins GDevCon 2018

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 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 fulfill 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 concieved 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 proficency. 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

Photo Credit: GDevCon 2018

One of LabVIEWs great advantages is the ease with which a developer can create multiple tasks working in parallell 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

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 a 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 industry. 

Danielle Jobe's talk titled "Using the Right Tool for the Job" was of particular interest for 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

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.