NI Week 2017 (3 of 3)

Erdos Miller had a great time this past week at NI Week 2017, we got to sit down at a variety of sessions and have summarized our notes from several sessions divided into three blogs. 

This blog contains notes regarding:

• Session AD0194 which covered a new type of VI in LabVIEW 2017
• Session 0826 which covered ideas and history in regards to UI design
• Session 0205 which covered how to use stored procedures to simplify database code

Using Malleable VIs for More Code Reuse
AD0194
Stephen Loftus-Mercer; Jeff Kodosky

This session introduced a SUPER technical new feature that has been introduced in LabVIEW 2017, providing an alternate method for focused functionality previously only accessible using xnodes.  Malleable VIs allow a developer to create a single VI that can automatically create a new VI depending on the data types wired into the malleable VI when used as a subVI. Malleable VIs increase the developers ability for code re-use and ultimately reduces time to market and cost.

Malleable VIs allow you to create a polymorphic VI like the primitive arithmetic functions NI provides. This can make it significantly easier to re-use code for multiple types of data types (e.g. scaling data from raw to engineering units whether it be a double, fixed-point or boolean).

Another one of the very cool technical additions to make this possible is a special case structure called a ‘Type Specialization Structure’ that can be used for certain data types which pave the way for safe type conversion.

Creating Advanced User Interfaces with LabVIEW
0826
Collin Draughon

This session was an overview of UIs followed by a recent history of user interface layouts and finally information about LVNXG (LabVIEW NXG) in terms of what new items it brought to the table in terms of tools for developing user interfaces; with the addition of WPF support and practically being able to make a UI from a website, the options for creating interfaces in LVNXG are less limited and will ultimately be more aesthetically pleasing.

The session summarized that UIs should revolve around efficiency, adaptability and modularity; when those three tenets are followed you increase the chances of the user experience being a good one. Interfaces went through a couple of phases (especially in the LabVIEW world): skeuomorphism where the design mimicked real-life knobs and buttons to help the switchover from physical controls to software controls, flat design in which designs where minimalist and meant to increase efficiency, reduce complexity and convey information easily and finally material design which uses lighting and shadows to convey immediacy and emphasis.

UI Best practices involve the following:

• Consistency is king, differences can be distracting
• The color palette should be limited (we use Palleton)
• Simplicity = success

LabVIEW NXG from the perspective of UIs:

• WPF Support  meaning that you can practically import layouts that mirror websites
• Fixed canvas (block diagrams are infinite)
• Guidelines replace splitters, controls can be anchored to guidelines to dictate what happens upon resize, they can be configured to resize as a percentage or pixels
• LabVIEW is 100% vector based (yay for zoom)
• UIs can be totally web-based, i.e. your UI can be a website and support web-based technologies

Advanced Database Connectivity
0205
William Welch

Although true to its word, the session involved a solution indicative of a LabVIEW developer. Often one of the questions we always ask ourselves (as developers) is how can we make a process more efficient, or make our jobs easier.  This session showed how using stored procedures in a database can reduce source code complexity and make processes involving large amount of data more efficient.

I, having had the same problem in recent projects, found the idea fascinating.  The solution was to use technology already built into SQL: Stored Procedures/Functions .  The general idea was that you could use what boils down to a subroutine located server-side that could be provided with parameters and even return specific values.

By placing ‘business logic’ in a stored procedure on a server, you enable the following:

• Single location to update code rather than updating it in multiple places
• Reduce number of database calls to achieve a given

One of the most useful examples provided was the conundrum of updating or inserting an unknown data set.  Generally, in a relational database, when you want to insert data into a table that has a primary key, there can be no duplicates thus, without a stored procedure, it will take at least two calls to put data into the table: (1) You must query the table to see if the primary key exists and (2) if the primary key exists, update the data, otherwise insert the data. Although one could assume, you could do this in the application once and just ‘remember’ that to only must do one operation, you must also consider that it’s a database whose purpose is to allow multiple clients to access data simultaneously and that the existence of that primary key is never a given.

I expect to put this to use soon, maybe even create some blogs with proof of concepts regarding using stored procedures in LabVIEW.