In my first tutorial, I introduce the Composed Systems' open source framework called the MVA Framework. We looked at how to port a common UI application to the MVA style of programming. This tutorial picks up where I left off and covers how to have more than one UI in an application. 

Our last application was largely unremarkable on the surface, but under the hood we architected it to let us easily swap out one UI for another. What if my application needs more than one UI? How do I decompose a single UI into more modular UIs? In this tutorial I'm going to introduce a few more classes and concepts that'll allow us to host multiple "widgets" in a UI.  We're going to make the UI you see below composed of two "widgets". One widget is given the responsibility of stopping the application by presenting a stop button to the user. The other widget simply has a ring control that presents options to a user.

Using our same abstract graphics from the first tutorial, the goal is to create the following:

Here, the red class (IViewModel.lvclass) is a thing designed to host other things. In the first tutorial we hosted a UI (IViewable.lvclass, the purple class). Now I'm going to introduce a new concept: the view manager (IViewManager.lvclass; that's the green class above). Among its other responsibilities, the View Manager is responsible for defining the layout of the widgets. We'll talk about other responsibilities in later tutorials. Our two widgets are are both of type IViewable.lvclass (the purple and the yellow classes).

As mentioned above, one of the View Manager's responsibilities is to define the layout of a UI. Defining a layout means putting down one subPanle per widget. To create a View Manager:
1. create a new Actor Framework actor and inherit from IViewManager.lvclass:

​ ​"...\MVA Tutorials\2 - A Community of Two\gpm_packages\@cs\mva-framework\Source\Framework\IViewManager\IViewManager\IViewManager.lvclass"

2. Create an override of the Actor Core. 
3. Place your sub panels on the front panel.

We need to make the MVA framework aware of these subpanels. To do that we call

​"New Protected Subpanel.vi" (...\MVA Tutorials\2 - A Community of Two\gpm_packages\@cs\mva-framework\Source\Framework\IViewable\ProtectedSubpanel\New Protected Subpanel.vi).

Creating the widgets follows same procedure described in the first tutorial. So now we have all the ingredients we need. We have a thing that hosts layouts (the red class, aka IViewmodel), a thing that defines the number and layout of widgets (the green class, aka IViewManager), and two widgets (the yellow and purple classes, aka IViewables).

In our previous tutorial, the stop button value change event was conveyed out of the View (Purple class) to the ViewModel (red class) in the override of "catch nested updates". Then the view model stopped itself which caused the framework to shutdown all nested views. 

What if we don't want to convey an event outside of a view for handling, but rather handle the event in the view itself? There are two concepts I'll need to introduce here: 1. The Framework API that allows us to register things for events, 2. The thing that handles the event. 

In the actor core of the yellow actor you'll see a new VI called "Register For Control Events.vi".

Register for Control Events takes an array of control references and an array of event types as inputs. What we're telling the framework is "Hey MVA, when you see any of these controls do any of these events, then receive and act on the value change event." Note the array of control references and the array of events is NOT parallel. If the framework sees any of the events in the event array for any of the controls in the control reference array, it will act.

The thing doing the acting is an override of an IViewable called "Receive Value Change Event.vi". On an event, this VI will execute and looks like:

In this VI, we take the user's selection from the ring control and show it in a one button dialog. Think of this case structure to be similar to the frame of an even structure. But like our deconstructed hamburger from the first tutorial, we've cut up the even handler into more granular parts. Here's what I mean:

The block diagram on the left is our standard event structure set to handle a value change on control labeled "Choose An Option". It provides the control reference, old and new values, and time. Our MVA block diagram on the right does the exact same thing using APIs instead of the event structure.

​Now we just need a chef to assemble our ingredients. And if you'll recall from the first tutorial, that's the responsibility of the Assembler.   ​Below is our assembler for this application. Again, I've included pictures to help illustrate what's going on.

Something to note: we've introduce a new VI called "Write Startup Views". This framework VI does two things: 1. Indicates nesting, 2. Assigns a name to a widget (we'll see where the name is used shortly). "Write Startup Views.vi" embeds views into a View Manager. You'll notice our green class (view manager) is passed in as the top left input, and views and names are passed in as parallel arrays. We're directing the framework to insert the view classes into this specific view manager and then we give those views names.
We give the views names so the view manager knows which subpanel will host which view. Inserting the correct view into the desired subpanel happens in the "Initialize Front Panel" of our View manager, shown below:

In our override we use a for loop to scan through the array of names. In each case, we select the specific Protected subpanel reference (we created the subpanel references earlier in this tutorial) and pass in the enqueuer of the view to host. "Send Insert Front Panel" is the framework VI responsible for insert a view into a subpanel.

Done and Done! We now how a modular UI composed of two widgets. 

So was it worth it? Well... now I can easily swap in any widget I want. But here's a cool bonus. Let's imagine you like the UI of the widget but not it's behavior. Since events are handled in an override called "Receive Value Change Events" all you would have to do to create new behavior is make a child View from the parent and override its  "Receive Value Change Events" and call the child in the assembler. That's kinda cool!

To whet your appetite (aka preview for the next tutorial), our two widgets compose the UI, but we'll likely want them to communicate with each other. I'm going to borrow from one of my all time favorite TV shows "Star Trek" to demonstrate how we open hailing frequencies between the two views. Prepare to make it so!

All of the tutorials are available at the  MVA-Tutorial Bitbucket Repository. Each tutorial is a LabVIEW project designed to present the smallest set of concepts possible to accomplish a meaningful task. And each tutorial builds on the concepts of the previous one. So DON'T SKIP!

To view any of the tutorials
1. Clone the repository using Sourcetree (or your favorite Git method).
​2. Install GPackage manager.
3. Open GPackage manager and navigate to the directory containing the LabVIEW project for a given tutorial.
4. Install the dependencies:

There's nothing terribly fantastic about this VI. It's designed to start, wait for the Boolean button value change, and then stop. The MVA framework allows us deconstruct the front panel and block diagram into more granular parts you can programmatically interact with. Deconstructed food is a good analogy here, mostly because I like food. You might be used to a hamburger that looks like

But the MVA Framework deconstructs it to look like

so you can eat any part independently of the other and in whatever order you'd like.  Let's deconstruct our VI into is separate parts. 

First we will split the front panel from the code by using subPanels, and we'll insert our UI into something designed to host UIs. I'm going to concentrate more on "What we are doing" and less on "Why" for the time being.

We'll make both the thing hosting the VI (aka the "hoster") and the hosted VI Actor Framework actors.
​WAIT! Actor Framework?! Ruuunnnn!!!! Deep breaths...before panic sets in, I'm a noob with the Actor Framework (AF), so I'm with ya. There isn't much AF stuff you'll need to know to use the MVA Framework. You'll see... just keep with me. 

To create the "hoster" MVA actor

1. From a LabVIEW project right click on "My Project" and select "Actor"
2. Inherit from \gpm_packages\@cs\mva-framework\Source\Framework\IViewModel\IViewModel\IViewModel.lvclass

To create the "hosted" MVA actor

1. From a LabVIEW project right click on "My Project" and select "Actor"
2. Inherit from gpm_packages\@cs\mva-framework\Source\Framework\IViewable\IViewable\IViewable.lvclass

​
So this is what we're putting together.

 Path: gpm_packages\@cs\mva-framework\Source\Framework\ActorEvents\IEventAggregator\Register For Control Events.vi
We pass in an array of control references to dynamically register to an event handler (we'll get there). We also pass in an array of event types we want to handle. In this case we are saying "Something execute when the value of "stop" changes." In effect the code above is a programmatic version of:

Since we have two actors running (our hoster actor and hosted actor) we want our stop command to be handled by the hoster. The MVA framework propagates the "stop" to the hosted Actor. So we need to create an override in the hoster called "Catch Nested Value Update.vi". While each UI can (and often does) handle each value change event, stop is a little special because we want to close the hoster as well as the hosted VI. So in the hoster we create an override of "Catch Nested Value Update.vi". This VI is designed to handle messages sent from any sub actors or "nested" actors. The block diagram of the override looks like:

In the override we use an MVA function called "Unpack Nested Value Update" that outputs the label and value of the registered item (in this case the "stop" button). So in the "stop" case we stop the hoster actor which will in turn stop the hosted VI.

So now we'er almost done! We just need a "chef" to assemble our deconstructed hamburger on the serving plate. In every MVA application, the "Assembler" is responsible for inserting actors into actors. Let's take a look at the Assembler of our application. 

I've added pictures and comments in the code to explain what's going on here. The red class is the hoster and the purple class is getting hosted. We use the MVA framework function called "Construct MVA Application" to stitch everything together. The "IViewModel" is the hoster (red class) and, in this case, the startup view is our UI being hosted (IViewable, purple class). When the program starts the MVA starts the actors and stitches them together. 

Soooo what gives? This seems like a whole lot of complexity for not a whole lot of return. Here's the payoff:

1. I can easily swap out the purple class for any other class instantly without changing anything else in the code. And at this point, all we assume is the hosted VI is sending a "stop" message. (actually, the hosting vi automatically handles the panel close event too!)
2. Developers can work on separate sections of the UI without stomping on each other's work.
3. UIs become more modular. It's almost like we are developing "widgits" of a UI instead of monolithic sets of code.

In the next tutorial I'll show how the MVA framework let's us have N widgets in a UI working together. We'll start with "A Community of Two". So stay tuned!

Demo Project Selection
​As an experienced homebrewer, I picked an automated home brewing system as a demo project.  There are some open source projects like The Electric Brewery and CraftBeerPi that are similar, along with a plethora of PLC-based commercial offerings.  The hardware complexity is relatively simple, with a few temperature sensors, heating elements, and assorted pumps and valves.  There are a half dozen brewing steps that always run in the same sequential order, limiting the control complexity.

The Challenge 
​With these existing open source and commercial solutions, is it possible to create a fully featured, single board system with a rich user interface and feature set while keeping the cost about the same?  Could it be configurable enough to work on systems with different plumbing configurations? Could it be done with LabVIEW?
​
In my opinion, the answer is YES!

Making it Real
​I’m working with a friend to turn his 20 gallon, propane-fired homebrewing system into an automated brewing system.  This will involve purchasing solenoid valves and swapping the propane burners out for electric resistive elements.  I’ve selected a single board UDOO x86 computer to act as the brain of the operation.  It has an Arduino-compatible module with GPIO onboard.  Its low cost and integrated DAQ makes it a good match for a hobbyist project like this one.  I’ll include a full parts list in the source code as we build the system. 

The Brewing Process
The system consists of three vessels: the Hot liquor tank (HLT), Mash Tun (MT), and Boil Kettle (BK).  In the current system, the hoses are moved manually depending on the brewing step.  The steps are as follows:
Preheat – The water in the HLT is heated and maintained at the strike temperature.
Mash – the water is pumped into the MT where it steeps a barley tea called wort.  The wort drains into a grant and is then pumped through a heat exchanger in the HLT to maintain temperature and recirculated  into the MT.
Lauter – The mash tun drains into the grant and the wort is pumped into the boil kettle.
Boil – The wort is then boiled and additions like hops are added at scheduled intervals.
Cool – The wort is pumped through a plate chiller and is cooled to near ambient.
​
At this point the wort is done and can be drained from the system into the primary fermentation vessel and the yeast can be pitched along with any dry hop or other post-boil additions.  

Why automate a homebrewing system?
​Adding controls and instrumentation to the system adds cost and complexity.  Brewers have been making beer without any of this for literally thousands of years.  What are the advantages that this brings?  First, controlling the temperatures precisely aids in the repeat-ability of the recipe, as the temperature of the mash controls the activation rate of the starches and sugars in the barley.  This leads to the density, or original gravity measurement, which effects everything from alcohol content to body and mouth feel of the finished brew.  Most home brewers use a step mash of one temperature.  Advanced home brewers and professionals can use a multi-step mash, with rests at several temperatures to get a specific and more complex wort.  Automating this step takes out the manual work of controlling the temperature and timing, so you can get a great mash every time.

The Framework
​For this project I selected the Composed Systems MVA Framework.  MVA stands for Mediated Viewable Actors.  Not only did I choose it because it is the subject of the presentation, but it is the daily driver that I use every day for my clients.  Ethan Stern did a great job following SOLID design principles while adding two critical pieces on top of NI’s Actor Framework: A mediated message bus and Model-View-ViewModel design pattern.

Separation of Concerns
The most fundamental design principles in my mind are how to separate my user interface code from the model/business logic in the application, and how to bind these two entities together.  The MVA framework provides this functionality through the use of abstractions for Views, Models, and the ViewModel.  Views are thin, Models do the computational work, and the ViewModel binds them together.  The mediator pattern is used for messaging and the API imposes rules on how to do so.  

The ViewModel​
The MVA ViewModel has a few responsibilities.  As the root actor in the system, it must launch all the startup models and views.  It is also the top level View and can handle menu events.  Last but not least, it can publish data to the mediator bus.  This is critical because Views cannot do this, and any events originating in the View layer that need to be communicated to the Model layer must percolate up to the ViewModel where the event can be translated and published.  

Thin Views
​The View layer exists to display data to people in a meaningful way, and to provide an interface for interaction.  The actor core above handles those two cases elegantly using two framework methods.  Bind Terminal Value connects the SystemStatusString to the same name and type on the mediator bus.  Register for Control Events will send Value Change messages to this actor whenever the buttons are pressed.  The button references are bundled to manipulate the button state and visibility.

Application Control
​With a bunch of asynchronous actors merrily doing their own thing, we need a way to perform the brewing steps in a synchronous way.   The Process Model and test steps operate synchronously.  The test steps publish model data onto the mediator bus that the asynchronous models respond to.  The models then send messages as needed to the concrete hardware to perform actions.  The results of these actions are published to the mediator bus to be consumed by models, test steps, and/or views.  

The Test Executive
Jon McBee has written an excellent, nearly turing-complete sequencer called @cs/test-executive that you can find over on GPM (That's G Package Manager, a creation of MGI).  This project uses it for straightforward, static sequencing, but it is capable of loops, conditionals, and parallelism.  To use it, all my process model needs to do is call get next.

Get next element
The process model is completely separate from the flow control in the test executive.  It only needs to know which brewing step is next.  In get next, it receives the test step object and its attributes, then spins up the step and sends it the execute message. 

Check it out
​This code is all open source (MIT license) and is hosted on the Composed Systems Bitbucket.  It is a work in progress and I will be continuing to develop this over the next few months as we put the system together.  All the Composed Systems packages used to build this project are hosted on GPM. The slides from the presentation can be found on the Composed Systems Presentations page over at www.composed.io.  Thank you for reading!

Steve Ball is a partner at Composed Systems and is a Certified LabVIEW Architect bent on producing SOLID open-source LabVIEW projects to share with the LabVIEW community.

I have been working on some pretty large applications lately that have highly dynamic behavior. Actors are getting launched and closed, views are frequently popping into subpanels--that kind of thing. At some point pretty far into my development, I started getting this dialog when my executable (EXE) shut down. It seemed harmless enough, until I realized it was not going away...ever.

I did the usual web snooping and stumbled on this LAVA post. Infinite Reset of Death sounds about right (IRoD, as I now call it).

In my first act of attempted remediation, I somewhat arbitrarily added explicit (actually redundant) shutdown to my framework. I don't like the idea of adding code just to see what happens, but I thought that I might avoid the problem by enforcing a more orderly shutdown process. Nope.

When that failed, I tried mass compiling and rebuilding. I pretty quickly learned something about a river in Egypt and that this problem is also intermittent. It tended to happen sometimes rarely...then constantly (and, of course, most often on the customer's embedded PC).

This problem is a strange type of nuisance. When it occurs, I've already done everything I can reasonably do to shut down my application. To be clear, this is not a case of an Actor left silently running. Everything is stopped--I'm sure of it--and LabVIEW is fighting with itself to release resources.

I spent a while pondering the safety implications and general dirtiness of the following solution. It was the best I could muster--and I think it is absolutely harmless, since all my code is completely done executing (hardware set to safe states, data saved, and resources obtained by LabVIEW closed).

Meet Reaper:
https://bitbucket.org/account/user/composedsystems/projects/REAP

The idea is super simple--kill the specified task through Windows command prompt. (Only works on Windows, of course.)

Call Collect Application.vi when you are ready to reap. You will, of course, want to call this after all of your code is done running. (The same place you might have called the Quit LabVIEW function)

You see this while reaper works:

...And that's the end of your application. No doubt about it. If you go this route, you'll need to build a reaper in whichever version of LabVIEW run-time you are deploying. You must also include the EXE and its batch file in your buildspec but, if you read this far and understood what I was talking about, you probably already knew that.

​Happy reaping!

​Ethan Stern is a Managing Partner at Composed Systems and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, NI Certified Professional Instructor, and SOLID software enthusiast.

If you haven't already heard--or tried it for yourself--LabVIEW 2017 offers a simple but powerful new language feature that definitely warrants a deeper look.

Somehow, I made it all the way to the CLA Summit in Austin--having used LabVIEW 2017 for months--before learning about this. Obviously I neglected to scan the LabVIEW 2017 Features and Changes list. At the very least, this new feature addresses the common tedium of making typed polymorphic APIs. It also potentially addresses a design problem I've been banging my head on for months. (A little more on that later.)

For starters, check out the link above to the LabVIEW 2017 new features page. It covers the basics of Malleable VIs quite thoroughly. It turns out, that the strict typing of data wires in LabVIEW, and the abundant polymorphism in the IDE, permit the compiler to make some pretty powerful (i.e. time-saving) assumptions. Let's consider a simple scenario:

• Wire two DBL numbers to an add node
• Highlight the add node and select Edit --> Create SubVI
• The scripted subVI now has two DBL input terminals
• Save the new subVI to disk

...But perhaps we change the source data type later and our calling block diagram now uses integers instead of DBLs. We'll see coercion dots on the subVI's inputs. If we want them to go away, we must either cast the integers to DBLs upstream of the subVI or change the subVI's input terminals to the new integer type.

The thing I never wondered until learning about malleable VIs is, why?

• The input tunnels are conduits for data and they establish an expectation--we could say an interface to the outside world.
• HOWEVER, the add node--the only source code inside the example subVI--is polymorphic

If everything inside the subVI is polymorphic and can easily handle a different numeric type, why impose this unnecessary rigidity on its connector pane? Now, we don't have to.

In case you were too busy to read the LabVIEW 2017 features and changes list linked above, here is a comprehensive list of instructions for converting a standard VI to a malleable VI:

1. Change the ".vi" file extension to ".vim"

Voila! Your subVI now defines a malleable (i.e. flexible, adaptable, less rigid, quasi-polymorphic) interface for its caller. Wire something in. If that something works, everyone (and the compiler) is happy.

In my world these attributes are more often helpful than harmful. Is it good that LabVIEW doesn't treat every VI as malleable? Sure. On the flip side, the behavior exists if you want it, and with only the tiniest effort. Edit-time polymorphism now traverses VI boundaries!

What's the performance penalty for this compiler sorcery? As far as I can tell, absolutely none--and this makes complete sense. There should be no performance difference at run-time. The malleable VI is still called statically (in fact, it is inlined) and the compiler checks and adapts type(s) at edit-time. If you did something silly, like try to add strings inside a malleable math VI, you'll get a broken wire.

This all felt immediately relevant to me because I just recently spun my own polymorphic array functions (in LabVIEW 2015) for Promote and Demote element. I figured I would do it right and make both functions polymorphic so I could reuse these simple widgets in other projects. After a bunch of tedious tinkering, typing, and testing, I had two polymorphic selector VIs, 26 typed instance VIs, and one big annoying compromise--properly handle only my most common data types.

Polymorphic selector VI for Promote Element​:

And the disk footprint for both functions:

With malleable VIs, there is no polymorphic selector VI, and the footprint shrinks to:

Not only is this far easier to write, maintain, and test--it also handles types I chose not to support because I needed to draw the line somewhere. (I originally added that dirty polymorphic variant instance to handle the types I wasn't willing to code explicitly.)

In this slick new world, the only thing that matters is whether the input types play nicely with the subVIs and primitives inside the malleable VI. All array element types work just fine, and I only wrote one VI for each behavior (Promote, Demote). ​Ladies and gentlemen, I think we have a winner.

But surely this requires some new syntax, terminal type, or something?
​NOPE:

I made my VI icon background orange because that's NI's convention with the new malleable VIs added to the palettes. It was simply a style choice.

I used variants for my malleable array type because they imply "wire anything!" It actually doesn't matter--I could have used input/output arrays of DBL, I32, String, etc.. Setting the VI as malleable tells the compiler to reconcile types at edit time--and it does!

At the CLA Summit, we got a quick preview of the malleable VI behavior coming in LV2017 Service Pack 1, and that's when I got really jazzed. SP1 malleable VIs will include a form of dynamic dispatch that allows classes to implement non-ancestor methods. GET OUT.

For months, I have worked on a home-cooked solution to object-oriented interfaces (the capital "I" interfaces that exist in other languages). After lots of deep thinking, kludgy demo code, and wheel-spinning, I had no good solution that provided clean, composition-based, functionality (probably because it was impossible). No harm in thinking big.

...But combine malleability with object-oriented dynamic dispatch (i.e. run-time polymorphism) and you suddenly have a powerful non-hierarchical way of designing classes. If I'm thrilled with the prospect of (almost) never again writing a polymorphic VI, I'm borderline giddy over this interface possibility. I can hardly wait to try some cleaner (and 100% kludge-free) design patterns with the release of LV2017 SP1. Stay tuned.

This will be a short post on a minor annoyance with putting together a dynamic UI in LabVIEW.  I am currently building a multi-subpanel UI with Stream and my simple actor implementation and was annoyed with the difficulty of registering for events on the individual panes in my UI.  This annoyance is rooted in the fact that I neglected to label my panes as they were created.  So I wrote a very simple little tool for identifying and labeling populated panes.

For context, I am putting together a resizable dynamic UI where I want to pop actors into and out of SubPanels based on user interaction.  To accomplish this I put together a UI View Controller Actor whose only job is to handle top level UI scaling and SubPanel ownership, which necessitated the creation of multiple Panes through the use of splitters.  Here is a little demo.

In the demo the white areas are subpanels where actor UI's will be visible at run time.  In the middle of the screen you can see the hamburger control that allows the user to slide the leftmost subpanels left or right.  In order to make sure that the hamburger was always centered vertically in its pane I had to detect a pane resize, which required that I know the pane name.  Since I neglected to name the panes as I created them, and was too lazy to delete the subpanels in each pane so that I could see it's label and change it I see this list when I try to add an event to the event structure.

My first thought was to drop some trash code on the block diagram to programmatically re-label the panes so that I could work with them in the event structure.

But this bit of code throws error 1073, "This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode."

So like any other software developer with an idea they want to try out, instead of moving my subpanels and changing the pane labels manually by right clicking on the splitterbars, I wrote a simple little tool.

There is nothing fancy about the pane re-labeling tool, it is so simple that I don't think it is worth my time to package it and give it away.  Instead I will just show you screenshots of the block diagram so you can write it yourself in whatever version of LabVIEW you like.

Zooming in on the pane discovery bit before the while loop.

Counting the panel close event case, the event structure has three event cases.  Here is a look at the handling of the doubleclick on the listbox.

And here is a look at the right click on the listbox.

In summary, this wouldn't have been a hard problem to solve manually but I figured I would write a short post on how I beat it to death with VI Server.

I've been wanting to write a network extension for Stream for about a year now, adding the ability to extend the mediator to the network and allow pub/sub between actors on different machines.  I finally got the motivation to do it after starting to collaborate with Jarobit Peña Saez at Bits 2 Byte on the Stream project.  This extension is a result of our collaboration efforts and the sharing of ideas.

​​I decided to use ØMQ (pronounced zero-em-queue) as it is a free messaging library for use in distributed applications that handles the TCP socket layer for you.  The base implementation is done in C++ but there are bindings for most popular languages including this binding for LabVIEW, which I used.  A cool aspect of the many bindings available is that ØMQ makes it easy to setup messaging not only between machines on network but between machines running different operating systems and using different programming languages.  As you saw in the demo above it was pretty trivial to connect Stream in LabVIEW to a simple Python script using ØMQ.  ØMQ has great documentation, I recommend that you read more here.

​Let's establish a little vocabulary so we can discuss the design.  The ØMQ Network Extension for Stream is meant to allow Stream actors to communicate across a network without the need to write any TCP/IP level code.  Let's refer to a system of actors on a machine as a microsystem, and the system comprised of many machines as a system.  We can now say that our system is comprised of many microsystems where each microsystem is comprised of many actors.  In the current implementation of the ØMQ Network Extension for Stream there must only be one server per system, and it is up to the developer to make this so.  I don't love the fact that we need a server and think that the design can be improved, but as it stands today there must be one server to rule them all, one server to find them, one server to bring them all and in the darkness bind them (as the saying goes).

​Within each microsystem there can be one or more mediators, this is really a design decision left to the architect.  I typically only have one mediator per microsystem but I know others like to spin up one global mediator per microsystem and one private mediator for each actor in the microsystem.  One thing to keep in mind with this implementation is that every mediator creates its own ØMQ context, and then using the context to create sockets.  The context is the container for all sockets in a single process and the ØMQ guide recommends "Do one create context at the start of your main line code, and one destroy context at the end."

​So how does the ØMQ Network Extension for Stream work?  At a high level the extension is a message broker that uses the ØMQ Publish/Subscribe pattern as the transport, and serialized JSON data packets as the data message.  The system level server maintains a list clients and spins up LabVIEW Topic Actor for each unique topic in the system.  The Topic Actors are assigned an available port and the server handles distributing the updated ports to all known clients as they come in.  The Topic Actors then each subscribe to the appropriate ØMQ endpoint and register as publishers on the appropriate local Stream topics.  For this to work each message object must override the Pack.vi and Unpack.vi methods, these methods handle serialization and deserialization of the message objects.

One nice thing about using ØMQ is that it handles a lot of the hard stuff for you.  ØMQ doesn't care if the server or the clients spin up first, it handles reconnecting after network dropouts, and makes it easy to bring the clients or the server down and back up again without the entire system going down.  I did add a client heartbeat message to the server so that when clients go down the server recognizes it and broadcasts the change to the other clients.  Likewise, if I bring the server down it will alert the clients, allowing each microsystem to run isolated until a new server spins up, at which point the mediator stitches the topics back together.

As it stands right now the ØMQ Network Extension for Stream works as designed, but there are a handful of design decisions that I would like to change.  If you would like to contribute or collaborate on this project please let us know!  The code for this project has been open sourced under an MIT license and can be found at this Composed Systems Bitbucket page.

I recently needed to create a small LabVIEW application that would allow my customers to view and interact with data they had acquired.  As much as I love LabVIEW I really don't love trying to make sleek UI's for data visualization using LabVIEW.  So I decided to tinker with embedding JavaScript UI elements in LabVIEW front panels using XControls.  It ended up being more fun than it sounds.

I knew that I wanted a JavaScript charting package and so I did a little Googling and I found too many to count.  I decided to buy a canned package that had examples that fit what I wanted to do because there is no way that I could build what I wanted myself for $20 worth of effort.  I came across a package called Chartli on codecanyon for $20, it seemed to fit my use case so I purchased a license.

The tangible artifacts that I purchased were HTML files with JavaScript code, JavaScript files, and CSS files.  We don't typically deal with these types of artifacts as LabVIEW developers but there is no reason we can't.  In fact there is a nice example that ships with LabVIEW called "ActiveX Event Callback.vi", this example uses the Microsoft WebBrowser ActiveX control to load a webpage in the ActiveX control so that it can be embedded in a LabVIEW VI's front panel.  As luck would have it, the Chartli package I purchased was just a bunch of webpages that I could tweak and embed in an ActiveX Control.

So I now had a way to take the webpage component and view it on a LabVIEW VI's front panel using the ActiveX control.  Notice that the Web Page URL is actually pointing to a local file on my hard drive.  I don't even need to host the html file for the ActiveX control to be able to run it; and run it is the correct way to talk about it because when the HTML page is loaded it actually executes the JavaScript code embedded inside it.  This is cool because it gives me a way to use JavaScript to handle UI elements, which, let's be honest, look and act nicer than anything I want to build with LabVIEW.

So this is where the XControls come in.  If you aren't familiar with XControls in LabVIEW then take a look here.  I didn't need to build much functionality into my XControls because I was only using them to encapsulate my hackery of programmatically updating HTML files and refreshing the webpage in the ActiveX control.

To finish I will mention a few caveats.  These aren't speedy and I wouldn't use them for display of live data.  Their responsiveness suffers with large amounts of data, for this reason I ended up creating a hybrid LabVIEW chart HTML+JavaScript chart that allowed me to do visualization for decimation of the data in LabVIEW and then push a decimated set of data up to HTML+JavaScript for fancy viewing.  Another caveat is licensing, if you go the route I went and purchase code from someone else be sure that their license fits your use case.  In my case the license I purchased allows me to use this package once and distribute it to customers without selling it to them.  If you download the code I post then you inherit that license along with this text here:

​One of the many things I can stand to improve upon is how I version my software.  I say this because throughout my career I have never adhered to a strict versioning scheme for the software I write.  This has been tolerable because my decisions typically only impacted me or at worst my team, but now that I am diving into the world of open-sourced software I think it is time to embrace a standard for software versioning.

In my research to understand what other people are doing with regard to versioning their software I came across the Semantic Versioning specification (SemVer).  I'll be honest there is nothing earth shattering here, SemVer follows the standard X.Y.Z (Major.Minor.Patch) semantics for versioning that we probably all already use.  What SemVer adds to the discussion is a very well defined standard for how/when/why the X.Y.Z versioning numbers are changed.  This is important with open source projects like Stream because if we all agree to follow this standard then we now have a common language we can use to discuss changes to the software and what impacts those changes have on our respective code bases.

SemVer is made up of a list of 11 rules that dictate how software versions are updated.  At a high level the software version number is structured as Major.Minor.Patch where the components are incremented as follows:

• Major version is incremented when you make incompatible API changes
• Minor version is incremented when you add functionality in a backwards-compatible manner
  
• Patch version is incremented when you make backwards-compatible bug fixes
  
  

​We can see that the Patch version number identifies the number of backwards-compatible bug fixes that have been implemented under the current Minor version.  SemVer defines a bug as an "internal change that fixes incorrect behaviour".  The Minor version number identifies the number of backwards-compatible features that are added to the current Major version.  This number is also incremented when existing features have been deprecated but not yet removed from the codebase.  The Major version number identifies backwards-incompatible changes to the codebase.  This a subtely powerful feature of SemVer because it allows me to guarantee that a consumer of my open-source code can update my published package without breaking their code that depends on my package as long as the Major version does not change.

In the context of Stream I like the idea of using SemVer to explicitly define how releases are versioned.  When you decide to use a package that I publish you and I have entered into an agreement that allows you to make a few assumptions.  These assumptions include that I will maintain the code base behind the package, I will notify you when I make changes to the code base, and that I will give you the information that you need to decide if you want to adopt the new version or not.  SemVer helps to remove the risk from the assumptions by explicitly defining how my changes impact your code base.

I encourage you to take a look at the SemVer specification and would be interested to hear your thoughts on it.  I am also curious how you handle versioning your software and if you have adopted a formal defintion for your versioning semantics.  I will be using SemVer for all open-source projects that I publish on the Composed System Bitbucket page moving forward.  Hopefully this decision will make it easier for you to use and participate in our open-sourced projects.

Janus is the ancient Roman god of beginnings, gates, transitions, time, doorways, passages, and endings.  As the god of transition Janus presided over the beginning and ending of conflict, and hence the doors of his temple were open in time of war, and closed to mark the peace throughout the ancient Roman republic.

In his Clean Code series, Robert Martin (a.k.a. Uncle Bob) talks about the primary and secondary values of software.  Uncle Bob states that software's secondary value, which is the type of value we are most familiar with, is that our software does what our customer wants it to do today.  Our customers typically have this secondary value in mind when they evaluate what we deliver to them.

However, Uncle Bob claims that our software's primary value is that it is soft, i.e. it is able to meet the changing needs of the changing customers.  This statement has a profound impact on how we both interact with our customers and write our software.  It is this idea of change that is core to the principles of agile software development.

So let's embrace Janus as the ancient Roman god of software development.  Janus embodies change and as software developers we need to embrace change.  Closing the etymology loop, we saw before that the word janitor comes from combining Janus with the suffix -tor, meaning "caretaker of a building, person employed to see that rooms are kept clean and in order".  As software developers we act as janitors of our code, caretakers focused on keeping it clean and in order.  It is by being janitors of our code that we are able to deliver on our software's primary value.