Warning: run away if maths & computing aren't for you!

Got a book describing machine tool installation c1930. After levelling the floor, and maybe digging a deep 6" wide trench around the machine to isolate it from nearby machines, the first test is for vibration. Not levelling the bed or runout – they're for later. Vibration gets top priority because it's the main cause of poor finish. To detect it, a mechanical device consisting of several suspended pendulums was plonked on the ways. Any swinging indicated vibration frequencies to aid diagnosis. Much testing at various speeds and cuts. Here I attempt to replace the pendulum device with a computer, and investigate my WM280.

Running machines make noise due to bearings and gear settings. The noise is a rich mix of frequencies. Not a problem unless there's a match to one of the machine's natural resonances causing shaking at the cutting point.

I put a laptop on the bed of my WM280 and used its built-in mic to record the noise idling at 1260rpm. (Ubuntu command arecord -d 180 -D plughw foo.wav records 180s of audio from device plughw (the microphone), and saves it in a unsigned 8-bit mono wav file, sampled at 8000Hz )

Next is identifying frequency spikes in the sound. A wav file is a list of numbers representing frequencies changing over time. The image below is a simple test wave made from 3 clean sine waves and its already hard to see what they are. A Fast Fourier Transform converts the wave from the time domain into the frequency domain producing a sort of histogram showing how frequencies are spread across a spectrum.

Wunderbar, FFT found 3 inputs!

Applying FFT to the WM280 recording:

Complicated result, but big spike at 400Hz, which seems nicely related to the chuck at 21rps (19*21). Also related spikes at about 200, 600, 800, 1000, and 1200Hz.

No conclusions yet! Next, I'll look for lathe settings producing poor finish and repeat to see if it occurs at particular frequencies.

Python program doing the work:

Don't understand why I had to multiply frequencies by 44 to get the graph X scale right. Hate fudge & I'm baffled! A promising start though. My brain is cooked…

Dave

Edited By SillyOldDuffer on 23/05/2020 16:25:25

Thanks for responses and pointers chaps. Even more for me to think about.

The 44 fudge factor mystery is solved. My mistake – I plugged in the wrong sum instead of 1/sampleRate.  See AdrianR's post!

Latest version of the Python program that does the analysis:

Probably ought to mention in connection with the maths that 'data', 'normalData', 'fftResult' and 'xfreqs' are arrays of numbers, not individual values. An audio sample lasting 15 seconds consists of over 100,000 numbers, so – despite the programs' apparent simplicity – it's doing millions of floating point calculations. Not a job for a slide-rule or calculator!

Anyway, next analysis is of something bad! I rubbed a carbide insert on the shoulder of ⌀38mm steel at 1260rpm, which produces an awful 'stop now you idiot' screech. The frequency spectrum is:

There's a fundamental at about 864Hz, second harmonic at 1728Hz, third at 2592Hz, and maybe 4th at 3456Hz. Rubbing vibration completely dominates whatever other noises the lathe is making. So what's vibrating at 864Hz? It can only be the tool.

Applying the tuning fork formula to the size and material of my insert holder gets close:

The formula suggests a 12x10x106mm steel tool would vibrate at 864Hz, which is delightfully close to its actual size, 12x10x100. However, I don't believe it! Unfortunately the tool is clamped to the tool-post with three bolts, and its overhang is only 17mm. I think I'm measuring the vibration of the tool, tool-post, compound slide and saddle. Also, because the tool is rubbing, the vibration may be more forced than free. Not sure what part is played by the tool rubbing on a 33mm diameter shoulder rotating at 21 revolutions per second. Is my insert-holder & tool-post vibrating in tune like a violin string, or is it just responding to a frequency generated by the spindle and tool rubbing at a surface speed of 2.5m/s? I've no idea!

Dave

Edited By SillyOldDuffer on 27/05/2020 14:57:31

Digitising data and the FFT opens the door on applying mathematical filters to data. In this next example I took two samples. The first is of my lathe running at 1260rpm without doing anything useful. The second is the same settings but with the saddle engaged to take a 0.2mm deep cut out of a 38mm diameter steel pipe.

The idea is to extract vibration due to just spinning from vibration due to spinning AND cutting. The subtraction should highlight vibration due to cutting while hiding vibration due to normal running.

So two samples are taken, trimmed to equal length, normalised, and both are analysed by FFT to produce a pair of frequency spectra. Then the difference of the two is taken, and the random noise filtered out by ignoring any frequency counts below a convenient level. What remains is vibration due to cutting.

Three graphs:

The Difference graph shows 7 frequency spikes appear whilst cutting. The good news is they are all small compared with ordinary running : it suggests my lathe doesn't have a vibration problem at 1260 rpm whilst cutting steel at feed-rate 0.28mm per revolution. I've no idea why my test combination of gears, belts and cutting conditions produces these 7 frequencies.

Dave

Edited By SillyOldDuffer on 27/05/2020 16:30:35

I have now! I've switched to a RaspberryPi3B, which is vibration free – no disc or fan!

The breadboarded device at right is an MPU6050 6-axis Accelerometer and Gyroscope Module. It connects to the Raspberry's GPIO pins. Quite easy to use. There are two outputs,

• binary frames sent serial at 115200 baud which can be converted to USB with an adaptor or connected directly to the RX pin on an Arduino or Raspberry UART. This data is integrated on the module by a digital motion processor, ie the two sensors are corrected relative to each other by black magic.
• The module also allows raw sensor data to be read directly over I2C.

The module's DMP continuously sends acceleration, spin rate and attitude data, all in x,y & z dimensions. And temperature. Conceptually the module's accelerometer can detect lathe vibration in three planes, to answer:

1. Is lathe vibration cause for concern, and in which planes is it vibrating?
2. At what frequencies is the lathe vibrating?

No problem getting the Arduino to work, but I got into trouble by writing Python3 on the Raspberry to decode the binary stream. After several tantrums and false clues, the answer turned out to be easy. Python's integers aren't directly compatible with signed 16 bit shorts. Fortunately Python's ctypes module supports the binary sent by the MPU6050.

That sorted out, I did a few trial recordings expecting great results. Nope! Either my lathe doesn't vibrate, or more likely it's not vibrating enough for the module to detect it. Another cause for concern is the relatively low sample rate. More research needed, but looks like I've bought the wrong accelerometer.

There is a Plan B. Anticipating trouble I ordered a Keyes 801S Vibration Sensor at the same time. Although much simpler than the MPU6050, I'm hoping it will be more sensitive. Not betting the farm on it though – I couldn't find a detailed specification.

The advantage of hosting on a RaspberryPi is they run headless, on a battery if necessary, can store large logfiles, could be used to do the number crunching, and the logs (or graphics) can be accessed over wifi from Apple, Windows or Linux.

In the prototype the unboxed Raspberry and sensor are powered up resting on the lathe's headstock and then the Python program is started from a remote terminal. Logging to file is started and stopped at the lathe by grounding the green wire. Each start opens a new logfile, so many recordings can be done per session. If the sensor can be made to produce meaningful data, the computer and sensor would be boxed up and provided with push-button controls.

Dave