Next Generation Remote User Interfaces forMachinekit · This includes the selection of a...

36
BACHELOR THESIS Electronic Engineering Next Generation Remote User Interfaces for Machinekit Author: Alexander Rössler Student ID: 1110254020 Supervisor: Beneder Roman, MSc Vienna, June 16, 2014

Transcript of Next Generation Remote User Interfaces forMachinekit · This includes the selection of a...

Page 1: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

BACHELOR THESISElectronic Engineering

Next Generation Remote User Interfacesfor Machinekit

Author: Alexander RösslerStudent ID: 1110254020

Supervisor: Beneder Roman, MSc

Vienna, June 16, 2014

Page 2: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

KurzfassungDas Ziel dieser Bachelorarbeit ist es, eine neue Software zur Entwicklung von grafischenBenutzeroberflächen für das Maschinensteuerungsprojekt Machinekit zu entwickeln unddie wichtigsten Teile des Designs und der Implementierung zu erklären. Der erste Teilder Arbeit beschäftigt sich mit einer kurzen Einführung in das Machinekit Projekt undeiner Übersicht über die aktuell verfügbaren Werkzeuge zur Entwicklung von Machinekit-Benutzeroberflächen. Im nächsten Abschnitt werden Konzepte und Vorraussetzungen fürdie Entwicklung beschrieben. Dies umfasst die Auswahl eines GUI Toolkits für plattfor-mübergreifende Benutzeroberflächen-Entwicklung sowie Methoden zum aktualisieren vonWerten, sowie Transport-Protokolle, Serialisierung von Daten und automatisches Auffindenvon Diensten. Das dritte Kapitel beschäftigt sich mit den Implementierungsdetails derSoftware, einschließlich der entwickelten Klassen und Module. Im vierten Kapitel wirdeine Validierung der erarbeitenden Ergebnisse durchgeführt. Weiters wird erklärt welcheÄnderungen und Erweiterungen notwendig und geplant sind, um die Funktionalität zuerweitern.

Schlagwörter: Embedded Systems, Maschinensteuerung, Graphische Benutzeroberfläche,Netzwerk

Page 3: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

AbstractThe goal of this bachelor’s thesis work is to develop the next generation remote userinterface development kit for the realtime machine control software project Machinekit andto discuss the most important parts of the design and implementation. The first part givesan introduction to the Machinekit project and its main concepts. Furthermore, the currentstatus of user interface development is described. The thesis then goes into the design detailsof the software. This includes the selection of a cross-platform user interface framework,a method for value updates, a transport protocol, serialization of data and the servicediscovery method. The third chapter addresses the implementation details of the software,including modules and classes of the resulting user interface development framework. Thefourth chapter analyzes the performance and reliability of the implementation. The resultsare displayed graphically and analyzed. The thesis goal was reached: the user interfacedevelopment framework was implemented and can be used to develop user interfaces forthe Machinekit project. Furthermore, it is explained what future work needs to be done toextend the functionality.

Keywords: Embedded Systems, machine control, remote user interface, network, servicediscovery

Page 4: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Contents

1. Introduction 11.1. Machinekit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Hardware Abstraction Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Current User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Design 32.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Cross-Platform User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3. Value Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5. Serialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6. Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.7. Machinetalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8. QtQuick Virtual Control Panel . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Implementation 113.1. HalRemoteComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. HalPin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3. Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4. ServiceDiscovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5. ApplicationConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6. HalApplicationWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.7. ConnectionWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.8. HalRemote Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4. Analysis 204.1. Test setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5. Conclusion 23

Bibliography 24

List of Abbreviations 25

List of Figures 26

List of Tables 27

Page 5: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

A. Test results 28

Page 6: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

1. Introduction

Traditionally user interfaces for Machinekit run on the same personal computer (PC) as themachine control part of the software. However, recent trends in the PC market and theappearance of new hardware platforms suggest to separate the execution platform of userinterfaces and machine control software. Over the last decade desktop computers becamefaster, but - counter-intuitvely - less suitable for running of realtime applications, mostly dueto agressive power-saving methods which impact realtime performance. This fact suggestsporting Linux realtime kernel frameworks such as Xenomai or RTAI to other platforms suchas the ARM platform widely used in Systems-on-a-Chip (SoC’s). However, SoC’s like theBeagleBone Black from Texas Instruments are not designed for complex graphic processing.On the other hand, mobile devices such as tablets and smartphones which are designed forcomplex graphics processing become more and more common. Therefore, the decision hasbeen made that the next generation user interface for Machinekit should work remotely overthe network in order to run on desktop computers as well as mobile devices.

1.1. MachinekitMachinekit [4] is a community-driven project with the goal to provide open-source softwareand protocols which can be used to create distributed applications to control and commandmoving things in realtime, and with high spatial accuracy. The roots of the Machinekitproject go back to the open-source software project LinuxCNC which is mainly used to con-trol CNC milling machines. Machinekit can also be used for the same use cases as LinuxCNC.However, it extends the application scope to arbitrary machines that need realtime interac-tion with hardware like robots, quad-copters and 3D-printers. Machinekit runs on a varietyof different hardware platforms such as desktop x86 systems as well as ARM based SoC’s.

1.2. Hardware Abstraction LayerMachinekit has a very flexible hardware configuration layer. The scripting language calledHardware Abstraction Layer Command (HALCMD) is based on a circuit paradigm - similarto soldering electronic components together. Furthermore, Machinekit configurations usuallyconsist of realtime and userland components as well as a Hardware Abstraction Layer (HAL)configuration to glue the different parts of the machine configuration together. While realtimecomponents execute in a rather limited environment, userland components have the full LinuxAPI at their disposal, enabling integration of a wide range of devices.

1.3. Current User InterfacesMachinekit comes with two major user interface creation toolkits (also known as virtualcontrol panels (VCP’s)). All of these user interfaces currently communicate with the machine

1

Page 7: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

control part of Machinekit using the HAL Python or C++ bindings and the Neutral MessageLanguage (NML) C++ application programming interface (API). At the moment bothinterfaces use polling to update the values stored in a shared memory block.

PyVCPPython Virtual Control Panel (PyVCP) is based on the TkInter [11] widget set. A userinterface is designed using a text editor to edit a Extensible Markup Language (XML) userinterface description file and iteratively viewing results and improving them. PyVCP providesno support for user-defined event-handling and is purely based on HALs pin Input/Output(IO).

GladeVCPGlade Virtual Control Panel (GladeVCP) is based on the GTK+ [2] widget set. User in-terfaces are designed using the Glade What You See Is What You Get (WYSIWYG) userinterface designer [1]. Furthermore, using GladeVCP it is possible to edit and configure thebehavior of the user interface (UI) using the GTK event handling system by defining Pythonevent handlers. Besides HAL pin IO GladeVCP supports communication with the Machinekitinterpreter using the NML C++ bindings. Moreover, similar to PyVCP Glade UIs are sim-ple XML files. Therefore, it is possible to clearly separate user interface appearance andfunctionality implemented in Python.

1.4. MotivationThe main focus of this project is the development of an open-source cross-platform remote UIdevelopment framework for Machinekit. By creating a consistent API and a robust design,development and testing of the UI framework can be streamlined and likely made usable bya wider audience than just developers and engineers. Additionally, trough the introductionof a modern UI technologies new, end-user friendly UIs with customized and branded designscan be created which was previously impossible.

2

Page 8: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

2. Design

The goal of this project is to develop a remote user interface development framework forMachinekit. As currently Machinekit is designed as monolithic application with user in-terfaces executing on the same host as the realtime environment, it is necessary to surveythe requirements to enable the development of remote user interfaces. However, the designdetails of the transition from Machinekit as a monolithic application to a component basedapplication are out of the scope of this bachelors thesis. Therefore, only the relevant partsfor the introduction of remote user interfaces will be described in this paper.

2.1. RequirementsConsidering the disadvantages and limitations of the current UI development frameworkimplementations, we come to the following requirements for the new UI development frame-work. One of the most important requirements of the future framework is that it should becross-platform and work on any major desktop platform (Linux, Microsoft Windows and MacOSX) as well as the two most popular mobile platform operating systems (OS’s) Androidand iOS. Furthermore, all required libraries and development tools of the UI frameworkshould be open-source in order to comply with the General Public License (GPL) licenseused by Machinekit and to guarantee continued availability. Moreover, the remote interfacesshould rely only on widely used and stable libraries and technologies to avoid the risk ofobsolescence.Given the above requirements we can split the design of the project into five parts: Cross-Platform User Interface, Value Updates, Transport, Serialization and Service Discovery.

2.2. Cross-Platform User InterfaceIdeally, Machinekit user interfaces should run on different platforms with minimal or noporting overhead. Moreover, the framework used should be suitable for desktop, mobile andembedded UI development in order to satisfy all possible platform requirements. Further-more, another criteria to select the user interface software development framework is thatUIs should be loadable at run-time rather than compiled into the source code of the clientapplication.

QtQt [10] is C++ class-library for platform independent development of graphical user interfaces(GUI). Besides the main usage as GUI framework Qt also provides cross-platform librariesfor internationalization, databases, multi-threading, networking and more. The main con-tributor and company behind Qt is currently Digia [?]. However, the Qt project has alsomany contributors from the open-source community especially from the K Desktop Environ-ment (KDE) project. Besides the official C++ binding from third parties also bindings for

3

Page 9: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Python, Ruby, Go and many other programming languages are available. Since version 4.8Qt is triple licensed with a proprietary license, the GNU GPLv3 open-source license and theGNU Lesser General Public License (LGPL)v2.1 open-source license.

QtQuick and QMLQt comes with its own JavaScript based scripting language Qt Meta Language (QML) whichis part of the software application framework QtQuick for rapid user interface and applica-tion development. QML is a declarative interface specification and programming language.QtQuick is designed with the requirements for mobile and embedded devices in mind provid-ing a framework for highly dynamic and customized user interfaces. QML is a interpretedscripting language. Therefore, the QML interpreter is part of the QtQml module and canbe included into any Qt application. This makes it possible to load QML applications atrun-time either from the applications resources or from the file system. QML can be ex-tended with new modules developed in C++ using the Qt framework. This make it possibleto create custom QML modules based on any C or C++ library.

2.3. Value UpdatesValue Updates in the user interface should happen fast and efficient. However, there isa tradeoff between runtime overhead and UI responsiveness. To propagate value changesessentially two patterns are available: Polling scalars in a shared memory block, and event-driven messaging.

Shared Memory PollingPolling describes the process of cyclically checking a signal source for value changes. In thecase of the current user interfaces for Machinekit the process of polling involves checking ashared memory block (see figure 2.1). The advantage of polling is that it easy to implementand predictable. However, due to the fact that the data is checked in a specific interval valuechanges which happen within the checking interval may be lost.

SharedMemory

HAL UI

UI

UI

Polling

Polling

Polling

Figure 2.1.: Polling-based messaging

Furthermore, polling user interfaces does not scale well in a networked setup, and the theoverhead of polling the data increases with every additional signal source, and UI instance.This is especially important if UIs are built in a modular fashion and parts of the UI act asan individual instance.

4

Page 10: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Event-Driven MessagingThe idea behind event-driven messaging is that a service consumer subscribes to the valuesit is interested in rather than checking all available data. The service provider informs theconsumer in case the data changes. This messaging pattern is very efficient and reliable.Furthermore, it is suitable in all cases where the messaging overhead is acceptable comparedto polling the data. For this project a compromise between polling and even-driven messaginghas been made.

SharedMemory

HAL UI

UI

UI

HaltalkPolling

Events EventsEvents

Figure 2.2.: Event-based messaging

Depicted in figure 2.2 is that a single part of the software polls the shared memory block fordata changes and informs all clients in case a value has changed using event-driven messaging.This results into a reasonable tradeoff between scalability as well as data overhead due tomessages generated by events.

2.4. TransportThe task of the transport layer is to provide a reliable end-to-end connection between networknodes. The transport layer can be thought of as a pipe between two end-points transportingbinary data (see figure 2.5). For selecting a suitable transport layer several parameters haveto be taken in consideration: Network performance, development effort, dissemination inother systems, setup requirements and management overhead.

CentralizedCentralized messaging designs include a central broker that all node communicate throughas can be seen in figure 2.3.The advantages of a centralized messaging design are certain reliability guarantees such asmaking sure that a node receives a message. The biggest disadvantages of a centralizedmessaging design are the high development costs and that the message broker itself is asingle point of failure.

DecentralizedDecentralized messaging designs include nodes communicating directly with each other ascan be seen in figure 2.3. This peer to peer concept normally provides higher performance andlower latency than centralized messaging designs, because nodes can directly communicate

5

Page 11: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

NodeNode

Node

MessageBroker

NodeNode

NodeNode

Node

Figure 2.3.: Centralized (left) and decentralized (right) messaging

with each other. Another advantage of this design is that nodes can join and leave thenetwork at any time since there is no central server that needs to be available.

ZeroMQZeroMQ [13] is an asynchronous low-latency messaging library developed by iMatix. AltoughZeromMQ looks like a networking library its doubles as a concurrency framework. Thelibrary provides sockets with different transports like in-process, inter-process, TransmissionControl Protocol (TCP) and multicast. ZeroMQ provides a way to connect sockets withN-to-N patterns like fan-out, pub-sub, task distribution and request-reply. The two patternsrelevant for the use in Machinekit are router-dealer and publish-subscribe (see figure 2.4).

REQ

REP SUBSUB SUB

PUBROUTER

DEALER

REP REP

REQREQ

Figure 2.4.: Router-Dealer (left) and Publish-Subcribe (right) ZeroMQ messaging patterns

ZeroMQ is widely used in different areas from various companies for both communication

6

Page 12: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

inside applications and communication over networks. ZeroMQ is licensed under the GNULGPLv3 open-source license.

nzmqtnzmqt [6] is a lightweight C++ Qt binding for ZeroMQ. Altough the ZeroMQ C++ bindingscould be used when developing applications using Qt and C++, nzmqt provides an interfacethat integrates better with the development interfaces of Qt. Furthermore, nzmqt providesintegration with Qt’s event loop and signals and slots. nzmqt is licensed under the BerkeleySoftware Distribution (BSD) open-source license.

2.5. SerializationSerialization is the process of converting data into an architecture-independent wire format.

Object

0 1 1 0 1 0 0 1

Bytes

0

1

Serialization

Transport

Figure 2.5.: Serialization of objects

The figure 2.5 depicts the serialization process. The output of the serialization process isa stream of binary data. The input depends on the serialization layer used. Serializationmethods are usually highly optimized for certain purposes. Therefore, a choice needs to bemade.

Protocol BuffersProtocol Buffers (protobuf) [7] is a method, set of tools and libraries to serialize structureddata. Protobuf was developed by Google [?] for internal use in their products. Similar in goalto XML protobuf provides a means to exchange data structures between applications, how-ever the implementation was designed to be faster and smaller compared to XML. protobufinvolves a interface description language and a software package that generates source codefor various programming languages. Per default the programming languages C++, Pythonand Java are supported by the protobuf compiler. protobuf is not only used for commu-nication between applications, but also inside applications as alternative to C++ classesand structs to store and interchange data. protobuf is licensed under the BSD open-sourcelicense.

7

Page 13: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

2.6. Service DiscoveryService discovery subsumes methods for applications to find services offered by other ap-plications on a computer network. Service discovery includes a common language for allparticipants to detect service providers without the need of user interaction. Service discov-ery methods can be divided into centralized and decentralized patterns.

CentralizedA centralized service discovery is the easiest to implement. All clients connect to a singlehost to obtain information about available services (see figure 2.6). Service providers informthe service discovery about available services.

DecentralizedDecentralized service discovery implies that every service provider announces its own services(see figure 2.6).

ServiceDiscovery

Client

Client

ServiceDiscovery

ServiceService

Service

Client Service

ServiceDiscovery

Service

ServiceDiscovery

Service

Client

Figure 2.6.: Centralized (left) and decentralized (right) service discovery.

Clients may search for all services required. The service discovery nodes are not coordinated.All information about the services is directly published by each service provider. This pat-tern has the advantage of no single point of failure relative to centralized service methods .Furthermore, it is easier to add new services since other parties are not involved.

DNS Service DiscoveryDNS Service Discovery (DNS-SD) is a service discovery method based on the standardDomain Name System (DNS) protocol to discover services on the network. In combinationwith Multicast DNS (mDNS) it builds the basis for Zero-configuration networking (zeroconf).However, DNS-SD is not dependent on mDNS and works also with standard unicast DNS.Two widely available implementations are Apples Bonjour and Avahi for Linux.

8

Page 14: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

JDNSJDNS [3] is a simple DNS implementation capable of performing normal unicast DNS queriesas well as mDNS queries. It also supports advertising of mDNS records. The origin ofJDNS is the Delta Extensible Messaging and Presence Protocol (XMPP) project [12] (instantmessaging). JDNS is a pure C implementation and has no particular external dependencies.Furthermore, it provides a Qt wrapper. The project is licensed under the MassachusettsInstitute of Technology (MIT) open-source license.

2.7. MachinetalkThe legacy middleware framework NML is unsuitable as a basis for a remote API intoMachinekit for a variety of reasons. Therefore, the decision was made to swap NML for acombination of the above mentioned libraries and tools - ZeroMQ, protobuf, DNS-SD andlock-free queues. This middleware stack is called Machinetalk, and over time all NML-using parts of Machinekit will be ported to use Machinetalk. The goal was to providea end-to-end-capable communications stack which retains message encoding and structureall the way from UIs and even JavaScript Object Notation (JSON)/JavaScript to realtimecomponents, without the need to transcode messages due to media breaks (for instance,NML - being defined in C++ - is not usable in a kernel RT threads setup, hence messagesneed to be transcoded to from C++ instance objects to C structs and vice versa at therealtime boundary). Machinetalk also adds the capability for message exchange betweenrealtime (RT) components, RT and userland processes, and arbitrary userland-to-userlandprocesses through a common API.Along these lines ZeroMQ and protobuf act as an remote-capable API to Machinekit. Keyparts of Machinetalk are HAL remote components, HAL groups and HAL named ringbuffers.In this thesis only the HAL remote components are used, HAL groups and HAL namedringbuffers are currently not implemented on the UI side. [5]

HAL Remote ComponentsMachinekit UIs like PyVCP or GladeVCP are implemented as HAL components. UI controlssuch as buttons and sliders are represented by HAL pins inside the HAL realtime envi-ronment. However, the current implementation of HAL components uses shared memorypolling. As discussed in section 2.3 this design pattern is not suitable for networked setups.For this purpose the HAL remote components where introduced with Machinetalk. HAL re-mote components behave similar to HAL components inside the HAL realtime environment,but they have no thread function. Therefore, HAL remote components do not do anythingby themselves and need a userland process to adopt and serve them.For remote UI this userland process is called Haltalk. The Haltalk server provides two Ze-roMQ sockets for clients to communicate with the remote components. This sockets areannounced using DNS-SD discussed in section 2.6. Haltalk cyclically refreshes the state ofa components and publishes changes via the halrcomp service; but other than the previousscheme, HAL objects are scanned only once per Haltalk instance, not once per UI instance.The second service halrcmd can be used by remote clients to upate values of remote compo-nent.

9

Page 15: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

2.8. QtQuick Virtual Control PanelThe resulting user interface development framework based on QtQuick is called QtQuickVirtual Control Panel (QtQuickVcp). QtQuickVcp is designed with remote interfaces onmobile devices and embedded systems in mind. A UI is designed once for a specific formfactor and can be deployed to any mobile, embedded or desktop device over the network.Communication with the remote Machinekit instance happens over the halcmd and halrcompservices provided by Haltalk. The UI is implemented as HAL remote component with UIelements acting as pins of the HAL remote components.

10

Page 16: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

3. Implementation

This chapter provides design and implementation details of QtQuickVcp software modules.All modules are implemented in C++ and designed to be used inside the declarative QMLenvironment. Consequently, the C++ modules are built into several shared objects for useby the QML interpreter. Such shared objects designed specifically for use in QML are calledQML plugins or QtQuick modules. At the moment QtQuickVcp consist of five QtQuickmodules:

• Machinekit.Controls - Generic UI items not associated with HAL pins which can bealso used in non HAL specific applications

• Machinekit.HalRemote - Non graphical user interface (GUI) HAL remote pins andcomponents

• Machinekit.HalRemote.Controls - UI items such as Slider and Button combined withHAL pins

• Machinekit.PathView - GCode path and progress view• Machinekit.VideoView - Video view, for example Motion JPEG (MJPEG) webcam

streams

The remainder of this chapter will focus on the implementation of theMachinekit.HalRemote and Machinekit.HalRemote.Controls modules.

3.1. HalRemoteComponentThe HalRemoteComponent is the UI counterpart of a remote component on the HAL side. Itworks as actor for representation and manipulation of the remote component running insidethe HAL realtime environment. For each remote component in HAL zero or more actorsmay exist.

Realtime hostClient

Realtime environment

HAL instanceHalRemoteComponent

Haltalk

halrcomp

halrcmdHalRemoteComponent

Remotecomponent

Figure 3.1.: Relation between UI and HAL remote components

11

Page 17: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Figure 3.1 depicts how a HalRemoteComponent is related to a remote component in HAL. TheHalRemoteComponent connects to a remote HAL instance using the halrcmd and halrcompservices provided by a Haltalk server running on the realtime host. The halrcomp serviceis implemented as ZeroMQ publish-subscribe pattern. If an update of a remote componenthappens all subscribers to a specific topic are informed. The halrcmd service is implementedin a router-dealer pattern (see figure 2.4). This ZeroMQ socket is used for updating datafrom the client side as well as heartbeat and other client-specific messages.

Disconnected

Connecting

Error

Connected

ready=true

bind accepted

pin change rejectedping timeoutor other error

bind rejectedsocket error

ready=false

ready=false

ping acknowledge

Figure 3.2.: HalRemoteComponent state-machine.

Figure 3.2 depicts the state-machine of a component. The component starts in theDisconnected state. When the ready property is set to true both ZeroMQ sockets attemptto connect and the state transitions to the Connecting state.Figure 3.3 depicts the communication of both services with the Haltalk instance. Then thecomponent recursively scans its containerItem for HalPins and sends a bind message tothe halrcmd socket. In case the connection attempt fails or the bind request is rejected thestate of the component transitions to the Error state. If the bind request is accepted thestate transitions to the Connected state. Once the component is in the Connected stateit receives a full update of the status of all pins. All further pin status updates happenincrementally relative to the current status of the remote component. Furthermore, thecomponent cyclically sends a heartbeat message to the remote host to check the connectionstatus. If one heartbeat message is not answered the state of the component transitions tothe Error state. In this case it is possible that the component is able to recover from theError state if the answer to the heartbeat messages is received after the timeout period. Inall other cases it is necessary to change the ready property of the component to false inorder to reset the error.

12

Page 18: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Client 1 Haltalk Client 2

Client 1 connects

Client 2 connects

Client 1 pin change

Client 1 heartbeat

bind remote component

full update

pin change

incremental update (echo)

bind remote component

full update

bind confirm

bind confirm

incremental update

ping

ping acknowledge

Figure 3.3.: Haltalk communicating with two clients over halrcmd (blue) and halrcomp (red).

3.2. HalPinThe HalPin is the counterpart of a pin of a HAL remote component. The HalPin compo-nent works in combination with the HalRemoteComponent. The value of a HalPin can beconnected to a UI component such as a button using QML bindings. If the value changes inthe HAL component, this is reflected in the local user interface, and vice versa.

synced

notsynced

update fromremote component

update from UI

Figure 3.4.: A state diagram for the synced property of the HalPin component.

Figure 3.4 shows the state-diagram for the synced property of the component. The syncedproperty is updated every time the value of the pin changes. In case the value was changedfrom the QML code the synced property is set to false. This indicates that a pin changesyncing the local value with the remote components value is in process. When the echofrom the remote component is received by the HalRemoteComponent it updates the value ofthe HalPin again. In this case the synced property of the component is set back to true.

13

Page 19: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

3.3. ServiceThe Service component represents a Machinekit service. In combination with theServiceDiscovery component it can be used to automatically resolve services running on aremote host. The Service has to be in a ServiceList controlled by a ServiceDiscoverycomponent in order to receive updates.

ready=

false

ready=

true

SD items >= 1

SD item = 0

SD items >=1

Figure 3.5.: A state machine for the Service component.

Figure 3.5 shows the stat-machine for the ready property of the component. The componentis ready as long as the items property has one or more entries. When a Service componentis used to represent a single service running on the remote host the items property usuallyshould have only one entry. In case more than one service of a single type exists the servicesneed to be filtered. For that purpose a ServiceDiscoveryFilter can be used.

3.4. ServiceDiscoveryThe ServiceDiscovery component can be used to discover and resolve available serviceson the network. The component uses mDNS and DNS-SD to discover published services.Depicted in figure 3.6 is how the discovery of services for different service providers works.Every client has a DNS-SD browser to discover published DNS-SD services and every serviceprovider has its own DNS-SD publisher. Therefore, the service discovery is decentralized andhas no single point of failure.mDNS names are generated using the serviceType and domain properties of the compo-nent as well as the type property of the Service. This results in the following scheme:_<type>._sub._<serviceType>._tcp.<domain>. Therefore, a Service type acts as amDNS subtype whereas the serviceType of the ServiceDiscovery component acts asmDNS service type. The domain for multicast queries is usually ’local’. As DNS-SD is notlimited to mDNS the domain name could be easily changed when operating in unicast mode.However, at this moment unicast is not supported by the ServiceDiscovery component.The ServiceDiscovery component looks up services as requested by the user interface. Forthis purpose Service components need to be registered with ServiceDiscovery groupedinto ServiceLists. When the updateServices function is called, the list of services isscanned by the ServiceDiscovery component and for each new Service a new DNS PTRlookup is created. Existing DNS PTR lookups for all removed services are closed. When thePTR lookup is answered by a node a new discovery entry is created by the component. Theresponse is then followed by two additional DNS lookups for SRV and TXT types. When

14

Page 20: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Client

DNS-SDPublisher

halrcompService

configService

DNS-SDPublisher

videoService

Client

DNS-SDPublisher

halrcmdService

Config-Server

Haltalk

MJPG-Streamer

DNS-SDBrowser

DNS-SDBrowser

Figure 3.6.: Service discovery of different services.

both lookups complete the corresponding Services are updated with the data from theprevious DNS lookups. The data relevant for a Service are the DNS name provided by theSRV lookup and the TXT records provided by the TXT lookup. The TXT records are thenparsed and used to fill the properties of the Service component.

3.5. ApplicationConfigThe ApplicationConfig component acts as a client for a config-server providing applica-tion configurations. This component has two main purposes, gathering and listing avail-able configurations on a remote host and downloading QML files from a remote host. TheApplicationConfig component uses the config service by connecting to the remote config-server with the dealer-router socket pattern (see figure 2.4). The application configurationprotocol supports two basic messages, one for listing all available configurations and one fordownloading details of a specific configuration.When the ready property of the component transitions from false to true, the componentstarts to connect the ZeroMQ socket and sends a list applications query to the host. Whenthe query is answered the ApplicationConfig component updates the configs propertywith the results. The list of available configurations provided by the configs property can beused to display a configuration selection. To select a specific configuration and to download

15

Page 21: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

application configuration details as well as the QML files of the remote application thefunction selectInstance must be called with the name of the configuration. When therequest is answered by the config-server the new data is accessible using the selectedConfigproperty of the ApplicationConfig component. With this information it is possible toexecute the QML files downloaded from the remote host. Usually QML files downloadedfrom the config-server are placed into the temporary files directory of the OS. If more thanone QML file is provided by the configuration the main file is detected using three rules.Firstly, it is checked whether a QML file with the name of the configuration exist. Then, thefiles are checked for a file with the name main.qml. If still no main file was found the firstfile of the list of downloaded files is selected.

3.6. HalApplicationWindowThe HalApplicationWindow is a component provided as convenience for creatingQtQuickVcp user interfaces. The component combines a HalRemoteComponent as well asthe necessary halrcomp and halrcmd Services within a status and error information page.However, the HalApplicationWindow is not designed to work as standalone component. Itis necessary to provide a source for the two services. This can be done by either combin-ing it with a ServiceDiscovery component or by specifying the service Uniform ResourceIdentifiers (URI’s) manually.

HalApplicationWindow

ContainterItem

HalButton

HalProgressBar

HalButton

HalGauge

HalPin

"button1"BitOut

HalPin

"button2"BitOut

HalPin

"gauge"FloatIn

HalPin

"bar"FloatIn

HalPin

"bar.scale"FloatIn

HalRemoteComponent

"control"

Service

halrcmd

Service

halrcomp

Figure 3.7.: QtQuickVcp QML component structure

Depicted in figure 3.7 is the structure of a typical user interface built uponHalApplicationWindow. The main principle behind the HalApplicationWindow is that

16

Page 22: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

a user interface is presented inside the HAL realtime environment as a single remote com-ponent. All user interface components available within the user interface have HalPinsassigned to their value. Therefore, a button in the user interface is represented bya pin of the remote component. For this to work the HalRemoteComponent providedwithin the HalApplicationWindow scans the containerItem, in this case the wholeHalApplicationWindow, for HalPins. This makes it possible to place any component ofthe HalRemote.Controls module within the HalApplicationWindow and it will be repre-sented by a pin in the remote component.Besides making it easier to build new user interfaces the HalApplicationWindow also featuresa error and status page for displaying information about the status of the halrcmd andhalrcomp services as well as error information from the HalRemoteComponent. When theservices are not ready a indicator is visible in order to inform the user about the applicationstatus. In case an error happens the window displays the type of the error as well as theerror information provided by the HalRemoteComponent.

3.7. ConnectionWindowThe ConnectionWindow component provides an all in one container item to load and dis-play QtQuickVcp user interfaces. It combines service discovery as well as instance se-lection for local as well as remote deployed HalApplicationWindows. Furthermore, theConnectionWindow component provides pages for selecting Machinekit instances, applica-tion configurations and displaying the network connectivity status.

NetworkNetwork

Instance

Application

Running

network opened

instance selectedapplicationselected

backback

networkclosed

Figure 3.8.: State-diagram of the ConnectionWindow

Figure 3.8 displays the state-diagram for the ConnetionWindow component. In case thenetwork connection is closed the state of the ConnectionWindow transitions to the Networkstate displaying the network page. When the network connection is available the statetransitions to the Instance state showing the instance selection page. Then the user needsto select a specific Machinekit instance and the state of the ConnectionWindow transitionsto the Application state. In the Application state all available configurations will be

17

Page 23: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

displayed. When the user selects a specific configuration the state transitions to the Runningstate displaying the actual application. If a user presses the back button the state transitionsto previous state independent of the current state.

ApplicationSelection

HalApplicationWindow

Service

halrcmd

Service

halrcompServiceDiscovery

InstanceSelection

Service

video

ApplicationConfig

Service

config

uuid filter

ready

load QML filesconnect Services

select app

Figure 3.9.: Remote application selection

Depicted in figure 3.9 is a representation of how the components contained by aConnectionWindow interact with each other in case the window works in the remote de-ployment mode. The selection of a specific Machinekit instance is implemented using theitems property of the config Service. When an instance is selected a uuid filter is appliedto the ServiceDiscovery component. The uuid filter results in a single entry in the itemsproperty of the config Service. Then the ApplicationConfig component is activated withthe URI provided by the config Service. Now the application configuration is presented tothe user. Once a configuration is selected first the QML files are downloaded from the remotehost and then loaded inside the QML environment using a Loader component. Next, theservices of the loaded HalApplicationWindow are now connected to the ServiceDiscoverycomponent. When the halrcomp and halrcmd Services of the HalApplicationWindow be-come ready the user interface eventually becomes visible.Depicted in figure 3.10 is a representation of how the components contained by the aConnectionWindow interact with each other in case the window works in local mode. Theprocess works similar to the remote deployment process. However, the application configu-ration selection is skipped because the HalApplicationWindow is already available locally.It is also possible to configure the ConnectionWindow to automatically select a specific in-stance using a filter component. This use case is useful for development purposes in combi-nation with local mode .

18

Page 24: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

HalApplicationWindowService

configService

halrcmd

Service

halrcompServiceDiscovery

Service

video

InstanceSelection

uuid filter

show

Figure 3.10.: Local application selection

3.8. HalRemote ControlsWithin QtQuickVcp a few user interface components combined with HalPins are provided.This components are designed for rapid Machinekit user interface development and can beused as starting point to develop useful user interfaces. The UI components provided withinthe HalRemote Controls module are:

• HalButton - A push button with a text label.• HalCheckBox - A check box with a text label.• HalColorPicker - Provides a beautiful color picker.• HalComboBox - Provide a drop-down list functionality.• HalContainer - A container item to enable and disable children.• HalGauge - Provides a linear gauge control to display data.• HalLabel - A text label.• HalLed - Provides a LED-like control to display binary values.• HalLogChart - A chart for logging data.• HalProgressBar - A progress indicator.• HalRadioButton - A radio-button with a text label.• HalSlider - Provides a vertical or horizontal slider control.• HalSpinBox - A spin box control.• HalVirtualJoystick - A virtual joystick control.

However, machine control UIs often require custom UI controls. With QtQuickVcp this ispossible by adding a HalPin to a component and binding the value of the custom controlto the value of the HalPin. This makes it possible to extend the range of available controlswithout the need to modify C++ code.

19

Page 25: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

4. Analysis

This chapter analyzes the performance of the remote user interfaces in terms of networkperformance and response time as well as reliability. For this purpose two test setups wherecreated. The first one tests the echo time of a remote component and the second one thetotal round-trip time between two connected remote components. Both test setups wheretested under real-life conditions with a Ethernet network and a wireless network setup.

4.1. Test setupDepicted in figure 4.1 is the setup for the first experiment. A simple application withjust one HalRemoteComponent and one HalPin is created. When the HalPin is con-nected to the HalRemoteComponent a pin change is performed and the synced propertyof the HalPin changes to false. Furthermore, the signal travels from the HalPin over theHalRemoteComponent to the Haltalk instance running on the remote realtime host. Afterthe pin change has been processed the Haltalk instance sends a pin update to all connectedHalRemoteComponents. In this case only one HalRemoteComponent is connected and up-dated. The message is then processed by the HalRemoteComponent and results in an updateof the HalPin value. This update sets the synced property of the HalPin back to true. Thetime between the change of the synced property to false and the change of the syncedproperty back to true is measured and used for the performance statistics.

RemoteComponent

Pinpin change pin update

Haltalk

measure time

Figure 4.1.: Test setup 1.

Figure 4.2 shows the setup for the second experiment. For this setup an application withtwo individual HalRemoteComponents was created. Both components are connected to asingle HalPin. The HalPin of the first component acts as input pin and the HalPin ofthe second component acts as an output pin. The pins of both remote components areconnected inside the HAL realtime environment on the Machinekit host. When the value ofthe first HalPin is changed the pin change event is processed by the HalRemoteComponent

20

Page 26: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

and sent to the Haltalk instance. The Haltalk instance sends the pin change event to theHAL realtime environment where the pin change event is processed. The pin change thenresults in an update of the connected pin of the second remote component. This update isthen detected by the Haltalk instance and forwarded as pin update message to all connectedHalRemoteComponents. The pin update event results in an update of the value of the secondHalPin. The time between the change of the value of the first HalPin and the update of thesecond HalPin is measured and used for the performance statistics.

RemoteComponent

Pinpin change

Haltalk

RemoteComponent

Pin pin updatemeasure time

Figure 4.2.: Test setup 2.

For both setups the value of the triggering HalPin was toggled 1000 times. Furthermore, thecaptured data was processed to derive statistics.

4.2. ResultsBoth tests where performed with different Haltalk remote component timer intervals. Haltalkpolls every remote component in a specific interval in order to detect changes and sendsthem to all connected remote instances. Therefore, this parameter is especially relevant forperformance measurements.Table 4.1 shows the results of the first test setup and table 4.2 shows the results of the secondtest setup. A graphical representation of the test results can be found in Appendix A.

Table 4.1.: Results of Test 1Type Timer Mean StdDev StdErr Variance Max Min MedianEthernet 5 9.048 3.405 0.108 11.591 19 1 9Ethernet 10 11.734 4.265 0.135 18.187 29 2 11WLAN 10 20.123 40.747 1.289 1660.312 511 2 14Ehernet 20 18.085 10.274 0.325 105.547 116 1 18WLAN 20 17.571 30.485 0.964 929.360 556 3 14Ethernet 100 53.984 28.230 0.893 796.927 148 4 52.5WLAN 100 63.625 89.543 2.832 8017.962 1927 4 57

21

Page 27: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Table 4.2.: Results of Test 2Type Timer Mean StdDev StdErr Variance Max Min MedianEthernet 5 9.274 3.249 0.103 10.555 18 1 9Ethernet 10 12.018 5.034 0.159 25.337 88 2 11WLAN 10 17.273 16.836 0.532 283.446 184 3 13Ethernet 20 17.054 6.990 0.221 48.854 34 2 17WLAN 20 21.397 14.939 0.472 223.175 152 3 19Ethernet 100 57.436 29.735 0.940 884.188 112 3 58WLAN 100 66.219 60.130 1.901 3615.569 896 5 62

4.3. InterpretationThe results of the performance tests show that the system performs very well on both Ether-net and Wireless Local Area Network (WLAN) networks. However, the standard deviationof the test results from the wireless measurement is higher than the standard deviation ofthe test results from the Ethernet measurement. If we analyze the scatter diagrams (seeAppendix A) we can see that the wireless connection slows down from time to time. Thiscan be tracked down to signal variation and interference during the measurement. Therefore,for controls where high reliability and small jitter is important a non-wireless network con-nection should be used. For most end-user devices such as 3D printers and self-built robotsthe wireless interface is reliable and fast enough.

22

Page 28: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

5. Conclusion

The new remote user interfaces provide a significant improvement in the capabilities of Ma-chinekit as rapid development platform as well as production-ready machine control platform.Creating user interfaces independent of the machine control platform avoids the limitationsof embedded platforms in terms of CPU speed and graphical performance. Furthermore,the software is designed in a way that it can be easily extended with new modules andfunctionality. This is especially relevant for incremental development of rapidly innovatingtechnologies such as 3D printers and robots. Moreover, QtQuickVcp provides a set of prede-fined components and configurations for rapid machine control user interface development.

Future workFuture work on QtQuickVcp will include the development of a GCode path and progressdisplay. Moreover, the interface to communicate with the Machinekit interpreter needs to bedefined and implemented in QtQuickVcp in order to enable remote user interface developmentfor GCode controlled machines. Furthermore, the default client application should come witha set of useful tools such as a HAL scope and meter to further improve the rapid developmentcapabilities of Machinekit.

23

Page 29: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

Bibliography

[1] The Glade project (2014), Glade: A User Interface Designerhttps://glade.gnome.org/, 10 June 2014

[2] The GTK+ Team (2007-2012), The GTK+ Projecthttp://www.gtk.org/, 10 June 2014

[3] Delta XMPP Project (2014), JDNShttp://delta.affinix.com/jdns/, 10 June 2014

[4] The Machinekit Project (2014), Machinekit in a nutshellhttp://www.machinekit.io/, 10 June 2014

[5] Michal Haberler (2014), Machinetalk functional overviewhttps://github.com/mhaberler/asciidoc-sandbox/wiki/Machinetalk-functional-overview, 10 June 2014

[6] Jonny Dee (2014), nzmqt - A lightweight C++ Qt binding for 0MQhttps://github.com/jonnydee/nzmqt, 10 June 2014

[7] Google Developers (2012), Developer Guide - Protocol Buffershttps://developers.google.com/protocol-buffers/docs/overview, 10 June2014

[8] Digia Plc (2013), Qbs Manual Version 1.2.0http://qt-project.org/doc/qbs-1.2/index.html, 10 June 2014

[9] Digia Plc (2014), Qt Creatorhttp://qt-project.org/wiki/category:tools::qtcreator, 10 June 2014

[10] Digia Plc (2014), Qt Projecthttp://qt-project.org/, 10 June 2014

[11] John W. Shipman (2013), Tkinter 8.5 reference: A GUI for Pythonhttp://infohost.nmt.edu/tcc/help/pubs/tkinter/tkinter.pdf, 10 June 2014

[12] Delta XMPP Project (2014), Delta XMPP Projecthttp://delta.affinix.com/, 10 June 2014

[13] iMatix Corporation (2014) ZeroMQ - The Guidehttp://zguide.zeromq.org/page:all, 10 June 2014

24

Page 30: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

List of Abbreviations

API Application Programming Interface

BSD Berkeley Software Distribution

DNS Domain Name System

DNS-SD DNS Service Discovery

GladeVCP Glade Virtual Control Panel

GPL General Public License

GUI Graphical User Interface

HALCMD Hardware Abstraction LayerCommand

HAL Hardware Abstraction Layer

IDE Integrated Development Environment

IO Input/Output

JSON JavaScript Object Notation

KDE K Desktop Environment

LGPL Lesser General Public License

mDNS Multicast DNS

MIT Massachusetts Institute of Technology

MJPEG Motion JPEG

NML Neutral Message Language

OS Operating System

PC Personal Computer

protobuf Protocol Buffers

PyVCP Python Virtual Control Panel

Qbs Qt Build Suite

QML Qt Meta Language

QtQuickVcp QtQuick Virtual Control Panel

RT Realtime

SDK Software Development Kit

SoC System-on-a-Chip

SSH Secure Shell

TCP Transmission Control Protocol

UI User Interface

URI Uniform Resource Identifier

USB Universal Serial Bus

UVC USB Video Class

VCP Virtual Control Panel

WLAN Wireless Local Area Network

WYSIWYG What You See Is What YouGet

XML Extensible Markup Language

XMPP Extensible Messaging and PresenceProtocol

zeroconf Zero-configuration networking

25

Page 31: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

List of Figures

2.1. Polling-based messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Event-based messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3. Centralized (left) and decentralized (right) messaging . . . . . . . . . . . . . . 62.4. Router-Dealer (left) and Publish-Subcribe (right) ZeroMQ messaging patterns 62.5. Serialization of objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.6. Centralized (left) and decentralized (right) service discovery. . . . . . . . . . . 8

3.1. Relation between UI and HAL remote components . . . . . . . . . . . . . . . 113.2. HalRemoteComponent state-machine. . . . . . . . . . . . . . . . . . . . . . . . 123.3. Haltalk communicating with two clients over halrcmd (blue) and halrcomp

(red). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4. A state diagram for the synced property of the HalPin component. . . . . . 133.5. A state machine for the Service component. . . . . . . . . . . . . . . . . . . 143.6. Service discovery of different services. . . . . . . . . . . . . . . . . . . . . . . 153.7. QtQuickVcp QML component structure . . . . . . . . . . . . . . . . . . . . . 163.8. State-diagram of the ConnectionWindow . . . . . . . . . . . . . . . . . . . . . 173.9. Remote application selection . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.10. Local application selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1. Test setup 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2. Test setup 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A.1. Test 1: Ethernet 5ms timer interval . . . . . . . . . . . . . . . . . . . . . . . . 28A.2. Test 1: Ethernet 10ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 28A.3. Test 1: WLAN 10ms timer interval . . . . . . . . . . . . . . . . . . . . . . . . 28A.4. Test 1: Ethernet 20ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 29A.5. Test 1: WLAN 20ms timer interval . . . . . . . . . . . . . . . . . . . . . . . . 29A.6. Test 1: Ethernet 100ms timer interval . . . . . . . . . . . . . . . . . . . . . . 29A.7. Test 1: WLAN 100ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 29A.8. Test 2: Ethernet 10ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 30A.9. Test 2: WLAN 10ms timer interval . . . . . . . . . . . . . . . . . . . . . . . . 30A.10.Test 2: Ethernet 20ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 30A.11.Test 2: WLAN 20ms timer interval . . . . . . . . . . . . . . . . . . . . . . . . 30A.12.Test 2: Ethernet 100ms timer interval . . . . . . . . . . . . . . . . . . . . . . 31A.13.Test 2: WLAN 100ms timer interval . . . . . . . . . . . . . . . . . . . . . . . 31

26

Page 32: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

List of Tables

4.1. Results of Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2. Results of Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

27

Page 33: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

A. Test results

time[m

s]

0

10

20

30

40

50

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 10 20 30 40 50

(b) Gauss function

Figure A.1.: Test 1: Ethernet 5ms timer interval

time[m

s]

0

10

20

30

40

50

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 10 20 30 40 50

(b) Gauss function

Figure A.2.: Test 1: Ethernet 10ms timer interval

time[m

s]

0

50

100

150

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150

(b) Gauss function

Figure A.3.: Test 1: WLAN 10ms timer interval

28

Page 34: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

time[m

s]

0

20

40

60

80

100

120

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 10 20 30 40 50

(b) Gauss function

Figure A.4.: Test 1: Ethernet 20ms timer interval

time[m

s]

0

50

100

150

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150

(b) Gauss function

Figure A.5.: Test 1: WLAN 20ms timer interval

time[m

s]

0

50

100

150

200

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150 200

(b) Gauss function

Figure A.6.: Test 1: Ethernet 100ms timer interval

time[m

s]

0

50

100

150

200

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150 200

(b) Gauss function

Figure A.7.: Test 1: WLAN 100ms timer interval

29

Page 35: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

time[m

s]

0

20

40

60

80

100

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 10 20 30 40 50

(b) Gauss function

Figure A.8.: Test 2: Ethernet 10ms timer interval

time[m

s]

0

50

100

150

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150

(b) Gauss function

Figure A.9.: Test 2: WLAN 10ms timer interval

time[m

s]

0

10

20

30

40

50

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 10 20 30 40 50

(b) Gauss function

Figure A.10.: Test 2: Ethernet 20ms timer interval

time[m

s]

0

50

100

150

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150

(b) Gauss function

Figure A.11.: Test 2: WLAN 20ms timer interval

30

Page 36: Next Generation Remote User Interfaces forMachinekit · This includes the selection of a cross-platform user interface framework, ... NML-beingdefinedinC++-isnotusableinakernelRTthreadssetup,hencemessages

time[m

s]

0

50

100

150

200

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150 200

(b) Gauss function

Figure A.12.: Test 2: Ethernet 100ms timer interval

time[m

s]

0

50

100

150

200

measurement []0 200 400 600 800 1,000

(a) Scatter diagram

prob

ability

[]

0

0.2

0.4

0.6

0.8

1

1.2

time [ms]0 50 100 150 200 250 300

(b) Gauss function

Figure A.13.: Test 2: WLAN 100ms timer interval

31