CS++ framework – An introduction

Version 0.3

03. 12. 2015

Please send comments / corrections / ideas to D.Neidherr@gsi.de

Dieses Material steht unter der Creative-Commons-Lizenz Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 4.0 International. Um eine Kopie dieser Lizenz zu sehen, besuchen Sie http://creativecommons.org/licenses/by-nc-sa/4.0/.

Copyright 2015 GSI Helmholtzzentrum für Schwerionenforschung GmbH,

Dr. D. Neidherr, RBEE, Planckstraße 1, 64291 Darmstadt, Germany

2

Contents1 Introduction......................................................................................................................................5

2 Getting started...................................................................................................................................52.1 Version control.........................................................................................................................5

2.2 GitHub......................................................................................................................................72.3 Downloading CS++ main and additional packages..................................................................8

2.4 Installation and Configuration of LabVIEW............................................................................82.5 Install the CS++MessageMaker................................................................................................9

3 Basic concepts..................................................................................................................................93.1 Object orientation.....................................................................................................................9

3.2 Concept of Inheritance............................................................................................................113.3 Actor framework.....................................................................................................................11

3.4 Communication between actors..............................................................................................123.4.1 Actor framework messages............................................................................................12

3.4.2 Communication layer.....................................................................................................133.5 The Factory.............................................................................................................................13

4 Basic Programming within CS++...................................................................................................144.1 The Base actor........................................................................................................................15

4.2 Messages within CS++...........................................................................................................194.3 Using the CS++ factory and the CS++StartActor..................................................................21

4.4 Error Handling........................................................................................................................234.5 PV & SV – Monitor................................................................................................................26

5 Everyday programmers tasks within CS++....................................................................................315.1 New devices in the device layer.............................................................................................31

5.2 A new GUI in the application layer........................................................................................315.3 Configuration parameters.......................................................................................................31

A Test.................................................................................................................................................31

3

4

1 IntroductionThis document will describe everything important to start with the development of an own, experiment-specific, CS++ based control system. The aim is to have a relatively “short” manual, with which everyone can start. Nevertheless the reader should be familiar with the basic concepts of LabVIEW to understand the later chapters.

The first chapter of the following text will show where to get the source code of the framework, how to install everything, and how to upload changes. In chapter two the basic idea of CS++ is presented. This includes questions like “Why do we need an object oriented approach?” or “What is an actor?”. Chapter four and five are probably the most important one since they describe the source code and show general examples.

Red boxes indicate important information.

2 Getting started

2.1 Version controlCS++ is only available on GitHub. All files can be downloaded there manually (be sure that you download the correct branch, see later) but we would like to encourage you to use Git for your daily work. Git is a powerful distributed version control system (VCS) that has some advantages over centralized version control systems like Subversion which was used for the CS-framework. Most developers within the CS++ community are PhD students or Postdocs who have studied physics or chemistry and may not be aware of the necessity of a version control system at all. If they want to save a snapshot of their current work they normally just create a zip-file and copy it to another disc. This is certainly working (and very fast) but also very uncomfortable. A version control system does the same (and more) and has a lot of benefits:

Depending on the used VCS, the handling can be much simpler than copying files around. It allows you to add comments to your snapshots. This is a very important point. Many times I

visited experiments and saw files like “Test1.zip”. And no one could tell me what the difference is between the files in this zip file and the current working copy. This means: A version control system without comments works only for one working day at max.

It easily allows you to work with colleagues on the same project. (Because for example they can read your comments and do not have to ask you each time they want to work on your files.)

Git is a distributed VCS, which means that it does not necessary needs a central server to be connected to. This makes it much easier to work offline. The server (in our case GitHub) is only needed to share the files between developers. The next figure shows the idea of a distributed VCS like Git:

Each PC has the files in all versions locally available. In contrast to a centralized VCS the PCs do not have to establish a connection to the server, when you want to switch from one version to the other.

5

One should note that the developer sees only one revision at a time. The other ones are hidden. But he can almost instantaneous switch between them (but one should close LabVIEW...).

There are many different ways to use Git. Some people prefer a graphical user interface and some are happy with using just the command line. In the following the usage of the freeware GUI SourceTree is presented. You should install both: Git and SourceTree.

During the installation of SourceTree you will be asked if you want to create a new repository or clone an existing one. Later you can use the Clone / New button. Nevertheless on the left side of the GUI you can see all independent projects on this computer. In this example the first one is named CSPP and is located at D:\Git\CSPP. A double click on this bookmark opens the history window on the right side. This history shows you all existing snapshots which were previously committed together with comments. Note that the development does not necessarily have to be only linear. One can also split it (if for example two developers are working on the same files at the same time) and merge everything in the end (create a new branch, see next).

A branch is something like a pointer to one of these commits. It can be used to easily switch between them. In the example above we have three different branches (DNDev is the one which is right now active). With a right mouse click and Checkout you can switch between different branches. Note that there is also a history entry called Uncommitted changes. This means that there is a difference between my working copy (the files which are visible on the local hard drive and on which I work) and the current branch (DNDev), so I modified them. We could commit these changes to the current branch. In the two windows below one can see all these uncommitted changes (right now just one File called CSPP_DN.lvproj). The commitment procedure is a two-step process. First you have to select all files in the Unstaged files list which you want to commit. If the Staged files list is complete you can press the Commit button, enter a new comment and you will see that a new entry in the history (a new snapshot) will be created and your current branch will point to that one.

Git allows you to have many different versions of the same set of files on your local hard drive and to switch between them easily. But if you want to share your files with colleagues you need an online (remote) repository. In this example I created an online repository called origin which has the same three branches like my local one. With the Fetch button (or Pull button for single branches) you can update your local repository with respect to changes on the online one. Note that this will not change your working copy. You will only see in the history if there were any changes online. With the Push button you can upload local changes.

6

Within CS++ we are using packages to combine classes with similar features and tasks (for example CSPP_IVI for all IVI classes). This makes the maintenance more structured and in the end much simpler. Git supports such packages but names it as so called Submodules. A submodule is a complete repository which is part of your main project. If there are any changes to these repositories you will not see it in the history of your main project. In the example above you can see that I included four submodules to my project (to add a submodule use the right mouse button on the CSPP tab and select Add submodule...). The small symbols next to the first three of the four submodules indicate that there are uncommitted changes. A double click on the opens their history.

Just as a last remark: It is certainly a good idea to play a bit with SourceTree before downloading CS++.

2.2 GitHubGitHub is used to distribute the source code to all developers. You only need a connection to GitHub if you want to download packages or upload changes you made. The main page of CS++ is:

https://github.com/HB-GSI/CSPP

On this webpage you can find a link to our wiki, where you can find step-by-step manuals for many questions arising during the development process. We would also like to encourage you to use the Issues link in the top-right corner, if you find any bugs.

You may not have write access to the CS++ source files on GitHub. Nevertheless if you want to contribute to these sources you can Fork the existing project (button in the upper right corner). This means that GitHub will copy the original project and make a new one to which you have write (or push) access. So the idea is that you make changes to a project on your local disc, push everything into your forked project and afterwards start a “Pull Request”. A “Pull Request” means that you want your modified files to become part of the original project. Since you don´t have push access this means the maintainer of the original project will get a notification, can have a look at your code, and in the end decide to include your changes or reject them. This is the preferred way to upload new files. Note that you don´t need to do that if you created a completely new package. Then you are the maintainer of that project and responsible for all changes (and you get the notifications once someone wants to modify your files).

7

2.3 Downloading CS++ main and additional packagesThis chapter shows you how to download and install CS++ on your PC. A similar manual can be found in the wiki. You can also create your own, new project and just add the necessary submodules.

1. Download Git: Download and install Git.2. Register at Github : Register yourself at Github.3. Fork the CS++ main Repository: For this, open the main CS++ web page (HB-GSI/CSPP) and

click on the “Fork” button in the upper, right corner. This will open a new webpage (YourAccountname/CSPP).

4. Install SourceTree: Download and install SourceTree. During the installation you will be asked to clone an existing repository. You should be able to choose the just forked repository (YourAccountname/CSPP) from the list. Otherwise skip this step, open SourceTree and click on Clone / New to clone it.

5. Create a new local branch: In SourceTree click on Branch to create a new local branch and copy the master branch from the GitHub repository.

6. Install the necessary submodules: You can find a list with all available submodules at:https://github.com/HB-GSI/CSPP/wiki/Getting-started

The two necessary submodules Core and DeviceBase are already included in CSPP. To add more modules, right click on the free workspace below the remote branches and select Add Submodules....

Add the Source URL from the list above and change the local relative path to for example:

Packages\CSPP_Core

7. Change all files in the submodules to read-only: It is now a good idea to set all files in the submodules which you do not want to modify to read-only. This will help you a lot while working with LabVIEW, because it is quite common that LabVIEW makes small modifications to files which are in fact not necessary. In Git these changes would occur as new versions and would therefore lead to a lot of confusion.In your main project click on Terminal and enter:

chmod a-w –R Packages

In step 6 all files from the submodules were put in the Packages subfolder. Now they are all read-only.

2.4 Installation and Configuration of LabVIEWFor the CS++ the installation of LabVIEW 2015 (or newer) is necessary. In addition the DSC module should be installed if available (see below). It has to be decided from case to case which drivers should be installed. Generally spoken, a standard installation should be enough (maybe together with the IVI drivers). Special drivers, like FPGA drivers for example only have to be installed if necessary.

8

Please check the following webpage for details how to configure LabVIEW. Some of these options are very important, so you should take two minutes to follow that list:

https://github.com/HB-GSI/CSPP/wiki/LabVIEW-Options

2.5 Install the CS++MessageMakerThe CS++MessageMaker is an extension to the standard Actor Framework Message Maker. As you will see later, messages are an important part of CS++ and during the development process you may have to create a lot of them. Therefore we created a small tool which will help you here. The CS++MessageMaker can be downloaded from:

https://github.com/DN-GSI/CSPP_MessageMaker

Again: It is a Github repository, so you should use SourceTree to download everything, and check out the newest version. Afterwards go to the _CSPP_MessageMaker\Installer subfolder and execute the Installer.vi to install everything.

Note that you also need the CS++MessageMaker installed if you don`t want to create messages by yourself. In other words: Installing it is mandatory.

3 Basic conceptsThe CS++ framework supports you in creating a control system for an experiment. It delivers a toolkit for further developments, which means that there is still work to do for you! The main features of the framework are:

It should be “relatively” easy to learn for the local developments, especially since we expect that these developers are no full-time programmers. This aim can´t be always achieved. But this manual as well as the wiki documentation on Github should help. We tried to hide as much as possible of the very complicated stuff from the local developers.

The framework has to be flexible. So the configuration of the control system must be changeable online.

Compared to the CS-framework CS++ should be easier to use for smaller experiments (table top experiments).

The following subchapters describe some important paradigms used in CS++. Depending on your knowledge you may skip some of these.

3.1 Object orientationObject orientation is a well-known concept in programming languages and necessary for the flexibility of our system. National Instruments included it in LabVIEW version 8.2. Because of the data-flow paradigm of LabVIEW, its object orientation ansatz is a bit different from many other programing languages. The “older” CS-framework was created before LabVIEW 8.2 and used references to combine data-flow and object orientation. This was working but relatively difficult to use and especially complicated to debug.

But first: What is object orientation? Object orientation means that you have to write so called classes, which are just blue prints for objects you create during runtime. For example you can write a class called “car” which has some attribute data (its properties) like “color” or “max speed” and some methods like “Move” or “Stop”. During runtime you can create as many objects from “car” as you want, but you have to write the source code (the class) only once (Reusability of code). Your main application has to create and interact with these objects and they can interact with each other. In our case this means for example that you program a class for a specific power supply once and if you have many of them you can reuse the source code of the class.

Because of the data-flow paradigm there are some important notes for using classes within LabVIEW:

In LabVIEW a class is a passive data object. Like all other LabVIEW data types it exists only as long as the wire is still active (so within a loop for example).

9

Each class can have attribute data and / or methods. Methods are special VIs with the class wire as a required input parameter (and optional output). The methods can be for example used to set or get attribute data or perform some actions (communicate with devices and so on).

The figure above shows an example of the usage of classes within LabVIEW. In the first sequence step an object of the class CS++Base (which is part of the library CS++BaseClasses.lvlib) is created. This class has at least one attribute, called Object name, which can be set (step 2) and read out (step 3) with specific VIs. Note that the life span of this object ends at step 4. The next figure shows how this looks within the project explorer:

You can see here the attributes of the class (CS++Base.ctl) and one method (Initialize Attributes (public).vi). The other methods are within the two folders.

A very important case is the following:

A junction of an object wire leads to two independent objects! It is really important to always remember this during the work on the source code since it is a very common mistake to create an unwanted second object, making changes to this one and trying to see the result on the first one. A mistake like this can be difficult to debug. And especially if the object carries a resource (like a device class a connection to a device) this leads certainly to an error.

10

3.2 Concept of InheritanceAnother advantage of object orientation is inheritance. This is again a way to reuse parts of your code, but this time not within the same class but between different classes which share certain attributes and / or methods. So a class which was inherited from another, so-called parent class has the attributes and methods of this parent class as well as some new attributes and methods.

In the file menu under “View” and “LabVIEW class Hierarchy” you can find all classes of the CS++ framework:

Note that child classes always should be more specific compared to their parents. Within CS++ we have for example a class CS++DeviceActor which delivers some functions needed by all hardware devices (Firmware Revision, Resource Name and so on). The class CS++Scope inherits from CS++DeviceActor and adds functionalities which are specific for oscilloscopes. This is still more an abstract class. Only its child class IVI_Scope includes the hardware driver and can be used to communicate with a real device. The advantage of this approach is that if we want to include a new oscilloscope in CS++ which does not use the IVI driver, we do not have to start from scratch. We just create a second child class of CS++Scope and include the driver. So we don´t have to touch the graphical user interface, the communication layer in the background and all these things. Depending on the actual device this could mean that the workload is reduced by a huge factor!

To change the inheritance of a class, you just have to use the right mouse button on this class in the project explorer and go to “Properties” and “Inheritance”.

Another important aspect of inheritance is the possibility for the child class to overwrite a method of the parent class. So, for our example above this would mean that a method TakeMeasurement.vi could be implemented in CS++Scope as well as in IVI_Scope. However in CS++Scope the VI would be more or less empty, just the inputs and outputs would be there. This is necessary to include TakeMeasurement.vi at other places in the source code independent of what type of oscilloscope is loaded. In IVI_Scope the instrument driver would have to be included. In LabVIEW a parent class VI which can be overwritten is called dynamic dispatch. Note that the child class VIs can also execute their parent methods (there is a special function on the palette for that). To understand the rest of this manual it is essential to get the point of dynamic dispatching. If you are looking for an easy example in LabVIEW just go to Help, Find Examples, Search and type dispatch. Open the Dynamic Dispatching.lvproj project.

3.3 Actor frameworkCS++ is based on the Actor framework by National Instruments (the framework itself is nowadays a common programming concept, but NI included it in LabVIEW 2012). A very detailed introduction

11

can be found here1. An actor can be seen as an “active object”. Active means in this context that an actor can do something by itself, triggered for example by an internal clock or by the user. In contrast, a LabVIEW object is a passive piece of data. You can write something in its attribute data, read it out or execute some methods from outside. An actor has an active VI running in the background (which is called ActorCore.vi). There is also a build-in way of communicating between actors with so-called messages (see chapter 3.4.1).

To summarize this because it is important for everything what follows: An actor is a class, which already inherited from the Actor.lvclass, delivered by National Instruments. It offers a messaging system to communicate with it and an active thread (a running VI) to react to these messages or do something for example periodically.

In contrast to a simple object, an actor object (from now on I will use the term “actor” also for “actor object”) has to be started and stopped. For this a Launch Actor.vi and a Stop Message are provided.

A question which often comes up at this point is: Why do we need such a structured approach? Everything would also work without it, or not? The reason is that without such software architectures we would create a very inflexible framework. And probably after weeks or months of work we would encounter problems which could have been easily avoided by using a well-known architecture. So without such an approach you can make mistakes without even recognizing it immediately; something no programmer likes.

3.4 Communication between actorsIn general there are two ways of communication between different actors in CS++. The actor framework offers the possibility to send messages to an actor. These messages will be executed by the actor one after each other in a deterministic way. This is important if you for example want to execute a specific sequence of commands. And it is the native way of communication in CS++. This means it is much easier to use for the programmer.

The other way is using a network communication protocol like the Shared-Variable engine from National Instruments or DIM. This has the huge advantage that it can be used to communicate with other PCs without much effort. In fact, since the framework has to be scalable this method has to be used extensively when communicating between different actors.

In the end a combination of both ideas is used. How this is exactly done will be explained later.

3.4.1 Actor framework messagesEach actor has a queue belonging to it. This queue is used to send messages to this actor, so to tell it to do something. The messages are put into this queue and the oldest one is dequeued by the actor within its Actor Core.vi:

1 https://decibel.ni.com/content/docs/DOC-18309

12

But not everyone can send messages to a specific actor. Only the VI which launched the actor knows the reference to the queue of the new actor (It is one of the outputs of the Launch Nested Actor.vi):

So if one actor launches several other actors and these actors may also launch nested actors by themselves, all actors can be sorted within an actor tree (with the main or root actor on top). This is especially important for the shutdown procedure since if you shut down the root actor you also have to send a shutdown message to all actors which were previously launched by this actor and these actors again have to send stop messages to their nested actors and so on.

Within CS++ an object manager is running in the background, which collects all message enqueuers. This is necessary because otherwise the communication from one actor to another one could be very complicated (in the worst case all actors within the “actor tree” would have to send messages around, so a huge overhead would be created). Nevertheless each actor still keeps a copy of its launched actors enqueuers for the shutdown procedure.

3.4.2 Communication layerThe second way of communication is the usage of process variables. Here, one has to distinguish between two different methods: (i) Polling mode and (ii) Event driven mode:

In the Polling mode a “client” is continuously asking a “server” for the newest value of the process variable. An example could be a graphical user interface asking a temperature sensor for its value each second. This is relatively simple to achieve but has the disadvantage that a lot of data traffic between the different actors is produced, which is probably unnecessary. On the other hand, the amount of data which has to be transferred will never fluctuate, so there cannot be any traffic peaks, which could disturb the system during a critical situation. So let´s assume the temperature sensor just determines the temperature with a precision of one degree (a very bad sensor). In a temperature controlled area this could mean that its value might change only a couple of times during a whole day. So the GUI actor would ask the sensor actor far too many times for new values.

For this the Event driven mode can be used. This means that a client (here our GUI) registers once to a server (the sensor) and each time the server wants to update its value (because the temperature changed) it automatically sends it to all registered clients. In many applications this is the preferred way of communication in CS++.

The next question would be which technique should be used to implement these two ways of communication (or at least the event driven one). In CS++ we have included two different network layers for this purpose. They can be exchanged on the fly by modifying the configuration ini-file.

The first one is National Instruments Datalogging and Supervisory Control (DSC) module. It offers you the possibility to use so-called shared-variables across the network. Note that with the standard installation of LabVIEW you can already use the Shared-Variable engine in polling mode. For the event driven mode you need the DSC module which is an additional software package and has to be ordered (and paid) separately.

The CS-framework is based on the DIM2 protocol developed by CERN. This is also included in CS++. We are using it only in the event driven mode and compared to the Shared-Variables engine from NI it is a bit more complex to install and to configure. DIM is a small C++ program which serves as a network layer for several larger experiments at CERN. To use it with LabVIEW an interface library has to be used. This will be described later. In fact, the usage of the DSC module is the recommended method, but DIM does not cost anything and should offer the same basic communication. The disadvantage of DIM is clearly that the support can be more difficult.

2 http://www.cern.ch/dim

13

3.5 The FactoryThis chapter describes a very basic aspect of CS++ needed to achieve the desired flexibility: The factory. As described in chapter 3.1 in LabVIEW an object is created by putting a constant on the block diagram (just like a normal variable). So if you would want to give the user the possibility to choose which class he wants to create, you can for example use a case structure. The problem with that

method is that you would have to modify this case structure each time a new class is added to your control system. A much more elegant way is the usage of a factory.

The CS++ factory is a simple LabVIEW class with the methods Create Object.vi and Create Actor.vi. These methods (see the inset above) get an object name and deliver a fully initialized object / actor. During runtime the user only has to pass the object- / actor-name to the factory. Then the factory will check a configuration file (can be a simple ini-file or a database for example) for the class which has to be loaded. “Initialized” means in this context that each classes Initialize Attributes.vi method is executed, which in general reads out all remaining parameters from the configuration file and saves them in its own attribute data. This is done to reduce the number of accesses to the configuration file.

Note that an actor object created by the factory still has to be launched (see chapter 3.4.1) to become active.

4 Basic Programming within CS++CS++ is based on the Actor framework from National Instruments. In fact we only added our own CS++BaseActor which includes some needed functions as well as additional classes, which are not mandatory. This has the huge advantage that the core of our framework is maintained by a large, world-wide community (and in the end actually by National Instruments).

The following chapter describes the core of CS++ together with programming examples (yellow boxes) and comparisons to the Cs-framework (blue boxes). All these files can be found in “...\Packages\CSPP_Core”.

The general layout of the framework is shown in the next figure:

The idea is that the local developer only touches the application layer (if he wants to create a new GUI or a special sequencer for example) or the device layer (if he wants to include a new device). The

14

black box in the middle will be maintained by us and should not be touched by the developer. Nevertheless he should be familiar with the interfaces between the black box in the middle and the rest of the system (the gray arrows).

Chapter five will focus on these two parts. There you will find explanations and examples to extend the application layer of CS++ (chapter 5.2) as well as the device layer (chapter 5.1). This chapter describes more the basic concepts and the main parts of the framework.

4.1 The Base actorThe BaseActor of the CS++ framework can be seen on the right hand side. All actors within the framework have to inherit from this one. In the library CS++BaseActor.lvlib you can find the actor itself (CS++BaseActor.lvclass) together with its messages in a separate folder. The actor has some privat attribute data (CS++BaseActor.ctl) and some protected VIs (in the folder protected) as well as public methods (in the folders Accessors and Actions). “Public” means that these methods can be addressed from outside; so another VI outside this class can include them as sub-VIs. The difference between VIs in the folders Accessors and Actions is that in the first folder only VIs are included which grant access (read or write or both) to one of the privat attribute data (these VIs can be generated automatically; right mouse button => “VI for Data Member Access...”). You can have a look at these VIs. They are very simple. Attribute data without such access VIs cannot be modified from outside (principle of information hiding).

At this point it is important to understand what the VIs in the Actions and protected folders are actually doing. Especially important are After Launch Init.vi, Instrospection.vi, Actor Core.vi and StopCore.vi. These VIs will be discussed in a moment.

You may already have noticed that some of the protected VIs in the folder protected have nearly the same name as some public VIs in Actions just with an additional Core at the end. The reason is that both VIs are needed for one function. Let`s explain that with the first example:

After Launch Init.vi is executed always just after the Launch Nested Actor.vi for this actor is executed. It can be used to initialize a device for example. For this the Actor Core.vi of the CS++BaseActor sends an After Launch Init Msg to itself, which triggers this VI. Note that the Actor Core.vi of a child class is so designed that it always has to execute the Actor Core.vi of its parent class and so on. This means that this AfterLaunchInit procedure is working for all classes which are inherited from CS++BaseActor directly or indirectly. Once the After Launch Init.vi is executed via the self-send message it directly executes a dynamic dispatch VI called After Launch Init Core.vi (so the 2nd VI is somehow the “core” of the 1st). In total the message leads to the execution of two VIs: The public one of the parent class and the “Core”-VI of the child class (or grandchild, simply the “youngest” one). The “Core”-VI of the child class can be modified for each actor within CS++ (different devices have different initialization routines) and in the public one of the parent class a common functionality for all initialization procedures can be included. There is also a Pre Launch Init.vi which is executed just before the Actor Core.vi becomes active.

The three VIs After Launch Init.vi, After Launch Init Core.vi and Pre Launch Init.vi have the same purpose as the Constructor.vi in the CS-framework. Overwrite After Launch Init Core.vi in child classes and allocate any resources there. Pre Launch Init.vi can be used to make consistency checks which can prevent the whole actor from being loaded.

The Introspection.vi is needed to achieve the desired flexibility of the framework. In this context “introspection” means that one can ask an actor on which messages he is listening to. If you want to have a general GUI, which can send messages to all your actors you either have to include case structures for each actor in this GUI (not preferred, too much work; you have to modify the GUI each time you include a new actor) or the GUI just asks each actor for his messages. Each child class of

15

CS++BaseActor has to overwrite the Introspection Core.vi and attaches its own messages to the CS++Messages array. But this is self-explaining like the following example for the CS++PVMonitor actor shows:

In the CS-framework the Introspection is done with the ProcEvents.vi.

The Actor Core.vi is the heart of the actor and the actual difference to an ordinary object. It will be executed by the Launch Nested Actor.vi just after the Pre Launch Init.vi. The Actor Core.vi of the Actor Framework base class has a loop which waits for and reacts to arriving messages (see the actor core in the first figure in section 3.4.1). All inherited Actor Core.vis have to invoke their parent’s class VI so that in the end both VIs are executed (the parent class VI and the child class VI). In fact, if you have a longer inheritance chain, all children should call their parents VIs. The following screenshot shows an example of an actor core (in this case for the CS++StartActor):

On the left side you can see some initialization routines for this VI (for example the setting of the front panel title). On the right hand side are two parallel threads: (i) the VI in the upper right corner is the parent class Actor Core.vi so in the end the VI shown in section 3.4.1, and (ii) the loop below for the GUI interaction with the user. Note that both parts of the source code run in parallel during runtime.

In the CS-framework the ProcPeriodic.vi and the ProcCases.vi somehow behave like the Actor Core.vi within CS++. But in the Actor Core.vi you have much more possibilities. You can for example also create GUIs here.

The Stop Core.vi is the counterpart of the After Launch Init.vi. All resources (VISA resources, queue references and so on) which you allocated there can be cleared here.

16

In the CS-framework the analogon is the Destructor.vi.

Example 4.1

This is a small example showing how to create a new actor. Our new actor TestActor will have a GUI which increments a number and a stop button. All the following examples can be found at Github at DN-GSI/CSPP_Introduction. Nevertheless you should follow the next steps by yourselves.

1. First we have to create a new library and a new class in the project explorer. Just use the right mouse button and the menu point “New”. Create the library, the class and a folder called “Messages”:

2. Now we have to change the inheritance of TestActor.lvclass to actually make an actor out of it (up to now it is just a normal LabVIEW class). For this use the right mouse button on TestActor.lvclass, go to “Properties” and to “Inheritance”:

You can click on “Change Inheritance” and select the CS++BaseActor. Here you can also see that the CS++BaseActor is inherited from Actor.lvlass which is the base actor of the actor framework. This actor is then inherited from an abstract LabVIEW class.

3. Now we can start adding features to our new actor. For this we should first have a look at all the features coming from our parent class (and grandparent and so on). Right click on TestActor.lvclass and select “New”, “VI for Overwrite”:

This window shows a list with all dynamic dispatch VIs of the parent classes which you can overwrite. If you don´t overwrite anything and don´t add VIs, our class would behave exactly like an Actor.lvclass class. The asterix in front of Introspection Core.vi means that this VI has

17

to be overwritten. For our example we create overwrite VIs from Introspection Core.vi and Actor Core.vi.

4. We won´t include any messages to this class at this point, so the Introspection Core.vi will remain empty (Check the automatic created Introspection Core.vi. In fact, it is not empty. It only invokes its parent method!). The actor core will be very simple:

Three notes to this VI: The invoked parent class method is in the upper right corner. Not all overwritten VIs

need to invoke the parent class VI but if you would leave it out here our actor could not react on messages since this mechanism is in the Actor Core.vi of the Actor.lvclass, so here it is mandatory!

In parallel (!) to this parent class method we have now a second thread (the for-loop) which reacts to user input (the stop button) and increments the counter every one second (the number indicator). The idea to add a loop parallel parent class ActorCore.vi is sometimes called “Decoration pattern”.

If we want to stop the actor we have to stop both threads. Our “GUI”-thread can be stopped relatively easy by just stopping the while-loop. But there are still the threads in all parent classes. These threads can be stopped by sending a stop message to our self. For this we first need the Self-Enqueuer (send message to ourselves) and then the stop message. You can find both in the LabVIEW palette under “Data Communication”.

5. One important step is still missing. As already explained in step 4 one always has to be sure to stop all running threads if an actor should be stopped. Now we are stopping the threads in the parent classes if we press the stop button on our GUI but we still have to take care about the opposite direction: What if something else within the system wants to stop our actor (i.e. sends us a stop message)? Then our GUI loop has to be stopped programmatically. For this the base actor of the Actor Framework offers a special VI (Send Normal stop.vi), which in the end executes the Stop Core.vi. We have to overwrite it and create a user event to stop our loop. So open the Actor Core.vi, create the user event, and stop the loop within the new event:

18

6. The next step is to save the user event reference we just created in the attribute data of our class. So create an indicator on the “user event out” of the “Create User Event function” and copy its front panel indicator to the cluster in TestActor.ctl:

7. After you saved everything we have access to this event reference from everywhere within our TestActor class via bundle and unbundle functions, so we can simply save it in the Actor Core.vi:

8. Now let`s overwrite the Stop Core.vi in TestActor.lvclass (check step 3). Within this VI we have to generate the user event, which stops our loop:

In total we have now an actor with a small GUI loop and the ability to be stopped via an external stop message.

Once you create a new “decoration” (so a new thread or parallel loop in the Actor Core) you should never forget to modify the Stop Core.vi. The huge advantage here is the simplicity of including new threads. Within the CS-framework for example each class has only two threads (ProcCases and ProcPeriodic), which is sometimes not enough.

4.2 Messages within CS++As already explained in chapter 3.4.1 messages are the only way to send commands from one actor to another in a deterministic way. “Deterministic” means here for example that you can be sure about that the message will arrive at the destination actor and will be processed, even if this actor is currently busy. In this case the message has to wait.

A message is a special class inherited from a native message class in the actor framework and belongs to an actor. In general it consists of two VIs: A Do.vi and a Send XXX Msg.vi. The Do.vi will be executed, when a message of this type arrives at an actor. The Send XXX Msg.vi on the other hand is the VI you need to execute if you want to send a message of this type from somewhere in the source code (normally this VI is public, so you can send such a message from everywhere).

19

There is a very simple way to create message classes to execute public methods of an actor: The “CS++ MessageMaker”. It can be found in the main menu under “Tools”. It will create a message class with a Do.vi which does nothing more than executing the public method. Have a look at the following example to see how it works:

Example 4.2

Within this example we will continue the work done in Example 4.1. Now we want to include a message to reset the counter back to zero.

1. First we have to add another user event to our Actor Core.vi which can set the counter to zero. You also have to add this user event to the attribute data and save it, so that it can be executed from another method (see Example 4.1):

User events are one way to transfer information from one thread to another within the same actor. Others are for example queues or notifiers. Their handling is quite easy. Try to have a look at the NI examples!

2. Now we should create a public VI which generates our “Zero” user event. In the project explorer use the right mouse button on the TestActor.lvclass and select “New” and “VI from Static Dispatch Template” (static means that child classes of TestActor.lvclass cannot overwrite this method). This new VI just has to generate the event:

3. This VI has to be executed from outside with a message, which we have to create: In the main menu, go to “Tools” and “CS++ Message Maker...” and create a message for our new method Zero.vi. The MessageMaker offers you four different message types. For this example we will use the “Simple message”:

20

Save all VIs and move the new Zero Msg.lvclass to our Message folder in the project explorer.

Now everyone can execute the Send Zero.vi leading to a reset of the counter in the Actor Core.vi of our TestActor. We should test it:

4. Create a new 4_Main.vi outside TestActor.lvlass (maybe in the root folder of your project):

Don´t forget to set the name of the new object. You will find the needed VI in the Accessors subfolder in the CS++ BaseActor class.

In this Main.vi the following is happening: First we are creating a new object (in this case an actor) of the class TestActor.lvclass and launching it. At this point a new front panel will open and you can see there the number in the indicator increasing, so the actor is running. If you press the “Zero” button in the Main.vi a message is send to the actor and the counter goes back to zero. Try to modify the Main.vi to stop the actor once you press the “stop” button there!

4.3 Using the CS++ factory and the CS++StartActorThe Main.vi in the previous example implemented a hard-coded starting routine for an actor. The disadvantage is, it is not very flexible. To create another actor we would have to modify the source

21

code. So it is better to use the CS++Factory which can be found in the “Classes” folder of the “CSPP_Core”-package.

This class creates and initializes objects inherited from the classes CS++Base.lvclass and CS++BaseActor.lvclass. For this, one has to provide an ini-file in which all necessary initialization parameters are defined. For the future it is foreseen to implement also other factories which will inherit from this class. One idea is for example to include the possibility to use a database instead of the ini-file. With one initialization parameter the user could then very easy switch between both techniques.

The following example should give an impression of the structure of the ini-files:

Each object in the system has a separated section (here the object name is “myBaseActor”). Within these sections all parameters have to be set. The structure is always LibraryName:ClassName.AttributeName=” ”. The first parameter is a bit special since it has to point towards the path of the lvclass file of the object you want to create. In this example here it is “CS++BaseActor.lvlib:CS++BaseActor.lvclass”.

One important remark to this approach to load classes: All classes you want to load during runtime have to be already in memory! Otherwise the compiler will not find the class (because he does not know where to look on the hard disc). One can solve this problem very elegant by including a dummy object of this class the Main.vi. This object will not do anything (and in fact will be destroyed immediately after creation), but the blue print of the class will remain in memory. We will see what this means in the next example.

Each class has a set of attributes which have to be configured if you want to create an object. For your object you always have to set the attributes of the objects class as well as all parent classes. So if you for example want to create an object of the class IVI_Scope.lvclass you have to configure all initialization parameters of the IVI_Scope class as well as the CS++Scope class (the direct ancestor), the CS++DeviceBase class, and the CS++Base class.

Within the CS-framework the configuration parameters of the objects where saved in the CSDB data base. In CS++ it is up to you how to save this information. The default way is a large ini-file. But you can create your own factory (by inheriting from CS++Factory.lvclass) and use other types.

Example 4.3

This example should clarify the importance of the factory and the usage of it. We will start with the Main.vi of Example 4.2.

1. Instead of manually including a TestActor class on the block diagram we let the factory do that:

At first this looks more complex than the VI from Example 4.2. But it is much more powerful. The decision which class is loaded is now done within the ini-file, so it is not hard-coded

22

anymore. Later on the object name of the object to be loaded (in this case “myTestActor”) can be changed by the user online.The ini-file of this example looks like this:

The four CS++BaseActor attributes are without any meaning here. In the class path we have now the absolute path to the class. Note that this will not work in an executable. There, LabVIEW is “packing” everything together and you have to address the class with the specification of the library and class name. Let`s try that:

2. Changed the path in the ini-file to:LVClassPath=”TestActor.lvlib:TestActor.lvclass”

If you would try to execute it in an executable with this ini-file entry you would get error 1373 “Class could not be loaded”. The reason is that the application builder would not include it. But we can just add the dummy object of the TestActor class:

In CS++ we are using Contents.vis which includes all possible classes for the application builder. Note that within the developer environment the newest LabVIEW versions load everything in the project, so you won´t have the problem that he cannot find a class.

Everything what we just discussed in the Example is already prepared in the CS++StartActor. This actor is supposed to start the control system.

In the library CS++StartActor.lvlib you can find the “official” starting VI for the framework which is called: Launch CS++StartActor.vi. But you can always make your own start VI (or you can even use this VI as a SubVI in your own StartVI). Also the StartActor needs to be configured in the ini-file:

The actor has four special attributes which can be set:

The MessageLogger can be used to debug the application. This will be described later. For now we can leave it empty.

23

Open_ActorCore should be set to “True”. This will open the front panel once you start the application so you have control of a central VI.

StartActors defines a link to a list with all actors which should start automatically together with StartActor. You can also configure here if the GUI of these actors should pop up.

ActorList on the other hand defines a list of actors which can be started by this StartActor manually. For this the user can open a list and choose which actor he actually wants to start. The entries of this list as well as their actor core behavior can be defined here.

The CS++StartActor has the same role as the SuperProc in the CS-framework. Both are the first objects to be started and can launch further objects. The SuperProc also needs to be configured in the database (where for instance the Special arguments define the automatic started objects).

4.4 Error HandlingError handling is a very important aspect of each software. If this is done properly it will be very easy later on to follow any kind of errors. It is quite clear that first it costs time to catch al errors but later on you will definitely profit from it. And you can be sure that this work won´t be for nothing since you will do mistakes when changing the configuration file or connecting devices to the system and so on. And then you will be very happy if the system tells you immediately what is wrong.

The behavior of an actor in case of an error can be configured in the Handle Error.vi. This VI is a dynamic dispatch VI of the original actor framework actor. It can be overwritten to change the behavior in case of errors. One remark should be made:

We are only talking about errors which arrive in the Actor Core.vi of the original actor. These are errors from the execution of messages or from the initialization procedure (as long as all errors are properly connected). Errors which occur in a possible new thread of your own Actor Core.vi are not following the behavior defined in Handle Error.vi! You have to take care of these errors!

The following two figures show the Handle Error.vis of the original actor as well as of the CS++BaseActor.lvlib which directly inherited from the Actor Framework actor:

The original VI only deletes error 43 (this occurs if the user cancels an operation) and always stops the actor. For many applications this can already be enough. But the disadvantage is that the user will not get any information about what error actually occurred. And maybe the user does not want the actor to stop immediately; maybe the occurred error was not very important. For this we have overwritten the VI in our CS++BaseActor:

24

In the first part we send a message of the occurred error to our message logger (again: later). The second part defines the behavior of the control system: If an error occurs and the initialization parameter for the “ErrorDialog” for this actor is set to “True” (see chapter 4.3) a dialog will pop up, giving you all necessary information about the error and asking you to stop the actor. If “ErrorDialog” is set to “False” the actor will stop without a notification.

Note that an error which will stop also stops all actors which were previously launched by it. This means if an error in the StartActor occurs and you don´t react he stops the complete system (!).

Example 4.4

In the following we will include a “Save” button to the Actor Core.vi of our previous example. This button should save the value of our counter in a file on the hard disk.

1. Include the new save button on the front panel and add an event to the event structure in which the actual number is saved:

2. For a test: Start the 4_Main.vi, wait until our TestActor is started and save the number to a file.3. Now let´s provoke an error: Change the file property of the file you just created in step 2 to

“Read-only” and try to overwrite it. You will see that nothing happens. The program continuous to run but the file is not overwritten. In the worst case this would mean that your measurement data is not saved and in fact lost and no one would realize it (=> disaster).

4. To overcome this problem we will send an error report to our self if necessary. It should be clear how to do that: You need again the self-enqueuer and the Send Error Report.vi from the pallet. Make sure to only send the error report if an error occurs and connect the error cluster with the “Error from sender” input of the Send Error Report.vi.

5. If you make the same test now, you will see that the actor core of our TestActor closes once you try to overwrite the read-only test file. The reason should be clear: The ini-file which we are using has the entry:

25

CS++BaseActor:CS++BaseActor.ErrorDialog=False

If you change this to true, you should get the following error dialog, where you can choose if you want to stop the actor:

The example above shows how to add error handling to your own (decoration) threads (in this case the GUI loop). At this point, and since it is a GUI loop you could also pop up an error message, which is much easier. But this would only work for GUIs and not for other threads.

4.5 PV & SV – MonitorAs previously described the communication between actors via process variables is the preferred one. A very important, and up to now not mentioned, reason for this is that it completely decouples the caller and the callee of a message. So what does this mean? Imagine an actor (let´s call him “caller”) which launches a second one (the “callee”). Both actors want to communicate with each other. If the caller sends a message to the callee he always knows exactly the type of the callee (so he knows the class of the callee, because he started the callee and executed the SendXXX.vi of the message which belongs to the callee’s class). So this is easy. But now let´s assume the callee wants to send a message to the caller. The point is: He does not know the type of the caller and therefore he does not know on which messages the caller is listening to!

This is a very crucial step in many software architectures and it can be solved in several different ways. But at this point one always has to decide how much the caller and the callee should be coupled. Here High Coupling means that the callee knows everything important of the caller. The source code is written in that way, so the programmer has told the callee everything he needs to know. At first glance this makes the source code of the callee relatively easy to understand but unfortunately it has some severe disadvantages:

You have a lot of code duplication. The reason is that you need a special callee class for each possible caller.

You always have to create a new callee class if you include a new possible caller to your system. So from here on it should be clear that such a “solution” is not feasible.

Within CS++ all messages to another actor (which could as well run on a different node) will be send as process variables. This means you do not execute the SendXXX.vi of a specific message; you simply overwrite (or “publish”) a process variable. The receiver actor of the information on the other end uses a “helper”-actor called CS++SVMonitor.lvclass which “unpacks” the data from the process variable and sends an “internal” (and local) message to the receiver:

26

So, each actor in CS++ which wants to receive messages over the network needs to register itself to a PVMonitor actor. This monitor actor listens to several PVs and sends Actor Framework messages to all registered observer actors, who have to run on the same node, each time new information arrives.

By this, we are using a so-called Zero Coupling solution to the problem mentioned above, which avoids all the disadvantages of coupling different actors.

The red marked area in the figure above means that the transmitter and the PVMonitor could be on different PCs in the same network. So for example if the transmitter is a device which wants to send new measurement values, many receivers (GUIs) could listen to this new data. The transmitter would have to update the PV only once. Each PVMonitor (one for each GUI) would recognize this value change and sends a (local) message to its GUI actor. This would also work in the case of a communication in polling mode (see chapter 3.4.2). The only difference is that here, each PVMonitor actor continuously checks if the network variable has changed.

From the two network protocols which can be used, the DSC engine and DIM, only the DSC engine will be discussed here shortly. DIM will be maybe described later in the appendix.

Process variables within the DSC engine can be viewed in a special program by National Instruments called Distributed System Manager (DSM):

Each variable has a type, a value and can be accessed from all PCs within the same network domain. They are grouped in “Processes”. Important for testing purposes is that the DSM shows “live” value changes and you can also set values there manually. This is very helpful if you want to debug the communication process just described.

Let´s go back to the PVMonitor actor. The following figure shows the inheritance scheme of the actors involved:

27

The PVMonitor.lvclass is an abstract class which offers functions you need to initialize the monitor. For example you have to tell him on which PVs he has to listen to. The SVMonitor.lvclass has inherited from the PVMonitor.lcvlass and implements everything needed for a DSC communication in polling mode. This actor class can be used with the standard LabVIEW installation and is somehow the basic communication of CS++. The DSCMonitor.lvclass overwrites several functions of the SVMonitor.lvclass to use an Event-driven DSC communication. Again: For this mode to work you will need the DSC module from NI installed. The DIMMonitor.lvclass on the right hand side includes everything needed for the communication with DIM. But for this you also have to install and configure DIM on your PC.

Here, the approach is (like everywhere within CS++) that if you want to use a monitor actor you always use the VIs from the PVMonitor.lvclass, even if most of them are empty or incomplete. During runtime and with the help of your configuration file (the ini file) LabVIEW decides by itself which class it uses. So if you want to switch from the DIMMonitor to the DSCMonitor for example you don´t have to touch the source code (because there you used only the PVMonitor). You just change the configuration file.

The main part of all the monitor classes is the overwritten Actor Core.vi (note that the PVMonitor.lvclass has no Actor Core.vi). It includes a decoration loop to check for PV updates and send the local messages. So let´s have a look at the Actor Core.vi of the SVMonitor.lvclass:

In principle it is just a loop with an event structure. In the timeout case which is executed periodically he will read each shared variable from the DSC engine and sends a (local) actor framework message to all observers. Within the next example we will see how such a monitor actor is used:

Example 4.5

In this example we will include a PVMonitor which listens to a numeric process variable. Once this variable changes, our actor from the last example will add this change to its indicator. In principle this

28

means that from now on our actor acts like a GUI which reacts to a process variable. For this a lot of coding is already done in the CS++GUIActor.lvclass. So the best start is to change the inheritance of our actor to CS++GUIActor.lvclass. So by changing the inheritance of TestActor.lvclass we added a lot of functionality without touching the code at all!

At this point it is a good idea to check what the CS++GUIActor is actually doing. The protected VI Dispatch PVMonitors.vi can launch a monitor actor. It just needs the name of the PVs you want to monitor. The Actor Core.vi of the CS++GUIActor.lvclass will be overwritten by the Actor Core.vi of our TestActor.lvclass (in fact this is already the case, since we have a VI with this name already in our test class from the last example). The GUIActor also has an Initialize Attributes.vi which is a hint that we will need additional entries in the configuration file. We will come to the configuration file in a moment. All the remaining VIs are not important for this exercise.

Now we should use the new functionalities of CS++GUIActor in our Actor Core.vi:

There are some changes in our Actor Core.vi:

1. There are two, new Sub-VIs in the upper left corner. The first one is the already mentioned Dispatch PVMonitors.vi which gets the name of just one PV, which we will call “AddNumber”. The second one ReadPV-Update.vi returns the reference to a new User Event. This event delivers the PV, once it changed; so we have to connect it to our event loop. The destruction of this user event is not happening here. It is already done in the Stop Core.vi so we don´t have to worry at this point.

2. The second change is the new event case in the event structure. We added an event which fires once a PV user event arrives (from the new, just connected user event). In this case we have to check if the name of the arriving PV is “AddNumber” and if yes, we convert the variant data back to a double and add it to our indicator. On top of that a time stamp is updated. The default case of the case structure is empty (we don´t expect other PVs to arrive here). So note that the name of the case in our case structure has to be identical to the name of the variable we created in the Dispatch PVMonitors.vi!

If we would run this actor within CS++ it would already work. But our problem is that we wrote our own 4_Main.vi which starts our actor. In CS++ all actors are either started by the CS++StartActor.lvclass or by one of its nested actors (A nested actor is an actor which was launched by a

29

root actor). This already includes some background functionality which we have to add in our main VI manually now:

The two new VIs can be found in the CS++Utilities.lvlib of the CS++Core package. In principle they configure two global variables in the background with information about the used communication protocol with the DSC engine. Normally the CS++StartActor.lvclass is doing that, so at this point just include these SubVIs.

The next step is the modification of our configuration file (CS++Introduction.ini):

First of all, there are four new sections in this configuration file: PV_Protocols, PV_Monitors, SVConnection, and SVMonitor. This information will be saved in the just discussed two global variables and is needed by the monitor actor to find out which communication protocol should be used. The format is not that complicated: There is written that each URL with the prefix “ni.var.psp_p” is a shared variable in polling mode (because the SVConnection section links to the shared variable class) and uses the CS++SVMonitor.lvclass, if a monitor actor is needed.

The second change are the two additional lines in the “myTestActor” section. Both are needed because we are now inheriting from the CS++GuiActor.lvclass. The “AssociatedActor” is the name of the actor, which owns the PV our monitor is listening to. In reality we would listen to a PV created by a device actor. In this case the name of the device actor should be entered here. The PVProxy is not important right now and can remain empty.

30

In a new section named “myTestActor.URLs” all PVs, which we want to observe, have to be listed. The format is the following:

First one has the name of the PV (in our case “AddNumber”). This is the name you have to use in the source code (see the block diagram of our new Actor Core.vi in this example). It should be relatively short and describe the purpose of the variable.

Then we have the prefix of the URL (“ni.var.psp”). You can leave the “_p” here, since it is the default value. This prefix defines the communication protocol and has to match one entry in the PV_Protocols and PV_Monitors section. Note that this means switching to another communication protocol is very easy: You just need a second entry in the PV_Protocols and PV_Monitors sections (maybe called “dim”) which points to your new PV and monitor actor classes and then you can exchange the prefix of the URL of your variables (all of them, or just a part).

The next part is the URL of the PV. You always have://NodeName/ProcessName/VariableName

At the end there can be more parameters needed to configure this communication protocol. In our case, since we have decided to use the Shared-Variable engine in polling mode, we have to tell him with which rate we want to check for updates. This number after the “?” is the timeout in seconds. Note that this means you can also mix SVs with different readback rates in your system!

The last step is that we have to manually create the shared variable we want to use. If the DSC engine is installed LabVIEW can do this automatically (and CS++ is actually doing that), but we have to do it manually right now. You only have to do it once on a PC since the shared variable configuration of the PC is persistent and will survive also the restart of windows. Open the DSM and the subfolder “My system”. Right-click on “localhost” and choose “New process”. Enter “myTestProcess”, right-click on the new process and create a shared variable with the name “myTestActor_AddNumber”. Check that this variable is of the type “double” and initialize it with 0:

Start 4_Main.vi, and check if the number in our actor increases once you change the shared variable.

4.6 The PVProxyThe PVMonitor introduced in the last subchapter has the task to react on PV changes and send a local actor framework message to its worker actor.

31

5 Everyday programmers tasks within CS++The last chapter showed more academic approach of a CS++ introduction. In the following chapter five, examples are shown which are relatively close to the work the local developer has to do when adopting the local framework.

The first subchapter shows how to include a new power supply in a proper way. Tasks like this pop up at nearly all experiments from time to time; therefore this is maybe the most important part of this manual. Many aspects of CS++ are designed in such a way that especially this step should be as simple as possible.

In the next subchapter the creation of a new GUI is discussed. Within the CS-framework a lot of local developers added additional device classes but only very few created customized GUIs. We think that the main reason for this was that the creation of an own GUI was more complex and this process was not documented anywhere.

The introduction of chapter four described the approach of the development process for a local developer. Subchapter 5.1 will deal with the blue box and subchapter 5.2 with the red box of the first figure of chapter four.

The third and final subchapter of chapter five deals with the configuration file. As already discussed the complete framework should be very flexible meaning that also normal users can change its behavior, for example by modifying the configuration. This subchapter gives some tips how to work with it.

5.1 New devices in the device layer

5.2 A new GUI in the application layer5.3 Configuration parameters

A Appendix 1

32