It didn't take long for me to become unhappy with the design of my anti-backlash mod. Due to the large amount of friction, I became concerned about excess wear of the lead screw. A lot of nonuniform wear could cause problems when traversing to the extremes of the table. So I started working on a scheme similar to the approach Sherline took on their CNC mill. Their approach uses an external feed screw nut that is snugged up against the table to remove backlash. To keep the nut in place, its outer perimeter has a rather coarse knurl. A thick washer, also knurled on its outer perimeter, engages the external nut. The external nut is turned via the washer until the backlash is reduced to a low value (while keeping the drag relatively low), then the washer is fixed in place with a bolt thru its center.
Below you can see my version of this:
The round piece is the external nut (fabricated from a feed screw nut I bought from Little Machine Shop). I drilled a 1/16" hole in the nut, to engage a wire. The bracket is bolted to the end of the X-axis table. The slotted piece holds a 1/16" piece of piano wire that was bent to fit into the nut, and is fixed in place with a standoff/bolt combination.
Here's a photo of the installed pieces:
In use, the bolt is loosened so the nut can be rotated clockwise in order to remove any backlash, then tightened. Since the only force the standoff, slotted piece and wire experience is the frictional torque between the nut and feed screw, they don't need to be very heavy-duty.
With this setup I was able to reduce the uncontrolled table "slop" to about .001", and the mechanical turns dial vs. DRO indicate I have about .002-.003" of backlash. Before, there was about .005" of slop and about .010" of backlash.
The only thing I would change at this point would be to replace the Philips-style screw with an socket head screw. Right now, to adjust the backlash I have to remove the feed screw bracket to gain access with a screwdriver.
Items, ideas, works-in-progress in a wide variety of interests. Includes mods and machining on my mini-lathe and mini-mill, analog electronics, computers and microcontrollers and whatever else strikes my fancy.
Tuesday, January 3, 2017
Monday, January 2, 2017
Knife sharpener geometry -- spreadsheet
I have created a spreadsheet to illustrate the geometry I described in my previous post on the subject. It can be found at: knife geometry.xls.
Variables to play with are the radius of the arm (actually, the distance from the pivot point to the knife holder), length of the knife and the rotation angle of the knife. If the radius is changed you will need to figure out the height of the pivot above the blade, to give you the desired bevel angle.
The spreadsheet has some warts -- some of the parameters have to be entered in several places. To help figure out what goes where, the spreadsheet parameters are as follows:
Arm radius = 18"
Length of knife blade = 8"
Knife is rotated 12.75 degrees.
To determine the error in bevel angle halfway down the blade, just change the value in cell I50. Right now it is set to show what the error is at the tip of the blade. Changing it to 4 inches will show what the error is at the halfway point (in cell B46).
FYI, the angle calculations use the dot product of two normalized vectors. If you take the dot product of two vectors whose magnitude is 1.0, the result is the cosine of the angle between the vectors. Vectors can be normalized by dividing each component by the magnitude of the vector, which is given by: sqrt(x^2 + y^2 + z^2), where x, y and z are the components of the vector in 3 dimensional space.
Dot products are very useful beasts, having a wide range of applications, from calculating the Fourier Transform to computer generated graphics.
Variables to play with are the radius of the arm (actually, the distance from the pivot point to the knife holder), length of the knife and the rotation angle of the knife. If the radius is changed you will need to figure out the height of the pivot above the blade, to give you the desired bevel angle.
The spreadsheet has some warts -- some of the parameters have to be entered in several places. To help figure out what goes where, the spreadsheet parameters are as follows:
Arm radius = 18"
Length of knife blade = 8"
Knife is rotated 12.75 degrees.
To determine the error in bevel angle halfway down the blade, just change the value in cell I50. Right now it is set to show what the error is at the tip of the blade. Changing it to 4 inches will show what the error is at the halfway point (in cell B46).
FYI, the angle calculations use the dot product of two normalized vectors. If you take the dot product of two vectors whose magnitude is 1.0, the result is the cosine of the angle between the vectors. Vectors can be normalized by dividing each component by the magnitude of the vector, which is given by: sqrt(x^2 + y^2 + z^2), where x, y and z are the components of the vector in 3 dimensional space.
Dot products are very useful beasts, having a wide range of applications, from calculating the Fourier Transform to computer generated graphics.
Sunday, January 1, 2017
Knife sharpening fixture
This entry contains some preliminary work I've done to build a knife sharpening fixture. No photos as yet, but there probably will be some in a future post. This time I'm just outlining the geometry of the fixture, variations in the bevel angle along the blade due to the geometry, and approaches to minimize the variations.
Below is a simple figure showing the basic fixture from the side:
Below is a simple figure showing the basic fixture from the side:
The vertical mast has a pivot (the circle) whose height can be adjusted. The line passing through the pivot depicts a rod, whose opposite end has a sharpening stone attached to it (the green line). The knife is shown in magenta. Hardware for holding the knife is not shown. The whole thing is assembled on a base, shown by the thick horizontal black line.
The basic idea is as follows. The pivot is above the plane of the knife by a distance dictated by the desired bevel angle and distance between the mast and knife. We can calculate the bevel angle using this: tan(theta) = H/L, where theta is the desired angle, H is the height of the pivot above the knife, and L is the distance from the mast to the edge of the knife. If we know theta and L, then H = L*tan(theta). Caution: many spreadsheets assume radians, not degrees, are the argument to trig functions. To convert degrees to radians, remember that 2*pi radians = 360 degrees. (2*pi/360) * degrees gives you the radians.
There is an interesting aspect of this. My online searching revealed that most everyone seems to be building fixtures that create a specific half-angle -- not the full angle between the two sides of the bevel. So, if you're sharpening a knife to a "20 degree bevel", the angle between the two sides of the bevel is twice that -- 40 degrees. Not that it matters, it's just different relative to the usage found in general machining practice.
Anyway, back to the fixture. While it might seem to ensure you are sharpening your knife to a specific bevel, that is incorrect. Take a look at the diagram below.
The diagram shows the fixture looking down from the top. The magenta rectangle is the knife and the thin black lines show the position of the rod (plus sharpening stone) over two positions on the knife. Observation tells us that the bottom line is the shortest line and the top line is longer. The difference depends on the size of the knife. This variation in distance causes a variation in the effective bevel angle that will be ground into the knife. How much of a difference are we talking about here?
Let's do some calculations based on a fixture design I found on the web. In that design, the shortest distance was set to 10 inches. Probably to keep the fixture small and easily transported. If we want a 20 degree bevel, trig tells us that the pivot point must be 3.65 inches above the knife blade. If we are sharpening an 8" chef's knife, the tip of the knife is further away from the pivot, and as a result the bevel angle is reduced to 15.9 degrees! Ouch.
How can we improve this situation? The easiest approach is to increase the distance between the pivot and knife. Let's increase the distance to 18 inches. We have to raise the pivot point to 6.55 inches to get a bevel angle of 20 degrees. This change reduces the variation in bevel angle to 1.6 degrees.
But we can do better than this if we want. Since the change in bevel angle is due to the increased distance, let's rotate the tip of the knife toward the pivot point to reduce the distance. It turns out that a rotation of 12.8 degrees will reduce the error to close to zero. Nice, huh? Not so fast. What about the bevel angle at the midpoint of the knife? With this rotation, the error is .4 degrees. Still, not too bad. Zero rotation gives us a MINUS error of about the same magnitude, so that's a wash.
Figuring out the optimum rotation angle of the knife may seem like a mysterious process. But it's not, and actually is easy to set up. In the case of our 18"-long fixture, let's use a very large compass to draw a circle around the support mast for the pivot. The circle will have an 18" radius. Now, loosely install your knife in the holder and rotate the tip so it just intersects the 18" circle you just drew. That's the angle you need, because the circle denotes a constant 18" distance from the pivot! Tighten the holder down and start sharpening, with the assurance that the variation in your bevel angle along the length of your 8" knife is no more than .4 degrees. Shorter knives will have less variation. If you are sharpening 10-inchers or longer, maybe you should think about an even bigger fixture, maybe with a baseline of 20 inches or more. Even so, it still will have a footprint less than 2 feet deep.
The downside of a setup that requires you to rotate the knife has some design complications you may not want to bother with. For one, you probably need to have a knife holder than can rotate, too. Then be easily locked into position without engaging in an excessively-complicated procedure. And for longer blades you probably want some sort of support partway down the blade to keep the blade from flexing (or popping the knife out of the holder). But to accommodate different blade lengths, the support has to be movable -- the knife rotation angle will change. Or you will need to fabricate custom holders for each size of knife you have. Mmm, more tradeoffs. But that's the fun of design -- addressing problems like this in as elegant a manner as practical. No, I didn't say "as possible" -- that's not engineering. The art and fun of engineering is finding the balance between performance and practicality.
Saturday, December 31, 2016
Was Julia Child really left handed?
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.
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.
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:
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.
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.
Subscribe to:
Posts (Atom)
