Machinetalk explained - Part 1: Introduction

7 minutes read

This blog article is about Machinetalk, the middleware for distributed systems which serves as remote API to Machinekit.

This blog post is the first part of the Machinetalk explained series which describe different parts of the Machinetalk middleware.

I'm writing this blog post series since I dedicated a lot of time in the last years working on the Machinetalk technology stack.

My target is to explain the considerations behind Machinetalk. You may find this post useful if you are working with Machinekit or on a similar middleware solution.

Other posts of this series:

• Part 2: Middleware Requirements
• Part 3: Technologies
• Part 4: HAL Remote
• Part 5: Code Generation

Overview

Machinetalk is a middleware for distributed systems introduced to the Machinekit project as a replacement for the outdated Neutral Messaging Language (NML).

One of the reasons for adding the Machinetalk middleware into the Machinekit project is the missing network transparency of NML, which has been lost over time.

Currently, the transition from NML to Machinetalk is still in progress. However, wrappers around the legacy modules enable the development of remote user interfaces. The long term plan is to completely replaceNML and the wrapper components.

An essential requirement of Machinetalk is to reuse widely used message transport, serialization and service discovery standards to minimize maintenance cost and most importantly to decrease the risk of obsolescence.

Therefore, three core technologies serve as a basis for the middleware stack. ZeroMQ serves as messaging library, Protocol Buffers (Protobuf) enables platform-independent data serialization and the Zero Configuration Networking (Zeroconf) standard DNS Service Discovery (DNS-SD) over Multicast DNS (mDNS) works as service discovery method.

Middleware

The term middleware has historically been used to describe a wide variety of software. Middleware, in general, defines software that provides an abstraction layer to underlying platform dependent technologies.

Summarized, middleware is software that decreases the development effort of constructing distributed systems.

A typical middleware consists of service suppliers and service consumers. Suppliers produce information or provide services, and consumers require information or services.

For example, a heart-rate monitor device is a consumer of data produced by a heart-rate sensor. Nevertheless, the heart-rate monitor is a service supplier for a smartphone connected via a wireless network interface logging the values to a database.

This schema can be applied to all types of middleware independent if they are message-oriented, object-oriented or use shared-memory [zotpress items="XTEPI2RZ" style="IEEE"].

Machinekit and NML

I don't think I need to explain the basic concepts of Machinekit or LinuxCNC here since you already found this blog post. If you are not familiar with Machinekit, please check out my other blog posts or the Machinekit homepage.

The Machinekit design encapsulates each function into a separate software component. However, over the years these clear interfaces disappeared, and functionality of the software grew together.

Originally, there has been a middleware called Neutral Messaging Language (NML) to exchange messages between components. Parts of this middleware still exist in the Machinekit project.

One goal of using Machinetalk as middleware for the Machinekit project is to reintroduce proper interfaces between software components to disentangle Computer Numerical Control (CNC)-related parts of the software and the real-time control Hardware Abstraction Layer (HAL) core.

Machinetalk Architecture

To understand the considerations behind Machinetalk it is good to recall the underlying architecture of Machinekit.

Hardware is abstracted and controlled by the HAL which serves as a basis for Machinekit. HAL supports real-time as well as user space components, which are composed using an HAL configuration.

Besides the generic HAL, the architecture of Machinekit also contains three components related to the CNC stack of the software. The CNC stack consists of the Motion Controller component which includes real-time motion control and the trajectory planner. Furthermore, the IO Controller serves as an interface for hardware that does not require real-time control capabilities such as spindle, coolant, and auxiliary controls. The Task Executor coordinates motion and IO Controller. The Task Executor contains the RS-274 GCode interpreter and sequencing logic.

Moreover, Graphical User Interfaces (GUIs) and Textual User Interfaces (UIs) can interact with the CNC stack as well as directly with the HAL.

Usage Scenarios

The Machinekit architecture is designed in a component-based fashion. However, over the time it grew more and more into a stovepipe system [zotpressInText item="{4QQ7TR6M}"] not sharing functionality between individual components.

A primary reason for this design problem are the shortcomings of the legacy NML middleware. The most significant limitations of NML include a static configuration, shared-memory polling for communication and a lack of language bindings for programming languages other than C, C++, and Java.

NML is not under active development anymore as a result of these problems. Wrappers hide NML wherever possible.

Over time these problems resulted in Machinekit growing into an inflexible monolithic application. However, with the support of single-board computers as target execution platform for Machinekit interesting new usage scenarios arise for Machinekit, which make a case for replacing NML with the Machinetalk middleware.

Usage scenario 1 shows Machinetalk as middleware for external and internal communication in Machinekit.

Human machine interfaces for modern machine control systems are not limited to desktop workstation computers. Instead, smart devices such as tablets or smartphones allow remote monitoring of machine status.

Remote Application Programming Interfaces (APIs) can also be used to ease the interaction between part designer and machine operator. For example, a designer can add new work-pieces to the production queue from a desktop computer. Furthermore, web UIs enable remote monitoring of machine status and modification of machine parameters directly from a web browser.

The middleware is also intended to be used internally by components of Machinekit communicating with each other. Using Machinetalk provides the means of implementing Machinekit components in high-level languages and to replace parts of the system as required by the application.

Machinetalk enables the use of multiple user interfaces in a single machine control system. This setup allows running a UI instance on a stationary computer mounted next to a machine tool and a remote UI on a different device at the same time.

The middleware system automatically synchronizes both UI instances without requiring any further modifications by the UI designer. The secondary user interface could for example run on a hand-held device that the operator can carry around when working with the machine.

Machinetalk also allows doing the opposite. Instead of one machine configuration controlled by two separate UIs, one workstation is used to control multiple systems. This usage scenario is especially interesting in environments where either multiple machines produce the same part, or for a supervisor to monitor the production process.

Scope the Machinetalk Middleware

To prevent any miss-interpretations it is important to clarify the scope of the Machinetalk middleware.

In the diagram below you can see an overview of the communication between Machinekit and Machinetalk components.

Please note at this point that not all of the depicted components are already in place. Moreover, the illustrated setup is not complete and does only represent only an example to demonstrate the scope of Machinetalk.

Parts of the system entirely related to the Machinetalk middleware are colored
blue. Components that are part of Machinekit are colored red.

Real-Time Host 1 in the diagram represents a typical GNU/Linux system with a real-time kernel where parts of the setup are executed in the real-time environment. This part of the setup includes the HAL and CNC specific components such as the Motion Controller and the Trajectory Planner. As can be seen in the graphic, these real-time components communicate with each other using the HAL API. Moreover, other Machinekit components are executed in user space. This includes, for example, the GCode Interpreter and Haltalk. User space applications can access HAL employing the HAL API. Furthermore, other applications such as the GCode Interpreter need to exchange messages with components executed in the real-time environment. For this purpose ring buffers (marked in the diagram with RB) are used. Important to note is that messages passed through the ring buffers are Protobuf encoded Machinetalk messages.

Moreover, user space components communicate with each other using Machinetalk bindings (labeled MT). Since these components are not executed in the real-time environment, full Machinetalk functionality can be used. This functionality includes ZeroMQ as transport and automatic service discovery utilizing mDNS/DNS-SD. Furthermore, distributed clients can also use Machinetalk to exchange data with the Machinetalk instance running on the Machinekit host. Some Machinetalk clients may act as bridges to other technologies. Depicted in Figure 10 is a Webtalk Bridge. This bridge translates Protobuf to JavaScript Object Notation (JSON) encoded messages and maps ZeroMQ sockets to web browser supported WebSockets (labeled WT).

Additionally, multiple real-time hosts can communicate with each other using fieldbus technologies. Fieldbus technologies such as Controller Area Network (CAN) or Ethernet for Control Automation Technology (EtherCAT) are real-time capable. Hence, multiple HAL instances and fieldbus enabled hardware can exchange information over fieldbuses in real-time. The Machinetalk middleware does not obligate to provide real-time capabilities. Therefore, Machinetalk does not indent to replace fieldbuses for real-time distributed controls. Instead, it enables distributed systems based on standard computer networks. However, Machinetalk can exchange information with components executed in a real-time environment passing Protobuf encoded messages over ring buffers.

Coming up

I hope you have enjoyed reading about Machinetalk so far.

The next blog article will be about the Machinetalk requirements and the used technologies in more details.

Furthermore, I will dedicate a third blog post solely to HAL remote since it is the most important part of Machinetalk.

The last blog of the posts of this series will be about modeling and code generation for the Machinetalk bindins.

I would very much appreciate any feedback and comments.

Your
Machine Koder