This paper aims to introduce the ideas of practical implications of using industrial robots to implement additive/hybrid manufacturing. The process is discussed and briefly demonstrated. This paper also introduces recent developments on human–machine interface for robotic manufacturing cells, namely the ones used for additive/hybrid manufacturing, as well as interoperability methods between the computer-aided design (CAD) data and material modeling systems. It is presented – using a few solutions developed by the authors – as a set of conceptual guidelines discussed throughout the paper and as a way to demonstrate how they can be applied and their practical implications.
The possibility to program the system from CAD information, which is argued to be crucial, is explored, and the methods necessary for connecting the CAD data to material modeling systems are introduced. This paper also discusses in detail the main requirements (also from a system point-of-view) needed for a full implementation of the presented ideas and methods. A few simulations to better characterize the interactions from heat conduction and physical metallurgy were conducted in an effort to better tune the additive manufacturing process. The results demonstrate how the toolpath planning and deposition strategies can be extracted and studied from a CAD model.
The paper fully demonstrates the possibility to use a robotic setup for additive manufacturing applications and shows the first steps of an innovative system designed with that objective.
Using the aimed platform, unsupervised net-shaping of complex components will substitute the cumbersome processes, and it is expected that such a visionary concept brings about a significant reduction in cost, energy consumption, lead time and production waste through the introduction of optimized and interactive processes. This can be considered as a breakthrough in the field of manufacturing and metal processing as the performance is indicated to increase significantly compared to the current instruction-dependent methods.
Pires, J. and Azar, A. (2018), "Advances in robotics for additive/hybrid manufacturing: robot control, speech interface and path planning", Industrial Robot, Vol. 45 No. 3, pp. 311-327. https://doi.org/10.1108/IR-01-2018-0017Download as .RIS
Emerald Publishing Limited
Copyright © 2018, Emerald Publishing Limited
Modern robotic manufacturing systems, beyond just being flexible, must allow users – at programming, advanced engineering, maintenance and operator levels – to be able to simply tell or show what users are calling them for. This means that the challenge for flexible and agile manufacturing relies – to a considerable extent – on simple and natural human–machine interfaces (Pires, 2007) (Hägele et al., 2016).This is particularly important when small- and medium-sized enterprises (SMEs) are targeted, as the availability of technical expertise among their human resources is limited, both in terms of number and time dedicated to these tasks, compared to larger entities. Consequently, SMEs require radical new approaches when considering the several angles of the problem, namely, new business models, properly adapted robots, flexibility and agility, powerful human–machine interfaces and more efficient integration with all levels of the company (Pires et al., 2006) (Pires, 2007). This is very important because SMEs represent 99.8 per cent of the companies in the world (extrapolated from Eurostat data), more than 70 per cent of the employment and more than 65 per cent of the gross domestic product (Pires, 2012) (Eurostat, 2015), i.e. SMEs are the backbone of the global economy.
Consequently, new robotic manufacturing systems need to respond to the needs of smaller businesses, enabling integrators to easily develop robotic manufacturing solutions specially adapted to low-volume and emerging markets (application pull), i.e. solutions that can be designed, installed, supported and maintained at much lower costs, and also easily operated by regular non-skilled personnel. Future robotic systems need also to interface better with humans and adapt easily to working conditions and setups. This means that novel technologies from the world of information and communication technology, sensors and electronic consumer markets will have a major influence on the design and performance of new robotic automation systems (technology push).
The adoption of scenarios where humans and robots share the same workspace with robots being able to make decisions requires machines that are hyper-flexible, open, fully based on standards, very easy to deploy and integrate into IT environments (plug-and-play), safe to integrate (human augmentation), easy to instruct interactively by using human-like mechanisms (programming-by-demonstration instead of regular code writing), flexible to environment and component geometry, capable of high forces and moments without compromising safety, very easy to setup and start working (plug-and-produce) and adapted to customer needs (creativity push/pull) (Pires, 2004, 2005a, 2007, 2012) (Hägele et al., 2016).
So far, instructing robots in the same way that one would instruct a human worker how to carry out a task is not possible. In this paper, several of these aspects are covered in the process of elaborating the idea of designing and constructing an additive/hybrid manufacturing system. In fact, this work is the first of a collection of publications that will report the design, project and implementation of an advanced robotic platform demonstrator composed of an advanced deposition system for near-net shaping, a given component and modular series and in situ post processes (e.g. machining, drilling and roughing) to minimize the production cycle, shop-floor space and capex. To elevate the operation to the level of intelligence and cognitive manufacturing, data harvesting tools and sensors such as force-torque, temperature and geometric vision are envisaged. Consolidation of all relevant net-shaping processes will be an upswing step toward one-stop-shop manufacturing of complex multi-material components. Using the aimed platform, unsupervised net-shaping of complex components will substitute the cumbersome processes, and it is expected that such a visionary concept brings about a significant reduction in cost, energy consumption, lead time and production waste through introduction of optimized and interactive processes. This can be considered as a breakthrough in the field of manufacturing and metal processing as the performance is indicated to increase significantly compared to the current instruction-dependent methods.
2. Generic robotic setup
Nowadays, robotic cells are designed using digital tools, namely, computer-aided design (CAD) packages and realistic simulation environments (capable of simulating the kinematics and dynamics). In such conditions, the simulation is not only geometrical but also runs the setup with the exact same version of the robot control software, with capacities to generate code that is fully ready to run in the robot controller. Nowadays, an engineer, who may not be a robot specialist or even software expert, is usually able to manipulate a CAD package and a mathematical package (for simulation and data analysis) and has some knowledge about a programming language.
Considering the objective of fast and reliable robot cell development, setup and programming, it is highly desirable to rely on CAD packages and simulation environments to execute the task of handling the development of new industrial robotic cells. Another task is how to design and implement the software to remotely monitor and command the cell functionalities. In this work, we use a client-server model, defining that all the functions available in the robot are offered as highly flexible parameter-based services that the client can request from any client application. The robot controller application software is then designed to implement a multitask state-machine that listens to incoming commands and executes them in sequence (Figure 1).
The calls to the robot follow a simple mechanism of access authorization (list of allowed IPs and password), and the robot informs the authorized remote user about its availability for any requested command. For example, if the robot is not ready (motors have the power supply circuit open), the command to start a program is not possible and is immediately refused with the corresponding error message. Furthermore, if the robot is executing a task and the user tries to command another one, the robot refuses the call by answering that it is busy. For safety reasons, the authorized user may only stop the ongoing task (including the motion), and only after that, another command can be issued. Stop motion, restart from the same point or abort and repeat or perform another task is always possible.
The cell used in this paper (Figure 2) was designed to hold a robot [ABB IRB140, running the IRC5 robot controller with Robotware OS version 5.14 or higher (ABB, 2018a)], equipped with a simple robot tool for following a given contour of a workpiece (which can be easily substituted by deposition tools such as laser metal deposition [LMD] heads/welding torches for wire-arc additive manufacturing or any machining and roughing tool) and a table to place the robot and a workpiece. Both the cell and the selected component were designed to constitute an additive manufacturing demonstrator where we can test three-dimensional (3D) printing and advanced path planning strategies, controlling software, sensors, methods, etc., along with subtractive technologies in the interactive process of building high-precision parts of standard or radically new materials. A view of the selected workpiece is present in Figure 3.
To obtain the necessary contour trajectories the user/programmer should take the advantage of the information available from the 3D file of the workpiece. In fact, all the contours are graphic objects, such as lines, arcs and points, from which the complete path identification can be extracted as the CAD engineer uses such commands to design the workpiece. Hence, one basic function of any graphical simulation and programming software is the capacity to allow users to place points (robot targets) aligned with the surfaces of the 3D object in the process of generating the desired robot path (manual or user defined paths). Another basic function is the possibility to associate a path to an already existing graphic element, retrieving the information from the 3D object and generating the required path along the selected graphic element (automatic paths). In any case, the user needs to define the tool orientation and robot configuration to be able to execute the programed path, as such information is not commonly available from the 3D object (although it can be defined at the CAD software level and will be increasingly required in the near future), along with the dynamic information needed for the path (deposition speed, jogging speed, idle times etc.). Figure 4 shows the contour paths for the workpiece used in this example, along with a selection of individual segments that could be consider special by the user. The idea is to get several options to follow the contour: the complete part and a few other paths on specific zones. The front-end user can select one of six options:
Home: It commands the robot to move to a safe (home) position.
Full: It commands the robot to perform the contour following of the complete workpiece.
Exterior: It commands the robot to perform the contour following of the exterior walls of the workpiece.
Holes: It commands the robot to perform the contour following of the two holes that are sub-geometries in the workpiece.
Interior: It commands the robot to perform the contour following of the interior walls of the workpiece.
Lines: It commands the robot to perform the contour following on the two parallel lines engraved in front of the workpiece.
The above-mentioned paths are programed automatically just by extracting information from the CAD object [RobotStudio auto-path feature (ABB, 2018b)]. The strategy we used was to define approach points just above any path entry and exit points, allowing the user to arrange flyby paths in between those paths (Figure 4).
2.1 Robot controller software (the server)
The strategy used to build the software is based on a client-server model (Pires et al., 2006) (Pires, 2007, 2012). The robot controller should hold at least two independent tasks. One is used to move the robot and implement the operational functionalities expected for the application, and another is used to implement the communication with other robots, computers and generally any client device available in the network (Figure 5). In this example, although we are of course not limited to it, a client-server transmission control protocol/internet protocol (TCP/IP) model implemented over an Ethernet network is used. All actual robot controllers, from any brand, have the Ethernet signaling protocol available (with the TCP/IP data protocol) to share data and to allow basic high-level communication. Most of them, at least from the best brands (with higher levels of market shares), allow the advanced user to implement tasks, manage their priorities, program TCP and UDP services, etc., which creates the basic platform to implement the ideas presented in this paper.
The following tasks and routines are then available in the robot controller:
Motion Task (TROB1): This task has higher priority and is used to implement all the robot motion routines designed for the demonstrators presented in this paper. It includes also the state-machine that regulates the behavior of the robot manipulator and all the trap and exception handling routines.
Communication task (TROB2): This task has lower priority and is used to implement the communication with external devices. It implements a TCP/IP server, based on TCP sockets, design to handle all the data communication between the robot and any external client. The available services were designed to allow the users to read and change variables of any datatype, to start and stop programs and to read and change the operational state of the robot controller.
To allow this strategy to work properly, it is necessary to have variables that can be shared through all the available tasks in the robot controller. Shared memory variables are normal variables that are visible in any task, and as they are located in the shared memory, they can also be accessed from outside, i.e. they can be read and changed from a remote client. For example, consider a numerical variable, e.g. a number with an integer part and decimal part (similar to the float datatype available in C, C++ or C#). At ABB robots, the datatype is called “num”. Suppose that you want to read and/or change the value of a specific numerical variable available in the robot controller. If that variable is declared in shared memory, it is easy to access it. The TCP/IP server implemented in Task 2 allows users to do that only by calling the “read_num” service (to read a numerical variable) or the “write_num” service (to write to a numerical variable). For example, if the numerical value is called “data” (declared as “PERS num data;”), an external client just needs to connect to the communication server, opening a socket, and send the following messages:
To read the value stored in the variable: “read_num data”. The call will return a code, followed by the value stored in “data”. For example: “0 12”, where “0” means that that the call finished successfully (otherwise, it would be negative, specifying an error code) and “12” is the actual value stored in variable “data”.
To write a value in the variable: “write_num data value”. Example is “write_num data 123” to write the value 123 in variable “data”. The call will return a code specifying if it was successful (“0”) or if there was any error (negative value specifying an error code).
Services to access all types of variables, with proper access regulation and security mechanisms in place, of any datatype, are available from the TCP/IP server implemented in the communication task (TROB2). Also, an extensive collection of services was designed that allow the user to change the operational state of the robot controller and read the actual state are present. For example, to enable power supply to the motors, the socket message is “motor_on”, as opposed to “motors_off” to close that circuit. Any program can be started or stopped using the following messages:
“program_start module_name”: It moves program pointer to the beginning of “module_name” and starts the module. If no “module_name” is specified, the robot starts module “main”.
“program_start_pp”: It starts the actual module at the exact position of the program pointer. If program pointer was lost, the robot will refuse to start and the user needs to request the “program_start” service.
“program_stop”: It stops execution of the running program.
The synchronous answer to these calls use error codes to inform authorized users about the system state and execution (calls from non-authorized users are always refused). It is then up to the caller to proceed accordingly to the answer.
The motion task (TROB1) is based on a state-machine regulated by a commanding variable and a collection of parameters that were all declared in shared memory. Changing the value of that variable (updating has needed the value of the parameters), the robot can be commanded to execute the routine required by the user. For example, considering that any possible command can be represented by a number with until five parameters, the following service was implemented in the socket server:
“command_string command parameter_1 parameter_2 […] parameter_5”
When the server receives a message requesting that service, it extracts the values from the commanding string and places them in the respective shared memory variables “command”, “parameter_1”, […], “parameter_5”. As those variables are accessible from the motion task (TROB1), a TEST-CASE-DO loop can be used to implement the state-machine:
WaitUntil command <> 0;
CASE 1: run routine_1(parameters);
CASE 2: run routine_2(parameters);
CASE N: run routine_N(parameters);
DEFAULT: say something like
“routine not available”;
Following the implemented strategy, the robot controller waits for a command, runs the commanded option and waits again for a new command. It is a simple, but very effective and reliable, implementation of the idea of having a robot executing a collection of services that can be built as simple and general as desired.
2.2 Remote monitoring, commanding and control software (the client)
The client software is an application that should allow the user to make parameterized calls to the robot controller TCP/IP server (task TROB2), exploring in this way the functionality available from the robot. As client and server sides are fully open and programable, it is very easy to extend the functionality available from the robot controller just by adding new services or adapting the existing ones. For the current example, and having in mind the possibility to build a 3D printing example using a similar setup, a multiplatform application was designed considering the following assumptions:
There should exist at least two types of users: full access users (administrators) that can access all the services, make modifications in the system, parameterize the motion, adjust paths, etc., and normal access users (operators) that can access to all the basic (operation level) functionality.
The application should be able to access and command any of the existing robotic setups, namely, the 3D digital setup designed in Robotstudio, composed of a graphical robot and a virtual robot controller, and the real robotic setup, composed of a real robot and robot controller, without changing anything or making any assumption.
The user should be able to command the robot by accessing a prebuilt graphical user interface (GUI) or typing the necessary calls by using something similar to a command line interface.
Information about the state of the robot controller and robot program should be available at any time also to guide the user in a logical way. For example, if the robot is in “Motor OFF” state, all the commands related with starting/stopping programs and accessing available program options should be deactivated.
Some type of high-level programming (Pires, 2007, 2009a) (Gustavsson et al., 2017) interface should be available to demonstrate the capacity to add advanced features to the developed platform. From the available features, a speech interface was added to allow the users to command the robot by using their own voice (this feature is only available for administrators). Consequently, at least two types of speech recognition (SR) and a text to speech engines are used: one set of engines for American English and another set for Portuguese from Portugal (Pires, 2005b, 2005c, 2009a) (Gustavsson et al., 2017).
The client application was consequently designed to implement the above-mentioned features. It is capable of issuing TCP/IP calls based on user commands and receive information from the robot controller. The process of receiving information can be implemented in two ways:
just by polling the robot controller, asking for the information needed; or
just by generating events from the robot controller to update the client with any change on any of the interested variables.
For simplicity, a simple pooling mechanism is used, although an event-driven strategy is also possible and is available.
2.2.1 Detail of the client software features
Any client software should be able to inform the user about the actual status of the robot controller, namely, state of the robot program, options being executed and availability to receive more commands, and also allow the user to send commanding messages to the controller, exploring in this way the complete functionality of the software implemented in the robot controller (the server). Having these objectives in mind and considering our goal of introducing a 3D printing example, the following was implemented in the client (Figure 6):
Configuration tab: It allows the user/operator to edit and/or select the robotic setup that will be used. The operator with enough privileges can edit the IP address and PORT address of the robotic setup and change the process velocity, regulate the acceleration and change a few parameters of the client application.
Manual tab: In this screen, the user can start the automatic polling of the robot controller and manually, i.e. writing the calls messages in a command-like environment and can send commands to the robot controller. Information about the robot status, program status, etc. is printed in the screen if the polling mechanism is activated.
Automatic tab: It allows the user to command the robot using the mouse or issuing speech commands. The application informs the user about all relevant information, including the processing of the speech commands. This is the normal operation of the system.
Speech interface tab: It is a specific configuration screen that allows the user to select the language he wants to use, the voice that the robot will use to interface with him and specific details about how the speech interface is working. In this screen, the user can also activate or deactivate the speech interface.
This application is built as a guideline, so it can be used as a template for other specific applications that required the same basic functionality.
2.2.2 Speech interface
The system should identify, with high level of confidence, sequences of commands with a well-defined structure.
The programmer should be able to select the level of confidence that is safe enough to allow a sequence (utterance) to be considered as a valid command.
The collection of commands must be adjustable by the user, using some type grammar specification.
The recognition engines should allow command-mode operation, disabling the dictation mode.
There should be at least an English and a Portuguese version;
Consequently, for the windows version of the presented application, running on Windows 10 Pro (version, 1709), the American English SR engine and text-to-speech engine (TTS) are the ones that come with the operating system. Nevertheless, as a Portuguese SR engine is not yet available, we decided to use an adapted version developed by the Portuguese MLDC (Microsoft Language Developing Center) (Pires, 2005b, 2007, 2009a) for SAPI 5.1, along with the Portuguese TTS voice Madalena (not available commercially) (Pires, 2005b, 2009a) (Microsoft SAPI, 2010). To be able to use all these versions with a XML grammar, we also used SAPI 5.1 and 11 (Microsoft SAPI, 2010) in the implementation of this speech strategy.
The grammars developed for this application are based in the following type of command sequence:
“robot <command> <parameter_1>… <parameter_5>”
“robot moto on/off”, to activate/deactivate the motor on circuit;
“robot program cycle”, to run module “main” from the beginning in TASK1;
“robot program run”, to run actual program from the actual TASK1 program pointer; and
“robot program stop”, to stop execution of the robot program in TASK1.
or, in the specific case of this application:
“robot contour only”, to run program option “contour only”;
“robot holes only”, to run program option “holes only”; and
“robot all piece”, to run program option “all work-piece”;
As all the commands are programed using an XML grammar file (SAPI 5.1 compatible), it is easy to change the command sequence and adapt it to the type of user, type of application, etc.
Moreover, the client application has access to the procedure of identification. Consequently, it is possible to observe the identification hypothesis and the level of confidence and make the necessary decisions about what to consider as a positive command sequence identification.
In our application, a sequence (utterance) is only identified as a command sequence if a proper ID is obtained from the XML grammar and if the level of confidence is higher than 75 per cent. If those objectives are met, the sequence is authorized to be processed and the corresponding TCP/IP socket call is issued to the robot controller. Otherwise, if the utterance is identified, but with a level of confidence lower than 75 per cent, the user is notified to repeat the command. Any other option is simply ignored (Figure 7).
The utilization of the word “robot” to start any command sequence enables the user to speak normally, with the microphone open, without having too many possible identifications and, consequently, having the robot requesting the user to repeat a command. A noise-cancelling microphone is used, although, for safety, it is equipped with a press-to-speak button that can be useful in very noisy and crowded environments.
The interested reader may find demonstration videos of the presented application in a study by Pires and Azar (2018a).
3. Extension to three-dimensional printing using a robot manipulator
Building from the presented example and related applications, it is possible to consider how the developed ideas may be applied to a 3D printing example or, in a more general approach, to additive/hybrid manufacturing. In fact, supposing that the robot is using some type of additive manufacturing tool (welding gun, laser head, etc.), along with a material removing tool (assembled in the same head or using a tool-change mechanism), making in this way a manufacturing head capable of adding and removing material, it is possible to design a strategy that could extend the above presented application to be able to produce a metal component. For the sake of simplicity, we will focus on printing the workpiece considering only the material adding function.
What is needed to be able to print the above presented workpiece?
Additive manufacturing tool: It is a tool capable of adding material continuously and at controlled deposition rates. A good example is a MIG/MAG welding gun that we will consider for demonstration purposes only.
Slicing software: It is able to extract the printing trajectories from the workpiece under production. This can be easily done using one of the available slice software. From the several options available, we decided to use Slic3r (2018), a free and open-source package very popular for this type o applications.
Robot simulation software: As it is very easy to get several thousands of points from the slicing of the workpiece (e.g. with our setup, we got more than 11,000 points), the process of generating the robot code, along with the capacity to automatically adjust robot configurations, which will make the robot moves possible, needs to be automatic. Consequently, it is very important to have access to a robot simulation environment capable of receiving the points and automatically generated programs and, with simple derivatives, obtain the necessary robot configurations. For this demonstration, and because we are using ABB robots, we decided to use the excellent simulation package called RobotStudio (from ABB) (ABB, 2018b);
Automatic generation of robot targets and robot code: To extract information from the slicer, we export those points by generating the G-code (Slic3r, 2018) associated with the 3D printing task. A small program was built to extract the points, generate the necessary robot targets (with position and orientation), generate the printing programs to load in the robot controller (divided in layers for better understanding of the process) and generate a set of other files that are used to feed other analysis software, such as the one used in Section 4 of this paper.
Possibility to simulate the all procedure and generate the final robot code: The same simulation environment (ABB RobotStudio) is used to simulate the complete procedure showing the individual layers and respective paths, add the capacity for small adjustments and be able to observe, in real time, the printing process.
The procedure described in this paper to produce (print) a complete workpiece is fully presented in the flowchart of Figure 8. The process starts from a CAD file, includes slicing of the 3D model of the workpiece, extraction of targets, automatic configuration, automatic code generation and simulation and fine tuning, as well as the capacity of simulating the physics of the process and extracting valuable information for the manufacturing task.
Figure 9 shows the simulation robotic setup. Figure 10 shows the result of the slicing procedure and aspects of the printing layers generated by the slicing process. Figure 11 shows the G-code reader, the complete printing sequence and a zoom of the first layer. Figure 13 shows the simulation of the printing process, with details about the automatically generated paths. A video of the complete procedure can be found in a study by Pires and Azar (2018b) (Figure 12).
4. Modeling of the deposition phenomena based on the toolpath
Wire-arc additive manufacturing (WAAM) and LMD are complex processes that conceive complex phenomena from mass and heat transfer, as well as physical metallurgy. Understanding the thermal history of areas around the deposited beads using analytical solutions becomes difficult when the geometry is complex. Rosenthal (1946) and Rykalin (1953) have established analytical solutions assuming the bead-on-plate condition. However, the majority of the deposited materials are performed in a sequential pattern depending on the CAD geometry and toolpath settings, which affects the original assumptions. Although Grong (1997) and Azar et al. (2012, 2013) have proposed methods to approximate the heat input for different deposition geometries, the problem is still complex for sophisticated shapes. On the other hand, finite element methods can take more parameters into consideration. Setting up a finite element model including all the physical phenomena is already challenging. Additive manufacturing is yet another challenge as incorporating all the toolpath and making the mesh elements appear wherever the heat source is traveling, poses computational constraints and makes the calculation expensive. Previous attempts for thermomechanical analysis (Ding et al., 2011) (Denlinger et al., 2014) of large-scale additive manufacturing components (Williams et al., 2016) were simplified because of intricate process of implementing toolpath for finite element simulations, especially for exerting the intervals between deposition passes. The major disadvantage of such simplifications is that the correlation between real robotic toolpath and simulation results becomes insignificant, particularly for complex and large-scale components.
However, in the value-chain of modeling for WAAM and LMD processes, we have made a contribution through introducing the toolpath directly to the finite element method (FEM) environment from the CAD slicer software. This will help shortening the model setup phase and save time for the users. Moreover, further developments make it possible to read the outcome of the finite element analysis and optimize the toolpath based on the results in an online setting.
Transient (time dependent) heat conduction applies to the WAAM or LMD process. The heat conduction in 3D will then be defined by the following equation (Haug and Langtangen, 1997):
4.1 The model and materials
The model consists of a workpiece that was presented in Figure 3, and it is assumed that the deposition is performed by a wire arc system. The deposition paths were optimized and created using Slic3r open-source software and exported as G-code. The material of the deposited beads and the back plate is Al4.5MgMn. The model was meshed, and a script code converted the robot positioning nodes into a toolpath that could be imported by finite element software. Figure 14 shows the universal model with the applied boundary conditions. The back plate was set on a bearing similar to the work bench conditions and clamped on four corners with the stiffness of 1,000.0 N/m.
4.2 Boundary conditions and deposition parameters
The deposition process is assumed to start from the room temperature. Therefore, the pre-heating temperature of about 20-25°C was applied. The convectional heat dissipation around the surface is:
General boundary conditions will be as below:
Preheating temperature is Ti = 20 − 25°C.
The transient heat flux of any existing or evolved surfaces is , where q0 = ηUI, η is the weld efficiency factor and U and I are the deposition voltage and current, respectively.
The heat dissipation by radiation follows the Stefan–Boltzmann law (Carslaw and Jaeger, 1959):
Deposition voltages for the first layer is set to 15 V. Deposition current is 140 A for all passes in Layer 1 and the heat efficiency is set to 80 per cent. The linear welding speeds are 7 mm/s for all the passes in Layer 1. The former values were extracted from prior experimental work.
The dimensions of the coherent mushy zone are normally less than those of mesh elements. It leads to some unevenness when presenting the fusion line in scalar node average mode. This will create premature appearance of the surrounding elements. However, as the heat source will run over those elements again in their own turn, the thermal cycle will reset the previous history for those elements, and therefore, this unevenness is assumed to be uncritical. The viscous effect in the liquid phase was ignored (Aarbogh et al., 2010), and elements only appeared at the solidus temperature. Double-ellipsoidal heat source model (Goldak et al., 1986) was used to simulate the deposition process in this study. The heat source parameters are listed in Table I with reference to Figure 15. The heat source design was performed suing the guidelines given in (Azar et al., 2012).
The defined path consists of three patches of sequential moves to cover the deposition of the first layer. The first layer is 3 mm high, and the hatch spacing is 6 mm. In other words, each deposited layer is assumed to be 3 mm thick in the deposited direction and 6 mm thick in the lateral direction. The whole path, including the three move patches, was deposited without intervals.
4.3 Thermo-physical properties of the materials
Figure 16 shows thermo-physical properties of the applied material that are used for deposition process modeling. As both the back plate and the deposited materials are assumed to have the same properties, the dilution factor is neglected here.
5. Materials modeling results
The simulation was presented only for the first layer for sake of simplicity. The toolpath for simulation was also changed into 0° hatching orientation (i.e. Figure 10 shows 45° orientation) to demonstrate another possibility for extracting the toolpath from a Slic3r software at any given settings and introduce it directly into the simulations without major difficulties. The toolpath was extracted using the G-code reader interface (Figure 11).
Figures 17, 18 and 19 show the thermal field, principal stresses and total distortion, respectively, throughout the first layer deposition at 10, 400, 1,200, 1,600, 2,000, 2,400, 2,800, 3,200 and 3,600 s. The wireframe presentation of the workpiece shows the initial position of the back plate at time 0 s. All the distortions were multiplied by five for sake of vivid illustration.
In Figure 17, the maximum temperature occurs within the volume of the heat source, where the molten pool is located at any given time. The rise in the temperature on the opposite side of the start position occurs when almost half of the layer is deposited. It also shows that the temperature contours around the heat source are relatively small in the beginning of the deposition and get larger as the deposition is progressing continuously. The latter is because of the temperature rise throughout the model, as the heat input is continuous (no interval) during the entire process. The advantage of such models is that the sequences and time intervals between each given set of beads or deposition blocks can be modified and adjusted prior to experiments. This is particularly important when the material has a solid-state transformation (e.g. steels) that makes it inevitable to engineer the microstructure by monitoring the cooling rates throughout the deposition.
As illustrated in Figure 18, most of the residual stresses evolved in this model is in the first quarter of the deposition area. The major reason is because of the colder conditions of the back plate. When the heat source arrives at the middle of the total path, the deposition of the next bead takes place on a region of the substrate, which is already pre-heated because of the conduction from the earlier deposited beads. This rise in the temperature reduces the mismatch between the temperature of the deposited material and the substrate and apparently helps to reduce the residual stresses between any two sideway beads. The stress concentration in the middle of the upper edge of the back plate, just above the bigger hole, is due to the warpage of the plate. Preventing the warpage by applying higher clamping stiffness will probably eliminate the stress concentration in the mention region. However, the inter-pass stresses can increase significantly and cause cracking in the deposited material. The maximum reading of the principal stress in this model is about 200 MPa, slightly above the yield stress of the material. Therefore, pre-heating the back plate will help reducing the risk of plastic deformation in this case.
Figure 19 shows the total distortion of the whole model after depositing the first layer. This number is subjected to major changes, positive or negative, once the subsequent layers are deposited. However, preventing the distortion in the first layer will increase the chance of building relatively straight and large pieces according to the generated toolpath by using the CAD information. Although increasing the clamping stiffness may limit the total distortion, high level of residual stresses may evolve, as discussed previously. As it can be seen, the warpage at the cooler start is registered more than the warmer end, which is another indication that pre-heating can be useful.
In this paper, a detailed description on how to implement additive/hybrid manufacturing with current robot manipulators was presented and discussed. The possibility to program the system from CAD information, which is argued to be crucial, is explored, and the methods necessary for connecting the CAD data to material modeling systems are introduced. This paper also discusses in detail the main requirements (also from a system point-of-view) needed for a full implementation of the presented ideas and methods. A new interface was designed and implemented that convers the CAD data into toolpath that can be used for both manipulators and simulation purposes to converge the results and engineer the toolpath from two main perspectives: robotics and materials. Not only this information can be used for instructing the robots but also the same path can be studied for process optimization.
A few simulations to better characterize the interactions from heat conduction and physical metallurgy were conducted in an effort to fine tune the additive manufacturing processes. Unfortunately, because of the slow nature of the precise FEM simulation on plain computers, the path planning and simulation may not be performed simultaneously. However, reducing the number of elements in the model and using rough meshes and techniques such as parallel computation, graphical processing unit and high-performance computing integration may result in scaling the simulation time down. Such an advanced system can be eventually coupled with robotic path planning to adjust the operation in real-time.
Double ellipsoid volume Gaussian heat source parameters
|Parameter||a [mm]||b [mm]||cf [mm]||cr [mm]||ff [-]||Gaussian parameter|
|Entire path in the first layer||5.0||3.0||3.5||6.5||0.7||3|
Aarbogh, H.M., Hamide, M., Fjær, H.G., Mo, A. and Bellet, M. (2010), “Experimental validation of finite element codes for welding deformations”, Journal of Materials Processing Technology, Vol. 210 No. 13, pp. 1681-1689.
ABB. (2018a), “ABB IRC5 documentation”, ABB Flexible Automation, available at: www.abb.com/robotics
ABB. (2018b), “ABB RobotStudio”, version 6.06.01 or higher, ABB Robotics, available at: www.abb.com/robotstudio
Azar, A.S., Ås, S.K. and Akselsen, O.M. (2012), “Determination of welding heat source parameters from actual bead shape”, Computational Materials Science, Vol. 54, pp. 176-182.
Azar, A.S., Ås, S.K. and Akselsen, O.M. (2013), “Analytical modeling of weld bead shape in dry hyperbaric GMAW using ar-he chamber gas mixtures”, Journal of Materials Engineering and Performance, Vol. 22 No. 3, pp. 673-680.
Carslaw, H.S. and Jaeger, J.C. (1959), Conduction of Heat with Solids, 2nd ed., Oxford at Clarendon Press.
Denlinger, E.R., Irwin, J. and Michaleris, P. (2014), “Thermomechanical modeling of additive manufacturing large parts”, Journal of Manufacturing Science and Engineering, Vol. 136 No. 6, p. 061007.
Ding, J., Colegrove, P., Mehnen, J., Ganguly, S., Almeida, P.S., Wang, F. and Williams, S. (2011), “Thermo-mechanical analysis of wire and arc additive layer manufacturing process on large multi-layer parts”, Computational Materials Science, Vol. 50 No. 12, pp. 3315-3322.
Eurostat. (2015), “Statistics on small and medium-sized enterprises”, Eurostat data, available at: http://ec.europa.eu/eurostat/
Goldak, J., Bibby, M., Moore, J., House, R. and Patel, B. (1986), “Computer modeling of heat flow in welds”, Metallurgical Transactions B, Vol. 17 No. 3, pp. 587-600.
Grong, Ø. (1997), Metallurgical Modelling of Welding, 2nd ed., Maney Publishing, Leeds.
Gustavsson, P., Syberfeldt, A., Brewster, R. and Wang, L. (2017), “Human-robot collaboration demonstrator combining speech recognition and haptic control”, Proceedings of the 50th CIRP Conference on Manufacturing Systems, Science Direct, Taichung City, Vol. 63, pp. 396-401.
Hägele, M., Nilsson, K., Pires, J.N. and Bischof, R. (2016), “Industrial robotics”, chapter 54 of Handbook of Robotics, 2nd ed., doi: 1007/978-3-540-30301-5_43, ISBN: 978-3-540-23957-4 (Printed version) 978-3-540-30301-5 (Online eBook version), Springer, Berlin-Heidelberg.
Haug, A.A. and Langtangen, H.P. (1997), “The basic equations in Eulerian continuum mechanics”, Methods and Software Tools in Industrial Mathematics, Birkhäuser, Boston.
Lewis, A.C., Nithiarasu, P. and Seetharamu, K.N. (2004), Fundamentals of the Finite Element Method for Heat and Fluid Flow, John Wiley and Sons, West Sussex.
Microsoft SAPI. (2010), “Microsoft Speech Application Programming Interface (SAPI) and SDK”, Version 5.1, 5.3 and 11, Microsoft Corporation, available at: www.microsoft.com/speech
Pires, J.N. (2004), “Handling production changes on-line: example using a robotic palletizing system for the automobile glass industry”, Assembly Automation Journal, Vol. 24 No. 3, MCB University Press.
Pires, J.N. (2005a), “Complete robotic inspection line using PC based control, supervision and parameterization software”, Elsevier and IFAC Journal Robotics and Computer Integrated Manufacturing, Vol. 21 No. 1.
Pires, J.N. (2005b), “Robot-by-voice: experiments on commanding an industrial robot using the human voice”, Industrial Robot, an International Journal, Emerald Publishing, Vol. 32 No. 6.
Pires, J.N. (2005c), “Semi-autonomous manufacturing systems: the role of the HMI software and of the manufacturing tracking software”, Elsevier and IFAC Journal Mechatronics, Vol. 15 No. 10.
Pires, J.N. (2007), Industrial Robots Programming, Building Applications for the Factories of the Future, 1st ed., ISBN: 97897-0-387-23325-3 (Printed version) 978-0-387-23326-0 (Online eBook version), Springer, New-York, NY.
Pires, J.N. (2009b), “From the coworker to the cognitive factory scenario: new developments for SME manufacturing”, 4th International Congress on Welding Technology and Manufacturing, Saltillo, 5 to 7 of November.
Pires, J.N. (2012), Automação Industrial, 5a edition, ISBN: 978-972-8480-31-8, Lidel.
Pires, J.N. and Azar, A. (2018a), “Video: Robot programming and control using RobotStudio, speech and TCP/IP sockets”, YouTube link, available at: www.youtube.com/watch?v=szxNe3SmMfM&t=259s
Pires, J.N. and Azar, A. (2018b), Video: “Using a robot manipulator for 3D printing”, Youtube link: available at: www.youtube.com/watch?v=HrshHPNeJSc&t=279s
Pires, J.N., Loureiro, A. and Bolmsjo, G. (2006), Welding Robots, Technology, Systems Issues and Applications, 1st ed., 97897-1-85233-953-1 (Printed version) 978-1-84628-191-4 (Online eBook version), Springer, London.
Rosenthal, D. (1946), The Theory of Moving Sources of Heat and its Application on Metal Treatments, Trans. ASME, Vol. 68, pp. 849-866.
Rykalin, N.N. (1953), Berechung der Wärmevorgänge beim Schweissen, VEB Verlag Teknik, Berlin.
Slic3r (2018), “Slic3r – G-code generator for 3D printing”, V1.3.0 or higher, available at: www.slic3r.org
Williams, S.W., Martina, F., Addison, A.C., Ding, J., Pardal, G. and Colegrove, P. (2016), “Wire + arc additive manufacturing”, Materials Science and Technology, Vol. 32 No. 7, pp. 641-647.
Pires, J.N. (2017), “Industria 4.0: as oportunidades, os desafios e o impacto social”, 1st Congress of Portuguese Independent Consultants, Lisbon, 17 December.
Pires, J.N. and Dias, M.S. (2009a), Interfacing with Robots: do Robots do What We Want Them to Do?, Microsoft Language Development Center, Magazine Futures, (March).
The authors want to thank their affiliated institutions (University of Coimbra, Mechanical Engineering Research Center; and SINTEF Industry) for the support in this research work. Some of the process parameters were determined by experimental work carried out in AddMan-Al HydrosFond project of SINTEF, and the authors acknowledge this project.