My wife and I were watching a very old Julia Child cooking episode on YouTube when we noticed something interesting. OK, I noticed -- she was oblivious.
This was an episode where Julia was extolling the uses of eggs in things like chocolate mousse. The video alternated between face-on views and top-down, showing the whisking action when Julia was beating egg yolks and stuff like that on the stove. I noticed the top views showed Julia using her left hand beating the eggs and whisking stuff etc. But the face-on views showed her using her right hand. Finally, I saw a top down view that showed several pots on the stove, and the arrangement was reversed between the top-down view and face-on view.
So, here's an interesting observation. Maybe it's been noted before, but a quick internet search did not reveal any confusion about Julia's handed-ness. I think the top-down views were done using a mirror, so the viewpoint was reversed. Perhaps today's directors are more concerned about consistency from shot to shot so that doesn't happen now....maybe.
I would be interested to know if anyone else has noticed this in the old Julia Child episodes.
Saturday, December 31, 2016
Thursday, December 22, 2016
Repeating decimals and encoding messages
I have another math nurd post.
It has a loose relationship with a branch of mathematics called number theory, and a close relationship to a sleepless night.
I was (for no obvious reason) thinking about repeating decimal numbers that are the result of dividing one number by another. A good example: .33333.... = 1/3.
I started wondering if would be possible to define two numbers A and B to generate any arbitrary sequence of repeating decimal numbers when calculating A/B. Oh yes, those dark winter nights! For a triplet of repeating digits, my initial mental math went like this:
A/B = .WXYWXYWXY.....
where W,X and Y are numbers between 0 and 9
Multiply A/B by 1000 and we get: 1000*A/B = WXY.WXYWXYWXY....
The value behind the decimal, clearly, is the same as A/B so we can write:
1000*A/B = WXY*A/B. If we divide both sides by A/B we get: 1000 = WXY. Clearly, there is no sequence of 3 digits that can equal 1000 (999 is the closest we can get). So it would appear that there is no solution for this.
Not so. Let's say WXY = 123. Now set A = 123 and B = 999. Get out the old 4-banger calculator and what do we see? 123/999 = 0.123123....
So what is the problem here? Unfortunately, simple math (remember I mentioned it was a late night). The real equation for this relationship is as follows: 1000*A/B = WXY + A/B. Where WXY really equals W*10^2 + X*10^1 + Y*10^0
If we go back to setting WXY = 123, we get: 1000*A/B = 123 +A/B, or 999A/B=123. I.E., 999A = 123B, or A/B = 123/999. Do the division again, and you get: .123123....
A straightforward generalization tells us that we can generate any arbitrary repeating-decimal number by multiplying the sequence of numbers by the power of 10 equal to the length of the sequence and dividing it by 10^K -1, where K is the length of the sequence.
An interesting possibility raises itself in this discussion of rudimentary numerical analysis. Suppose we encode the alphabet by setting A = 01, B = 02....Z = 26. If you have a message you want to send securely, encode it into a string of tuples (2 digits each) and treat the whole thing as your repeating rational number. Unfortunately, not too hard to decyper, right? Well, now multiply the W-wide number (equal to 2*the number of characters in your message) by another number, large enough to ensure some carries between each tuple. NOW we have a more interesting thing to decode, because the resulting tuples depend on each other. It becomes a context-dependent code. The keys to the code are the multiplier....and the length of the message. In today's age, the two could be sent separately without too much trouble so time-sensitive information (which would take some time to decode) would be relatively secure. Attempts to crack the code would be complicated by the fact that the encoded message string is unique due to the context dependency.
Suppose we choose the multiplier to be 11. This is an interesting example because it is equivalent to shifting the original code over by one, and adding the result to the original code. It would completely alter the cypher.
Is this completely original? Hah --- close to a zero chance of that. But it is an interesting illustration of how easily a simple encoding scheme could be turned into a nontrivial decyphering problem, except for government level expertise. Also, due to the fact that certain letter sequences occur pretty often, the encoding scheme would be susceptible to statistical analysis -- if long enough.
Relatively simple obsfucation techniques like reversing the digit sequence would still yield to this type of analysis, if the analysis is thorough enough. Possibilities are endless though -- consider encoding some well-known text in the same fashion and adding its digit sequence to the message. This is an example of the use of a code book, in addition to the mathematical encoding. Without knowledge of the code book (and where the code string begins), things get difficult in a big hurry. The code book string itself could be mathematically obsfucated by using yet a different multiplier. And maybe reversed (or not) as well. Ouch!
It has a loose relationship with a branch of mathematics called number theory, and a close relationship to a sleepless night.
I was (for no obvious reason) thinking about repeating decimal numbers that are the result of dividing one number by another. A good example: .33333.... = 1/3.
I started wondering if would be possible to define two numbers A and B to generate any arbitrary sequence of repeating decimal numbers when calculating A/B. Oh yes, those dark winter nights! For a triplet of repeating digits, my initial mental math went like this:
A/B = .WXYWXYWXY.....
where W,X and Y are numbers between 0 and 9
Multiply A/B by 1000 and we get: 1000*A/B = WXY.WXYWXYWXY....
The value behind the decimal, clearly, is the same as A/B so we can write:
1000*A/B = WXY*A/B. If we divide both sides by A/B we get: 1000 = WXY. Clearly, there is no sequence of 3 digits that can equal 1000 (999 is the closest we can get). So it would appear that there is no solution for this.
Not so. Let's say WXY = 123. Now set A = 123 and B = 999. Get out the old 4-banger calculator and what do we see? 123/999 = 0.123123....
So what is the problem here? Unfortunately, simple math (remember I mentioned it was a late night). The real equation for this relationship is as follows: 1000*A/B = WXY + A/B. Where WXY really equals W*10^2 + X*10^1 + Y*10^0
If we go back to setting WXY = 123, we get: 1000*A/B = 123 +A/B, or 999A/B=123. I.E., 999A = 123B, or A/B = 123/999. Do the division again, and you get: .123123....
A straightforward generalization tells us that we can generate any arbitrary repeating-decimal number by multiplying the sequence of numbers by the power of 10 equal to the length of the sequence and dividing it by 10^K -1, where K is the length of the sequence.
An interesting possibility raises itself in this discussion of rudimentary numerical analysis. Suppose we encode the alphabet by setting A = 01, B = 02....Z = 26. If you have a message you want to send securely, encode it into a string of tuples (2 digits each) and treat the whole thing as your repeating rational number. Unfortunately, not too hard to decyper, right? Well, now multiply the W-wide number (equal to 2*the number of characters in your message) by another number, large enough to ensure some carries between each tuple. NOW we have a more interesting thing to decode, because the resulting tuples depend on each other. It becomes a context-dependent code. The keys to the code are the multiplier....and the length of the message. In today's age, the two could be sent separately without too much trouble so time-sensitive information (which would take some time to decode) would be relatively secure. Attempts to crack the code would be complicated by the fact that the encoded message string is unique due to the context dependency.
Suppose we choose the multiplier to be 11. This is an interesting example because it is equivalent to shifting the original code over by one, and adding the result to the original code. It would completely alter the cypher.
Is this completely original? Hah --- close to a zero chance of that. But it is an interesting illustration of how easily a simple encoding scheme could be turned into a nontrivial decyphering problem, except for government level expertise. Also, due to the fact that certain letter sequences occur pretty often, the encoding scheme would be susceptible to statistical analysis -- if long enough.
Relatively simple obsfucation techniques like reversing the digit sequence would still yield to this type of analysis, if the analysis is thorough enough. Possibilities are endless though -- consider encoding some well-known text in the same fashion and adding its digit sequence to the message. This is an example of the use of a code book, in addition to the mathematical encoding. Without knowledge of the code book (and where the code string begins), things get difficult in a big hurry. The code book string itself could be mathematically obsfucated by using yet a different multiplier. And maybe reversed (or not) as well. Ouch!
Thursday, December 15, 2016
A different sort of anti-backlash scheme for an X2 mini mill, and serendipity
Over the last year or so I've been (slowly) working on testing a different type of anti-backlash system for my SX2 mini mill. This approach does not use traditional spring-loaded nuts, split nuts or heat-formed acetal nuts.
The original approach involved two nuts -- the standard, as-installed one, that is installed into the X or Y axis table, and a second "traveling" nut. The traveling nut is constrained inside a cage that is bolted to the table. In use, the feed screw is turned and the traveling nut is carried to one side or the other of the cage. Once it fetches up against the cage, the slop or backlash of the system is removed.
I tested this idea using some all-thread, two nuts and two aluminum angle brackets, and it worked. I did find that the system was sensitive to misalignment, to the point that a little misalignment would cause the traveling nut to "freeze up", making it impossible to turn the feed screw (in that case, the all-thread).
Here's a photo of my test setup:
You can see that I used the table of my mill as the test bed for this.
So I proceeded to the next step, making a bracket for the traveling nut cage, modifying a nut to fit in the bracket, and drilling/tapping two 8mm holes to mount the bracket on the right side of the saddle (I was going to mod the X axis first, because that looked to be a lot easier than the Y axis).
The final results are shown here:
The bracket is on top and the traveling nut is between the two 8mm bolts. The bracket has a slot to accommodate the traveling nut. In use, the idea was to insert the nut in the slot and then advance the bracket down the feed screw until it could be bolted to the saddle.
However, when I did this I found that the traveling nut would seize up once the feed screw had been turned a revolution or two. I thought the problem was a combination of the rather tight fit of the nut on the feed screw, and machining tolerances of the bracket (i.e., my so-so machining skills). I tried shimming but there was no improvement.
Here is where the serendipity comes into play. I started thinking about a variation on this, similar to an anti-backlash scheme I has seen on a Sherline CNC-ready mill. They have a nut that is on the exterior of the table, held in place by what appears to be a fine-tooth gear. The gear is loosened enough to rotate the nut so it snugs up against the table, then tightened.
So I took a second bit of my modified nut (I had cut it into two pieces) and fed it up against the exterior of my bracket. I had removed the traveling nut at this point. The idea was to use the bracket to implement something like the Sherline approach, and I needed to know the orientation of the nut when it fetched up against the bracket. But to my surprise, when I brought the nut up to the bracket, the feed screw did not seize up. And the backlash disappeared! Well, this was interesting. More interestingly, when I used my original traveling nut, it DID seize up. Whoa. That seemed to eliminate tolerance variations on the exterior surface of the bracket.
So I took a closer look at my two nuts (please, no jokes here ... alright, I can't keep you from going there). The main difference was a ridge left on the edge of the second nut. Maybe it was acting as a little buffer to ease the mechanics of the system. To test this hypothesis, I sanded the end surfaces of the second nut smooth (I had already done this on my original traveling nut) and re-installed it. It now behaved the same, locking up with a turn or so of the feed screw.
With the "buffer" hypothesis in mind, I fabricated a rubber gasket out of some rubber sheet, maybe 1/16" thick. The gasket ID was the same as the feed screw OD, and the gasket OD matched the external nut. Bracket installed, followed by rubber gasket and nut:
And this works! The nut fetches up against the gasket with enough force to prevent it from backing out when the feed screw motion is reversed, and the backlash goes to zero.
Now, I don't know if this nice combination of items and effects will be robust or not -- it's possible that lube grease from the feed screw will find its way between the gasket and external nut so it will loosen up. If so, I can use a scheme akin to the Sherline approach to fix the nut in place. I'm thinking of a hole drilled in the nut, pin installed to match a little arm that engages the pin on one side, slotted on the other (for adjustment) and fixed in place with a screw that eventually screws into the bracket. This approach won't apply any axial force to the nut/feedscrew combo, just keep things from rotating.
CONCLUSION:
Don't give up! If something doesn't work out as you expected, analyze the setup, experiment, make an hypothesis and test it. Repeat as needed. Don't forget to gratefully accept what lady Serendip gives you.
The original approach involved two nuts -- the standard, as-installed one, that is installed into the X or Y axis table, and a second "traveling" nut. The traveling nut is constrained inside a cage that is bolted to the table. In use, the feed screw is turned and the traveling nut is carried to one side or the other of the cage. Once it fetches up against the cage, the slop or backlash of the system is removed.
I tested this idea using some all-thread, two nuts and two aluminum angle brackets, and it worked. I did find that the system was sensitive to misalignment, to the point that a little misalignment would cause the traveling nut to "freeze up", making it impossible to turn the feed screw (in that case, the all-thread).
Here's a photo of my test setup:
You can see that I used the table of my mill as the test bed for this.
So I proceeded to the next step, making a bracket for the traveling nut cage, modifying a nut to fit in the bracket, and drilling/tapping two 8mm holes to mount the bracket on the right side of the saddle (I was going to mod the X axis first, because that looked to be a lot easier than the Y axis).
The final results are shown here:
However, when I did this I found that the traveling nut would seize up once the feed screw had been turned a revolution or two. I thought the problem was a combination of the rather tight fit of the nut on the feed screw, and machining tolerances of the bracket (i.e., my so-so machining skills). I tried shimming but there was no improvement.
Here is where the serendipity comes into play. I started thinking about a variation on this, similar to an anti-backlash scheme I has seen on a Sherline CNC-ready mill. They have a nut that is on the exterior of the table, held in place by what appears to be a fine-tooth gear. The gear is loosened enough to rotate the nut so it snugs up against the table, then tightened.
So I took a second bit of my modified nut (I had cut it into two pieces) and fed it up against the exterior of my bracket. I had removed the traveling nut at this point. The idea was to use the bracket to implement something like the Sherline approach, and I needed to know the orientation of the nut when it fetched up against the bracket. But to my surprise, when I brought the nut up to the bracket, the feed screw did not seize up. And the backlash disappeared! Well, this was interesting. More interestingly, when I used my original traveling nut, it DID seize up. Whoa. That seemed to eliminate tolerance variations on the exterior surface of the bracket.
So I took a closer look at my two nuts (please, no jokes here ... alright, I can't keep you from going there). The main difference was a ridge left on the edge of the second nut. Maybe it was acting as a little buffer to ease the mechanics of the system. To test this hypothesis, I sanded the end surfaces of the second nut smooth (I had already done this on my original traveling nut) and re-installed it. It now behaved the same, locking up with a turn or so of the feed screw.
With the "buffer" hypothesis in mind, I fabricated a rubber gasket out of some rubber sheet, maybe 1/16" thick. The gasket ID was the same as the feed screw OD, and the gasket OD matched the external nut. Bracket installed, followed by rubber gasket and nut:
Now, I don't know if this nice combination of items and effects will be robust or not -- it's possible that lube grease from the feed screw will find its way between the gasket and external nut so it will loosen up. If so, I can use a scheme akin to the Sherline approach to fix the nut in place. I'm thinking of a hole drilled in the nut, pin installed to match a little arm that engages the pin on one side, slotted on the other (for adjustment) and fixed in place with a screw that eventually screws into the bracket. This approach won't apply any axial force to the nut/feedscrew combo, just keep things from rotating.
CONCLUSION:
Don't give up! If something doesn't work out as you expected, analyze the setup, experiment, make an hypothesis and test it. Repeat as needed. Don't forget to gratefully accept what lady Serendip gives you.
Monday, March 14, 2016
Scraper Tool Update
Cutter Radius Matters
I've been using my newly-shaped/sharpened carbide scrapers on my not-so-good surface gauge and noticed something. I have three scrapers, ranging in width from 3/4" down to 1/2". I made three different brass inserts for my sharpening fixture with radii decreasing from 4-1/2" down to 1-1/2". The thought was that the smaller scrapers would be good for more-detailed work & would work better with a smaller radius on the cutting edge.
Problem was, the 3/4" tool with the 4.5" radius on the end was very hard to use. It would skid unless I used a very high angle, and even then it was difficult to control. The problem was not caused by a dull scraper because I re-honed it with my 14,000 grit lapping wheel and did not find any improvement. I then tried the 3/8" scraper and observed that it was much easier to use, so decided to make another brass insert with a smaller 3-3/8" radius. The reason I chose that radius is because it's the same as the Dapra "standard" carbide insert. This was a good decision -- the scraper now works much better. The width of the cut is still pretty wide so it is good for rough work.
It is possible that the 4.5" radius brought too much material into play, making it difficult to get enough power into the scraping stroke to be effective. A smaller radius (& therefore smaller work volume) would reduce the power requirement. In terms of HP needed for milling/lathe work, there's a definite relationship between horsepower and material removal rate -- and the HP requirement goes up considerably as the material removal rate increases. People power can't compete with machine power, so I guess the lesson here is that scraping should be a finishing job not a forming job.
I've been using my newly-shaped/sharpened carbide scrapers on my not-so-good surface gauge and noticed something. I have three scrapers, ranging in width from 3/4" down to 1/2". I made three different brass inserts for my sharpening fixture with radii decreasing from 4-1/2" down to 1-1/2". The thought was that the smaller scrapers would be good for more-detailed work & would work better with a smaller radius on the cutting edge.
Problem was, the 3/4" tool with the 4.5" radius on the end was very hard to use. It would skid unless I used a very high angle, and even then it was difficult to control. The problem was not caused by a dull scraper because I re-honed it with my 14,000 grit lapping wheel and did not find any improvement. I then tried the 3/8" scraper and observed that it was much easier to use, so decided to make another brass insert with a smaller 3-3/8" radius. The reason I chose that radius is because it's the same as the Dapra "standard" carbide insert. This was a good decision -- the scraper now works much better. The width of the cut is still pretty wide so it is good for rough work.
It is possible that the 4.5" radius brought too much material into play, making it difficult to get enough power into the scraping stroke to be effective. A smaller radius (& therefore smaller work volume) would reduce the power requirement. In terms of HP needed for milling/lathe work, there's a definite relationship between horsepower and material removal rate -- and the HP requirement goes up considerably as the material removal rate increases. People power can't compete with machine power, so I guess the lesson here is that scraping should be a finishing job not a forming job.
Monday, February 15, 2016
Stepper Motors -- a back story to my scraper-sharpener project.
While working on my "low speed motor" side of the project, I encountered a problem. When I turned the power supply on, often as not the stepper wouldn't spin -- it would just buzz loudly. This happened for several different steppers, including a new one. So what was going on?
I did figure out that I could get the stepper to turn by giving the diamond disk a good spin with my hand, but wasn't sure why until I read an article written by some college students who designed and built their own stepper motor controller. The controller included speed and acceleration control. They mentioned that a stepper has limitations with regard to acceleration. If requested to accelerate too quickly, the stepper can't follow so it will lose steps.
I think my simple oscillator circuit is the culprit. It immediately starts oscillating, so the stepper is requested to basically instantaneously accelerate. That's not going to happen so it exhibits the ultimate in lost steps -- it loses them ALL and just turns into a noisemaker.
To solve this I am working on a modification to my 555 oscillator that will produce a ramped output frequency. My first attempt using a capacitor on the control pin didn't pan out so back to the drawing board.
I suppose I could replace my oscillator with a microcontroller but that just seems like overkill. But then I could claim I have the beginnings of a CNC sharpening setup <g>.
While working on my "low speed motor" side of the project, I encountered a problem. When I turned the power supply on, often as not the stepper wouldn't spin -- it would just buzz loudly. This happened for several different steppers, including a new one. So what was going on?
I did figure out that I could get the stepper to turn by giving the diamond disk a good spin with my hand, but wasn't sure why until I read an article written by some college students who designed and built their own stepper motor controller. The controller included speed and acceleration control. They mentioned that a stepper has limitations with regard to acceleration. If requested to accelerate too quickly, the stepper can't follow so it will lose steps.
I think my simple oscillator circuit is the culprit. It immediately starts oscillating, so the stepper is requested to basically instantaneously accelerate. That's not going to happen so it exhibits the ultimate in lost steps -- it loses them ALL and just turns into a noisemaker.
To solve this I am working on a modification to my 555 oscillator that will produce a ramped output frequency. My first attempt using a capacitor on the control pin didn't pan out so back to the drawing board.
I suppose I could replace my oscillator with a microcontroller but that just seems like overkill. But then I could claim I have the beginnings of a CNC sharpening setup <g>.
Sunday, February 14, 2016
Making the tools to make the tools
Recently I've started learning how to scrape metal. The purpose: improve the fit of machine tool surfaces, like milling machine dovetails. Practically speaking, I want to improve the inexpensive tabletop lathe and milling machines I currently own. They are a good illustration of "you get what you pay for". Although I do have to say that I've made useful stuff on them, doing no improvements other than adjusting them. But as I've become a little more proficient on them, some of the shortcomings have started to annoy me. So began an unexpectedly long (still in progress) sequence of getting tools to improve other tools, only to discover that they're not so great, either.
So I found my self in a sort of bootstrap mode. The starting point was a granite surface plate and what turned out to be a very non-flat surface gauge. So, scraping had to start there before I could even begin to work on my mill. But in fact, I had to go back even further. First, about scraping.
The scraping process involves marking the surface of the item you want to improve. A very flat granite surface plate is loaded with blue pigment, and the work is rubbed over the surface plate. The high spots on the work are marked. They are removed using a sharp scraper. Repeat. A gross oversimplification, but that's basically what is done. At the end, you should have a very flat surface. But not necessarily one that is parallel or perpendicular to anything else you care about. To achieve those other things, you need a good dial indicator and a surface gauge to hold it. I got a decent dial indicator, but the cheap surface gauge I bought quickly revealed itself to be insufficient. It rocked when placed on the surface plate, to the tune of about .006" -- impossibly bad for the kind of standards that scraping can achieve. So my first task became clear: fix the surface gauge. Except it really wasn't the first step, as it turned out.
Through a number of false starts I arrived at the _real_ first step I needed to take: build a setup to sharpen tungsten carbide to make proper scrapers. The photos below show what I came up with. And it works.
Photo above shows the diamond lap (charged w14,000 grit diamond), tool support and tool holder. The scraper is held in place with a set screw that is in one of the steel blocks attached to the holder.
I got the diamond disks from a lapidary supply company. I got 150, 320, 600, 1200 and 3000 grit disks, and 14,000 grit diamond powder. I used the back of one of the coarse disks and charged it with the 14,0000 grit. A disposable aluminum loaf pan is used to hold water -- the disk rotates thru the water for lubrication. The 14,000 grit disk was used dry.
Closeup of holder and 3/4" carbide scraper. The left end of the holder is designed to accept brass inserts with different radii. The support has a fence on the end closest to the diamond wheel (shown at the top of the photo). The brass insert is pushed against the fence, so the end of the scraper describes an arc. This is how I ground a known radius on the scraper.
A photo showing my "low speed motor". It's a stepper motor with a driver. The step pulses are generated with a 555 timer-oscillator.
This is a slow-speed setup so there is little chance of heat buildup. The idea was to have a setup that can also be used to touch up HSS tool bits, and maybe the odd knife or two.
This setup worked very well. The scraper now removes metal pretty effortlessly. I'll sharpen my smaller carbide bits with smaller radii so I can use them for the fine work.
Recently I've started learning how to scrape metal. The purpose: improve the fit of machine tool surfaces, like milling machine dovetails. Practically speaking, I want to improve the inexpensive tabletop lathe and milling machines I currently own. They are a good illustration of "you get what you pay for". Although I do have to say that I've made useful stuff on them, doing no improvements other than adjusting them. But as I've become a little more proficient on them, some of the shortcomings have started to annoy me. So began an unexpectedly long (still in progress) sequence of getting tools to improve other tools, only to discover that they're not so great, either.
So I found my self in a sort of bootstrap mode. The starting point was a granite surface plate and what turned out to be a very non-flat surface gauge. So, scraping had to start there before I could even begin to work on my mill. But in fact, I had to go back even further. First, about scraping.
The scraping process involves marking the surface of the item you want to improve. A very flat granite surface plate is loaded with blue pigment, and the work is rubbed over the surface plate. The high spots on the work are marked. They are removed using a sharp scraper. Repeat. A gross oversimplification, but that's basically what is done. At the end, you should have a very flat surface. But not necessarily one that is parallel or perpendicular to anything else you care about. To achieve those other things, you need a good dial indicator and a surface gauge to hold it. I got a decent dial indicator, but the cheap surface gauge I bought quickly revealed itself to be insufficient. It rocked when placed on the surface plate, to the tune of about .006" -- impossibly bad for the kind of standards that scraping can achieve. So my first task became clear: fix the surface gauge. Except it really wasn't the first step, as it turned out.
Through a number of false starts I arrived at the _real_ first step I needed to take: build a setup to sharpen tungsten carbide to make proper scrapers. The photos below show what I came up with. And it works.
I got the diamond disks from a lapidary supply company. I got 150, 320, 600, 1200 and 3000 grit disks, and 14,000 grit diamond powder. I used the back of one of the coarse disks and charged it with the 14,0000 grit. A disposable aluminum loaf pan is used to hold water -- the disk rotates thru the water for lubrication. The 14,000 grit disk was used dry.
This is a slow-speed setup so there is little chance of heat buildup. The idea was to have a setup that can also be used to touch up HSS tool bits, and maybe the odd knife or two.
This setup worked very well. The scraper now removes metal pretty effortlessly. I'll sharpen my smaller carbide bits with smaller radii so I can use them for the fine work.
Subscribe to:
Posts (Atom)