Leaderboard

At the 2019 Americas Certified LabVIEW Architect Summit, GCentral was introduced to the LabVIEW Community. GCentral is a non profit organization (incorporated September 2019) composed of G community leaders creating a platform for programmers to find/use, contribute, and co-develop G code packages and collaboration resources. While GCentral is leading the charge to solve these problems, we will closely align with the community's needs. This forum is designed to connect GCentral's efforts with the community's needs. Some links to be aware of: GCentral.org LabVIEW Wiki Twitter (@GCentralOrg) LinkedIn Instagram (gcentralorg) Facebook Website GitHub Repo

The following slide was just presented at the CLA summit:

SMO. I'm guessing Francois will say the same thing since he wrote a large part of it. Several months ago I was comparing three common community frameworks and I had Francois chime in. I attached a screenshot of what we put together with our rankings obscured. If he's ok with me showing it, I'd love to reveal our rough rankings for the categories shown. My superficial summary of each? Actor Framework - you better love having LOTS of classes in your project and opening DO methods to figure out how the code works. JKI SMO - Use this framework and Steven Mercer will castigate you because no human alive can write code with reference class data that isn't riddled with race conditions and bugs. Honestly though, if you're that worried you can impose some rules when developing with this framework to make it more actor-like. DQMH - The fact that it was developed for customers who don't understand object oriented programming suggests that if an experienced developer wants to combine it with classes that it might be unnecessarily complicated. Sure enough, I watched the presentation on how to do hardware abstraction with classes and DQMH and it confirmed my suspicions. It makes one think about what a framework would look like if your initial design goals were NOT to hide classes from less experienced developers. Turns out that framework might look something more like SMO. In the same project that is using SMO, I'm currently using DCAF at the lower level to manage I/O because there are hundreds of I/O tags. Now that I've spent a fair amount of time developing a variety of DCAF dynamic modules for this project I think I have a good idea of DCAF's strengths and shortcomings. It is open source so if I want some of the bugs and nuisances fixed, I'm going to have to fix it myself. Whoever wrote it got us 80-90% of the way there, but that final polish is going to take a fair amount of work. A lot of the code under the hood just ain't that pretty and some people don't really care about that. I do so I find myself getting annoyed every time I dig into it.

We use a variety of frameworks/templates/patterns for our architecture: The Actor Framework is used for asynchronous UI operations and long-running data processing tasks. Queued Message Handlers (not using DQMH or QMH template) handle simple asynchronous tasks. Action Engines encapsulate privately shared data for our translation and general I/O libraries. (Queued) State Machines ensure that everything runs in order. The proxy pattern is used to interface most customer libraries. We have our own frameworks for the test execution engine and test libraries (message based). I find the publicly available frameworks and templates (DQMH, Messanger Library, NI templates, etc...) very valuable for learning and to get things started quickly. More advanced projects, however, require a deeper understanding of the underlying patterns in order to develop your own architecture (which may or may not utilize these frameworks/templates). In your case these are synonymous 😋 "Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke) For some reason that just popped into my mind... If your entire architecture and thought process is fundamentally based on actors, any small project will of course have to depend on it as well. That is, unless you are willing to rethink (and probably reimplement) the fundamental architecture. Then again, why reinvent the wheel?

Since 2011 I've been refining what I call Glued (Global User Event Driven) architecture. It is User Event driven using a publisher and subscriber model, with variants and variant attributes as the data containing things like the Request Data, event name, who requested the action, who is to perform the action, and GUID among other things. These parallel actors default to non-reentrant so that probing and debugging is easy (and possible on RT), and don't get spun up or down but instead have a known number of them at test start. They all start at once, and they all stop at once. If an actor needs to restart it can go through the queued message handler states that perform initialization but the only way to actually stop the actor is to stop the application with a global event, which is an event that all actors subscribe to. The actors are part of a Library but not Class. The architecture also supports events that are request only, or ones that will wait on a reply, and can do this by leveraging Futures or Promises. There is scripting tools for generating actors, template projects, or adding methods to existing actors. Manual panels, error actor, configuration actor, and probe actor are included with a template project since the majority of projects I have use them. Actors can be ran as the top level VI and events can be sent to itself. This way individual actors can be developed and debugged without the whole application, and without any other actors needed. Each actor can publish to a Sensor which is a scalar double or a string and is name based, or publish to it's own global which is a variant and can contain any data as a variant attribute and read with VIMs. These globals are read only to actors other than itself. Over the years this has been improved to support remote actors running on other targets such as RT with Network Streams being the back end for this. Requests for action can be sent to these remote actors, and reading the actor's global, or Sensors can also be done locally or remotely. It sounds like a lot of extra bells and whistles and there are times I'll start a new project just doing my own thing from scratch. And every time I've done this I ended up regretting it because some feature was built into Glued that I would have to re-write or hack in my custom project. Over the years I've just convinced myself that even small projects should start with some actor based design.