Predictive Machine Diagnostics

Machine maintenance is a costly problem for factory lines to manage because it requires many engineering hours to perform scheduled maintenance and can usually only be done by trained experts. If an industrial machine goes offline due to an unforeseen failure, it can cause the factory line days or weeks of production downtime, costing millions of dollars in lost production.

Predictive maintenance of machines intends to infer and predict potential for machine failure from patterns in the machine’s diagnostics data sourced from different sensors: accelerometers, cameras, acoustic sensors, and more. Once data is acquired, a machine learning model is used to to recognize patterns in the sensor data that is indicative of deteriorating behavior and output that data to a dashboard to notify the machine’s user.

This project attempted to build a proof-of-concept of the wide array of research done in academia on the predictive machine maintenance problem. Without access to an industrial machine, a 3D printer was used as an analogous machine to those seen in factory lines; the main similarity is the use of linear axes for motion in 3D space, as is often the case for industrial machines in fields such as semiconductor metrology and inspection (the author draws from work experience in this industry).

In particular the research methodology described by Windau et al. in Inertial Machine Monitoring System for automated failure detection served as a guide for this proof-of-concept experiment.

Data capture: Sensor instrumentation layout

Given that a real data set needed to be captured, much of the time spent on this project went toward building the sensor layout, setting up the microcontroller script, and troubleshooting until the data gathered was of the highest quality in terms of capturing relevant mechanical behavior in a usable dataset

Data capture: Design of experiment

Repeatable and distinguishable patterns in data are important to identify when feeding into a machine learning network. Since a dataset of vibration behavior from a 3D pritner was not readily available, a dataset had to be created. The design of this experiment called for repeatably running the same motion on the 3D printer while logging vibratory information from a network of accelerometers strategically attached to the printer.

It’s important to understand the breakdown of the animated motion shown above. The full “X-swath” motion can be broken down into multiple segments corresponding to the different points of the motor’s acceleration profile. There is further reading necessary into this particular motor, but in general, a stepper motor will follow an acceleration profile that consists of accelerate, decelerate, 0 acceleration (aka constant velocity), accelerate, and final decelerate components before coming to a rest.

When later visualizing the accelerometer data, it will be important to differentiate between the components of the acceleration profile to confirm an intuitive understanding of the vibration signal seen. This will help to validate the data before spending hours of effort in the data logging process.

general acceleration profile of a motor divided into its components

Data capture: Arduino script

The Arduino microcontroller cycles through each accelerometer connected to its I2C bus, running the ATmega328 chip at its default pre-scaler value, resulting in a 50Hz sampling rate. This is confirmed by including a timer column that measures the time elapsed in milliseconds between each data sample (time elapsed 20ms –> 1/20ms = 50Hz rate).

Given the Nyquist theory requirement to sample a desired frequency at double the rate, we know the sensor instrumentation can capture mechanical vibrations at half of the 50Hz sample rate; in other words, vibrations of up to 25Hz. This is important to keep in mind for understanding the data later in the pipeline.

Code can be found here:

Program flowchart for reading sensors and streaming to serial port for data logging

Data capture: Printrun Python library

In order to run the printer as described in the Design of Experiment section, the printer controls need to be bypassed and the open source printer control library Printrun enables exactly that. The documentation for the library can be accessed here: __

Although the library is robust in its features offered, for this experiment’s purposes, only the printcore class was used to gain access to the core control methods. In addition to that, I wrote a short program to interface with printcore via serial, Arduino via serial, and a custom data logging program to capture the data streaming into the serial port. Details are below and the code will be published via Github.

Code can be found here:

Program flow for printer control and simultaneous data reading from serial port

Data shaping and visualization: Jupyter notebook

As the data starts to come in, it is absolutely crucial to project timeliness to catch any errors and misunderstanding about the experiment by visualizing the data. To accomplish this, I wrote a simple visualization script in Jupyter and ran the first few data readings to ensure the plots I see made sense to my mechanical understanding of the printer system.

Along with the time series data, it is important to extract and visualize the frequency content present in each dataset. The frequency content will be used as unique features of the mechanical behavior of the 3D printer as it is executing the repeated X-swath experiment over 100s of trials.

Program flowchart for data visualization

Using this program, I can visualize the time series data and frequency content for each axis of each accelerometer,

Time series plot of XYZ axes from Sensor0
Frequency content of XYZ axes from Sensor0

Predictive data analytics: Machine Learning architecture

The concept design, instrumentation layout, data capture and data visualization of this experiment was what I was most familiar with and could drive myself, drawing from previous experiences.

For the predictive analytics portion, I closely followed the guidance provided by Windau et al to replicate the machine learning network provided in the publication. As described in the paper, I built a feed-forward neural network using a single hidden layer and the ReLu activation function. As much of the project timeline was spent building and extracting the dataset, this portion of the project needs further investigation. The resulting accuracy of the network, using the real-world printer vibration dataset is 33%.

The ML network code can be found here

Overall learning and next steps

The sensor instrumentation, data logging, shaping, and visualization portions of the project provided a deep insight into building a high quality dataset that is intuitive to understand and easy to reuse in other experiments. Although this design is able to accomplish the primary objectives to prove the concept, I will be considering the following improvements for future work:

  • increase number of sensors. The sensor system is easily expandable to 8 sensors at the minimum with capacity for 8+ after modification to the microcontroller
  • modify microcontroller chip’s default pre-scaler setting to accomodate higher serial baud rate, thereby increasing sensor sample rate
  • should consider SQL, it is possible CSV format is not ideal and is not industry standard
  • consider further reading into Scipy library for Fast-Fourrier Transforms to confirm intuition

The ML network uses just one hidden layer as described in the paper. I have found other readings which apply an ensemble of networks to image datasets that show dramatically improved prediction accuracy results. As the model stands right now, an ensemble approach with a larger dataset from 8+ sensors may be helpful in modelling the time series dataset I’ve built for this experiment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s