Arcam Log File Analysis

As the build is processing, EBM Control registers process data in a log file (.PLG). Upon completion of the build, the .PLG file is compressed into a .ZIP folder. The .PLG file is a text

170

file, with its own unique syntax for storing data. Given an understanding of the syntax of the log file, a user can pull out useful data about the process. This may be done manually, with a script, or by using the proprietary EBM Log Studio software from Arcam.

Process Themes store process parameters locally, so that a given theme can be recalled in EBM Control for running a build. These are stored locally as .XML files. However, the theme values are stored in the .PLG file, so it is not necessary to store the .XML files (but may make it easier to compare and/or re-run a specific theme). In fact, it is necessary to look at the .PLG file to check for any parameter changes made during processing (these will not be registered in the .XML file unless saved).

Each line of the .PLG file includes a piece of data. Some lines are prefaced with a date/time stamp; these lines are collected data. Other lines are prefaced with “#-IOItem:” to delimit inputs from the process themes selected.

#-IOItem:

Name=Themes.ProcessStep[9].Theme.Melt.Squares.StartSquare.AutoOffset.Enable|DName

=Enabled|Type=Boolean|Unit=|Format=|Axis=Linear|HiHi=0|Hi=0|Lo=0|LoLo=0

Most lines log either inputs from the user or data measured by the machine. An example line of standard user input is:

2014-07-28

13:38:46.671|Themes.ProcessStep[10].Theme.Melt.Squares.StartSquare.Beam.Current|Cor e|44316247|12

Vertical bars are used to divide values. Periods are used to divide levels/classes on the list.

The last value listed is the input value (in this case 12mA) for the last level (Current). The units for the value are taken from the standard IO that is shown on the user input screen.

171

Brackets are used to hold the value of the process step (in this case step 10). These process steps correlate to the order in which the steps were loaded in the Theme, which may not be the same order that steps are run in; the order in which steps are run and loaded may be different and cause some confusion during analysis (especially is themes are re-loaded or un-loaded).

A standard line of output data looks like:

2014-07-30 00:00:37.828|OPC.Temperature.BottomTemperature|SuperUser (OPC)|49110884|858

Again, the timestamp is the leading value. This line shows the output of the temperature from the thermocouple under the start plate reading a value of 858°C. Data is appended as it is collected, so it is ordered by time and not by category. For this reason, parsing of the log file data can be useful for data analysis.

V.2.1 Data Analysis Code Development at ORNL

Work at ORNL has started to develop a log file analysis code for the EBM process. The code is written in a set of Python modules that read .PLG files. The code works by first parsing the .PLG file into a more readable file format (.hdf5). The python module h5py is then used to read the .hdf5 file. NumPy and Matplotlib modules are then called and used to plot the data, as specified by the user. One of the most useful tools is the ability to calculate the average layer time, while excluding anomalous layers (Figure 80).

172

Figure 80. Average layer time as calculated by the ORNL code from log file data.

These modules were used in this dissertation to analyze builds from a variety of different materials, hardware, software versions, and layer thicknesses. Although parameter

optimization was ongoing for most of these builds, useful information can still be extracted;

a few parameter changes between builds is mostly assumed to not be impactful, except as noted in the text for the various builds considered. Build descriptions for samples prepared for this study are given in Table 17. Data on processing time is given in Table 18. The average layer time was calculated using the ORNL code, excluding anomalous layers. The part volumes were calculated using a function in the basic version NetFabb. Deposition rate was calculated by dividing either the mass or volume by the process time. This gives a deposition rate that includes the time waited for raking, preheating, and postheating (not just the melting stage) to give a more accurate account of the rate the process occurs at.

Cool down time was not included in the deposition rate calculation. If cool down time was included, the calculated deposition rates would decrease relatively dramatically; the cool down time for shorter builds is sometimes larger than the process time (in cases using the

173

slow, vacuum cool). Cases from this data will be compared (§V.2.4 through §V.2.10), including discussion of important differences in process parameters.

Table 17. Summary of analyzed builds.

Build

#

Layer Thickness

Machine Software Powder Build Geometry

174

Table 18. Summary layer time, process time, and deposition rate.

Build # Average

In addition to the NIST Test Artifact, other example geometries were run. Simple bars were designed to fit on a 150x150mm start plate and are called the “X-Y Tensile” part. These bars (Figure 81) were designed to measure tensile properties in the X- and Y-directions. Another build was designed to produce both horizontal and vertical tensile samples. This build is called the “Verification” part (Figure 82).