Vibrometer for CNC stiffness tuning

Stiffness is a top issue for the performance of CNC mills and lathes. Previously when the optical table CNC lathe was unable to cut steel, it was easy to find. The top slide had so little stiffness that it would visibly deform when pushed into a steel bar to cut. Also, when cutting, putting a finger across the two parts of the slide connected with a bearing, I could sense that the vibration was much stronger in one part than the other. Clearly the bearing was not stiff enough.

The replacement slide uses crossed roller bearings and works much better. However, the surface finish on steel bars is still not where I want it to be. However, the source of the vibrations is not clear enough to detect with feeling by hand. To get a better sense. I decided to use an accelerometer, the ADXL001 from analog devices:

http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL001.pdf

This is an analog device, so I just connected it to the analog input of a fast microcontroller. For this, I used a teensy 3.2. I soldered the sensor to a breakout board and glued the board to the micro.

This accelerometer is only sensitive in one axis, so I have to take 3 measurements, or get another two sensors in the future.

The code is rather simple to implement in Teensyduino:

elapsedMicros timeElapsed;

void setup()

{               

  Serial.begin(115200); // baud rate ignored because transmission goes over USB...

}

int val;

void loop()                    

{

  val = analogRead(0);

  Serial.print(val);

  Serial.print(" ");

  Serial.println(timeElapsed);

}

This sensor sports a very wide bandwidth of about 10 kHz. I don't have total confidence in the reliability of the data transmission, so I am adding a timecode every sample

On the output, I get data like this on the serial monitor:

512 2233997535

509 2233997563

507 2233997588

504 2233997615

509 2233997641

514 2233997669

so, a data sample about every 25 uS, or 40 kHz. Plenty fast.

Next, the data needs to be imported. To that end, the easiest thing to do is to acquire a few seconds of data on the serial port. I opened the serial monitor in the arduino environment. Waited a bit, and then copied the data from the window and saved it into a file, received.log

(stty raw; cat > received.log) < /dev/ttyACM0

Next, this data has to be processed and a powerful tool for that is the "MATLAB clone", Octave.

In octave,

>>  DATA = load("-ascii", "received.log");

>>  scatter(DATA(:,2),DATA(:,1))

shows the following, where I banged the board onto the table a few times:

Ok. Time to transfer the data to the frequency domain.

pkg load ltfat

DATA = load("-ascii", "received.log");

sgram(DATA(:,1))

So now I can look for the amount of vibration using the acceleration data and the excitation frequencies using the spectrogram.

I acquired data two times. And it looked like this both times. the cutting actually happened in the middle range and one can see the envelope broadening a little.

Both times the sensor signal was buried in the noise of the system. Even when filtering

https://tty1.net/blog/2009/filters-with-gnu-octave_en.html

the signal with a low pass filter to below 100 Hz

The sensor is specified for +-70G acceleration full scale. Clearly that is too much. I have to get a sensor with a smaller range.

So I got a ADXL335 accelerometer. This unit measures +-3g

The range is still much larger than optimal, but useful data can be had.

I did a test cut of several passes on a steel bolt. The surface finish is quite poor.

The positioning of the accelerometer was like this; I held it fast by pressing on top of the accelerometer with my finger during cutting.

So the x direction is the compound slide, the y direction is the table (along the spindle axis) and the z direction is floor to ceiling.

I soldered X to A1, Y to A2 and Z to A3 on the Teensy, and then used the following code to send the data on to the computer:

void loop()                    

{

  val1 = analogRead(1);

  val2 = analogRead(2);

  val3 = analogRead(3);

  Serial.print(val1);

  Serial.print(" ");

  Serial.print(val2);

  Serial.print(" ");

  Serial.print(val3);

  Serial.print(" ");

  Serial.println(timeElapsed);

}

So after importing the data to octave DATA(:,1) is X, DATA(:,2) is Y and DATA(:,3) is Z. DATA(:,4) is the time index

The scattergram for the x y and z directions look like this:

This is pretty interesting. The x direction, held on by the screw, nut and motor, has the least deviation. The Y direction, held on to by a ball screw and a motor that was undriven for this experiment seems most unstable. The Z axis is constantly vibrating regardless of cut.

lets look at the spectrograms, using these parameters:

sgram(DATA(:,1),'xres',1600,'yres',2400,'dynrange', 300)

And the spectrograms tell the same story...

Next, lets measure on the massive LRX rail to determine the movement of the table itself:

The x direction is almost limited by quantization, but the back and forth movement of the cutting tool can be seen. Again, the most vibration shows up in the y direction, but it seems independent of the cutting.

Interestingly enough, the cuts themselves have very little effect on vibration here, suggesting that the table is more stable than the cross slide. This is what one would expect, of course. I speculate that at least some of the y axis vibration is to blame on the y axis ballscrew/motor combination. The motor is not driven, so that the axis is only held by friction and the detent force of the motor magnets. Some movement could easily occur. Also. even though I cannot feel any backlash in the ballscrew, it does not have a double nut, so there could be some. Therefore, the first thing I am going to adjust is to connect the motor and hold it in place with power.

I did this, but it had little effect on cut quality. The motor was driven with enough current to assure no steps are lost, but since it is run

- in open loop

- at constant current

- at zero speed

any change in torque on the motor shaft will result in a change in shaft position. There is a nice piece on hackaday that illustrates the point: http://hackaday.com/2016/08/29/how-accurate-is-microstepping-really/

So, with a screw that has a smaller pitch, the corresponding torque on the motor shaft due to cutting forces is lowered. Thus, I replaced the ballscrew for this axis.

The new screw, a W1603MA-2Y-C3T from NSK has a lead of 2mm whereas the old one had a 5mm lead. so that should improve the stiffness by more than a factor of 2. I also used more substantial mounts. \

The Cnts/Inch in KmotionCNC have to be adjusted. The motor is a 200 step/rev stepper and so the z axis now has 636 steps/inch.

The situation improved:

Though it is maybe not visible by comparing to the previous picture, for the most part, I don't have vibration issues any more. What I see now is a stiffness problem that I recognize from running manual lathes in the past, the tool sometimes digs in deeper, then pops out to a different diameter later, only to dig in deeper again later.

From the x axis data alone, it seems clear that the top slide is at least partially to blame for the lack of stiffness. I will replace it next.