Implementation of a robot control architecture for additive manufacturing applications

Purpose – Additive manufacturing (AM) technologies have recently turned into a mainstream production method in many industries. The adoption of new manufacturing scenarios led to the necessity of cross-disciplinary developments by combining several ﬁ elds such as materials, robotics and computer programming. This paper aims to describe an innovative solution for implementing robotic simulation for AM experiments using a robot cell, which is controlled through a system control application (SCA). Design/methodology/approach – For this purpose, the emulation of the AM tasks was executed by creating a robot working station in RoboDK software, which is responsible for the automatic administration of additive tasks. This is done by interpreting gcode from the Slic3r software environment. Posteriorly, all the SCA and relevant graphical user interface (GUI) were developed in Python to control the AM tasks from the RoboDK software environment. As an extra feature, Slic3r was embedded in the SCA to enable the generation of gcode automatically, without using the original user interface of the software. To sum up, this paper adds a new insight in the ﬁ eld of AM as it demonstrates the possibility of simulating and controlling AM tasks into a robot station. Findings – The purpose of this paper is to contribute to the AM ﬁ eld by introducing and implementing an SCA capable of executing/simulating robotic AM tasks. It also shows how an advanced user can integrate advanced simulation technologies with a real AM system, creating in this way a powerful system for R&D and operational manufacturing tasks. As demonstrated, the creation of the AM environment was only possible by using the RoboDk software that allows the creation of a robot working station and its main operations. Originality/value – Although the AM simulation was satisfactory, it was necessary to develop an SCA capable of controlling the whole simulation through simple commands instructed by users. As described in this work, the development of SCA was entirely implemented in Python by using of ﬁ cial libraries. The solution was presented in the form of an application capable of controlling the AM operation through a server/client socket connection. In summary, a system architecture that is capable of controlling an AM simulation was presented. Moreover, implementation of commands in a simple GUI was shown as a step forward in implementation of modern AM process controls.


Introduction
Nowadays, the industry is constantly searching for modern approaches (Pires, 2007), as it is necessary to develop new solutions and formulas for classical problems that may not introduce new sets of challenges (Pires et al., 2006). This paradigm shift happens in virtue of previous production methods, which were based on application of a machine for each operation. Such approaches are becoming outdated due to many reasons, including but not limited to economic and environmental reasons.
The adoption of new solutions can be achieved by using nonconventional working scenarios packed with machines, which are capable of executing a wide range of operations. The main goal of applying this concept is to decrease the production costs, through the increase of the system efficiency, toward saving resources such as prime materials and energy. Although such scenarios are based on the economical revenue, the quality should almost never be compromised.
There are several international initiatives (Pires and Azar, 2017, 2018a, 2018b that are expected to make a significant impact on industrial variables; examples are as follows: Production time: A decrease of at least 20 per cent is estimated as the operations are optimized and fully integrated into only one cell.
Production costs: A decrease of at least 25 per cent is estimated as all the former process integration into the single working cell reduced the capex and machinery costs.
Resources costs: A decrease of at least 50 per cent is estimated due to the technologies and architecture in this process, in which it is important to highlight the usage of hybrid manufacturing process, resulting in reduced leadtime between operations.
In this article, some considerations about the creation of a virtual robot working cell, currently referred as digital twin, will be presented. It is intended to simulate additive manufacturing (AM) tasks, and the system control application (SCA) responsible to control and adjust all the robot simulation parameters.

Additive manufacturing overview
In the 1980s, the rapid prototyping method was developed as a way to produce 3D objects, layer by layer, directly from CAD packages. It was a significant advance in industry as models and prototypes could be easily produced.
AM extended significantly this concept, just by introducing a set of technologies that allow a 3D object to be built by the simple process of adding layer upon layer of material until reaching the desired shape (ASTM-International, 2012). The main advantage of the AM is the versatility of the concept, which allows to create virtually any 3D shape as they are all bases in layer-by-layer manufacturing. Consequently, modeling and prototyping were the first applications. But quickly it started to be applied to manufacturing of small series, tricky parts, etc., and are now seriously considered for the production of large metal parts that are difficult to manufacture in traditional manufacturing plants, i.e. using traditional manufacturing technologies. Also, producing complex 3D parts, for several industries, including aeronautics and space, seems easier and more efficient if AM is included in the manufacturing process. In fact, AM has grown significantly in the past years, especially because of the industrial interest on the subject. However, it is important to clarify that AM is not just limited to the commonly used printers, optimized to build plastic parts. The ASTM committee (ASTM-International, 2012) published a set of standards which describe all the current seven classes of AM technology.
As in the conventional technologies, each AM technology uses specific materials as genetics of the processes does not allow a full material coverage. Consequently, as explained in the study conducted by Bourell et al. (2009), the materials used in AM technologies can be grouped into two categories; homogenous and heterogeneous materials. In addition, some studies about the practical application of these materials have been done, such as the ones in the following table (Table I).
Accordingly to Bourell et al. (2009) andMueller (2012), it will be possible to see AM technologies in industries such as aerospace, military, automotive and motorsport, electronics, biomedical, jewelry, collectables, dentistry, food, education and toys in the near future.
According to Espacenet (Ménière et al., 2017), the number of patented intellectual properties regarding AM are facing an exponential growth since a few years back, a behavior that is expected to keep its tendency justified by the increase of investment from big companies and countries, that are inserted in the program Industry 4.0.
AM promises to overcome many boundaries imposed by conventional manufacturing technologies such as the production limitations of components with complex geometries/shape, and the excessive waste of material due to excessive wall thickness or the type of the technological process.
However, it is important to notice that in an industrial environment, all of these AM technologies are only possible due to the integration of multidisciplinary areas.
Industrial robot manipulators have been allied with AM technologies due to the fact that they are machines with a huge potential in this field as they have natural characteristics that make them enabled to perform AM tasks such as the ability to perform repetitive tasks, a high reliability and performance, easy to program and control, and, the ability to fabricate large components, an option that is challenging for common AM machines.
A recent study conducted by Evjemo et al. (2017) shows some projects that are impractical by using a traditional 3D-printing machine due to physical limitations Most of the common machines only have 3 degrees of freedom (DoF), which only allows translations along X, Y or Z. In the worst-case scenario, a robot manipulator has more than 5 DoF, allowing execution of rotational movements in addition. Such setups make difference in a 3D-printing task because it allows keeping the extruder nozzle correctly oriented during the movements.
Some of the recent crucial developments could be challenging to realize if the advanced robot manipulators were not in use; examples are as follows: Concrete printing: The aim is to produce full-scale constructions and architectural components such as walls, bridges and houses (Bos et al., 2016).

MX3D bridge:
This project aims to build strong, complex and gracious structures in steel, by a combination of AM technologies and advanced robots.
State-of-the-art summaries about AM and related technologies can be found in Gardan (2016) and Lehmhus et al. (2018). These two papers introduce the various AM technologies currently available, namely, laser, flash, extrusion, jet, lamination & cutting, etc., and discuss their major advantages and drawbacks, including an overview of the manufacturing processes that can take advantage from their basic characteristics.
Incorporating simulation of the AM process into the system, improving in this way the quality of the printing process, the capacity to do it right the first time and achieve autonomy, was also proposed recently by several authors (Azar and Pires   2017). The idea is to fully transform the AM process, just by adding mechanisms to better plan the manufacturing process and to dynamically resolve the problems as they arise. This means creating a data-driven AM system with the capacity of dynamic trajectory planning, taking information from near realtime process data and updated simulations (Azar and Pires, 2018). In summary, the robot-assisted AM technologies are paving the way to become an eminent part of the factories of the future. It is hard to ensure that by implementing these technologies, the challenges will be settled. Nevertheless, it is undeniable that it will help to reach a commonly acceptable resolution. In this line, the major contribution would be in terms of elevating the grade of these machinery to reach the level of plug-and-play and higher autonomy, with the objective of eliminating the inconveniences and challenges in programming of these advanced machines for executing a sophisticated printing task. In this article, an innovative method for creation of a virtual working cell using RoboDK and Slic3r software and a new design of SCA and interface using Python high-level programming is delineated.
1.2 Software 1.2.1 RoboDK RoboDK is an industrial robot software which has the possibility to perform offline/online robot programming and simulation (Nubiola, 2015).
The following are the advantages of this software package for becoming the choice of this study: For sake of conceivable object-oriented programming, it is necessary to add visual perspective during the simulation of the process. RoboDK provides a graphical presentation of the cell and it is possible to perform offline robot programming.
A wide range of robot manipulator brands and tools are available in RoboDK. Therefore, it is possible to create a generic task that can be executed on more than 200 types and brands of robots.
RoboDK offers a built-in gcode interpreter for execution of tool-path related projects.

Slic3r
Slic3r is an open-source software launched in 2011 by the RepRap community, with the objective of making self-replicating machines freely available for the benefits of the users. Following the rules of this community, Slic3r is used to convert 3D models into printing instructions by generating gcode, which is a programming language used to create numeric instructions that make a machine moving in Cartesian coordination system.
The input of the program is a pre-designed CAD file and the output is the gcode, which is used for path generation in the robotic printing technology.

Python
Python is an interpreted high-level programming language created by Guido van Rossum in 1991, and designed to work in a wide range of domains (General purpose programming language).
Python is known for its versatility, for being a fast development environment, an open-source software and also a "clean" and "clear" programming language (Peters, 2004).
In this research Python 3.6 was used because of the following reasons: The RoboDK source code was developed in Python and it offers a specific library that allows controlling all the robot station operations called Robolink. This library s used for offline/online programming and simulation.
Python is one of the most applied programming languages in the world, and it is also experiences one of the highest growth rate (StackOverFlow, 2018).
Python has a wide range of libraries such as Asyncio, threading, subprocess and kivy, which allow the creation of a comprehensive SCA.

Additive manufacturing simulation
One of the goals of the developments in this study is the development of an AM simulation, and this section will reflect all the work done to achieve it by using RoboDK and Slic3r. Basically, the system starts with the CAD file of the part to 3D print and follows the following steps: The user must slice the part to be printed, i.e. generate the code containing the robot trajectories required to manufacture the part. Slic3r is used to generate gcode. A generic configuration file is given for each to work with each user application.
Automatic robot code is obtained from the gcode taking in consideration the AM process selected, along with the type of AM process adopted.
There is the option to upload the generated code to the robot controller and control the operation of the robot.
There is also the possibility to include mechanisms to observe online the quality of the process under study and perform, also online and in real-time, the parameters of the AM process under study (Azar and Pires, 2018). These aspects will be described in detail in the rest of the paper.

Robot offline programming
The robot offline program is an essential part of this research toward emulating the real working cell environment, as well as all the AM tasks (e.g. extrusion control and control of the heating systems). In addition, the advantages of using this way of programming are tremendous (Nubiola, 2015;Montaqim, 2015): There is no break or pause in the production flow.
It is safer because there is no involved risk of damage to the working cell and its operator because of its virtual nature.
All the simulated processes can be reproduced in the real working cell as the virtual environment replicated the real case scenario.
To make the virtual developments useful in the physical robot cell, the design has to follow some important considerations: The robot must move freely, without any restriction or obstacle, otherwise it will stop the operation with error messages (collision control).
The robot must have a tool for simulating the material deposition that can be replaced by any other tool in a short instance.
All the deposited parts are built on an appropriate region such as a substrate on a workbench.
Before presenting the working cell architecture, it is important to discuss some details in the process of creating the presented working cell. As a good practice, in RoboDk, the working station should always follow a hierarchy in terms of sequence of introducing tools. The reason for following the hierarchical sequence is to make a reference frame, which allows the objects and tools to be oriented correctly. This is a delicate subject as it is the only way to ensure that all the generated paths and simulated operations will keep the same reference frame and to avoid problems such as singularities or wrong tool orientation.
Hence, the robot base was adopted as a reference frame because all the subsequent operations will be executed by the robot.
The hierarchy construction rule implies that all the other frames are dependent on the reference frame, as can be seen in Figure 1.
After this brief and important consideration, the working cell was designed following the previously presented requisites. In terms of design, the final solution consists of a table which supports a robot equipped with an extruder and a bed plate. The selected robot model is ABB IRB140, which is available in the RoboDK library, as well as the extruder and the work bench. The substrate was built in a CAD editor with dimensions of 250 Â 250 Â 10 mm and imported to the software environment. Table II lists the vectoral positions (x, y, z, u 1 , u 2 , u 3 ) of the used objects. The position of the extruder is not mentioned as it is attached in the robot flange. Figure 2 shows the designed virtual cell. The generation of the robot program for executing the AM simulation is presented and discussed in the next section.

Robot programs
An AM simulation gcode is composed of millions of points. Thus, the task of translating these connected points into a robot language is a critical step toward warranting the significance of all the movements.
The RoboDK software offers possibility of compiling information about the simulation, such as the robot flange velocities, paths, types of movements and controlling the active tool operation from gcode into robot-specific program. In this research, programs created through both manual and automatic approaches as presented below.

Manual programming
Manual programming is similar to teaching by showing presented by Lozano-Peres, where targets and operations are defined by demonstration (Lozano-Perez, 1983).
Targets are the space coordinates of each position and orientation occupied by the robot flange, which will be interpolated into a linear, joint or circular movement in the backstage. In addition, parameters such as robot flange velocity or material deposition conditions are also defined manually.
In this research, manual programming is used to define the following AM operations: approaching the robot flange and the mounted tool, close to the substrate surface; and returning the robot to a home position, after the AM simulation.
Both approaching and homing operations were performed by joint movements only as a high movement pace was envisaged. The velocity was set to 150 mm/s and the precision was set to high. Figure 3 shows the two aforementioned targets.

Automatic programming
RoboDK can generate automatic programs using the incorporated projects. The presented automatic programming in this research, which is responsible to simulate an AM process for building a simple CAD model, uses a project called machining/welding project.
This project only requires a gcode file to generate the toolpath, extruder function controller and the robot flange velocities. To simulate the material deposition, a Python script was developed, that is executed once the robot program is called.
To generate the gcode, Slic3r software was used. As the AM task is assumed to be fused deposition modeling (FDM), the printer configurations from Lulzbot[1] was used to define the slicing conditions. Working cell design Figure 4 shows the milling project user interface, and the toolpath that will simulate the AM task.
At the end of this operation, all programs were grouped in an eventual solution that performs AM simulation on the robot. This program is responsible to make predefined sequential calls of the robot programs simulate all the essential robot movements/actions during simulation. The details about the sequence of command execution are as below: Approach: This module is the manually defined robot program that approaches the mounted deposition tool close to the substrate.
3D: This module is the automatic robot program which contains all the information related to the toolpath.
Filament on/off: This module is the Python program which simulates the material extrusion.
Return home: This is a manual robot program module that moves the robot to the predefined home position at the end of the AM simulation ( Figure 5).

System Control Application
SCA is a user-interface mechanism that enables the interaction between a user and the virtual/real robot station. The importance of allowing SCA in simulation environments, namely by providing interface mechanisms with the system, is related to the fact that it allows users to control the operations through a previously designed and user-friendly application. The user-friendliness arises from a user interface that is intended to be intuitive and logical. These characteristics are achieved by creating the application with a simple design and clear commands, addressing the average factory floor staff independent of their experience.
As described previously, the SCA in this work was developed in Python through available libraries. Therefore, to understand the functionalities of the developed SCA, the applied libraries will be contextualized and explained accordingly to their objective of usage and the way they were combined to build a complete application.
The basis for the developed SCA are ( Figure 6): Asynchronous transport control protocol/internet protocol (TCP/IP) -Server/client.

Robot Station Control.
Generation of gcode.
Graphical user interface, GUI.

Asynchronous transport control protocol/internet protocol -Server/client
Principally, it is important to recognize that the robot and the computer are two devices that do not perceive how to share and communicate information as they do not have an implemented native protocol, capable of being interpreted by both. Consequently, a TCP was implemented and combined with the  The development of the SCA began with the creation of an asynchronous server and client, addressing the required SCA tasks in the AM simulation.
From a computer science perspective, the server and a client are part of a software architecture, where the objective is to establish and maintain inter-communication that the clients always sent requests while the server always responds the received requests. It is also responsible for executing and scheduling the client's request (Oluwatosin, 2014). Therefore, these two programs can be seen as a symbiosis case as they need each other to remain operational.
In the developed SCA, the clients represent all the operations requested by a user, while the server is the program responsible to receive the requests, and then, accessing the AM robot's station to set up the requested operation by the user, through sockets that are responsible for establishing the connection between the end nodes (Xue and Zhu, 2009) (Figure 7).
It is also important to ensure that the system is asynchronous, or else it is impossible to perform multiple simultaneous tasks (e.g. request position, extruder flow and bed temperature) as the system is blocked while it is performing an operation and it is only available at the end nodes.
The usage of asynchronous programming enables the system to interleave tasks, by suspending and returning through I/O control. This is called a concurrent programming, where all the tasks can start, run and complete at overlapping time periods. The biggest advantage of such strategy is the fact the system is always responsive and independent of the end of each operation to progress (Ghezzi, 1985) (Figure 8).
The implementation of an asynchronous TCP/IP server/ client was implemented in Python, as it was mentioned before, using the Asyncio library (Rossum, 2012).

Asynchronous server creation
The first step in any Asyncio program is the creation of an event loop, which in this case should run forever() as the server should always be ready to perform any operation or to receive a new client. The usage of a loop that will run forever means that it will only stop when a stop() command is triggered. However, it is fundamental to have in mind that after stopping the loop it is impossible to start it again.
After implementing the loop, it is necessary to create a coroutine, which can be performed together with a task. The coroutine is responsible to return a tuple with two objects: a StreamReader, which is responsible to interpret the message received by the client, and a StreamWriter, which is responsible to send information to the client. One important characteristic about this coroutine is the fact that it only executes once a new connection is established as each client's connection requires a new socket or else, the application may be blocked or even result in mixed or missed information.
The final step was to fire the loop to start the server, making it able to receive the client requests. The main code of the server can be seen. Each line of the code is commented for clarification. Server code snippet: import asyncio class Server: "This class is used to create the server" self.loop = asyncio.get_ event_loop() self.loop.run_until_complete (self.coro) #runs everytime there is a client self.run_forever() async def_coro(self): "Asyncio Coroutine that defines the TCP/IP protocol to start the server" await asyncio.start_server (self.handle_echo,`localhost, port = 8888, loop = self.loop) #ensure server is created async def handle_echo (self, reader, writer): "Asyncio coroutine which creates the StreamReader and StreamWriter self.reader = reader self.writer = writer del decisions(self): "Method used to decode the receives message and interact with the AM simulation" pass if__name__ =`__main__': Server()

Asynchronous client creation
The client is not supposed to keep connections alive forever as it will lead to a high consumption of the computer resources, which affects parameters such as connection velocity, as well as tasks and app performance. Problems can be easily avoided if the client is killed at the end of each socket. In other words, the client should run until complete, whereas the server will run forever.
It is important to note that if the server is asynchronous, the client also needs to be in the same scheme. Otherwise, the code will be blocked until the end of the client's work, due to the lack of concurrent tasks. The client was created with the Asyncio library, which has specific documentation about implementation of TCP/ IP client (Rossum, 2012).
The first step toward creating a server is implementation of the event loop, which always needs to be prepared to generate a new client when sending a request to the server and also to kill it whenever the work is finalized.
After creating the loop, the next step is to enable the client generation without waiting until the end of the previous task. The objective of the latter approach is to eliminate the blocking risk and to allow parallel requests. The solution to these problems was the creation of a task that will run the thread safe coroutine. By running this coroutine, the loop will be able to perform the creation of a new client, because it will prepare the loop to start a coroutine, which was not scheduled before firing the loop, which has initial running conditions without breaking the loop.

Robot station control
The server needs to perform tasks in the robot station; yet the server does not conceive how it shall be done as the source code is only able to accept clients and manage requests. Therefore, it is necessary to implement a solution that will be called each time the server receives a request related to the robot station. In such way, the server is capable of performing the station related tasks and translating and sending back the information from the robot station to the user.
This controller was implemented using Python and RoboDK library (RoboDK, 2018) as all the functionalities are well integrated.
The implementation of all the mentioned concept was realized in two main parts; the station recognition and the station tasks. Both parts are methods of the Subclass ValidateRobodk (Robolink).

Robot station recognition
The station recognition is a method that is responsible to detect all the objects in the cell, such as the robot, the working tool, the working frame and the final robot program. The recognition of the robot station is very important as the SCA must have access to the information about all the cell objects or else they will be uncontrollable from the application. A snippet view of the station recognition is presented. Code snippet showing the robot station Detection: from robolink import Ã class ValidateRobodk(Robolink): """RobotDk Class that makes possible manage robotDK, for this we use the Parent Class RoboLink""" def __init__ (

Robot station tasks
The station tasks are responsible for interacting with the robot station to perform all the user's requests. The following are a list of tasks: Get_position(): A method responsible to get the real position of the robot flange.

Go_home():
A method that sends the robot to a predefined home position.

Start_printing():
A method that starts the robot simulation.
Pause_printing(): A method that pauses the robot simulation.
Stop_printing(): A method that stops the robot simulation.

Check_collisions():
A method that checks if there is any collision.
Calibrate_robot(): A method that performs an automatic robot calibration.

Station_ready():
A method which verifies if the station is ready to perform.

Simulation_time():
A method that calculates the simulation time during the simulation.
A snippet view of the code, which has all the methods referred above, is illustrated. Code Snippet showing the robot station task: from robolink import Ã class ValidateRobodk(Robolink): """RobotDk Class that makes possible manage robotDK, for this we use the Parent Class RoboLink""" def get_position(self): """This is a method that gets the real position of the robot flange""" position = Pose_2_TxyzRxyz def go_home(self): """This is a method that sends robot to home position""" Robolink().RunCode('Return Home', True) return str("Robot at Home position") The listed methods represent all the client requests, which are performed by RoboDK and launched by the server. As it was mentioned before, such AM-specific class is crucial for enabling the system to collect information about the real-time status of the robot station and launching the required user operation.

Generation of gcode
The SCA should easily generate executable gcode that runs conditionally on the AM setup. When it comes to the Slic3r's software, it is possible to execute the slicing tasks from the command line, which makes it easy to implement it in another programming language platform (Gary, 2013). Therefore, by launching the Slic3r executable in the Python shell, generation of the gcode can be performed. If the commands in the documentation of the Slic3r software is implemented with care, there should not be any difference between the gcode generated from the command prompt and the gcode generated in the user interface.
The slicing command implementation was done by Python, using the subprocess library as it is necessary to execute command lines on the shell.

Graphical User Interface
GUI allows users to configure the operations in the system as it is usually simple and intuitive. In the SCA, GUI was developed to control the robot station through a series of simple interactions with the application, such as clicking buttons or draging bars and intuitive generation of the gcode. The GUI was designed and constructed using Python's Kivy library as it allows creation of elegant interfaces easier and faster than Python's native GUI developer called TkInter. Moreover, Kivy has a better compatibility with several operating systems.

Graphical user interface's development
The first step to develop the GUI is the creation of the Kivy's loop, and KV file. This was done simultaneously to visualize the construction of the GUI. It shows a piece of the Kivy class code. Code snippet of kivy class responsible to generate the loop: class InterfaceApp(App): def build(self): "Method used to build the loop and the User interface" return GenerateSlide() if __name__ == '__main__': InterfaceApp().run() In terms of design, the GUI was projected using straightforward features such as buttons, selectors and bars, which only require one touch to interact with the EventDispatcher.
As it was explained previously, the server and the client are asynchronous programs that require an Asyncio Event loop to be executed, which should not be suspended to keep the server and the client alive. This requirement entails a serious problem as it turns Kivy and Asyncio into incompatible libraries because they do not allow the execution of simultaneous looping.
The rationale behind this is related to the fact that both loops operate in the same thread, causing in suspension of one loop during the execution of another. This leads to lack of resources that are necessary to keep both sides alive. Therefore, the solution for this problem is launching the Asyncio's event loop in a new thread, using the multithreading library, which allows parallel execution without breaking (Noller and Oudkerk, 2008). In addition, the Kivy's loop will be launched in a lowerlevel thread, which represents the mainthread of execution.
However, the threads will have to communicate with each other, otherwise, controlling the AM simulation may not be feasible as the mainthread only triggers the callback that will imply a client generation and the respective messages in the upper-level thread.
To handle this situation, a worker was created to act as an intermediate character between each thread-lever. Its working principle is based on a callback that is triggered every time the EventDispatcher creates an event. A message will be sent after the worker has been created, containing the operation to be executed to the Asyncio thread. However, the opposite working flow must happen as the GUI must be updated, according to the user requests in the server.
Finally, the last step in the GUI development was to enable the application to generate the gcode. This feature was also implemented by launching another thread as the gcode program blocks during operation when it is required to waits() until the generation of gcode.
A complete view and description of the GUI can be seen in Figure 9.
It should be clarified that with this approach the user can run the simulation in real-time, fully controlling its behavior, and access an instance of RobotDK that handles the simulation process. Other work, from the same authors, explored the possibility of using other platforms, like ABB Robotstudio (Pires andAzar, 2018a, 2018b), including the possibility to have simulation and real production in parallel. The authors show a comprehensive demonstration of that possibility in Pires and Azar (2017, 2018a, 2018b, using a real test-case and showing full implementation details.

Conclusion
AM technologies are seen as one of the most influential area in research and development because of their positive impact on the industrial routines. However, these technologies still have a long way to reach maturity as the field is highly multidisciplinary.
The purpose of this paper is to contribute to the AM field by introducing and implementing an SCA capable of executing/ simulating robotic AM tasks. It also shows how an advanced user can integrate advanced simulation technologies with a real AM system, creating in this way a powerful system for R&D and operational manufacturing tasks.
As demonstrated, the creation of the AM environment was only possible by using the RoboDk software that allows the creation of a robot working station and its main operations.
Although the AM simulation was satisfactory, it was necessary to develop a SCA capable of controlling the whole simulation through simple commands instructed by users. As described in this work, the development of SCA was entirely implemented in Python, using official libraries. The solution was presented in the form of an application, capable of controlling all the AM operation through a server/client socket connection.
In addition, the SCA is also capable of automatic generation of gcode, through as simple operation as clicking a button.
In summary, a system architecture was presented that is capable of controlling an AM simulation. Moreover, implementation of commands in a simple GUI was shown as a step forward in implementation of modern AM process controls.